I use the certificate(s) generated by certbot for email as well as web.
There are two ways to use an x.509 certificate on an email server. The email server can use the certificate to authenticate itself and encrypt incoming connections via “STARTTLS” for receiving email, or it can present the certificate in client mode when making connections to MX port 25 for transmitting outgoing email.
Both practices seem to be a good idea, but it does not (yet) seem to be practical at this time to require the foreign server to present a valid certificate in client mode when accepting connections on port 25 for incoming email. On the other hand, there seems to be very little problem refusing plaintext emails and requiring the foreign server to use some form of TLS encryption, even if it is not configured to present a valid certificate in client mode.
On the one hand, very few spammers bother with TLS at all, and on the other hand, almost all legitimate email-sending servers are capable of some form of TLS these days.
It seems to be a more prevalent practice to sign email headers with DKIM, rather than x.509 certificates in client mode for TLS, but the DKIM public keys are published via DNS, and are not generally signed unless one is using DNSSEC, so they are vulnerable to DNS poisoning attacks.
Are there better ideas or general pointers on these practices?
I personally use DNS headers for emails.
(Since first, my personal mail use GSuite… and I set SPF to fail if not match, also deployed DMARC)
SPF + DKIM + DMARC (with report time once per day and quarantine or reject if any validation failed)
For my major automated email domain I also used dnseec.
DNSSEC should be available with major register (or some DNS provider), so I guess it’s not a problem? (Some DNS provider can provide manual dnskey input, not available from user interface)
After all, it won’t harm you if you use both DNS headers and x509 and other methods…
I think SPF, DKIM, and DMARC are OK solutions for sender authentication if you are worried about spammers, since in practice, spammers don’t need to poison DNS caches (not impossible, but has become increasingly difficult) to reach a large number of inboxes-- although data or research showing the contrary would convince me otherwise.
It’s unfortunately true that it is not currently feasible to validate certificates, since many mailservers present self-signed certs. The folks at IETF have been working on a draft for MTA-STS, which is in last call. The spec asks domains to publish their TLS policies at a .well-known HTTPS address, though it still relies on DNS somewhat to indicate a recipient domain’s support for MTA-STS. I’m also currently reviving an EFF project, STARTTLS Everywhere, which would act as another channel to deliver TLS policy & MTA-STS preload lists, to try to decouple the issue of e-mail authentication from DNSSEC adoption-- though this project is focused on recipient (rather than sender) authentication in order to prevent TLS MitM/downgrading.
For a long time now, I have found it difficult to get my outgoing email through even the most cursory spam filter without SPF. I was browsing the Web the other day and I found a how-to for OpenDKIM on Postfix, and I managed to install it and get a DKIM “PASS” from the GMail system and verify incoming DKIM signatures via a “milter.”
To be honest, I am still ignorant of DMARC and some of those related standards, but nonetheless I have found that presenting a valid x.509 cert in client mode does significantly lessen the chances of my outgoing email being classified as spam.
Yes, spammers do poison DNS caches, because spamming goes along with phishing, financial fraud, dealing illegal drugs, and all manner of such activity. Fraudsters do seem to have ready-made DNS cache-poisoning exploits for SPF + DKIM + DMARC, and again, to be honest, it is not that common to actually verify DNSSEC, because there are so many technical and corporate/business obstacles to getting it working correctly.