On Tue, May 19, 2015 at 9:19 AM, Terry Zink <tz...@exchange.microsoft.com> 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
