So I finally got authenticated SMTP working. So in addition to accepting mail for domains for which Siona is a relay and relaying mail from the local network, authenticated remote or mobile users can now relay mail as well. My criteria for this solution were that a) the authentication would be compatible/integrated with PAM, b) secure, and c) not some hokey POP-before-SMTP setup. So the solution is to have postfix authenticate against Cyrus saslauthd and then saslauthd authenticate with PAM (and PAM with LDAP, but that's just details).
Siona is running Debian Sarge with Postfix 2.2. So it turns out that in addition to the installed postfix package, I need sasl2-bin which includes the essential saslauthd and the useful testsaslauthd.
After installing saslauthd, it must first be enabled. The default file /etc/default/saslauthd should read:
You will need to create the directory listed above. A simple "mkdir -p" will do the trick.Note:
One page on the Internet recommended a PARAMS line which included a "-r". This will not work and cause all auth attempts to mysteriously fail since it is attempting to combine the local part and realm.Note 2:
Online I also so reference that you should change the saslauthd init script to move the PID into Postfix's chroot. This is also a lie. It won't make anything fail, it's just not needed.
So that's it for saslauthd. If you run testsaslauthd like this, you should get an "OK" for any existing user account:
$ testsaslauthd -u username -p password -s /var/spool/postfix/var/run/saslauthd/mux
Now onto postfix. First, let's finish up the SASL parameters. In /etc/postfix, there should be a sasl folder. If not create it. In there you create smtpd.conf which will contain the parameters for smtpd to actually use saslauthd and actually there's just two lines:
The first line is, you guessed it, the authentication method which in our case is the saslauthd. The second line just says which authentication methods are supported. For fancy (e.g. secure) methods like CRAM-MD5 and such, you need a separate password database. We don't have that so we're limited to the standard PLAIN and Microsoft's LOGIN. Since I don't need to support old Microsoft clients (though others do so watch out for this), I only enable PLAIN. Other fun types include OTP which provies a fancy one-time-password exchange. Very neat, but that's for another day.
The one thing to keep in mind is that this is a config file for Postfix, not saslauthd, so if you make changes to this file, it's Postfix that has to be restarted.
Note 3: Those are the only two lines you need. Anything else, like the socket path, is frivolous with our setup.
Note 4: There are standard locations to put the smtpd.conf, like /usr/lib/sasl2 in Debian, or /usr/local/lib/sasl2 when SASL is built with default paths. Some of these will work and others won't. In my case, the /etc/postfix/sasl worked as expected.
Now that we've written/uncommented a whopping 4 lines, let's get into Postfix's main.cf and do the last 4 lines. In main.cf, we want to a) enable sasl, b) permit sasl authenticated senders, and c) force TLS since our only auth method is "PLAIN".
In main.cf, add the following lines:
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_tls_auth_only = yes
For your sasl authentication, if your site is setup anywhere near sanely, then your domain is going to be your realm. Since we are doing PAM authentication, I'm not even sure this is required. I haven't tested it though so I've left it in.
The following line enables SASL, big surprise there ;)
In the smtpd_recipient_restrcitions, I have added the line permitting SASL authenticated connections. Make sure this line comes after your "mynetworks" line. Failing SASL is going to get your connection booted if you order it higher (last time I tested, not recently, I admit).
The SASL authenticated header, I'm not exactly clear what this does but it is "no" by default and most online documentation says you need to set it to "yes".
Lastly, the TLS auth only line requires TLS before AUTH is permitted. This will force all your users to enable TLS to protect their passwords (and subsequently their messages) in transit.
And now just kick postfix and you've got authenticated SMTP enabled for remote clients! You may have noticed that I have many rambling notes in my post. As you may infer, I got pretty frustrated in the end with instructions that were ambiguous, useless, or just plain wrong. Some of the stuff, like the -r for saslauthd, I don't know how the user even got their system to work... Ah well, c'est la vie.