15

According to the STARTTLS Spec Section 5:

A publicly-referenced SMTP server MUST NOT require use of the
STARTTLS extension in order to deliver mail locally. This rule
prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the
domain name on the right hand side of an Internet mail address.

However, this spec was written in 1999, and considering it's 2014, I'd expect most SMTP clients, servers, and relays to have some kind of implementation of STARTTLS.

How much email can I expect to lose if I require STARTTLS for incoming messages?

  • 1
    Good question. Having TLS forced on isn't going to prevent SPAM though. – Matt Aug 24 '14 at 21:58
  • 1
    I'm not expecting it to, I just want the encryption (which I seem to be getting from 90% of incoming messages without having it required) :) – jackweirdy Aug 24 '14 at 22:00
  • 2
    @Matt I checked recently received mails on one particular mail server and found this. Of mails received with TLS there was 4% spam, of mails received without TLS there was 100% spam. I wouldn't completely block mails without TLS based on this, but it certainly is a strong signal, which could be utilized in spam filtering. – kasperd Aug 25 '14 at 9:35
  • @kasperd - you could turn on TLS or use it as a means to reduce spam, but it won't last. All it means really is that the smtp client they are using to push spam to your server is not using TLS, or perhaps tries to not use TLS by default but may try a TLS enabled session if it is required. At best, you'll see a temporary reduction in SPAM, but I expect it to come back to normal levels over time. – Matt Aug 25 '14 at 20:39
  • @Matt That applies to most of the approaches currently taken against spam. Another problem with most of the approaches is that they block too many legitimate emails. People rarely consider how many legitimate emails it is acceptable to block. – kasperd Aug 25 '14 at 20:50
19

Yes, it is still a bad idea.

Three reasons:

  1. While the RFC you cited (RFC 2487) is in fact obsoleted by the current standard RFC 3207, the current standard keeps the MUST NOT verbiage you quoted in your question.

  2. SMTP Clients are not required to implement STARTTLS. It is totally acceptable not to do so. While STARTTLS is becoming more common, it is absolutely not universal.

  3. As a result of reasons 1 and 2, if you require STARTTLS on all incoming connections you will lose mail.

However:

Your server - your rules. If you want to arbitrarily reject any mail for any reason, or even no reason - that is your right and privilege. (does not mean that it is necessarily a great idea however)

Side notes:

You wont prevent spam by requiring STARTTLS, even if you require mutual STARTTLS authentication. Spammers can get certificates too - or create self-signed ones. Rejecting self-signed client certs will also result in losing legitimate mail.

STARTTLS is point-to-point encryption. The connecting system can still read the contents of the email. If you want real privacy, you need something end-to-end, such as OpenPGP or S/MIME.

That said, STARTTLS does remove one possible avenue for interception or MITM and therefore it is still a good idea to use it when feasible, ie when the other side supports it too.

  • 1
    The note about certificates and spam is out of place. It is the receiver who need a certificate not the sender. – kasperd Aug 25 '14 at 9:29
  • it wont help prevent spam. Even if you make mutual STARTTLS auth mandatory. Will update answer to clarify. – Joe Sniderman Aug 25 '14 at 11:55
  • 2
    +1 on note about spam. Just because it's encrypted it doesn't make it secure. – Matt Aug 25 '14 at 20:40
10

Google maintains open statistics on their percentage of mail that is encrypted, both inbound and outbound. This information should be extremely useful to you in determining whether this is worth implementing:

http://www.google.com/transparencyreport/saferemail/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.