MTA가 MX 레코드를 처리하는 방법을 지정하는 RFC는 RFC974 , RFC1123 섹션 5.3.4 , RFC2821 섹션 5 및 RFC5321 섹션 5 입니다.
RFC974 상태는 이제 HISTORIC 입니다. 이에 따르면 MTA는 도메인과 관련된 MX 레코드 목록을 쿼리해야하며 모든 (또는 고정 된 수의) SMTP 서버를 선호도 오름차순으로 시도하도록 "권장"합니다. 기본 설정 값이 동일한 MX 레코드가 여러 개인 경우 MTA는 성공할 때까지 모든 SMTP 서버에 메시지를 전달해야합니다. 시도 순서는 MTA의 선택입니다. 즉, RFC는 SMTP 서버를 무작위로 연결해야하는지 DNS 서버가 제공 한 순서로 연결해야하는지 여부를 결정하지 않습니다. 또한 RFC는 여러 A 레코드를 참조하는 MX 레지스터를 처리하는 방법을 규정하지 않습니다.
(...) If the list of MX RRs is not empty, the mailer should try to deliver
the message to the MXs in order (lowest preference value tried
first). The mailer is required to attempt delivery to the lowest
valued MX. Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message, or all
the MXs have been tried. A somewhat less demanding system, in which
a fixed number of MXs is tried, is also reasonable. Note that
multiple MXs may have the same preference value. In this case, all
MXs at with a given value must be tried before any of a higher value
are tried. In addition, in the special case in which there are
several MXs with the lowest preference value, all of them should be
tried before a message is deemed undeliverable. (...)
RFC1123 상태는 인터넷 표준 입니다. 5.3.4 절은 MX 레코드를 처리하는 방법에 대한 RFC974 절차를 "정의"하는 것을 목표로한다. 이제 MTA는 성공할 때까지 모든 SMTP 서버를 선호도의 오름차순으로 시도해야합니다. 그러나 여전히 시도 횟수에 대한 구성 가능한 제한을 허용합니다. 동일한 기본 설정 값을 가진 여러 MX 레코드가있는 경우 RFC는 MTA가 하나의 레코드를 임의로 선택하도록 권장합니다 (필요하지 않음). 그러나 MX 레코드가 여러 A 레코드 (IPv4 주소)를 참조하는 경우 RFC는 MTA가 DNS 서버가 지정한 순서대로 성공할 때까지 모든 주소에 접속하도록 요구합니다.
(...) When it succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address,
because of (a) multiple MX records, (b) multihoming, or both.
To provide reliable mail transmission, the sender-SMTP MUST be
able to try (and retry) each of the 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, a host SHOULD try at
least two addresses.
The following information is to be used to rank the host
addresses:
(1) Multiple MX Records -- these contain a preference
indication that should be used in sorting. If there are
multiple destinations with the same preference and there
is no clear reason to favor one (e.g., by address
preference), then the sender-SMTP SHOULD pick one at
random to spread the load across multiple mail exchanges
for a specific organization; note that this is a
refinement of the procedure in [DNS:3].
(2) Multihomed host -- 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 (see Section 6.1.3.4 below)
to have ordered this list by decreasing preference, and
SMTP MUST try them in the order presented.
(...)
[DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974,
January 1986.
RFC2821 상태는 표준 제안 입니다. 이 RFC는 RFC974를 더 이상 사용하지 않으며 MX 레코드 처리 범위에서 RFC1123과 약간 다릅니다. 전자는 동일한 기본 설정 값을 가진 여러 MX 레코드 중에서 무작위로 SMTP 서버를 선택해야하지만 후자는이를 권장합니다.
(...) 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. (...)
RFC5321 상태는 초안 표준 입니다. 이 RFC는 RFC2821을 더 이상 사용하지 않으며 DNS 확인과 관련하여 기본적으로 동일한 서버 조회 절차를 다시 작성하고 IPv6 주소를 참조하는 MX 레코드 처리에 대해 약간 논의하는 새로운 섹션을 제공합니다.
(...) When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST
contain a domain name. That domain name, when queried, MUST return
at least one address record (e.g., A or AAAA RR) that gives the IP
address of the SMTP server to which the message should be directed.
(...) 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.
(...) MX records contain a preference indication that MUST be used in
sorting if more than one such record appears (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 the SMTP sender MUST try them
in the order presented. (...)
최신 메일 전송 에이전트는 최소한 RFC2821 또는 RFC5321 절차를 따르므로 세 가지 DNS 설정 모두 페일 오버 기능을 제공합니다. 그러나 첫 번째 설정 만 더 나은로드 밸런싱을 제공 할 수 있습니다. 두 번째 또는 세 번째 설정을 시도 할 경우 DNS 서버가 임의의 순서로 응답을 제공하는지 확인해야합니다. 또한 DNS 레코드는 MTA 자체 또는 재귀 DNS 서버에 의해 캐시 될 수 있으므로 임의성을 보장 할 수 없습니다. 나는 mail1.example.com대부분의 메시지를받을 것이라고 생각 합니다.
두 번째 및 세 번째 설정에 대해 내 의견을 제시하는 또 다른 이유는 하나의 IP 주소에 여러 이름을 참조하기 때문입니다. 인터넷의 메일 서버는 일반적으로 매핑 IP address => PTR => hostname => A => IP address이 일치하지 않는 호스트 (Postfix 제한 reject_unknown_client_hostname과 동일 )의 메시지를 거부 하므로 PTR 레코드 설정에 특별한주의를 기울여야합니다.
무작위 순서로 MX 레코드를 시도하지 않는 클라이언트는 이미 RFC2821 및 RFC5321 표준을 위반하고 있습니다. 따라서 이러한 클라이언트가 보조 IP 주소를 자동으로 시도한다는 보장은 없습니다. 이 때문에 가장 간단한 DNS 구성을 선호합니다.
example.com. 1200 IN MX 10 mail1.example.com.
example.com. 1200 IN MX 10 mail2.example.com.
mail1.example.com. 1200 IN A 172.16.10.1
mail2.example.com. 1200 IN A 172.16.10.2
편집 : RFC1123에 대한 참조가 추가되었습니다.