Emanuel Schorsch writes: > 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. > > I am curious to hear more what you mean.
I mane there has not been any user visible way of setting trusted ARC signers in those big players. > 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 news to me. I have never heard that gmail would be doing that. But what you seem to indicate there, that this some kind of global setting, not per user setting. As I have been trying to explain the usefulness of the ARC only comes when recipients can configure the trusted ARC forwarders themselves (or the system might automatically configure it if it sees that user seems to want to receive those emails having that ARC signer, by moving them out from spam folder or similar means). Person who is not using iki.fi forwardin should NOT use ARC headers signed by iki.fi, as he should not be getting those emails to his mailbox. And we had lots of (big) companies in Finland using SPF only setting, i.e., not adding DKIM headers. After no auth no entry this slowly started to change, and now we have more and more companies in Finland actually also adding DKIM signatures. And then there are of course some big companies who require BOTH SPF and DKIM for entry :-( > 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. It is no longer unauthenticated, but it still might be unauthorized, i.e., someone might maliciously forward his iki.fi emails to some other user, and then email would be authenticated by iki.fi ARC, but it would still be unauthorized by the final recipient. Not really going to happen in iki.fi, as we are non-profit organization, so we do have requirement to know real names of our members, so if someone would do that, it would be really easy to catch that person. But this kind of thing could happen if you have free email forwarding service where anybody can set up forwarding to anywhere. > 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. Ah, so that ARC header only affected whether you allowed mail to come in, but it did not affect the DMARC authentication at all. > 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. I think ARC is useful in multiple different ways, you explained one, I have explained another, and the most common use for me is for finding out why some email was not delievered... I.e., when we have user complaining that this email was rejected by xxx, and we get the original email, we can check the ARC header generated by iki.fi and see whether there was DKIM, SPF, DMARC pass at that point, and if we for example notice that there was SPF pass but no DKIM records, we can instruct them to fix their sending system to add DKIM signature. -- [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
