Các RFC chỉ định cách MTA nên xử lý các bản ghi MX là RFC974 , RFC1123 phần 5.3.4 , RFC2821 phần 5 và RFC5321 phần 5 .
Trạng thái RFC974 hiện là LỊCH SỬ . Theo đó, MTA dự kiến sẽ truy vấn danh sách các bản ghi MX được liên kết với một tên miền và được "khuyến khích" thử tất cả (hoặc một số lượng cố định) máy chủ SMTP, theo thứ tự ưu tiên tăng dần. Nếu có nhiều bản ghi MX có giá trị tùy chọn bằng nhau, MTA phải cố gắng gửi tin nhắn đến tất cả các máy chủ SMTP cho đến khi một bản ghi thành công. Thứ tự các nỗ lực là sự lựa chọn của MTA, nghĩa là RFC không quy định liệu các máy chủ SMTP phải được liên hệ ngẫu nhiên hay theo thứ tự do máy chủ DNS đưa ra. Ngoài ra, RFC không quy định cách xử lý một thanh ghi MX tham chiếu nhiều bản ghi A.
(...) 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. (...)
Trạng thái RFC1123 là TIÊU CHUẨN INTERNET . Mục 5.3.4 nhằm mục đích "tinh chỉnh" các quy trình RFC974 về cách xử lý các bản ghi MX. Bây giờ, nó yêu cầu MTA phải thử tất cả các máy chủ SMTP theo thứ tự ưu tiên tăng dần cho đến khi thành công. Tuy nhiên, nó vẫn cho phép giới hạn cấu hình về số lần thử. Nếu có nhiều bản ghi MX có giá trị tùy chọn bằng nhau, RFC khuyến nghị (và không yêu cầu) MTA để chọn một bản ghi ngẫu nhiên. Tuy nhiên, nếu bản ghi MX tham chiếu nhiều bản ghi A (địa chỉ IPv4), RFC yêu cầu MTA phải liên hệ với tất cả các địa chỉ này cho đến khi một bản ghi thành công, theo thứ tự được cung cấp bởi máy chủ 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.
Trạng thái RFC2821 là TIÊU CHUẨN ĐỀ XUẤT . RFC này đã lỗi thời RFC974 và, trong phạm vi xử lý bản ghi MX, nó hơi khác so với RFC1123. Mặc dù trước đây YÊU CẦU một lựa chọn ngẫu nhiên của một máy chủ SMTP trong số nhiều bản ghi MX có giá trị tùy chọn bằng nhau, nhưng cái sau chỉ NHẬN nó.
(...) 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. (...)
Trạng thái RFC5321 là TIÊU CHUẨN DRAFT . RFC này đã lỗi thời RFC2821 và, trong bối cảnh phân giải DNS, về cơ bản, nó viết lại quy trình tra cứu máy chủ tương tự và trình bày một phần mới thảo luận một chút về việc xử lý các bản ghi MX tham chiếu địa chỉ IPv6.
(...) 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. (...)
Tôi đoán một tác nhân chuyển thư hiện đại tuân theo ít nhất các thủ tục RFC2821 hoặc RFC5321, vì vậy cả ba thiết lập DNS đều cung cấp khả năng chuyển đổi dự phòng. Tuy nhiên, chỉ thiết lập đầu tiên có thể cung cấp cân bằng tải tốt hơn. Nếu bạn thử cài đặt thứ hai hoặc thứ ba, bạn sẽ phải đảm bảo rằng máy chủ DNS của bạn cung cấp phản hồi theo thứ tự ngẫu nhiên. Ngoài ra, các bản ghi DNS có thể được lưu trữ bởi chính MTA hoặc bởi các máy chủ DNS đệ quy, do đó tính ngẫu nhiên không thể được đảm bảo. tôi nghĩmail1.example.com sẽ nhận được hầu hết các tin nhắn.
Một lý do khác dẫn ý kiến của tôi chống lại các thiết lập thứ hai và thứ ba là việc tham chiếu nhiều tên đến một địa chỉ IP. Các máy chủ thư trong internet thường từ chối thư từ các máy chủ có ánh xạ IP address => PTR => hostname => A => IP addresskhông khớp (cũng như hạn chế Postfix từ chối_unknown_client_hostname ), vì vậy bạn sẽ phải đặc biệt cẩn thận khi thiết lập các bản ghi PTR.
Các khách hàng không thử các bản ghi MX theo thứ tự ngẫu nhiên đã vi phạm các tiêu chuẩn RFC2821 và RFC5321. Vì vậy, tôi nghĩ không có gì đảm bảo rằng những khách hàng này cũng sẽ tự động thử địa chỉ IP thứ cấp. Do đó, tôi thích cấu hình DNS đơn giản nhất:
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
EDIT: Đã thêm tài liệu tham khảo vào RFC1123.