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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
