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

Reply via email to