Postfix-3.1+ ebuilds do this: pkg_postinst() { [ "${EROOT}" == "/" ] && pkg_config ... } pkg_config() { # configure tls if use ssl ; then if "${EROOT}"usr/sbin/postfix tls all-default-client ; then elog "Configuring client side TLS settings" "${EROOT}"usr/sbin/postfix tls enable-client fi if "${EROOT}"usr/sbin/postfix tls all-default-server ; then elog "Configuring server side TLS settings" "${EROOT}"usr/sbin/postfix tls enable-server fi fi } This actively changes the config and may cause random breakage. Tying opportunistic-TLS to USE="ssl" is very unfortunate since one may wish to use SSL without opportunistic-TLS. I would strongly recommend only printing a message how to enable opportunistic-TLS and not actively interfering with user config.
(In reply to Patrick Lauer from comment #0) > This actively changes the config and may cause random breakage. How so? What's the breakage? > Tying opportunistic-TLS to USE="ssl" is very unfortunate since one may wish > to use SSL without opportunistic-TLS. I do not understand this statement. We only do opportunistic TLS if the TLS is not configured. Care to elaborate?
(In reply to Eray Aslan from comment #1) > (In reply to Patrick Lauer from comment #0) > > This actively changes the config and may cause random breakage. > > How so? What's the breakage? Our outgoing mail partially failed because some receiving servers didn't appreciate the change. It's not as harmless as a change as it looks like > > > Tying opportunistic-TLS to USE="ssl" is very unfortunate since one may wish > > to use SSL without opportunistic-TLS. > > I do not understand this statement. We only do opportunistic TLS if the TLS > is not configured. Care to elaborate? Yes, that's a bad idea. Only enable it when I ask for it to be enabled, otherwise there can be unexpected side-effects. And pkg_postinst actively changing the config (bypassing etc-update/dispatch-conf/...) is very naughty and shouldn't happen at all. So I'm not opposed to having it enabled in the default config (portage won't overwrite my locally modified config with it) or just printing a nice einfo "You may want to run these commands to enable features", but silently overwriting my handcrafted config is unexpected badness.
Jul 4 14:56:36 qa postfix/master[36617]: daemon started -- version 3.1.0, configuration /etc/postfix Jul 4 14:56:39 qa postfix/smtpd[36705]: connect from localhost[::1] Jul 4 14:56:39 qa postfix/smtpd[36705]: Anonymous TLS connection established from localhost[::1]: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits) Jul 4 14:56:39 qa postfix/smtpd[36705]: lost connection after STARTTLS from localhost[::1] Jul 4 14:56:39 qa postfix/smtpd[36705]: disconnect from localhost[::1] ehlo=1 starttls=1 commands=2 iow: it breaks all local stuff in the most awesome way possible
fd192b99315b9901124b1e26e34b87dc2f3b48eb disables this misfeature
(In reply to Patrick Lauer from comment #3) > Jul 4 14:56:39 qa postfix/smtpd[36705]: lost connection after STARTTLS from > localhost[::1] All that tells us that remote end dropped the connection which can be any number of gazillion reasons. Check the other end. Just step back and think about it. You are suggesting opportunistic tls in postfix is causing breakage. That's an extraordinary claim requiring extraordinary proof. Your argument is bogus and more drama than proof really. However, the other argument -don't change stuff in pkg_postinst- has merit and I will implement that in the next bump. (In reply to Patrick Lauer from comment #4) > fd192b99315b9901124b1e26e34b87dc2f3b48eb disables this misfeature Don't do that again before checking with me. In either case, consider working with people instead of against them.
