Greetings. I've been engaged in a spirited off-list discussion regarding the topic of relaxed alignment and the idea of a required relationship between two domains in relaxed alignment. I won't reveal the other party in the discussion, but I thought it best to bring the topic to the list to get consensus and clarity.
The question central to the debate I'm having is this: Given example.com as the Organizational Domain, are a.b.c.example.com and d.e.f.example.com in relaxed alignment? I contend that, as currently written, RFC 7489 and dmarcbis-04 contain text that puts those two domains in relaxed alignment. The text at issue supporting this claim is in RFC 7489 in sections 3.1.1 and 3.1.2, and in dmarcbis-04 in sections 4.7.1 and 4.7.2 and reads as follows: In relaxed mode, the Organizational Domains of both the DKIM-authenticated signing domain (taken from the value of the d= tag in the signature) and that of the RFC5322.From domain must be equal if the identifiers are to be considered to be aligned. In strict mode, only an exact match between both Fully Qualified Domain Names (FQDNs) is considered to produce Identifier Alignment. In relaxed mode, the Organizational Domains of the SPF-authenticated domain and RFC5322.From domain must be equal if the identifiers are to be considered to be aligned. In strict mode, the two FQDNs must match exactly in order for them to be considered to be aligned. My partner in the off-list discussion maintains that other text in RFC 7489 makes clear that the domains must have an hierarchical relationship (i.e., one must be a subdomain of the other) in order to be in relaxed alignment, and that this was the intent of the original authors. Examples of such text include the following: RFC 7489, section 3.1: Relaxed mode can be used when the operator also wishes to affect message flows bearing subdomains of the verified domains. RFC 7489, section 3.1.1: To illustrate, in relaxed mode, if a validated DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From address is "[email protected]", the DKIM "d=" domain and the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain are considered to be "in alignment". In strict mode, this test would fail, since the "d=" domain does not exactly match the FQDN of the address. RFC 7489, section 3.1.2: For example, if a message passes an SPF check with an RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom domain of "cbg.bounces.example.com", and the address portion of the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field contains "[email protected]", the Authenticated RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom domain identifier and the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain are considered to be "in alignment" in relaxed mode, but not in strict mode. Further, it seems to be the most common use case for relaxed alignment to be accomplished with domains that have a direct descendant relationship with each other, not just the common ancestor of the organizational domain. So, what is the consensus of the group here? If there MUST be a direct descendant relationship between two domains in order for them to be in relaxed alignment, then it seems that the text I cited above should be changed to explicitly state that. On the other hand, if there's no such requirement, I believe that should be explicitly called out, too, in order to avoid misunderstanding in the future. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* [email protected] *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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
