Skip to content

Let's talk about sex....

Gotchya! Actually let's talk about the ANTI-sex: email. Be it known that SMTP verily doth suck the Big Giant Wang, and woe is upon the face of the Wang as SMTP's big pointy bat fangs do nastily fillet his most sensitive parts. Be it further known that I have wasted nearly 11 years of my life learning all about sendmail, the venerable bat that symbolizes everything wrong with SMTP. And finally, be it known that I fucking host a server for $100/month, and I damn well want to be able to use it to send fucking mail from wherever I am (Are you LISTENING Optimum Online? You suck too!)
So, the iPhone is the impetus for this. Basically I want to be able to use a SECURE mail server from my iPhone, and in order to do that I need:
  • imaps (Secure IMAP over SSL)
    I have this already. I've had this for YEARS.
  • SMTP AUTH plus at least one of:
    • SMTP+STARTTLS (over Port 25)
    • SMTPS (over port 465)
So tonight I installed the Cyrus-SASL and SASL auth daemon ports and proceeded to teach an old bat new tricks. My sendmail installation now supports all of the SMTP Goodies above - and I'm going to tell you how I did it!
  • Step 0: Install Cyrus-SASL and Cyrus-SASLAuthDaemon If you're running FreeBSD, you want to install ports/security/cyrus-sasl2 and ports/security/cyrus-sasl2-saslauthd
  • Step 0.5: Configure the SASL Auth Daemon You need to create the file /usr/local/lib/sasl2/Sendmail.conf (Yes that's a capital S). It should contain one line:
    pwcheck_method: saslauthd
    You also need to configure teh SASL Auth daemon to start on boot - On FreeBSD add saslauthd_enable="YES" To /etc/rc.conf.
  • Step 1: Rebuild Sendmail with -DSASL You can get gory details on this from; If you're using FreeBSD add the following to /etc/make.conf and do a make world, the magic makefiles do the rest:
    # Sendmail SASL SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2
  • Step 2: Configure Sendmail
    Those of you who know me are probably expecting me to hand you diffs for; I'm not that mean. Here's the magic you need:
    dnl Auth Options define(`confAUTH_OPTIONS', `A p y') define(`confAUTH_MECHANISMS', `LOGIN PLAIN') TRUST_AUTH_MECH(`LOGIN PLAIN') dnl SSL Stuff - Helps to have a certificate define(`CERT_DIR', /etc/ssl/certs) define(`confCACERT_PATH', `CERT_DIR') define(`confCACERT', `CERT_DIR/cacert.pem') define(`confSERVER_CERT', `CERT_DIR/mail.pem') define(`confSERVER_KEY', `CERT_DIR/mail.pem') define(`confCLIENT_CERT', `CERT_DIR/mail.pem') define(`confCLIENT_KEY', `CERT_DIR/mail.pem') dnl dnl Daemon Definitions (ports and options) for SMTP (:25) dnl and SMTPS (:465). dnl dnl IPv4 Daemons DAEMON_OPTIONS(`Port=smtp, Name=SMTP-IPv4, Family=inet') DAEMON_OPTIONS(`Port=smtps, Name=SMTPS-IPv4, Family=inet, M=s')
    Line-by-Line: The confAUTH_OPTIONS stuff ("A", "p" and "y") translates to "Work around broken MTAs", "Never allow plaintext over unencrypted connections" (a DUH move), and "Don't allow anonymous logins" (which would defeat the point of authentication!) confAUTH_MECHANISMS lists the allowed authentication mechanisms (LOGIN and PLAIN are very similar - Login interrogates you for a user/password as two separate arguments (Base64 Encoded) while plain expects you to provide NUL (0-byte) delimited username/password as one argument. There are other options but these let you use your system password file TRUST_AUTH_MECH specifies which authentication mechanisms result in a "trusted" session (one that can relay). This list SHOULD be the same as confAUTH_MECHANISMS in every case I can think of. The next block is hopefully self-explanatory: Path to your SSL Certs, the filename of your CA's certificate, and the certs to use as a Server and Client (You're a server for anything connecting to YOU on port 25, and a client when you connect to someone else on port 25). In practice the server and client certs should be the same. In BEST practice, they're actual CA-Signed certs from Verisign or somebody trusted. Note that the certs are .PEM format, and one file can contain the cert/key pair if you want. Also note that these files need to be "Safe" according to sendmail, or sendmail won't use them and all your SSL stuff falls over (basicaly owned by root and mode 0600 is as permissive as you can get). The final block are daemon port definitions. The first one translates to "Listen on the SMTP port (25) on all IPv4 addresses". The second to "Listen on the SMTPS port (465) on all IPv4 Addresses, and require SSL" If you want SMTP Auth to allow you to bypass blacklists, include feature(`delay_checks') in addition to the other lines.
  • Step 3: run make in /etc/mail restart sendmail and test You should be able to use SMTP Auth on port 25 after a STARTTLS (and over port 465 from the beginning, but the connection needs to be encrypted). This should "Just Work" - If it doesn't, maillog usually has something interesting to say about the mater. For debugging purposes you can remove the "p" from confAUTH_OPTIONS and test on port 25 in the clear, but I would only advise doing that on localhost while SSH'd in or on the console. There are lots of references for the SMTP commands AUTH LOGIN and AUTH PLAIN around the internet - I suggest testing with auth_login as the conversation is easy:
    Server sends BANNER You send "AUTH LOGIN" Server sends nasty Base64 Encoded string You send a nasty Base64 Encoded string back (The username you want to log in as) Server sends another nasty Base64 Encoded string You send another nasty Base64 Encoded string back (The password for that user) Server sends either a 2xx "You're authenticated" or a 5xx "I hate you"
    The hardest part is actually doing the Base64 Encoding, and there's LOTS of things that do it for you :)
What does all this buy you? Well you get SSL-Secured SMTP. This is mostly useful on public wireless networks and other places where your SMTP traffic is subject to snooping. It ensures that your mail isn't read intransit between your client and your server (what happens after that is a wild west of nasty insecure servers, but hopefully those networks are more secure than the local TMobile hot spot). You also get SMTP Auth to validate relaying based on system username/password pairs. Obviously you wouldnt do this in plaintext (If you would get off my fucking blog you dumb noob!), so this goes hand-in-hand with SSL. Finally, most ISPs don't block port 465 yet, so you can send mail over SSL with your username and password from your nasty SMTP-Blocking ISP. What does all this buy me? Well one more tool in the sendmail bag for sure. Also I am now iPhone Ready - I can send and receive secure email from anywhere, and look forward to taking the fullest possible advantage of that functionality when my new toy gets here.


No Trackbacks


Display comments as Linear | Threaded

No comments

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.

Form options