Opportunistic SSL/TLS encryption on incoming emails

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.