On Thu, Jan 16, 2020 at 06:03:29PM +0100, Thomas wrote:
> How can I check whether the recipient / operator of an email server
> where I send email also operates one that offers it at all?
> Respectively. what is the state of the art that he should use / offer?
The answer is a matter of taste. I think it is safe to say that support
STARTTLS (with TLS 1.2 and perhaps also TLS 1.3) is now expected
best-practice behaviour. Just TLS 1.0 (or 1.1) are likely to soon if
not already encounter interoperability issues as operators start to
phase out these now deprecated TLS versions. Beyond that,
* Many will recommend DKIM and SPF. I am not a fan of these, but
I grudgingly added SPF to reduce some friction. Some will also
strongly recommend DMARC, which I personally find particularly
objectionable.
* I'd like to recommend DNSSEC and DANE to secure inbound email,
and there is noticeable support and momentum behind this in
Northern Europe. However, overall support for DNSSEC and DANE
is still the exception and not the rule.
https://stats.dnssec-tools.org/
https://mail.sys4.de/pipermail/dane-users/2020-January/000546.html
Please deploy DNSSEC and DANE, but these are not suitable as a
fire and forget fashion statement. They take some operational
dilligence to implement correctly, with monitoring and carefully
thought out key rollover processes a must.
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
* To secure inbound email from Google, Microsoft, et. al, you could
also implement MTA-STS, which like DANE also requires some care
and feeding. Don't to it unless you can do it right.
--
Viktor.
