"Cloudfare" is not qualified, so it does not credibly mean "This message was submitted by user Cloudfare with his correct password.". This guess can be validated by checking where the ARC set appears relative to the Received chain.
Since we know that Cloudfare is a large hosting service, I suspect the sender is asserting, "I am sending this messages through Cloudfare after logging into their server with a username and password." This is a misuse of ARC and this initial ARC set should be ignored. Doug On Wed, Jul 5, 2023, 10:15 PM Marcello <[email protected]> wrote: > Hey there, > > I was hoping to run a few questions by the authors of the ARC protocol. > > Long story short, I've discovered an email transaction service that always > claims "auth=pass" in it's AAR header, see the following example: > > ARC-Authentication-Results: i=1; rspamd-9fcc56855-j2crh; > auth=pass smtp.auth=cloudflare > [email protected] > > > This is how their AAR header *always* looks like regardless of the > senders domain SPF/DMARC/DKIM record. My questions here are: > > > 1. is "auth=pass" a valid property in the AAR header? RFC 8617 seems > to indicate you can technically put anything you want but all the examples > I've seen are different and actually have SPF/DMARC/DKIM check results. > (e.g. spf=pass etc..) > 2. Can an ARC chain be considered valid in the case where the first > hop (i=1) has the above AAR header and doesn't actually check > SPF/DMARC/DKIM of the sender domain? > 3. How should the final Email service provider treat an email with an > AAR header like the above? > 4. Should not having SPF/DMARC/DKIM checks in the AAR header result in > an arc=fail? > > > Thank you for your time. > > Marcello > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
