Since AMS i=1 doesn't pass, the information included in Set 2 only says that site3 claims that site2 said that spf passed, whereas in Set 1, the AS allows you to verify that site2 actually claimed that spf passed.
Now, since the i=1 AMS doesn't pass, it is true that the i=1 headers in both cases could have been either made out of whole cloth (in Set 2) or copied from an existing message (in Set 1). Your formulation also means that who asserted anything in i=1 is now missing. You could include information in the i=1 aar on who made the assertion (srv-id?) or not strip the broken AMS for i=1. Looking at my whitelist based local policy override code, it doesn't care about the seal, the seal is only used to verify the intact arc chain. So, assuming some changes to what you're saying, your handling of a single message is not different based on the two versions above. That is not the only utility of the arc chain, however. AS allows me to verify that what was asserted was asserted by the actual service, but not that that assertion applies to this message. The fact that it applies to this message is based on trusting the services which handled receipt, yes. But your version allows a malicious actor to invent the path the message went through. With AS, they have to copy an existing chain, without it they can just write whatever they want. This distinction becomes more important when using the information as training data for learning which paths to trust and which not to trust. The AS certainly contains more information there, but perhaps that more information is only useful for the largest actors, and then maybe only as some small percentage of decreased false positives or the ability to allow trust further down the long tail. Without sufficient data and implementation, it's hard to judge whether the utility of this extra information is useful. Brandon On Mon, Aug 14, 2017 at 7:06 PM, Bron Gondwana <br...@fastmailteam.com> wrote: > Seth pointed out that my emails have been long and contained many points, > so I'd like to keep this really simple. > > I will propose two sets of headers on the same message, and I ask if > anybody can find a case where the set with AS headers provides some > information which is not present in the set without. Assume you are a > receiver at site5.com who just received this message on your MX and are > validating it. > > Set 1: > > AS: i=3; cv=pass; d=site4.com > AMS: i=3; d=site4.com > AAR: i=3; arc=pass (spf=fail spfdomain=site1.com dmarc=fail fromdomain= > site1.com) > AS; i=2; cv=pass; d=site3.com > AMS: i=2; d=site3.com > AAR i=2; arc=pass (spf=fail spfdomain=site1.com dmarc=pass fromdomain= > site1.com) > AS; i=1; cv=none; d=site2.com > AMS: i=1; d=site2.com > AAR i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain= > site1.com) > DKIM-Signature: d=site1.com > From: <f...@site1.com> > > Set 2: > > AMS: i=3; d=site4.com; h=aar:aar:aar:to:from:etc > AAR: i=3; arc=pass (arcdomain=site3.com spf=fail spfdomain=site1.com > dmarc=fail fromdomain=site1.com) > AMS: i=2; d=site3.com; h=aar:aar:to:from:etc > AAR: i=2; arc=pass (arcdomain=site2.com spf=fail spfdomain=site1.com > dmarc=pass fromdomain=site1.com) > AAR: i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain= > site1.com) > DKIM-Signature: d=site1.com > From: <f...@site1.com> > > In each case the AMS with i=2 and the AMS with i=3 are valid. > > I would love to see a case where Set 1 gives information that Set 2 > doesn't, because that would prove that my understanding was incorrect. > > Regards, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > br...@fastmailteam.com > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
