Below is draft language which implements the design principles in my previous email. Some additional content is needed to discuss NP policy within an organization, and to describe the mechanics of the first tree walk, and to define the second tree walk.
Doug Foster Organizational Domain The organizational domain is a boundary point which serves as the upper bound for relaxed alignment tests, and provides the reference point for default subdomain policies. DMARC recognizes these types of organizational boundaries: A PSO Registration obtains its DNS subtree allocation from a Public Suffix Operator. The organizational domain is an FQDN comprised of the public suffix plus one segment. A Private Registration obtains its DNS subtree allocation from a PSO-registered organization. The organizational domain is the registration domain plus one segment. These arrangements are not recommended, but for accurate email authentication they are being acknowledged. A Partitioned Subunit chooses to have its DNS subtree treated as an independent unit for purposes of DMARC validation. Specifying the Organizational Domain Each registered organization SHOULD publish a DMARC record for its organizational domain name, and SHOULD include the term “org=y” to indicate that this name should be identified as an organizational domain. PSOs MAY publish DMARC policy records to serve as default policies for registered domains within their subtree. When this is done, the policy MUST contain the term “psd=y” to indicate that this policy is used only for disposition and reporting, but not for alignment, because every subdomain of this name is an independent entity. Private Registrars SHOULD publish a DMARC policy at the domain below which private registrations are issued, and this policy MUST contain the term “psd=y” to indicate that this policy is used only for disposition and reporting, but not for alignment, for the subtrees below this point. The psdy term prevents relaxed alignment from allowing one client domain from impersonating another client and having the impersonation incorrectly accepted using relaxed authentication. The presence of “psd=y” does not indicate that the domain is actually a PSO, only that subdomains should be treated as independent entities for purposes of DMARC evaluation. A single DMARC record may include both the “org=y” clause and the “psd=y” clause, since a domain may be registered with a PSO and may also grant private registrations using subdomains of its organizational domain. The “org=y” indicates that a boundary exists between this domain and the parent domain, while the “psd=y” indicates that a boundary exists between this domain and all subdomains. Consequently, the “org=y” term takes precedence when testing for strict alignment, while the “psd=y” term applies when walking up from a subdomain to detect the boundary for relaxed alignment. Because an Organizational Domain must be registered, that registration must be verifiable, as evidenced by a detected resource record within the organizational subtree. This requirement is satisfied if a DMARC policy is found within the organizational subtree. However, if DMARC is applied because of a “psd=y” policy occurring on the organizational parent, existence is uncertain. To provide certainty, a DNS lookup MUST be performed on the organizational domain. If the lookup returns NXDOMAIN, the organizational domain has no resource records, and the DMARC result is FAIL-UNREGISTERED. Finding the Organizational Domain The organizational domain is determined by walking up from the RFC5322.From domain to toward the top-level domain. - If a DMARC policy with “org=y” is found, the associated domain is the organizational domain. - If a DMARC policy with “psd=y” is found, the first child of the associated domain is the organizational domain. - If no policy is found containing either “org=y” or “psd=y”, then the top-most policy found is the organizational domain. - If no policy is found, the domain does not participate in DMARC. Note that the organizational domain is not used, and the evaluator does not need to compute it, when: - a DMARC policy is published for the RFC5322.From domain, and - the policy requires strict alignment for both SPF and DKIM, or DKIM PASS is achieved using identifiers that have strict alignment. Security Considerations -- Improper Alignment If a PSO publishes a policy record without the “psd=y” term, and organizations publish no policy or publish a policy without the “org=y” term, then the PSD policy will be treated as an organizational domain and relaxed alignment may allow intra-PSD impersonations to be authentication. This is why PSD policies MUST include the “psd=y” term. To mitigate the risk from an error of this type, and to improve processing efficiency, organizations SHOULD publish an organizational domain policy with the “org=y” term. Similarly, if a Private Registrar publishes a DMARC policy for its organization, but fails to publish a “psd=y” policy for his client registration point, his clients may be able to impersonate each other and improperly pass DMARC authentication using relaxed authentication criteria. Clients SHOULD mitigate this risk by publishing a DMARC policy with “org=y” at their organization’s top-level domain. Security Considerations – Altered Scope for Relaxed Alignment Because RFC7489 uses an externally-obtained public suffix list for relaxed alignment, the alignment test does not require a DMARC policy record at the Organizational level. By the algorithm used in this document, the organization must publish a DMARC policy for the organizational domain, to cause relaxed alignment to be applied correctly. When an organizational domain policy is missing, the scope used for relaxed alignment will be restricted to a subset of the entire organization, based on whatever lower-level policy is detected and applied.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
