RFC ที่ระบุว่าเอ็มทีควรจัดการระเบียน MX มีRFC974 , ส่วน RFC1123 5.3.4 , RFC2821 มาตรา 5และRFC5321 มาตรา 5
สถานะ RFC974 คือตอนนี้ประวัติศาสตร์ ตามที่คาดไว้ MTA จะค้นหารายการระเบียน MX ที่เชื่อมโยงกับโดเมนและได้รับการ "สนับสนุน" ให้ลองใช้เซิร์ฟเวอร์ SMTP ทั้งหมด (หรือจำนวนคงที่) ตามลำดับการตั้งค่าที่สูงขึ้น หากมีระเบียน MX หลายรายการที่มีค่ากำหนดเท่ากัน MTA จะต้องพยายามส่งข้อความไปยังเซิร์ฟเวอร์ SMTP ทั้งหมดจนกว่าจะสำเร็จ ลำดับความพยายามเป็นทางเลือกของ MTA กล่าวคือ RFC ไม่ได้กำหนดว่าต้องติดต่อเซิร์ฟเวอร์ SMTP โดยการสุ่มหรือตามลำดับที่เซิร์ฟเวอร์ DNS กำหนด นอกจากนี้ RFC ไม่ได้ปกครองวิธีการจัดการการลงทะเบียน MX ที่อ้างอิงหลายระเบียน 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. (...)
สถานะ RFC1123 เป็นมาตรฐานอินเทอร์เน็ต ส่วน 5.3.4 มีวัตถุประสงค์เพื่อ "ปรับแต่ง" ขั้นตอน RFC974 เกี่ยวกับวิธีจัดการระเบียน MX ตอนนี้ต้องการ 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 เล็กน้อย ในขณะที่ก่อนหน้านี้ต้องการการเลือกแบบสุ่มของเซิร์ฟเวอร์ SMTP ในหลาย ๆ ระเบียน MX ที่มีค่าการตั้งค่าเท่ากัน
(...) 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 โดยทั่วไปจะเขียนขั้นตอนการค้นหาเซิร์ฟเวอร์เดียวกันและนำเสนอส่วนใหม่ที่กล่าวถึงการจัดการระเบียน MX ที่อ้างอิงที่อยู่ 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. (...)
ฉันเดาตัวแทนการถ่ายโอนจดหมายที่ทันสมัยตามขั้นตอน RFC2821 หรือ RFC5321 อย่างน้อยที่สุดดังนั้นการตั้งค่า DNS ทั้งสามตัวจึงมีความสามารถในการเข้าแทนที่ อย่างไรก็ตามเฉพาะการตั้งค่าครั้งแรกเท่านั้นที่จะช่วยให้การทำโหลดบาลานซ์ดีขึ้น หากคุณลองการตั้งค่าครั้งที่สองหรือครั้งที่สามคุณจะต้องตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ DNS ของคุณให้การตอบสนองแบบสุ่ม นอกจากนี้ระเบียน DNS อาจถูกแคชด้วยตนเองหรือโดยเซิร์ฟเวอร์ 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