Re: [exim] Next Exim: TLS: changed smarthost example config

On 2018-04-21 at 11:23 +0200, Andreas Metzler via Exim-users wrote:
> Personally I am not convinced that this is the right way for trying to
> enforce stronger encryption standards on mail providers.

It's not about that. It's about providing people relying upon defaults
with worthwhile security, so that when their system goes to send email,
it's not trivially susceptible to MitM attack.

Along the way, I'm saying roughly "if these things don't work, then it's
breakage on the mail provider's side, here's my wet-finger-in-air
assessment of what these types of breakage mean as to whether or not you
should be using that mail-provider."

> is going to be any effect, people won't change their email address
> because the hosting smarthost does not provide TLS1.2 (due to SPF et

I didn't actually provide a wet-finger-in-air assessment of this point.
I covered "no TLS", "unverifiable certificate" and "ciphersuite
problems".

I mapped "no TLS" to "change mail provider" and I'm pretty serious
there: having to send email without any kind of link security at all
should be unacceptable.

I mapped "unverifiable certificate" to "seriously consider" changing
mail provider; after the past six years, since Heartbleed, enough
attention has been paid to TLS security that anyone providing a
commercial service to others should be able to manage a verifiable
certificate. Let's Encrypt is two years old and now common enough to be
a baseline minimum. If folks aren't offering a verifiable certificate
to their userbase, then now is the time to fix that.

This can be something from an internal certificate authority for an
organization which has such a thing and only lets internal systems send
email, or can be a free certificate if the more general public needs to
be able to send email. The verifiable identity should be "whatever you
tell end users is the real name of the server". None of this applies to
MX delivery.

I mapped "ciphersuite problems" to something which folks should expect
their mail provider to be able to fix quickly. If there are issues and
they can't be fixed quickly, then why trust that the provider can do
much of anything to provide TLS service?

I did not map "no TLS1.2 support" but would tend to treat it much like
ciphersuite problems.

> cu Andreas

Thanks for the GnuTLS fixes, I'll apply those. I did consider TLS 1.3
but there's enough uncertainty there that it seemed reasonable to wait,
rather than debug what protocol strings may or may not exist and be
parsed for SSLv3 etc etc.

-Phil