Skip to content

SMTP, STARTTLS, and Stastistics

I keep hearing, from people who ought to know better, “yeah, but hardly anybody encrypts their SMTP.”

I know I see it all the time in my mail logs, so I figured I’d go check and see who is sending me mail and how much of it is opportunistically encrypted (I’ve been accepting encrypted mail at my mail gateway since 2004 – it was pretty easy then, a nice patch set, and it’s trivial to do now).

First, here’s my method (postfix on linux):

# grep postfix/smtpd /var/log/maillog | grep "connect from"  | grep -v disconnect | grep -v bfccomputing.com | wc -l
# grep postfix/smtpd /var/log/maillog | grep "setting up TLS connection"  | grep -v disconnect | grep -v bfccomputing.com  | wc -l

And the results?  Since the mail logs were rotated this morning, this server has accepted 5927 connections, of which, 1141 were opportunistically encrypted.  That’s about 20%. Not bad for something “nobody does” because “nobody does”.

How are we doing on cipher selection?    Again, method:

# grep postfix/smtpd /var/log/maillog | grep "with cipher" | cut -d ' ' -f 15 | sort | uniq -c | sort -n | tac

and results:

458 DHE-RSA-AES256-SHA
300 AES256-SHA
170 ADH-AES256-SHA
134 RC4-SHA
33 DHE-RSA-CAMELLIA256-SHA
22 DHE-RSA-AES128-SHA
18 AES128-SHA
6 RC4-MD5
6 EDH-RSA-DES-CBC3-SHA

quite a variety, but not too bad overall.  We should publish some recommendations on cipher suite selections to make this a little better.

In the meantime – everybody else needs to get with the program.

Let me just take a moment to address one other bit of misinformation floating about out there: that STARTTLS isn’t really of value because it leaks metadata (To:, From:, Subject:, etc.). No, that’s PGP or S/MIME travelling on unencrypted SMTP (we need both message body and message envelope encryption for good security).

STARTTLS takes over just after the HELO (EHLO) command. So all your server is “leaking” is its name, which is almost certainly known through DNS already (yes, even Exchange admins can configure their HELO correctly if they want to). From the RFC:

   S: <waits for connection on TCP port 25>
   C: <opens connection>
   S: 220 mail.imc.org SMTP service ready
   C: EHLO mail.example.com
   S: 250-mail.imc.org offers a warm hug of welcome
   S: 250-8BITMIME
   S: 250-STARTTLS
   S: 250 DSN
   C: STARTTLS
   S: 220 Go ahead
   C: <starts TLS negotiation>
   C & S: <negotiate a TLS session>
   C & S: <check result of negotiation>
   C: EHLO mail.example.com
   S: 250-mail.imc.org touches your hand gently for a moment
   S: 250-8BITMIME
   S: 250 DSN

See, no leakage. Your job as a mail server admin is to protect the transport of the message (the envelope). The user’s job is to protect the content of the message (with PGP, S/MIME, etc.) Those concerns are separated between the MTA and the MUA with the current standards, and the users are assuming you do a better job than they do. Make them right.