mail at sabahattin-gucukoglu
Feb 20, 2010, 1:48 PM
Post #10 of 10
(2465 views)
Permalink
|
On 19 Feb 2010, at 22:42, Kyle Wheeler wrote:
> On Friday, February 19 at 12:59 AM, quoth Sabahattin Gucukoglu:
>> On 18 Feb 2010, at 17:54, Kyle Wheeler wrote:
>>> And yes, qmail has to make a CNAME request before it makes an MX
>>> request; that's specified by the SMTP standard.
>>
>> No it isn't. That's broken qmail behaviour based on flawed
>> interpretation of RFC 821 (clarified in 2821 and now 5321). If the
>> MX turns out not to be canonical, by all means follow to the next
>> name, which (according to RFC 1912 and many others) MUST be
>> canonical. But don't start by making cname queries, unless of
>> course you have a resolver that will not follow up for you (not
>> dnscache).
>
> You are correct IF all domains can be trusted to be correctly
> configured.
>
I have yet to see a domain *that* broken (BIND will disallow publication of such a zone, in fact). Certainly, it's my expectation today that domains not be, and I safely assume that to be the case for optimal mail delivery.
> The SMTP standard, in all its forms, does not permit the use of
> aliased hostnames, so senders (i.e. qmail) must determine whether both
> sending and receiving domains are aliases (e.g. CNAMEs).
>
The IETF today reconciles CNAME lookups in address envelope with the fundamental truth of CNAME evaluation in the DNS. There are indeed good reasons to avoid "Nicknames", but RFC 5321 (and indeed 2821) explain how this relates more to local nicknames and aliases than to any FQDNs, including FQDNs used as part of an email address and looked up in place of canonical names during the MX resolution process. There is simply no reason to go out of your way to avoid the process simply in order to distinguish CNAME usage from not. As I said, Dan simply misunderstands the connection between CNAME rewriting and CNAMEs used in the resolution restart process against MX records. His notes seem to corroborate that:
http://cr.yp.to/im/cname.html
In his example, www.your.site *must* be handled by your mailer. You *must* treat it local, and *must* accept or rewrite recipients accordingly (for Sendmail this is automagic since the typical local user delivery will work for "All my local names", or macro 'w'). In qmail this is just the rcpthosts file. This is a natural feature of any correct implementation of SMTP which simply expands MX records and delivers mail, as it always has and always will. There is no implied or mandatory rewriting here. There is only a rule that, wherever possible, aliases not be used, especially in RRs which might otherwise not provide efficient lookups in the DNS (MX, PTR, other CNAMEs).
> As far as for the delivery, it is true that, according to several
> RFCs, CNAMEs are not permitted to coexist with MX records for the same
> name, and good DNS software will return the CNAME value in the
> response to an MX query. However, the reality of the situation is that
> MX and CNAME records for the same name sometimes *do* coexist (perhaps
> less frequently these days than in years past, but it can still
> happen). In cases where DNS servers have both an MX record and a CNAME
> record for the same name, an MX query does not always return the CNAME
> data, but *can* return just the MX value (depending on the DNS server
> implementation). Even if it does respond with both values, not all DNS
> client libraries will recognize the issue, and often simply ignore the
> non-MX data (because you only asked for the MX data). In order to
> properly deal with such incorrectly configured domains while
> respecting the prohibition against aliases, qmail must make a separate
> CNAME query in order to detect the alias.
>
You can be justified in broken client behaviour if you have some preference of which set of MX RRs to use in such incredibly broken circumstances. If it were me, I'd simply use all MXs provided; it's the DNS server's job to do all that collection logic. But, in that case, the feature should certainly be optional. Otherwise, a breakage to work around a breakage is a nuisance when it doesn't work, as may be the case with the current thread.
> If a domain is correctly configured, and no CNAME and MX records
> overlap, then the only drawback of making the CNAME request first is
> that more queries are made than are absolutely necessary. I don't see
> what the basis is far calling qmail's behavior "broken"; it is
> attempting to deal with potentially misconfigured domains.
>
It's costing you an extra DNS query per MX lookup. It works around a bug or bugs that nobody cares about, or that rarely exist today. And it implements a feature most mailers are blindly unaware of, or indeed that most of them that go to the added trouble do not depend on to work. Really, if it's a feature, it's a very, very bad one. I prefer to call it a bug. :-)
Now, if you must have interoperability, then the software is working, albeit suboptimally, and is not broken. In any event, it's unusually conservative, given DJB's past history of breathing fire over matters of non-conformance, considering that this makes his software non-conformant itself. It is not behaviour specified by current standards. In my not very humble opinion, qmail should drop the CNAME/ANY routine, and do MX lookups instead.
Cheers,
Sabahattin
|
