On Fri 02/Aug/2019 00:15:30 +0200 Scott Kitterman wrote: > Taking a step back, iprev uses the policy ptype. It's also based on local > interpretation of DNS data. Why doesn't policy work for dnswl just like for > iprev?
Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/, does not contain the term "policy". 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. 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. Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
