RFC 2821 - Simple Mail Transfer Protocol
5. Address Resolution and Mail Handling
Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in sections 3.6 and 3.7), a
DNS lookup MUST be performed to resolve the domain name [22]. The
names are expected to be fully-qualified domain names (FQDNs):
mechanisms for inferring FQDNs from partial names or local aliases
are outside of this specification and, due to a history of problems,
are generally discouraged. The lookup first attempts to locate an MX
record associated with the name. If a CNAME record is found instead,
the resulting name is processed as if it were the initial name. If
no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host. If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.
Two types of information is used to rank the host addresses: multiple
MX records, and multihomed hosts.
Multiple MX records contain a preference indication that MUST be used
in sorting (see below). Lower numbers are more preferred than higher
ones. If there are multiple destinations with the same preference
and there is no clear reason to favor one (e.g., by recognition of an
easily-reached address), then the sender-SMTP MUST randomize them to
spread the load across multiple mail exchangers for a specific
organization.
The destination host (perhaps taken from the preferred MX record) may
be multihomed, in which case the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by
decreasing preference if necessary, and SMTP MUST try them in the
order presented.
Although the capability to try multiple alternative addresses is
required, specific installations may want to limit or disable the use
of alternative addresses. The question of whether a sender should
attempt retries using the different addresses of a multihomed host
has been controversial. The main argument for using the multiple
addresses is that it maximizes the probability of timely delivery,
and indeed sometimes the probability of any delivery; the counter-
argument is that it may result in unnecessary resource use. Note
that resource use is also strongly determined by the sending strategy
discussed in section 4.5.4.1.
If an SMTP server receives a message with a destination for which it
is a designated Mail eXchanger, it MAY relay the message (potentially
after having rewritten the MAIL FROM and/or RCPT TO addresses), make
final delivery of the message, or hand it off using some mechanism
outside the SMTP-provided transport environment. Of course, neither
of the latter require that the list of MX records be examined
further.
If it determines that it should relay the message without rewriting
the address, it MUST sort the MX records to determine candidates for
delivery. The records are first ordered by preference, with the
lowest-numbered records being most preferred. The relay host MUST
then inspect the list for any of the names or addresses by which it
might be known in mail transactions. If a matching record is found,
all records at that preference level and higher-numbered ones MUST be
discarded from consideration. If there are no records left at that
point, it is an error condition, and the message MUST be returned as
undeliverable. If records do remain, they SHOULD be tried, best
preference first, as described above.
Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in sections 3.6 and 3.7), a
DNS lookup MUST be performed to resolve the domain name [22]. The
names are expected to be fully-qualified domain names (FQDNs):
mechanisms for inferring FQDNs from partial names or local aliases
are outside of this specification and, due to a history of problems,
are generally discouraged. The lookup first attempts to locate an MX
record associated with the name. If a CNAME record is found instead,
the resulting name is processed as if it were the initial name. If
no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host. If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.
Two types of information is used to rank the host addresses: multiple
MX records, and multihomed hosts.
Multiple MX records contain a preference indication that MUST be used
in sorting (see below). Lower numbers are more preferred than higher
ones. If there are multiple destinations with the same preference
and there is no clear reason to favor one (e.g., by recognition of an
easily-reached address), then the sender-SMTP MUST randomize them to
spread the load across multiple mail exchangers for a specific
organization.
The destination host (perhaps taken from the preferred MX record) may
be multihomed, in which case the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by
decreasing preference if necessary, and SMTP MUST try them in the
order presented.
Although the capability to try multiple alternative addresses is
required, specific installations may want to limit or disable the use
of alternative addresses. The question of whether a sender should
attempt retries using the different addresses of a multihomed host
has been controversial. The main argument for using the multiple
addresses is that it maximizes the probability of timely delivery,
and indeed sometimes the probability of any delivery; the counter-
argument is that it may result in unnecessary resource use. Note
that resource use is also strongly determined by the sending strategy
discussed in section 4.5.4.1.
If an SMTP server receives a message with a destination for which it
is a designated Mail eXchanger, it MAY relay the message (potentially
after having rewritten the MAIL FROM and/or RCPT TO addresses), make
final delivery of the message, or hand it off using some mechanism
outside the SMTP-provided transport environment. Of course, neither
of the latter require that the list of MX records be examined
further.
If it determines that it should relay the message without rewriting
the address, it MUST sort the MX records to determine candidates for
delivery. The records are first ordered by preference, with the
lowest-numbered records being most preferred. The relay host MUST
then inspect the list for any of the names or addresses by which it
might be known in mail transactions. If a matching record is found,
all records at that preference level and higher-numbered ones MUST be
discarded from consideration. If there are no records left at that
point, it is an error condition, and the message MUST be returned as
undeliverable. If records do remain, they SHOULD be tried, best
preference first, as described above.
posted by e247net at 5:35 PM
0 comments
