On Tue, Nov 3, 2026 at 5:23 PM Tero Kivinen <[email protected]> wrote:
> Bron Gondwana writes: > > > Which basically means, as has been stated by Richard many times in > > many IETF calls and emails (and by me) that what you're doing needs > > a trust relationship with either the sender (in which case you > > re-originate) or the final recipient (in which case they override > > the PERMERROR for known sources, basically they don't re-validate > > DKIM2 if the message comes from you, they trust your validation). > > Unfortunately that does not work. I am pretty sure google/yahoo/etc > are saying no, when I say that for my emails they should trust DKIM2 > results from the iki.fi which will be forwarding my emails to there. > > They have not been able to implement such feature for the ARC, so I am > not holding my breath that they will implement it for DKIM2. Hi Tero, I am curious to hear more what you mean. When I was at Gmail we were using iki.fi Arcs headers. I made sure we were doing so because it would have been a big issue when no auth no entry was enforced otherwise. What do I mean? If iki.fi took a mail that had only an SPF pass and forwarded it along with an ARC chain added then we wouldn't treat it as unauthenticated and reject it. This is true for any forwarder that adds ARC headers because with the ARC chain we don't need a trust relationship to know that this message transited through the ARC signer, making the message no longer unauthenticated. Note, because we didn't have a trust relationship defined this does mean that if the message has p=reject and was only passing because of the SPF then it would be rejected. So fromHeader munging would still be necessary. I imagine other providers would handle this differently. I just wanted to clarify this because while I acknowledge the handling probably falls short of what you would like, the ARC chain was used to some extent. Best, Emanuel >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
