Summary

  • RFC 3974 showed that an IPv4-only secondary MX could accept mail that it could not relay to an IPv6-only primary MX; preference numbers ordered candidates but created no path between them.
  • DNS answers, TCP connection, SMTP acceptance, queue state, onward relay and final mail-drop arrival were separate receipts. A success at one layer could leave the message stranded at the next.

The most dangerous gap in a redundant mail design can appear after the redundancy has worked. A sender cannot reach the primary, so it follows the MX list, reaches a secondary and completes an SMTP handoff. From outside, the fallback looks successful. Inside the receiver’s network, however, that secondary may have no transport path to the system where all mail is meant to converge.

RFC 3974, published in January 2005, described exactly this mixed IPv4/IPv6 failure. Its example made the primary MX IPv6-only and the lower-priority exchangers IPv4-only. IPv4 senders could reach the backups. The backups could not reach the primary through IPv4 or IPv6. MX preference did not bridge the address families.

Preference ordered attempts; it did not forward messages

An MX record gives a preference value and a host name. The sender sorts candidate hosts by preference, resolves their addresses and attempts delivery. RFC 2821 was the authoritative SMTP algorithm for RFC 3974, as its unusually explicit IESG note stressed. RFC 3974 was Informational, defined no new protocol and did not replace the full SMTP rules. RFC 5321 later superseded RFC 2821.

That candidate ordering is not a forwarding topology. A secondary MX does not acquire a tunnel to every better-preference host merely because both names occur in one DNS answer. The first path runs from sender to selected MX. A separate path must run from the accepting MX to the receiver’s chosen final store or processing system.

RFC 3974 assigned that second responsibility to the receiver site. The easiest example repair was to make the primary dual-stack. But the document was careful not to confuse one repair with the requirement. UUCP, an IPv4/IPv6 translator or shared storage could also move the accepted message. The invariant was that every message accepted by an MX had to reach the recipient’s mail drop.

The history behind the algorithm reached back through RFC 974 and RFC 1123. DNS itself came from the framework represented by RFC 1035, while RFC 3596 supplied AAAA records for IPv6 addresses. The same IN-class MX record served both protocol families; an operator could not assume that listing a host conveyed the address-family path needed after acceptance.

“No record” was not one state

RFC 3974 also separated DNS outcomes that monitoring systems often flatten. NODATA meant the name existed but no MX answer was present, leading SMTP to an implicit MX rule. NXDOMAIN meant the destination domain did not exist and produced permanent failure. SERVFAIL was a temporary resolution failure and required retry.

This mattered during early AAAA deployment. The document reported broken DNS servers returning SERVFAIL to AAAA queries. IPv6-ready MTAs then queued mail for a later attempt. RFC 4074 subsequently documented common misbehavior against IPv6 address queries. A SERVFAIL observation did not prove that the domain lacked AAAA data, that A lookup had succeeded, or that IPv4 fallback had been attempted.

Once addresses existed, the state machine remained layered. A sender might reorder A and AAAA addresses only within MX records of the same preference. It then tried TCP port 25. Connection failure could move it to another address or another MX. Connection success only opened the SMTP transaction. A transient SMTP reply led to another candidate or retry; a permanent error stopped further MX attempts; a successful transaction established SMTP delivery to that MTA.

Even that last success was not the end of RFC 3974’s receiver-side story. It proved an accepting relay had taken responsibility. If the site designed all messages to converge on another host, the internal relay remained necessary. The route to that host and arrival at the mail drop needed their own evidence.

Later documents sharpened adjacent boundaries. RFC 7505 created an explicit Null MX for domains that accept no mail, avoiding ambiguous inference from missing service. RFC 3463 and the IANA enhanced status-code registry classify delivery status. RFC 6724 and RFC 8305 later addressed address selection and connection racing in broader IPv6 practice. They do not retroactively measure the systems RFC 3974 observed.

The RFC Editor record, errata search and IETF Datatracker establish documentary status and history, not deployment prevalence or loss rates. RFC 3974 said many IPv6-ready MTAs appeared to follow its described algorithm, but supplied no census.

The operational reading is therefore path-oriented. Verify that each published MX is reachable from the sender populations it is supposed to serve. Then verify that each accepting MX has a path to the final store, independent of how it ranks in DNS. Preserve the DNS response, selected address, TCP result, SMTP reply, queue transition, onward relay and final deposit as separate receipts.

The backup did not fail by accepting the message. It failed only if the receiver’s design left that accepted responsibility with nowhere to go. RFC 3974 made that invisible handoff visible.

Sources