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