Interesting responses to your post.. On Tue, Dec 7, 2021 at 7:37 AM Todd Herr <todd.herr= [email protected]> wrote:
> 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. > Let us consider that DNS is hierarchical. A subdomain cannot exist unless those responsible for the parent/organizational domain create it through DNS. We know to some extent that a relationship exists between a domain and it's subdomains. What can we know about the relationship between sister domains? Basically nothing. By allowing sister domains to act as "aligned" we enable a potential ly gaping security hole in various cases. In fact, those cases where the abuse is most likely involve folks who are likely to be unaware of or lacking understanding of email authentication and how it works. Consider buildium.com, which provides property management software and states " Every Buildium subscription comes with a custom subdomain - *http://yoursubdomainhere.managebuilding.com <http://yoursubdomainhere.managebuilding.com>*. Depending on your needs, you may want to use another name when talking with clients, residents, friends, and family." None of the users of these subdomains has a relationship with each other besides purchasing services from a common provider. John Levine and Scott Kitterman clearly see no opportunity for abuse by ill intentioned people in a scenario like this. A bad person would never use an SPF record from imreallynotabadguy.buildingmanagement.com to send an email with a FROM of innocentcustomer.buildingmanagement.com in anticipation of suckering those with relationships with innocentcustomer. Let's consider that there are still some ESPs who like to have (particularly smaller) customers use subdomains on their platform for various reasons. It might be that using subdomains from a common organizational domain is easier to manage than using domains/subdomains provided by the customer(s) or delegated by the customer(s). It might be that the ESP believes that existing customers in this scenario can "lend" reputation to new customers and/or dilute badness from a reputation perspective. Again, this sort of situation can allow unrelated entities to align and potentially get a DMARC pass through relaxed alignment which allows for sister domains. Many hosting sites for wordpress and other basic websites offer the use of subdomains as well. Again we might ask the question as to what the relationship of these sister domains is to each other? Should one be able to align and authenticate against it's siblings? Should an IETF standard knowingly allow and enable potential malicious behavior? We know that "bad guys" have been early adopters of email authentication. Anyone think there aren't bad guys subscribed to this list and thinking about the possibilities for abuse of this mechanism? Michael Hammer
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
