9

I run an MTA consisting of the standard Postfix, SpamAssassin, ClamAV, SPF/DKIM checks etc. This MTA is used for inbound email only, doesn't host any accounts and forwards any mail that passes said checks to a shared webhost.

I'm aware that a few email services are starting to attempt TLS connections before plain-text when attempting to deliver mail to my server.

I realise that not all services will support TLS, but I'm wondering how well-adopted it is so that I can satisfy the OCD security side of my brain (yes, I know SSL isn't as secure as we once thought it was ... ).

The Postfix documentation for smtpd_tls_security_level states that RFC 2487 decrees that all publicly-referenced (i.e. MX) mailservers do not force TLS:

According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced SMTP server. This option is therefore off by default.

So: How applicable/relevant is the documentation (or the 15 year-old RFC for that matter), and can I safely force TLS on all inbound SMTP connections without locking out half of the world's ISPs?

  • 1
    Standards are created by committees whose members probably never worked as sysadmin even a single year in their life, and it is quite visible in practically every internet standard specs. In case of RFCs is a little bit better situation, but RFCs aren't standards. They are drafts ("request for comments"). And: you get your wage not from a paper, but from a company. – peterh Dec 19 '14 at 1:58
  • 7
    That RFC was obsoleted by RFC 3207. And its author has been around a lot longer than one commenter here seems to think. – Michael Hampton Dec 19 '14 at 2:08
  • 6
    For outgoing email, here some stats from Facebook: The Current State of SMTP STARTTLS Deployment – masegaloeh Dec 19 '14 at 2:16
  • Unsure of the reason for the single downvote. Thanks Michel and Peter for your views, much appreciated. – Craig Watson Dec 21 '14 at 14:56
7

This is a very complicated question given that the mail providers of the world do not readily provide statistics on their mail servers.

Self Diagnosis

To determine the answer to your question based on your own server/domain peers, you could enable SSL logging:

postconf -e \
    smtpd_tls_loglevel = "1" \
    smtpd_tls_security_level = "may"

postconf
postfix reload

This assumes that you save your mail syslog messages for a while. If not, perhaps set up a syslog archiving strategy and write a shell script to summarize the TLS usage on your server. Perhaps there are already script to do this.

Once you are comfortable that all of your peers support TLS and at the cipher and protocol strength that you are willing to enforce, then you can make an informed decision. Every environment is different. There is no one answer that will meet your needs.

My own personal experience

For what it's worth, my own personal mail server enforces TLS. This has a funny side effect of negating most of the spam bots, as most of them do not support TLS. (Up until that change, I was relying on the S25R regexp methodology)

Update

It has been one year since I answered this and the only problems I have had receiving email with TLS forced on was from the front end web servers at Blizzard (parental controls) and Linode's management system. Everyone else I interact with appears to support TLS with strong ciphers just fine.

Corporate Environment

In a corporate environment, I would strongly encourage you to enable TLS logging and leave that running for quite a long time before enforcing TLS. You can always enforce TLS for specific domain names in the tls_policy file.

postconf -d smtp_tls_policy_maps

The postfix site has some great documentation on the usage of tls policy maps. You can at least ensure that specific domains that provide sensitive information are encrypted even if an ISP tries to strip out the TLS support in the initial server connection.

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.