meta: on mail header forgery (was Re: [ANN] Lua 5.4.0 (work1) now available)

[Jay Carlson <nop@...>]

Irony: this message will likely be flagged as spam.

Here's the DMARC side, mostly focusing on DKIM. I hope I am not igniting a big flamewar; I think the two positions on this are pretty well-represented between these two messages. I think people of good faith can disagree on this (they do!) even though one of the sides is stuck in the 20th Century. ;-)

On Mar 26, 2018, at 9:19 AM, Jonathan Goble <jcgoble3@gmail.com> wrote:

> [...]
> Yahoo's recommended solution for mailing lists, the last time I checked, was for the list to remove the sender's address from the From: header and replace it with the list's own address, but IIRC there's some internet standard (maybe an RFC?) that doing so violates. So the only real solution is to not use Yahoo addresses with mailing lists.

Someone is using nop@nop.com as a From spam address. A lot. What should I do?

The flip answer is "lol abandon your email address." nop@nop.com has existed since 1995, and it's a lot more than business cards that would have to be reprinted.

Either DKIM/SPF or traditional mailing lists are broken, and I strongly believe it's the mailing lists. Would you let a mailing list sign messages with your PGP key? No, it should wrap the messages with its own key, since that's the identity of the responsible party.[1][2][3]

I think the explanation below is an unnecessary compromise, but OpenWrt's mailing lists obsequiously do a full wrap of the rfc822 message.[4] The outer message is:

> From: Noah Meyerhans via Lede-dev <lede-dev@lists.infradead.org>
> 
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
> 
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.

and it includes the original message as an inline MIME rfc822:

> From: Noah Meyerhans <frodo@morgul.net>


At least in Apple Mail, the embedded message really is inline, and functions as a body.

The archives don't bother with the outer message, which is just there to support the "don't change the From header" doctrine. The archives are not sending mail, so it's the HTTPS certificate that would be authenticating that.

https://lists.infradead.org/pipermail/lede-dev/2018-March/011632.html

--
Jay Carlson
nop@nop.com

[1]:  Why do we sign headers at all? Because the Internet is a very different, and more hostile place than it was thirty years ago. I know that people don't want to update their mailing list software, but essentially everything else about how we process email in practice has changed.

[2]: The "obvious" way to make this work is for me to delegate partial authority to the mailing list to send mail on my behalf. Thinking about the implementation and usability, I'll say "lol" again.

[3]: Before there was crypto covering the headers, mailing lists could be seen as both pure reflectors and as resenders; there were no significant practical differences. People built their personal mental models around one of the two forms, not really knowing that some people thought of them the opposite way.

Crypto forces the issue. There's no reason you can't build crypto systems that allow broad message header forgery too, to support the reflector model, but they aren't that useful. "From" is arguably the most important mail header today, and systems that don't cover it in some way don't solve many problems. Does anybody support authentication against X-Forwarded-By? Should they?

PGP doesn't cover the headers, so it's fine with both reflectors and resenders, I could live with "reject all message content 'From' nop@nop.com which is not PGP- or S/MIME-signed." There's no way to declare that, as far as I know.

I'd also be OK with some kind of magic word in the body that says, "exempt this one message from DKIM". And of course I'm OK with people declaring, "lua-l will not spam me much, so do not reject DKIM-fail messages from it."

What's not acceptable is for random people to be able to wreck an email address casually, remotely, and untraceably. I think a lot of the anti-DKIM people haven't experienced this, or don't believe they'll have this problem.

[4]: Interestingly, this also resolves fights over what "Reply-To" should say. Because the mailing list is forwarding mail under its own identity and responsibility, it can make its own choice of headers on the outer message.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail