On Wednesday, December 19, 2018 01:27:42 PM Viktor Dukhovni wrote:
> On Wed, Dec 19, 2018 at 12:54:01PM -0500, micah anderson wrote:
> > >> This is easy enough to implement, the only complication is
> > >> that the documentation would need to explain the variable
> > >> default.
> > >> 
> > >>> If it is compiled without TLS, the default should be 'no'.
> > >> 
> > >> This is certainly possible.
> > > 
> > > It seems like the right thing to do. What needs to be done to move it
> > > forward?
> > 
> > Just wanted to "bump" this message, because it has been 1 year since the
> > original.
> 
> I did not see a clear consensus for or against a compile-time
> conditional default "may" for "smtp_tls_security_level":
> 
>     #ifdef USE_TLS
>     #define DEF_SMTP_TLS_LEVEL "may"
>     #else
>     #define DEF_SMTP_TLS_LEVEL ""
>     #endif
> 
> which would default to enable outbound opportunistic TLS whever TLS
> support is compiled in.  Since this last came up, we have:
> 
>       https://tools.ietf.org/html/rfc8314
> 
> which "obsoletes" cleartext for IMAP, POP and SUBMIT, but does not
> cover SMTP relay.  I am not opposed to changing the default, but
> also agree that setting defaults is something that can be done at
> package installation time.
> 
> So the real question is whether there is a non-trivial community
> of users who:
> 
>   * Have no explit "smtp_tls_security_level" setting in their main.cf
>     file.
> 
>   * Would not mind to see TLS turned on as a side-effect of a future
>     upgrade, but can't find the activation energy to do it explicitly.
> 
> Or, whether there are Postfix package maintainers in the same boat:
> too busy to add code to enable opportunistic TLS in the client at
> package install time, but would be happy to see it happen upstream.

I don't know why the previous Debian Postfix maintainer didn't enable it by 
default.  We have bug reports, including one from 2002, requesting it.

I'm definitely in favor of it being enabled by default, but, in addition to 
being busy, I've been trying to work towards less deviation from upstream in 
Debian vice more.  There is already plenty that is well baked into our 
ecosystem that would be hard to cleanly remove without causing upgrade 
problems.

Bottom line, I'd love to see it upstream and am unlikely to do it myself.

Scott K

Reply via email to