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

[Scott Kitterman <[e-mail]>]

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, "Дилян Палаузов" <[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