> Sure, but can it just be in a comment if you find that useful, or is it > necessary to > make that fact something a consumer of the field can parse out? Putting it into a comment is fine, maybe something like “dmarc=pass action=none header.from=<domain.com> conditional.to=<mailinglist.net>”. I think it’s permissible to add additional fields like that into A-R, isn’t it?
> I've always found the details of how it came to that conclusion to be of only > secondary interest I agree with the reasons you outline, but when debugging and troubleshooting potentially tens, hundreds, or thousands of messages per day, it’s no longer secondary. It’s also easier to collect statistics on how many messages are conditionally passing DMARC and what mailing list or forwarder it is attached to. -- Terry From: Murray S. Kucherawy [mailto:[email protected]] Sent: Tuesday, May 19, 2015 10:56 AM To: Terry Zink Cc: Scott Kitterman; [email protected] Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy On Tue, May 19, 2015 at 9:19 AM, Terry Zink <[email protected]<mailto:[email protected]>> wrote: >> I would think you'd have to. There's a replay risk that's unique to this >> type of >> signature, so I think treating them the same would be a naive approach. > But is that something that an agent downstream of a verifier needs to know? > A-R for SPF doesn't differentiate between "-all" and "~all", for example, nor > does it relate key sizes or header field selection from DKIM. It’s useful for debugging afterwards. Someone, somewhere, will send me a sample message that passed DMARC when it shouldn’t have (but in reality passed because of a conditional DKIM) and it’s useful to have this in the results. Sure, but can it just be in a comment if you find that useful, or is it necessary to make that fact something a consumer of the field can parse out? The idea behind A-R all along has been to be able to say "method X passed/failed/whatever for this message, and the things it authenticated are A and B". I've always found the details of how it came to that conclusion to be of only secondary interest because: a) They might no longer be true at the time an MUA processes that header field; this is supposed to reflect what the ingress MTA saw. b) The goal is specifically not to allow MUAs or downstream agents to repeat the authentications done at the ingress MTA, otherwise why bother having the border MTA do it? There's also a DDoS possibility if every MUA or downstream agent repeats checks. c) Having to keep all the MUAs current on message authentication techniques is a much bigger burden than just updating ingress MTAs, so that model is observed. See RFC7001, Appendix D, for details. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
