Stephen Holmes wrote, at 10/03/2008 12:01 PM: > Jorey Bump wrote: >> You've wisely configured postfix to offer AUTH only via STARTTLS, so it >> won't appear until the session is renegotiated and encrypted. telnet is >> not up to troubleshooting this task. You've confirmed with a client that >> it works, but you can also use openssl: >> >> openssl s_client -starttls smtp -debug -connect localhost:25 >> >> > Doh! That makes sense. Looks good. Thanks Jorey. Issued the command > and now see AUTH PLAIN and AUTH=PLAIN. I guess that's okay? Should I > have more authentication types?
You might want to add LOGIN, at the very least. That's usually enough to get widespread support. Your backend will determine if it's worth supporting more secure mechanisms. Patrick Ben Koetter posted an excellent summary earlier today, so I won't repeat it (search the archive for "Trouble setting up SASL authentication with postfix"). Note that if you do add secure mechanisms that don't require encryption, you can offer them even without TLS. In this case, you would use a combination of settings: smtpd_tls_auth_only = no # Restrict mechanisms offered without TLS smtpd_sasl_security_options = noanonymous, noplaintext # Restrict mechanisms offered with TLS smtpd_sasl_tls_security_options = noanonymous If you support the mechanisms PLAIN LOGIN CRAM-MD5 DIGEST-MD5, for example, this will only show CRAM-MD5 DIGEST-MD5 when unencrypted, but offer all of them with STARTTLS. Of course, this is only as secure as the mechanisms themselves, so there's no harm in continuing to require STARTTLS for all mechanisms. I mention it only to show the flexibility available in case you have troublesome clients and want to remain as secure as possible.
