Dave Crocker said: The challenge to the receiving site, then, is to decide whether to > believe that evaluating intermediary site (as well as then deciding on > an evaluation or the originating site. >
This is exactly the point that I was making earlier and I 100% agree with that. In order for ARC to be fully operational, the receiving party must have a way to know if the sender can be trusted or not. With ARC, this requires either a whitelist/blacklist system or relies on an external service that provides that list. Relying on an external service is even worse as they could implement a "pay to be on the list" system where only the big one could be in. Setting up a blacklist would cause too much damage for the receiver as they would initially accept many bad emails before considering a sender bad. The purpose of the service I run (ImprovMX) is exactly to forward email, so we had our fair share of thinking on how to make it work properly. SPF is not an issue at all, since it relies on the Return-Path email to be verified: You can change it to your own and have a way to match any response sent back (bounce, arf report, etc) to the original return-path to reverse the steps. One thing though you need to be sure of is that the sender either hasn't implemented DMARC or has a valid DKIM Signature with the domain aligned to the envelope From. Because DMARC requires domain alignment in **either** the SPF or the DKIM domain part. Since forwarding breaks the alignment in the SPF, it must remain valid in the DKIM. ARC fixes this issue, by saying "It was ok before, but I broke it when forwarding it", but it remains problematic regarding trust of the sender. Le dim. 19 juin 2022 à 14:24, Dave Crocker via mailop <mailop@mailop.org> a écrit : > > On 6/17/2022 6:17 AM, Paulo Pinto via mailop wrote: > > tldr; what ARC tries to address is already correctly handled by > > DKIM/SPF/DMARC if used as designed. > > None of those provide an authenticated handling record in the message. > > ARC is motivated by the cases where DKIM/SPF/DMARC information about the > author/originator get broken. > > With ARC, besides a authenticated handling sequence, there is > information about those original authentication tidbits that got broken, > when the site providing the tidbits says how its own evaluation went. > > The challenge to the receiving site, then, is to decide whether to > believe that evaluating intermediary site (as well as then deciding on > an evaluation or the originating site. > > d/ > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
