Postmasters might be interested in the newly issued RFC:
https://www.rfc-editor.org/rfc/rfc8314.txt
In this, Standards Track recommendations are made concerning TLS between
an MUA (mail client) and the SMTP Submission Server (and IMAP/POP3
services). This does _not_ affect server->server communications ("MX
Delivery").
Note that port 465 is now "blessed" as "submissions", for clients to use
for submitting messages, it's _preferred_ and mail server operators
should offer both this and 587 service.
If you've hit political resistance to deploying 465 mail service, this
should be the document to use to justify to others doing the sane thing
for mail clients.
The IANA registry has been updated and now dual-assigns port 465.
(Actually, triple-assigns).
There are also recommendations concerning TLS versions; note that Exim
when using OpenSSL has to use `openssl_options` to control these and
there's no way to use something different for incoming/outgoing from one
Exim config, let alone vary based on port. When using GnuTLS, the Exim
`tls_require_ciphers` option is interpreted as a GnuTLS Priority String,
and so you can control the allowed versions of SSL/TLS from within that
string.
Something like this might work for you (depends upon version of GnuTLS):
# macros section
CIPHERS_IN_MX=NORMAL
CIPHERS_IN_SUBMIT=NORMAL:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1
# main section
tls_require_ciphers = ${if forany{465:587}{=={$received_port}{$item}} {CIPHERS_IN_SUBMIT} {CIPHERS_IN_MX}}:!aNULL:!eNULL
# nb: outbound TLS controlled via tls_require_ciphers on
# `smtp`-driver Transport used
There's also stuff around SHOULD for using DNS SRV records for service
discovery by clients, etc. Basically updating the IETF standards to
current best practices. There's new Received: header fields to record
the TLS cipher and group, and the ciphersuite text format is _not_ the
format which Exim currently uses! We'll have to consider that
carefully.
-Phil
