@JKnott:
@kpa:
Check that you're not enforcing SSL/TLS on outgoing SMTP on your server, that is never going to work on the current internet where the vast majority of the mail servers are not yet SSL/TLS ready.
Please stop talking rubbish. First of all I'm talking about the standard mail transport from mail server to mail server that always uses port 25, regardless of SSL/TLS or not. When it comes to mail submission (user sending mail) you see either port 465 (being obsoleted, see below) with forced SSL/TLS or port 587 with StartTLS or even port 25 with StartTLS.
Secondly you have some very wrong information about StartTLS, there are no "security issues" known anymore than with forced SSL/TLS like you have on port 465 mail submission and the forced SSL/TLS methods are already being deprecated heavily. Hell, even HTTPS is moving towards StartTLS because everyone would like to have HTTP/HTTPS on single port 80 to simplify firewalling.
Weaknesses and mitigations
Opportunistic TLS is an opportunistic encryption mechanism. Because the initial handshake takes place in plain text, an attacker in control of the network can modify the server messages via a man-in-the-middle attack to make it appear that TLS is unavailable (called a STRIPTLS attack). Most SMTP clients will then send the email and possibly passwords in plain text, often with no notification to the user. In particular, many SMTP connections occur between mail servers, where user notification is not practical.
In September 2014, two ISPs in Thailand were found to be doing this to their own customers.[7][8] In October 2014, Aio Wireless, then a subsidiary of Cricket Wireless, was found to be doing this to their customers.[9][10]
STRIPTLS attacks can be blocked by configuring SMTP clients to require TLS for outgoing connections (for example, the Exim Message transfer agent can require TLS via the directive "hosts_require_tls" [11]). However, since not every mail server supports TLS, it is not practical to simply require TLS for all connections.
An example of a STRIPTLS attack of the type used in Thai mass surveillance technology:[12]
220 smtp.gmail.com ESMTP mail.redacted.com - gsmtp
ehlo a
250-smtp.gmail.com at your service, [REDACTED SERVICE]
250-SIZE 35882577
250-8BITMIME
# The STARTTLS command is stripped here
250-ENHANCEDSTATUSCODES
250-PIPELINING
250 SMTPUTF8
220 smtp.gmail.com ESMTP - gsmtp
ehlo a
250-smtp.gmail.com at your service
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250 SMTPUTF8
This problem is addressed by DNS-based Authentication of Named Entities (DANE), a part of DNSSEC, and in particular by RFC 7672 for SMTP. DANE allows to advertise support for secure SMTP via a TLSA record. This tells connecting clients they should require TLS, thus preventing STRIPTLS attacks. The STARTTLS Everywhere project from the Electronic Frontier Foundation works in a similar way. However, DNSSEC due to deployment complexities and peculiar criticism,[13] faced a low adoption rate and a new protocol called SMTP Strict Transport Security or SMTP STS has been drafted by a group of major email service providers including Microsoft, Google and Yahoo - that got more fine-tuned in its superseded versions. SMTP STS does not requires the use of DNSSEC to authenticate DANE TLSA records but relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interceptions. The TOFU model allows a degree of security similar to that of HPKP, reducing the complexity but without the guarantees on first use offered by DNSSEC. In addition, SMTP STS introduces a mechanism for failure reporting and a report-only mode, enabling progressive roll-out and auditing for compliance.
https://en.wikipedia.org/wiki/Opportunistic_TLS#Weaknesses_and_mitigations
Email encryption
Until recently, there has been no widely implemented standard for encrypted email transfer.[2] Sending an email is security agnostic; there is no URI scheme to designate secure SMTP.[3] Consequently, most email that is delivered over TLS uses only opportunistic encryption.[4] Since DNSSEC provides authenticated denial of existence (allows a resolver to validate that a certain domain name does not exist), DANE enables an incremental transition to verified, encrypted SMTP without any other external mechanisms, as described by RFC 7672. A DANE record indicates that the sender must use TLS.[3]
Additionally, a draft exists for applying DANE to S/MIME,[5] and RFC 7929 standardises bindings for OpenPGP.[6]
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Email_encryption
Seems to me someone else thinks there are issues with StartTLS in that they came up with a secure method to ensure TLS is used when possible.