Owner: nobody

We need to configure Postfix to speak Authenticated SMTP, aka SMTP AUTH to allow relaying. It is very important to not allow a user to do an SMTP AUTH until after they have done a STARTTLS (or are coming in via SMTPS, stunnel, on port 465). Only after that should Postfix offer SMTP AUTH with PLAIN and LOGIN.

SASL has the ability to use a separate password store from the unix passwords. If using those systems, we can then offer CRAM-MD5 and DIGEST-MD5 authentication. However, this means a complete set of separate password maintainence tools have to set up and users educated to use. SASL can also use the Kerberos GSS-API, but that again involves setting up Kerberos and educating our users. I think we are better off just dealing with PLAIN and LOGIN inside encrypted tunnels. It's a least-common-denominator with the mailers I've dealt with.

The other issue that comes up is what certificate to use for the STARTTLS and STUNNEL. The obvious first choice is the current stunnel-public.pem. However, we might want to restructure our service certs under a single self-signed CA cert. That is another topic NewSSLCertOrganization, but we will want to have it settled before we deploy this or users will have to add/change certs twice.

Lastly, there are port blockage issues. Many dial-up ISPs? are blocking port 25 as an anti-spam measure. Earthlink/Mindspring is one of these. As such, we should run our authenticated SMTP on a secondary port as well.

I use:

• port 25 - normal mail supporting SMTP AUTH after STARTTLS
• port 465 - stunnel wrappered mail, SMTP AUTH offered
• port 2525 - normal mail supporting SMTP AUTH after STARTTLS (alternative port)

Comments?

comments:

Some postfix references. --key, Thu, 24 Jun 2004 14:55:10 -0700 reply
We will need to install sasl2 and saslauthd and recompile Postfix with some patches to get TLS support. See: http://yocum.org/faqs/postfix-tls-sasl.html

Trim the AUTH list to what is really used. --key, Thu, 24 Jun 2004 15:01:32 -0700 reply
By default, SMTP AUTH will list all the SASL auth methods available, whether they are administratively being used or not. For example, if you follow the default instructions and create an empty sasldb the you may generate an AUTH line like:

AUTH LOGIN PLAIN OTP DIGEST-MD5 CRAM-MD5

The problem with this is some mail clients that also support multiple auth methods pick the first one that matches rather than find out from the user which one they want to use. The Mobile Pocket PC 2003 mail client, for example, picked the CRAM-MD5 from the list to try to authenticate with and if it failed, gave up rather than trying to use one of the other authentication methods available. The user was not configured in the sasldb but was being served by unix passwords. The mail client had no way to be configured to be told to use just the LOGIN and PLAIN methods. The fix is to make sure you only offer the AUTH methods that you are really configured to use.

I think you can see that if you authenticate some of your users by one method and others by another, they are hosed if they use the Mobile Pocket PC mail client.

Alternative to Postfix Patches for TLS. --key, Wed, 30 Jun 2004 12:58:08 -0700 reply
The STARTTLS support has been integrated into the Postfix development mainline stream. The next Major release of Postfix will thus have STARTTLS as a compile option. Currently it is just in the -development branch, though.

So an alternative is to switch to -development (I do not recommend this) or wait for the -stable release. I have not found any references to when this might occur.

"Submission" agent port 587 --key, Mon, 10 Jan 2005 16:18:05 -0800 reply
Rather than port 2525 above, we should allow submissions via the "Mail Submission Agent" (RFC 2476 - basically SMTP on port 587.