On Thu, Aug 4, 2022 at 7:37 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> RFC 9091 provides a way to detect misuse of unregistered organizations, > one level below the PSD/Registrar level. Use of an unregistered name is > inherently a form of unauthorized impersonation. Consequently, the test > may be used whether the PSD has published a policy or not, and the default > can reasonably be set to reject on non-existence. Every PSD policy should > have a NP policy, but if it is omitted, I have a hard time justifying why > the SP policy should be used in its place. > > For unregistered organizations, the NP test will produce the same result > whether the RFC5322.From address or the PSD+1 organization name is used, > but when it is applied to registered organizatios, the choice matters. > > When an organization is properly registered, only the domain owner decides > whether RFC5322.From addresses with non-existent domains may be used. > Absence of a DMARC policy does not transfer that right to the PSD or > registrar. To properly limit the scope of the NP clause on a PSD policy, > the non-existence test for PSD=Y policies should be based on the PSD+1 > organization name only. > > Within a registered organization, use of a non-existent RFC5322.From > address is not inherently suspicious and is not uncommon. Non-existent > subdomains will currently authenticate for DMARC using using relaxed > alignment. However, a domain owner may wish to use his DMARC policy to > announce that he never uses non-existent names within his subtree. This is > done by publishing a NP policy. When this is the case, the non-existent > test is applied to the RFC5322.From domain name. When a DMARC policy is > found but the NP term is omitted, all subdomains are handled equally, and > the SP term applies. > > So we have a double error: We fail to distinguish between the two types > of tests, and we fail to distinguish between the two different default > conditions, and we have not provided upward compatibility with RFC 9091. > > I'm struggling to understand what you're trying to say here. Below is section 4.7 from https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-15.txt. Can you please highlight the specific text you're taking issue with and help me understand how it maps to what you've written above? 4.7. DMARC Policy Discovery For policy discovery, a DNS Tree Walk starts at the point in the DNS hierarchy that matches the domain in the RFC5322.From header of the message. The DMARC policy to be applied to the message will be the record found at one of these three locations: * The RFC5322.From domain * The Organizational Domain (as determined by a separate DNS Tree Walk) of the RFC5322.From domain * The Public Suffix Domain of the RFC5322.From domain If the DMARC policy to be applied is that of the RFC5322.From domain, then the DMARC policy is taken from the p= tag of the record. If the DMARC policy is taken from either the Organizational Domain or the Public Suffix Domain and that domain is different than the RFC5322.From domain, then the DMARC policy is taken from the sp= tag (if any) if the RFC5322.From domain exists and the np= tag (if any) if the RFC5322.From domain does not exist. In the absence of applicable sp= or np= tags, the p= tag policy is used for subdomains. If a retrieved policy record does not contain a valid "p" tag, or contains an "sp" or "np" tag that is not valid, then: * If a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver MUST act as if a record containing "p=none" was retrieved, and continue processing; * Otherwise, the Mail Receiver applies no DMARC processing to this message. If the set produced by the DNS Tree Walk contains no DMARC policy record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to the message. Handling of DNS errors when querying for the DMARC policy record is left to the discretion of the Mail Receiver. For example, to ensure minimal disruption of mail flow, transient errors could result in delivery of the message ("fail open"), or they could result in the message being temporarily rejected (i.e., an SMTP 4yx reply), which invites the sending MTA to try again after the condition has possibly cleared, allowing a definite DMARC conclusion to be reached ("fail closed"). Note: PSD policy is not used for Organizational Domains that have published a DMARC policy. Specifically, this is not a mechanism to provide feedback addresses (rua/ruf) when an Organizational Domain has declined to do so. -- *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
