#110 closed enhancement (invalid)

Implicit MX hinders Non-Existent domain checks

Reported by: dougfoster.emailstandards@… Owned by:
Priority: minor Milestone:
Component: dmarc-bis Version:
Severity: - Keywords:
Cc:

Description

I assume that this will become a topic for Email Core, but should be discussed here first.

RFC 5321 specifies that if an MX does not exist, the sender should attempt sending to any A/AAAA record that matches the mail domain. An MX can only exist if the mail domain is a DNS domain, so a reasonable inference is that the authors were assuming that the A/AAAA record would also be a DNS domain, using a null host segment, so that the host name corresponded to the email domain. If that was the intent, it was not documented or enforced. As a result, any single host might be an email domain, and therefore the only valid test for the non-existence of an email domain is to demonstrate the absence of multiple records, including
A/AAAA.

Single-host mail domains cannot implement SPF policies or DKIM signatures, but might be able to benefit from DMARC policies at the organizational level, and DKIM signatures from other domains in the organization.

I tested four different email products, and confirmed that all of them will attempt delivery to an A record which represents a single host within a parent domain, in compliance with the nominal language of RFC 5321.

When validating the RFC5322 From address with DMARC, the MX/A/AAAA test is a poor fit, because an email domain used exclusively for third-party mass mailings may have no use for either MX or A/AAAA. I am prepared to argue that the appropriate test is to evaluate the existence of the domain, by checking for an NXDomain result on a record type other than A/AAAA/CNAME. But the argument is moot if a single-host can be a legitimate email domain.

Questions:

Did IETF specifically intend to allow a single host to be an email domain, or can we begin requiring that an email domain always correspond to a DNS domain?

Does IETF intend to allow Implicit MX forever, or can we declare this a transition mechanism which is no longer needed?

Does anyone have information about the volume of email domains which depend on Implicit MX host records, and whether they are domains or single hosts?

Change History (2)

comment:1 Changed 19 months ago by dougfoster.emailstandards@…

Discussion in this group indicates that when the SPF lookup returns NXDOMAIN, postfix and some other products will block the message by default. Single-host mail domains will experience SPF NXDOMAIN, so delivery problems may be sufficiently common to ensure that single-host domains are not viable in practice even if they are viable by specification.

It is possible to reliably detect whether a name string is or is not a domain name, by performing a TXT lookup on the name. If NXDOMAIN is returned, the name string is not a domain. If NODATA or a result is returned, the name string is a domain.

This simple test has applicability in many places:

  • Anywhere that a DNS name is being evaluated for reputation and the reputation depends on determining the correct DNS domain name.
  • Anywhere that a name string is being evaluated for existence as a DNS domain name
  • Anywhere that a name string is being evaluated for existence as a DNS host name, and the boundary between host and domain needs to be known with certainty.

For example, RFC 7208 describes how to use SPF on the HELO name, either as a substitute for a null RFC5321.MailFrom? address or as a tool for verifying that the server name is consistent with the source IP address. For this test to work correctly in all cases, the domain portion of the HELO name must be identified reliably before the SPF lookup on that domain is attempted. RFC 7208 fails to mention this step.

comment:2 Changed 19 months ago by johnl@…

  • Resolution set to invalid
  • Status changed from new to closed

Whether SMTP falls back from MX to A/AAAA is utterly out of scope for DMARC

Note: See TracTickets for help on using tickets.