* https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...
* https://datatracker.ietf.org/wg/dkim/about/
* https://blog.redsift.com/email/dkim/first-look-at-dkim2-the-...
The recently-held IETF 122 had a session on it:
So it seems, to me, that SPF is working exactly as it ought to. Just to be clear, this isn't pure theory or ignorant preference on my part, I've set up SPF for trusted forwarders before.
In the end once the letter has left your server, it is _not_ up to you to decide what they do with it. We already have ARC to basically bypass SPF when DKIM is missing. Letters _will_ be forwarded.
SPF is obsolete and weak in other ways as well. A mere IP address is not the proper way to authenticate or authorize anything.
Maybe so! But if I create the SPF record, it should be enforced. If I don't want it enforced, then I wouldn't have created it! I think, though, where we're converging is that, if you have DKIM at all, then you shouldn't even use SPF. Supporting both in DMARC was a hack.
Nevertheless, I think a lot of time and effort is getting expended to slap security on top of the email system of the 1980s but the practical reality is that email cannot possibly work like it did in the 1980s and we need to stop pretending like it can. If I send an email to a mailing list, it shouldn't be passed off as mine when forwarded. Just as hubs have been replaced with switches in Ethernet, so too should blind repeaters be replaced with smart forwarders (this analogy is not perfect). An email coming from a mailing list is a product of the mailing list, not the original sender. It's not like we don't have the Reply-To header! Moreover, internal forwarders for things like spam filtering and virus scanning and corporate domain forests are internal infrastructure problems that shouldn't be treated as something which the sender has to prepare for. Maybe that's too idealistic, but it's not like I'm dying on the hill that we should have rolled out global S/MIME!
As regards DKIM and length extension, I'm not aware of any way to force it off. Yes, its use may be down to "badly configured" servers (ironically, the whole point of it was to handle forwarders), but nearly everything wrong with email is down to "badly configured" servers in the first place!
I think it's actually the exact opposite, it should be possible to keep origin information intact. This lets everyone verify that it's "x through mailing list y" instead of "mailing list y saying it was x". It's a massive difference and lets the mailing list operate separate from the reputation of the content (from some other domain).
> Moreover, internal forwarders for things like spam filtering and virus scanning and corporate domain forests are internal infrastructure problems that shouldn't be treated as something which the sender has to prepare for.
And it isn't. But wanting it to be more difficult is simply not viable.
With DKIM2 coming, that kind-of combines DKIM and ARC, SPF will become even more useless and a hindrance. And signatures will be much more resilient to forwarding even with (some) modifications. This is what the industry wants, not the opposite.
> Maybe that's too idealistic, but it's not like I'm dying on the hill that we should have rolled out global S/MIME!
S/MIME is being revived as well right now. So who knows how it'll go, maybe that's an another thing we'll be getting.
> As regards DKIM and length extension, I'm not aware of any way to force it off.
Just don't use the length tag, then it's off.