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, "Дилян Палаузов" <[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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
