0

RFC 2847 states

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.

So, to conform to the RFC I must allow for the possibility that another agent may try to connect to my email server without using TLS and then send passwords in plain text, is that right?

If I break this rule and only allow encrypted email connections (i.e. on ports 454, 993, and 995, but no others), will other email services in general be able to send to my server?

Community
  • 1
spraff
  • 549
  • 4
  • 8
  • 18
  • I think that questions about mail server compatibility belong on Stack Overflow or Server Fault. – 700 Software Sep 22 '16 at 16:54
  • The SMTP server that the RFC is takling about in this context is incoming SMTP server, not outgoing SMTP servers. Incoming SMTP servers are listed as MX record, usually only accepts mails to a small number of TO address, configured to accept unencrypted connections, and typically do not require authentication. Outgoing SMTP servers, on the other hand, don't need to be listed on MX record, usually only accepts mail from a small number of FROM address, and should always require authentication and usually encryption. – Lie Ryan Sep 23 '16 at 17:34

4 Answers4

2

You can configure your server so that it accepts outgoing e-mail from your users on a different port (587) and only allow TLS there. On the standard port 25, prevent any kind of user login so that someone won't accidentally be using it and sending their password in the clear.

As far as I understand this doesn't break the RFC as it talks about how other servers talk to your server to deliver e-mail to your users. On your user-facing side, you aren't really bound by any RFCs and are free to enforce any policy you wish like enforcing TLS as it's supported on all major clients.

André Borie
  • 769
  • 1
  • 7
  • 22
0

For best compatibility you should allow unencrypted connections for general mail, as some clients do not support STARTTLS.

For the user's mail client (where password is sent) you should require the best possible encryption.

700 Software
  • 2,233
  • 10
  • 49
  • 77
0

If I break this rule and only allow encrypted email connections (i.e. on ports 454, 993, and 995, but no others), will other email services in general be able to send to my server?

No they won't. Mail delivery between mail servers is done by looking up the mail server responsible for the recipients domain using a DNS lookup for the MX record. This record contains a hostname and this host will then be contacted at port 25. There is no way to somehow configure a different port, i.e. if there is no server on port 25 the delivery will fail.

Steffen Ullrich
  • 13,227
  • 27
  • 39
0

There are 2 things to distinguish:

  • MTA (Mail Transport Agent), which relays emails from sender to recipient, usually using TCP ports 25, 465 and 587
  • MDA (Mail Delivery Agent), which allows users downloading/synchronizing their emails, usually using TCP ports 110 and 995 for POP3(S) and 143 and 993 for IMAP(S)

The RFC talks about A publicly-referenced SMTP server, meaning a MTA.

MTA usually listen on 3 different TCP ports for SMTP(S):

  • 25: plain SMTP that can support STARTTLS and that is the ONLY port used to deliver emails from an MTA to another MTA
  • 465: SMTP over TLS, used by users to send their emails
  • 587: plain SMTP that can support STARTTLS, that can be used by users to send their emails

For STARTTLS, if we take the example of Postfix, you can have 3 different configurations:

  • none: the server won't use STARTTLS
  • may: the server will propose and use opportunistic encryption (STARTTLS) if available
  • encrypt: the server will drop the connection if STARTTLS cannot be used

Now the real problem: currently too many MTA are poorly configured and do not support STARTTLS, this means that requiring it on your server may cause some of your emails not being delivered or your server won't be able to receive emails from senders using an MTA not supporting STARTTLS.

In order to accelerate the move about this, Google in its transparency report displays the percentage of emails being encrypted in transit. They even went further, now displaying red padlock when they were not encrypted.

However, too many servers are still not supporting STARTTLS, meaning you may face too many issues by requiring it on port 25. As a consequence, the suggestion I can make you for your configuration is the following:

  • SMTP port 25: "may", both as client and server
  • SMTPS port 465: open it for your users
  • SMTP port 587: not really needed
  • POP3 port 110: not really needed
  • POP3S port 995: open it for your users
  • IMAP port 143: not really needed
  • IMAPS port 993: open it for your users
Jyo de Lys
  • 101
  • 1