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.
Scott K On July 30, 2019 1:34:46 PM UTC, "Дилян Палаузов" <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc > >_______________________________________________ >dmarc mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
