
On Mon, Jul 30, 2012 at 4:26 PM, <valdis.kletnieks@vt.edu> wrote:
On Mon, 30 Jul 2012 10:07:37 -1000, William Herrin said:
If you can reference where in the SMTP RFC it offers an authoritative explanation what to do when merging results from various naming systems where one but not all of the naming systems has generated an error then let's read it.
RFC5321, section 5.1 is pretty clear on it:
5.1. Locating the Target Host
Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in Sections 2.3.5 and 3.6), a DNS lookup MUST be performed to resolve the domain name (RFC 1035 [2]). 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.
Well there you have it. Mechanisms for determining whether a name is intended to be acquired from the DNS are _outside the scope of the RFC_. So, the specifics of merging results from multiple naming systems is left to the implementer without IETF guidance. Clear as mud. And when the RFC goes on to say:
If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
one reasonable interpretation is that MX-type lookups only apply to lookups from the DNS system, another is that both the MX lookup and host lookup have to come from the same naming system, and a third reasonable interpretation is that they do not. And that's true even though the RFC also says:
If a temporary error is returned, the message MUST be queued and retried later
because the MTA *did* successfully acquire the _implicit MX_ from one of the name systems it uses. Chalk this up as a point that "needs work" in the next XX21 RFC.
The Internet uses DNS. You use some other scheme at your own peril, and probably shouldn't expect said other scheme to work outside the range of your administrative control.
"The Internet" uses a far broader set of technologies than you give it credit for. And it routinely uses the DNS badly. Structure your systems with that understanding or pay for your negligence with malfunction. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004