Tony Finch wrote:
RFC 2821 says:
If MX records are present, but none of them are usable, this situation
MUST be reported as an error.
This implies that a partially broken RRset is not grounds for rejecting a
message.
Doesn't this depend on what the MX lookup intention was?
2821bis says:
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.
Any other response, specifically including a value that will return a
CNAME record when queried, lies outside the scope of this standard.
This implies that it's OK to reject partially broken MX RRsets. Some
deployed software already does this.
Tony.
I don't see the change.
Obviously, if you are attempting to send mail out, you can't pull a
rabbit out a hat if the mail host service is not available.
Its a delayed reject - aka bounce.
But if we thinking in terms of verification? i.e., CBV or Web Service
Signup Email Address Verification Tool?
Would there be any semantics difference in MX error handling?
The only difference I see is the number of attempts the system is
willing to invest to determine *WHEN* an email domain is invalid via bad
MX/RRSet.
Maybe we should consider some old Fidonet Ideas? like a ZONE MAIL HOUR:
NEW IDEA FOR 2821BIS:
Section X.1 - SMTP ZONE MAIL HOUR
All SMTP systems MUST be open for mail services between the ZULU
(GMT) hours of 00:00 and 01:00 called the ZONE MAIL HOUR (ZMH).
During ZMH all compliant SMTP services *MUST* make sure their
MX and RRset are resolvable and an SMTP SERVICE PORT is available.
During ZMH, senders *MUST* reject mail intended for SMTP
servers whose MX/RRSet are not resolved and/or do not connect.
During non-ZMH hours, Senders *MAY* reject but they are
encouraged to re-queue the mail attempt.
Senders MAY schedule all daily outgoing mail to ZMH if they wish
to implement a strong rejection policy.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com