On 01/27/2012 04:38 PM, Sam Clippinger wrote: > 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.
I hadn't thought of that. You're right, it's in there. :) Outlook'03 doesn't support TLS, so I'm sure you're right there as well. > 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. I'd love to see this. It would certainly help to enforce a good security policy (no clear text passwords). Of course this would also require spamdyke to be installed on the submission port 587, but that's something I'd be willing to do if this option were available. Having spamdyke on port 587 will be needed also for some other future enhancements such as auto-whitelisting, so I don't think this is a big deal. > 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? This was somewhat of an afterthought. Enforcing this would indeed be a little impractical, but I'm a little surprised at how many servers are actually using TLS already (msn, gmail, as well as many small ones). Since the log messages have all the data required already to do analysis, this isn't a high priority. I just thought it might be a nice feature for companies who need a high degree of security. If the filter would be easy to code, I think it'd be a nice touch (not that it'd get much use). If the code would be troublesome, then forget it. Of course smtps (465) could be used internally, but there's no way to enforce an encryption policy externally (unless you write the filter). ;) Thanks again Sam for your great work with spamdyke. -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
