Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields

["Stan Kalisch" <[e-mail]>]

On Tue, Jul 30, 2019, at 9:57 AM, Scott Kitterman wrote:
> The published policy (that's why I suggest dmarc.policy). I'm not sure if disposition belongs in A-R. If it does, it'd be a local policy override, probably policy.dmarc as described now in RFC 8616.

In that case, if the downstream were to make use of the upstream's disposition, it's extrapolating a meaning from the disposition, but not actually deriving meaning from the authentication results themselves, so I'm inclined to agree.


Thanks,
Stan

> Scott K
> 
> On July 30, 2019 1:34:46 PM UTC, "Дилян Палаузов" <[e-mail]> wrote:
> >Hello Scott,
> >
> >do you want to include in the A-R header the published policy, as
> >obtained from DNS (my first interpretation of your
> >proposal), or the disposition of the message after applying
> >DKIM/SPF/DMARC validation, pct sampling, and the ominous
> >reject→quarantine sampling conversions?
> >
> >With disposition I mean what is called at
> >https://tools.ietf.org/html/rfc6591#section-3.2.2 Delivery-Result.
> >
> >For the disposition on p=reject only the MTA can make the decision
> >based on pct to reject, so it makes sense if the
> >result of disposition is included in the A-R header by the MTA and
> >consumed by the MDA. In turn, including pct and
> >published DMARC policy in the A-R header, so that the MDA can do the
> >sampling, does not make sense.
> >
> >If you want to call the new parameter “policy”, then it shall be
> >articulated that it means disposition, and not
> >published policy.
> >
> >I am in favour of the proposal.
> >
> >It allows for forwarded emails/aliases to indicate in the A-R header,
> >that sampling was already performed by the
> >aliasing server, and the final server that accepts the email can skip
> >performing the sampling again. Performing the
> >sampling again has the disadvantage, that the pct= parameter is
> >misinterpreted, as the parameter is supposed to be
> >applied only once.
> >
> >On the other side, skipping of the second sampling by whatever server
> >is pure theory, and has no practical impact.
> >
> >Greetings
> > Дилян
> >
> >On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote:
> >> On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman wrote:
> >> > I'd like to add the option to record DMARC results in an A-R header
> >field
> >> > for consumption by a downstream processor. I think it would be
> >something
> >> > like this:
> >> > 
> >> > Authentication-Results: mail-router.example.net; dmarc=pass
> >> > header.from=example.com policy.dmarc=none
> >> > 
> >> > That would take adding an entry in the Email Authentication Methods
> >registry
> >> > for:
> >> > 
> >> > method: dmarc
> >> > ptype: policy
> >> > value: dmarc
> >> > 
> >> > Does that make sense as a way to do it? Does anyone have
> >alternative
> >> > suggestions?
> >> 
> >> I think comments should be free-form. If we want data that can be
> >machine 
> >> parsed, we should specify it.
> >> 
> >> I think the above works in ABNF terms. It's:
> >> 
> >> Authentication-Results:" authserv-id; method=result
> >ptype.property=value 
> >> ptype.property=value
> >> 
> >> According to the ABNF, there can be more than one propspec 
> >> (ptype.property=value) per methodspec in resinfo, so I think it's
> >legal. It 
> >> would just need the new registry values for dmarc.
> >> 
> >> Scott K
> >> 
> >> 
> >> _______________________________________________
> >> dmarc mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dmarc
> >
> >_______________________________________________
> >dmarc mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/dmarc
> 
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>