Re: [dmarc-ietf] Prove me wrong!

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 <brong@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: <foo@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: <foo@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
>   brong@fastmailteam.com
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>