Opportunistic SSL/TLS encryption on incoming emails

Technical

FastMail now enables opportunistic SSL/TLS encryption on incoming emails. This means we now advertise STARTTLS support in response to an EHLO command on our MX servers.

Trying 66.111.4.70...Connected to mx1.messagingengine.com.Escape character is '^]'.220 mx1.messagingengine.com ESMTP . No UCE permitted.EHLO blah.com250-mx1.messagingengine.com250-PIPELINING250-SIZE 71000000250-ETRN250-STARTTLS250-ENHANCEDSTATUSCODES250 8BITMIME

If the server sending the email to FastMail supports it, it will enable an SSL/TLS connection and send the email to FastMail over an encrypted connection. Some extra notes:

  • At the moment, this only affects the sending of email from another
    server to FastMail, not from FastMail to another server,
    though we are looking into this
  • We can't force a remote server to use encryption, it's up to the
    remote server to detect that we support it and then enable it before
    sending the email
  • This is not full end-to-end encryption of the email. The email is
    only encrypted during transit from the other server to us, once at
    our side, it's stored unencrypted again. For full end-to-end
    encryption, you need something like
    PGP
  • Encrypted connections have extra headers added to the email so you
    can see the transmission was encrypted. An example:
Received: from remoteserver.com (remoteserver.com [a.b.c.d])    (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))    (No client certificate requested)    by mx1.messagingengine.com (Postfix) with ESMTPS id 8FDBA27063B    for <sam@fastmail.fm>; Wed, 15 Apr 2009 23:28:29 -0400 (EDT)

Since this feature is entirely optional, it shouldn't affect any sending servers that don't support STARTTLS, and thus shouldn't affect the deliverability of email in any way.