The Fugue

As many of you already know from this PLUG thread, the mail servers for MSN and Hotmail have been doing something despicable, for quite some time now. They quietly delete email that they think is spam, after accepting it for delivery.

Now, depending on your experience that may sound like no big deal, or it may rival the best plot ever for a horror movie. Let me explain why this is worse than zombies.

First, an analogy. If you put a stamp on an envelope and send a letter to your friend or business associate via the postal service, you expect it to get there. If you send a package via UPS you expect it to get there. You don’t expect the recipient to show up at the post office to find the postal worker wearing the sweater you sent him. The mail may have been delayed, but it will get there. “Neither rain nor hail nor sleet nor snow nor heat of day nor dark of night shall keep this carrier from the swift completion of his appointed rounds.”

If you show up to the post office with illegal mail—something that is outside the allowed dimensions or too heavy or has explosives in it—you will be told that you can’t send it. You’ll know you need to get a different envelope, pay more postage, etc. You have feedback. If you send mail to a bad address, or someone who hates your guts, you will get your mail back marked “Return to Sender” (assuming you provided a return address). Feedback. In neither case would you be satisfied if the post office just threw your important correspondence in the trash.

So, why would you accept this behavior from your email provider? When I send an email to fred@hotmail.com (whoever he is), and hotmail’s mail server says 250 Queued mail for delivery, I expect fred will get my email. Maybe it’s in his junk mailbox. Maybe fred is away on vacation and won’t see it for a few months. Maybe it takes more than 5 minutes to traverse the internet. But I expect it will get there, or that I will get a bounce message if it doesn’t. The reliability of email depends on it. The rules demand it.

If you use Hotmail or MSN, you have been losing email. I dare you to prove otherwise. You owe it to yourself and to the people with whom you correspond to switch right now. GMail is an excellent alternative. It has more features, better spam detection that doesn’t delete mail without asking, a nicer user interface, more storage space than even you will use, and POP3 and IMAP support. While you’re at it, if you use MSN for instant messaging switch over to Google Talk or, even better, Jabber.

If you have been corresponding with MSN or Hotmail users, your emails may have been trashed before the recipient ever saw them. They may not even realize this. Do your part and inform them. If they don’t want to switch to a sane email service, then insist on communicating in a different manner.

And let this be a lesson to you: don’t let the quest against spam (or anything else) turn into tilting at windmills. Keep your wits about you and consider the consequences of your actions. Especially if you’re a system administrator. Really especially if you’re a system administrator at a big email service like Hotmail. And that goes for SPF, too.

Postfix is my MTA of choice. Recently I had a second opportunity to set up relaying from Postfix to Postfix, with TLS and authorization. Seeing how I remembered precious little from the first time, I decided it would be a good thing to blog on.

The documentation on doing this is really quite good, but you have to get acclimated to the acronym soup before it makes any sense at all. The first and most mysterious acronym is SASL.

SASL is the Simple Authentication and Security Layer, a method for adding authentication support to connection-based protocols. To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection.

If that’s not a mouthful… Basically, SASL is a library and daemon that programs, like Postfix, can use to do authentication. The Postfix SASL Howto tells you all you need to know about configuring Postfix for Cyrus or Dovecot SASL. It also tells you how to configure either Dovecot or Cyrus SASL for Postfix.

I’m using Debian stable (4.0), and this is what I did. On both the client and server you need the postfix-tls package which includes SASL and TLS support for Postfix. On the server I had to install the sasl2-bin package (this is not at all obvious at first pass—I was looking for a saslauthd package). Then I had to enable saslauthd by editing /etc/default/saslauthd. The smtpd.conf file is in /etc/postfix/sasl on Debian, and it looks like this:

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

Here’s the relevant snippet from /etc/postfix/main.cf:

smtpd_sasl_auth_enable = yes
smtpd_sasl_application_name = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination

Now, there’s a problem. Debian runs Postfix in a chroot jail by default, which means you need to make special provision for Postfix to be able to find the saslauthd socket. This can be as easy as

mv /var/run/saslauthd/ /var/spool/postfix/var/run/
ln -s /var/spool/postfix/var/run/saslauthd/ /var/run/

You may also need to adduser postfix sasl, though I’m not sure if this is necessary.

That’s it for the server. Now, on the client you need this in /etc/postfix/main.cf:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relayhost = [mail.example.com]
smtp_sasl_security_options = noanonymous

/etc/postfix/sasl_passwd looks like this:

[mail.example.com] username:password

You need to postmap /etc/postfix/sasl_passwd after changing it.

Now, authentication is well and good, but you don’t want to be sending those passwords in the clear, especially when using the default PAM authentication source. So, you also need to configure TLS.

The Postfix TLS README tells you all you need to know for this. You need to create a certificate for the server, enable the use of TLS on both sides, and tell the server not to accept authentication without TLS. That last bit is perhaps the most vital element for security, though of course it does nothing to help you get TLS actually working. Here’s the config snippet:

# client
smtp_use_tls = yes # This option deprecated in later versions of Postfix

# server
smtpd_tls_CAfile = /etc/ssl/CA/cacert.pem
smtpd_tls_cert_file = /etc/ssl/certs/mail.pem
smtpd_tls_key_file = /etc/ssl/private/mail.pem
tls_random_source = dev:/dev/urandom
smtpd_tls_loglevel = 1
smtpd_use_tls = yes # also deprecated

Creating the certificates is nothing extraordinary, but this seems like a good time to post my /etc/ssl/README file:

self-signed:
    openssl req -new -nodes -out newreq.pem
    openssl x509 -req -signkey privkey.pem -in newreq.pem -out cert.pem

create CA:
openssl req -nodes -new -x509 -days 3650
    -keyout CA/private/cakey.pem -out CA/cacert.pem

generate request:
openssl req -new -text -nodes -keyout newkey.pem -out newreq.pem

sign request:
openssl ca -in newreq.pem -out newcert.pem -days $((365*2))

Don't forget to keep private keys private.

So there it is. Authentication and Encryption at your fingertips.