Interesting suggestions. The first one, logging how many users authenticate without TLS/SSL, is basically already there. Since the log messages already show both the authenticated user and the encryption status, you should be able to parse through them to find people who authenticated in the clear. That percentage is probably going to be pretty high, especially among Outlook users.
Implementing a filter to require TLS for authentication shouldn't be too hard. Lots of servers already do this -- they either don't advertise authentication until after TLS starts OR only advertise challenge/response authentication until after TLS starts. spamdyke could do that too, as well as stripping out (and blocking) cleartext authentication offered by a patched qmail. Implementing a filter to require TLS for every connection could be problematic. Remote servers (as opposed to mail clients) wouldn't understand the problem and a lot of mail would bounce. Even if a remote server is capable of doing TLS for outbound connections (many aren't), convincing the admins of those remote servers to make the change would be a nightmare (to say the least). If always-on encryption is really what you want, why not just use SMTPS? -- Sam Clippinger On Jan 27, 2012, at 2:13 PM, Eric Shubert wrote: > In the "Also ToDo" section of the TODO.txt document, there exists this item: > Add the ability to require TLS/SSL before authentication is allowed > (e.g. a "require-tls" value for "smtp-auth-level"). > > This is one that I requested some unknown time ago (I didn't even > remember requesting it yet, so I'm glad this list exists!). > > I've done a little more thinking about this and would like to modify the > suggestion a bit, and hopefully escalate its status to the Highest > Priorities list as well. > > First, I'd like there to be two options, one which would only log > attempts to authenticate w/out TLS/SSL, allowing the administrator to > try out the settings and see what the impact would be by examining the > logs. The 2nd option would actually enforce the policy, rejecting the > login attempt as well as logging the event. > > The importance of this capability is not so much that messages are > encrypted, as passwords. Without this feature, there's no way (that I > know of) to ensure that passwords aren't sent in the clear. Of course an > encrypted authentication method (cram-md5 or digest-md5) could be used > without TLS. That would suffice, but those methods have problems of > their own (storing clear text passwords), so I think the simplest and > best way of providing the ability to ensure that passwords are not sent > in clear text is to require TLS before authentication. > > One more thing. Someone might want to enforce encryption on all > messages, not only before authentication. This would mean that all > inbound messages would need to use TLS, period. I think this might > require an additional config parameter, which would have 3 values, > none|log|enforce. So this would be an additional enhancement (so long as > we're on the subject of enforcing TLS). > > If anyone has any thoughts about this, we'd like to hear them. > > As always, thanks for all your great work with spamdyke, Sam. > > -- > -Eric 'shubes' > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
