Rich Kulawiec via NANOG <nanog@lists.nanog.org> writes:
On Fri, May 23, 2025 at 01:49:07PM -0700, William Herrin via NANOG wrote:
I understand this has to do with DKIM crappiness where if any trace of the original email address remains in the From: header, the message may be rejected.
I believe it's DMARC, but: also crappiness. [...] But all this DMARC and DKIM complexity and bag-on-the-side-of-a-bag ad hackery must be worth it, because surely they have solved the spam problem (narrator: NO!) and forgery problem (narrator: NO, AYFKM?!).
These misunderstandings are rather common, so I'd like to point out a couple of things. First: SPF/DKIM/DMARC are not about spam, so that part is irrelevant. What they are about is protection against forged email. Next: no, these mechanisms do not totally solve the problem of forged email. As with every other problem faced by humanity, there is no silver bullet that alone fixes the whole thing. But they significantly improve the situation, and that's why they're used. A few words about each of these, from the point of view of a domain owner who wants to make it difficult for an attacker to forge email to look like it came from within that domain: SPF was the first. It lets you publish, through DNS, a list of the addresses of the mail servers that you have authorized to send email from your domain. When some mail server tries to deliver email purporting to be from your domain, you're asking the recipient mail server to check that list, and accept the email if the delivering mail server is on it, but refuse if it is not. SPF broke forwarding, both for individual recipients, and through email distribution lists, because the forwarding server wasn't on the list. DKIM was next. It lets you publish, again through DNS, the public key of a public/private pair. You then use the private key to create a cryptographic fingerprint of the message, using the body and a few selected headers (To:, Cc:, From:, and Subject: normally included). When a mail server out there receives the email, it can use your public key to verify the fingerprint. A match implies that the email has not been modified since it left the signing server. If the domain in the "From:" header matches the domain where the public key is stored, the recipient knows that the email was DKIM signed by a mail server trusted by the sending domain (since it must have the private key). It can, therefore, assume that the email really is from the "From:" address, and has not been modified along the way. DMARC, finally, ties these things together. It lets you publish, once again using DNS, a few policy options for the handling of SPF and DKIM, for what you want done with the email, and for reporting back to you what was done, and why. DMARC requires either SPF or DKIM to pass, and you can choose whether you want the recipient system to quarantine or simply refuse email that fails to pass at least one of them. A modern mailing list is not a simple forwarder. It sends out copies of the received email item (which, then, will have passed the DMARC requirements of the sending domain, if specified, or it wouldn't reach the mailing list software in the first place), but it will typically modify it before sending it out. This can be by adding a tag to the "Subject:" header (to help recipients direct the mail into a folder), by adding a footer that says which list this came from, and giving a link you can use to unsubscribe, or by making any of a number of other modifications list software sometimes makes. This will break DKIM - and SPF, of course, is already broken. So mailing list software today typically checks the originating domain's DMARC configuration. If that has a policy other than "none" (which says to deliver email even if it fails both SPF and DKIM), it will send the email "From:" the list, and not the originator. The email then nicely passes the mailing list's own SPF, of course. Additionally, the mail server sending it out from the list software will normally DKIM sign the outgoing email, so it ends up properly authenticating as coming from the mailing list software. This means that members of the list can choose to trust the mailing list owner to have configured everything so that they've properly verified the originating sender, and are not passing on something that is a forgery. If their own mail server is properly configured to check SPF/DKIM/DMARC, they can trust that the email is really arriving from the (trusted) mailing list. This stuff isn't perfect, of course. As is obvious from what I wrote toward the end of the last paragraph, transitive trust is a problem that it would be nice to have a good solution for. ARC is an attempt at this, but has failed to gain traction. Let's hope that DKIM2 (which John Levine mentioned in another post in this thread), by attacking the problem from another angle, does better! -tih -- The creation of the state of Israel was a regrettable mistake. It is time to undo this mistake, and finally re-establish a free Palestine.