On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely <[email protected]> wrote:
> Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/, > does not contain the term "policy". > Wow. I'm amazed I got away with that. But it is clear from the things in the registry that that's how you do it. My recollection is that reporting the > client IP is immaterial, as for SPF. The term policy.iprev is certainly > misleading, since the value is not related to a locally-defined policy, > and is > not a reversed ip. To stick with A-R semantics, it should have been named > tcp.ip, remote.ip or some such. If a property warrants deprecation, it's > policy.iprev. > The choice of "policy" for "iprev" is rooted in history, because the earlier versions of the document (as you well know) demanded that the things being reported had something to do with the message itself. "iprev" was an exception the community chose to allow. It pre-dated RFC5782 which introduced DNSxLs formally. For guidance here, I would rely on anecdotes of implementation. Has anyone implemented something that attaches "iprev" results? Now for dnswl. Knowing which zone was queried is substantial in order to > interpret policy.ip, because there is no standard format. Yet, an > implementation could just throw a DNS query to a given local IP, instead > of a > FQDN to the default DNS server. In that case, one would have, for example: > > dnswl=pass policy.ip=127.0.9.2 policy.zone=127.0.0.2 > > In that case one can hardly tell which is which. A meaningful ptype helps. > Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"? I would expect it to have that knowledge, not downstream things. Again, I don't know what the value of "dnswl=pass" is if the thing attaching it doesn't even know how to interpret the result it got. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
