On Wed, Aug 3, 2022 at 11:42 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> > Consider: A message has a verified DKIM or SPF domain which exactly > matches the RFC5322.From domain. > I don't understand what you're saying here; specifically, I don't understand what you mean by "verified DKIM/SPF domain". I understand the terms "valid DKIM Signature" (i.e, one that has passed validation checks performed by the receiver) and I understand what is meant by saying that a message has passed SPF validation (i.e., the message source is present in the Return-Path domain's SPF record), but I don't know what you mean by "verified DKIM or SPF domain". Can you please help me understand? > > In this case, the only applicable information in a policy record is the > reporting address(es). But the specification does not require evaluators > to send reports and does not require domain owners to request reports, so > these three situations are functionally equivalent: > Section 5.2 of the current rev describes the 'p' tag as RECOMMENDED for policy records, and further says that if no 'p' tag is present, the record is treated as if included "p=none". Therefore, functionally, there is no such thing as a policy record that only contains reporting addresses. The only valid DMARC record that doesn't contain an explicit or implicit 'p' tag is one published by a third-party report receiver, as currently documented in RFC 7489 ( https://datatracker.ietf.org/doc/html/rfc7489#section-7.1) and to be documented in the separate DMARC Aggregate Reporting document. > 1) The reporting address is not used because the evaluator does not send > reports. > 2) The reporting address is not used because the policy does not provide > an address. > 3) The reporting address is not used because a policy has not been > published. > See above. The record "v=DMARC1; rua=f...@example.com" would have an implicit policy of "p=none", so a policy has been published, and condition 3 doesn't exist. > > However, our specification says that for the third option, the evaluator > must ignore the exact-match verification and therefore treat the message as > having authentication status "unknown". This makes no sense. > There are precisely two occurrences of the word "unknown" in rev -14 of DMARCbis, and both are used in the context of referring to "unknown tags". I don't know what you're referring to here. > More generally, I object to any imposition of "must" on an evaluator. His > only "must" is to act in his own best interest to protect himself from > harm. Ignoring obviously favorable data is not in his interest. > There is currently no "MUST" with regard to sending reports. Section 5.7.4 of rev -14 says "Mail Receivers SHOULD generate and send aggregate reports..." -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
