Hi Friends!
A question that concerns relatively LE.
Reading here, the developer do not recommend the use of STARTTLS for the communication between email server and email client.
What do you think about?

I’m not sure why an unsecured connection would be safer than one using STARTTLS…

The author does have a point though: the “basic” PKI system in mail servers is not the same as it is for websites. Most OS and most webbrowsers (at least the leading ones) have a proper system of root certificates stores, so it actually is possible to check the validity of the certificates.

With mailservers though, the basic PKI system doesn’t work, because most mailservers don’t validate the certificate chain. Most will even accept self signed certificates. Therefore, any MitM attack is possible.

The author probably means “connections for which TLS is always mandatory, such as on port 465, are safer than connections which use STARTTLS for optional TLS, such as on port 25”. An easy misinterpretation of the FAQ text is “using plaintext is preferable to using STARTTLS”. But I think the author means “requiring the use of TLS is better than optional TLS”, not “avoiding the use of TLS is better than optional TLS”!

In most e-mail software, TLS is always optional on port 25, whereas it’s always mandatory on port 465, if the software can be configured to use port 465 at all.

This doesn’t mean that STARTTLS is worse than unencrypted e-mail or that STARTTLS shouldn’t be used when the server advertises it.

EFF is working on an experimental approach to improve the security of STARTTLS and make it more similar to TLS-required methods of transferring e-mail.

It’s still better than unencrypted e-mail because it protects against a passive attacker. An active attacker may not be present in every network or may not want to risk using its capability all of the time.

Some people like to make an argument about a “false sense of security”, but this is readily avoided in this case: (1) don’t believe that STARTTLS without more protects against an active attacker, (2) don’t show any security indications to any other users based solely on the existence of software support for STARTTLS.

Also I think the author of this FAQ has been confused by the EFF posts. The EFF tells you that enabling STARTTLS on your server doesn’t prevent clients from being tricked into doing unencrypted communication. But for a client, which is what the FAQ is discussing, insisting on STARTTLS works just fine the same way as insisting on a TLS-only port would.

What matters, to keep their users secure, is that they do a good job implementing STARTTLS, not that they advocate to get rid of it.

This became a nice discussion, hopefully I may add another view, at least to those who are not very familiar with mail servers. And jopefully my information is not outdated.

Port 25 was mentioned, but this port is for a long time “reserved” for server-to-server communication, that is MTA to MTA. So it should not be used to accept mail from clients. Therefore, for me, the solution is to always require SASL (authentication when sending mails) to relay mail and do this on port 587 (mail submission), while such connections are denied on port 25. So, basically only MTAs are accepted there. Since not every mail server implements TLS for SMTP, STARTTLS is optional on port 25. However, it is required on port 587 for any submission.

This configuration makes it secure enough, I think for now, so noone should be concerned about sending cleartext when STARTTLS doesn’t activate the TLS encryption.

As things are changing, I see this happens again with port 465, which was long deprecated by IANA and reserved for other purposes. Most MSPs are providing it to their clients. However, port 25 should not be used, as it is most often blocked on the network edge or in corporate networks to prevent malware and SPAM spreading.