The report receiver verification step was referenced in the response. This was the pointer:
https://tools.ietf.org/html/rfc7489#section-7.1. It requires a DNS entry at: <sourcedoman>. _report._dmarc.<domainname>, type TXT, value "v=DMARC1" (No other content is specified.) Since the DNS location, the purpose of the entry, and the content are all different, I do not see that it has any bearing on the question of whether "p=" is required or not. p=none probably means "I am trying to get my administrative controls in place, but I am not there yet", which still supports my earlier comment that "I don't know how to advise you on whether to accept or reject this message". If p=missing means, "I am trying to get my administrative controls in place, but I am so chaotic that I cannot construct a compliant DMARC record", then I don't know why I should take the policy seriously. If p=missing means "I am not trying to get any administrative controls in place, but I like to know whether my bot network is successful", then it is still not a DMARC record that I want to take seriously. Overall, it is a small requirement to insist that the domain owner publish a compliant DMARC policy. In addition, I propose making rua reporting mandatory. A domain owner that does not want to learn about, and correct, his configuration errors cannot be a reliable source of policy information. False positives will persist indefinitely, and therefore the policy record itself cannot be trusted. Domain owners with persistent errors made SPF pretty much useless until DMARC came along. I don't want to see it repeated. Doug Foster ---------------------------------------- From: Steven M Jones <s...@crash.com> Sent: 11/7/20 4:54 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Optional p= makes no sense On 11/7/20 1:11 AM, Alessandro Vesely wrote: > On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote: >> On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote: >> >>> It makes no sense to allow "p=" missing. Why would we suggest that >>> all >>> existing implementations alter their code to tolerate additional >>> unnecessary complexity, rather than requiring domain administrators >>> to key >>> a few more characters so that code changes will not be necessary? > > > Are there really implementations that choke on missing p=? > > How about "v=DMARC1; p=none; p=quarantine;"? I'm pretty sure both cases would be invalid as DMARC policy records, in which case they should be ignored. If an implementation is trying to do something with invalid records like these, particularly one with multiple "p=" tags, then that would be a problem. > > >>> I also don't understand this comment from Alessandro : >>> >>>> "Operators who don't need policy, for example external report >>>> receivers who just want to publish verification records, would find >>>> the relevant >>>> info in the base spec." >> >>> There is only one policy record, published by the domain owner. The >>> DNS >>> record either suggests enforcement (p=quarantine, p=reject) or it >>> does not >>> (p=none, p=missing, no DMARC record). >>> >>> >> I can't speak for him, but I believe he's referring to the records >> that a >> report consumer outside the authority of the domain at issue might >> publish, >> as documented currently in >> https://tools.ietf.org/html/rfc7489#section-7.1. >> In those cases where, for example, foo.com publishes a DMARC policy >> record >> with a rua= value of say "repo...@bar.org", there must exist a TXT >> record >> of "v=DMARC1" at foo.com._report._dmarc.bar.org in order to confirm that >> bar.org is consenting to receive these reports. > > > Exactly! Dropping the requirement allows the definition of DMARC > record to be unique. Not a terrific gain, just a little simplification. I'm not aware of any requirement for third party report receivers to publish a DMARC policy record for their domain, in order to operate as report receivers. If that's what you meant, Ale, can you tell us where it appears in RFC7489 or the -bis spec? --S. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
