Opened 16 months ago

Last modified 11 months ago

#115 new enhancement

Conflation of mail domain with DNS domain

Reported by: dougfoster.emailstandards@… Owned by:
Priority: minor Milestone: Deliverable #3 (changes to DMARC base spec + DMARC Usage Guide
Component: dmarc-bis Version:
Severity: - Keywords:
Cc:

Description

Regarding this section:

4.2. Key Concepts (page 14)

It is important to note that the authentication mechanisms employed
by DMARC authenticate only a DNS domain and do not authenticate the
local-part of any email address identifier found in a message, nor do
they validate the legitimacy of message content.

Nothing about RFCs 5321, 5322, or 7208 constrains an email domain to be a DNS domain. Any name can have an associated MX, A, or TXT/SPF record associated with it, whether the name is of the form "host within domain" or "null host within subdomain".

This also fits some easily imagined use cases: Organizational mail for example.com might be sent using the organizational domain, with the form "local-part at example.com", while an alarm notification server might send using its own host name, such as "alarms at monitoring.example.com".

In practice, mail recipients have no simple method for testing whether an email domain matches a DNS domain or not.

Because RFC 7489 assumes an equivalence between email domains and DNS domains, it uses a sub-domain for publishing DMARC policies. This is unfortunate, because it prevents a domain owner from publishing a domain-level policy for a mail domain which is not configured as a DNS domain.

For DMARCbis, we should specify a lookup mechanism for this situation.

If the "_dmarc.domain" lookup fails, a secondary lookup should be made using the domain name without the _dmarc subdomain. If both lookups return NXDOMAIN or NODATA, then the domain owner has published no domain-level DMARC policy.

I believe the assumed equivalence between email domains and DNS domains occurs in other parts of the document, but this location is where it is most explicit.

Change History (2)

comment:1 Changed 11 months ago by todd.herr@…

I do not understand the terms "email domains" and "DNS domains".

RFC 1034 makes clear that every node in the DNS has a "domain name" - https://datatracker.ietf.org/doc/html/rfc1034#section-3.1

RFC 1035 is all about domain names - https://datatracker.ietf.org/doc/html/rfc1035

RFC 5321 uses the term "domain name" and "fully-qualified domain name" - https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.5

RFC 5322 defines an email address as a local part, an @ sign, and a domain - https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1 - and further goes on to specify a domain as an "internet domain name"... "as described in RFC 1034" or a domain literal, which for practical purposes is an IP address enclosed in square brackets, and the use of domain literals is discouraged by RFC 5321 (https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.4)

comment:2 Changed 11 months ago by todd.herr@…

  • Milestone set to Deliverable #3 (changes to DMARC base spec + DMARC Usage Guide
Note: See TracTickets for help on using tickets.