boundary

In a given message path, there is a well determined boundary between the mail originating network (MON) and the mail receiving network (MRN). It lies where the first MX is looked up in the global DNS in order to determine the receiver for the next hop.

Topology

The boundary is defined by the MX records of the recipient's domain in the global DNS. Internal DNS views may provide for outgoing mail paths, as an alternative to MTA-specific configuration. Because DNS is global, the domain servers are uniquely identified.

The same message may follow different paths at different times, depending on connection availability, DNS changes, and DNS randomization. In addition, when the recipient changes, the path changes widely. It can well happen that the same host is on one side of the boundary for message A, and it happens to be on the other side for message B, even if both messages end up to the same target host. On the other hand, the whole path may consist of a single server, resulting in a degenerated boundary inside it.

This topology is not necessarily related to ADministrative Management Domains (ADMDs). On the one hand, hosts belonging to an ADMD may end up not being involved in any inter-domain forwarding. On the other hand, hosts that don't belong to an ADMD may negotiate an agreement and enjoy the amount of trust that is required to perform inter-domain forwarding.

Forwarders

Relays performing alias expansion are considered part of the MRN, if they use the target address legitimately.

Backup MXes

Main article: Backup MX

A message may pass through a backup MX if a direct connection to the target server is not available. The backup MX is considered part of the MRN, even if it currently does not have a list of valid users.

The way backup MXes currently operate generates backscatter. This, and the fact that connections are often very reliable, results in diminished use of backup MXes. Only large networks operate them, and they are usually in the same ADMD.

It is possible that the solution proposed here results in enhanced backup MXes operations. A backup MX has an implicit list of valid mailboxes that comprises any possible address within the given domain(s). However, it still needs to gather forwarding agreements explicitly. That would result in having an almost complete list of users. It may reply with a 4xx code for new users that are not in the agreements database. Additional mechanisms are needed (e.g. temporary blacklists of addresses, maximum allowed queries per time period) to make that behavior smooth.

See Also

• SPF Community Glossary has some more terminology and mentions where it originated.