Thank you Richard, this was very helpful! A few comments below. On Thu, Aug 27, 2026 at 3:16 AM Richard Clayton <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >DKIM1 currently allows the forwarder to pass along the message without > >modification. ARC helps forwarders comparatively more because now they can > >pass the mail along and don't make problems worse because if the next hop > >wants to take a stricter policy they can look inside the headers and see > it > >came into the forwarder unauthenticated and reject the message (I can > >attest that this was very helpful as I deployed no auth no entry in the > >past to handle forwarders without lowering the bar). > > my $DAYJOB$ experience with ARC is that "trusting" other people to get > it right is a snare and a delusion; and almost no-one (counting by > senders) uses it at all > My previous $DAYJOB$ experience included rolling out enforcement of NoAuthNoEntry, an experience which I think will bear similarities to the eventual transition off of SPF/DKIM1 to DKIM1. I hear you and others that ARC didn't live up to its vision because it's extremely hard to "trust" others. And that is true for "positive trust". But for this use-case it actually was extremely helpful, and I can attest a significant number of forwarders adopted it and it improved their experience during our NoAuthNoEntry rollout. Let's call our forwarder, "fwd.com". Because a valid ARC chain proves that ` fwd.com` is the recent intermediary, and so now I can track reputation on it as a forwarder. So at minimum, I don't need to treat the mail as unauthenticated because I have an entity to index on. The stakes are high for `fwd.com` because if they let any meaningful amount of spam/phishing through then their entire reputation will tank. So they have a strong incentive to keep a clean ship. But even better, ARC lets `fwd.com` clearly describe the previous authentication, and they have no incentive to lie about a previous message NOT having authentication (this is what I call "negative trust" since you are claiming things which hurt your deliverability). So I can actually look back and enforce a NoAuthNoEntry policy on the mail as it arrived at `fwd.com`. To me, this is a far more workable system for allowing a gradual transition. Let's say `fwd.com` is well-intentioned, they want to comply and create a better ecosystem! But they're in a hard place because they don't control whether the originating mail has DKIM2 or not. And one important receiver they have wants to enforce NoAuthNoEntry and another reciever isn't ready to do so yet and definitely wants that mail. Keeping track of every receiver's preferences is extremely hard. What ARC gracefully allows is for `fwd.com` to preserve visibility so that they pass it along and allow receivers to take the local policy that they want. That way instead of needing a centralized plan for when EVERYONE needs to enforce NoAuthNoEntry, the forwarder can remain in place and receivers can gradually adopt NoAuthNoEntry, gradually pushing the ecosystem forward, until one day some years later enough receivers have adopted the desired authentication and a centralized plan for a global NoAuthNoEntry policy can be adopted. I expect there will be a similar transition for DKIM2. I say all this because forwarding, while small by volume, is a critical use-case for both consumer and enterprise use-cases. In my previous experience at $DAYJOB, breaking forwarding across the board is not acceptable. In my opinion ARC had some features that allowed us to handle that edge case better. And without that, I worry that the deprecation of SPF/DKIM1 will only take longer as it will be harder to take the leap gradually. So if I'm understanding you right, I think this isn't a question of clarifying language in the spec. DKIM2 adds a ton of useful features which will make authentication more workable in places where ARC wasn't enough. But I think it is also true that there is a real feature that ARC had which has been lost which enables dealing with forwarding use-cases more gracefully. And I think it's worth discussion on how to re-enable that (perhaps in a simpler way). My strawman proposal would be to allow the forwarder to say something like: - I am not the originator for this mail. - When I received it I was able to validate that it had DKIM1 passing (or failing). And it had X MailFrom (or none). - I am starting a new DKIM2 chain here so if it stays in the DKIM2 ecosystem from here on out you at least now it wasn't exploded in between me and you. Best, Emanuel
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
