On Thu, Nov 03, 2005 at 10:39:00AM +0000, Paul Howarth wrote: > > Well, what is supposed to happen is that the MTA first looks up the MX > > record for the host that you specified, and THAT is used -- ater that, > > if no MX record exists, it should do an A lookup and convert CNAMEs. > > That's debatable because there should not be any MX records for a name > that has a CNAME record - see for example RFC 1912, section 2.4 "CNAME > records": It isn't debatable; until the MTA does the lookups, it doesn't know that the address is a CNAME or an MX or what it is. The MTA should and does (at least with sendmail) look for MX records for the supplied name first. Only if none are found does it do an A record lookup, which is when it would discover the CNAME record. > A CNAME record is not allowed to coexist with any other data. In > other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you > can't also have an MX record for suzy.podunk.edu, or an A record, or > even a TXT record. Indeed, which is the other reason not to use them. It just confuses things needlessly, and makes future errors (referring to CNAMES) too easy to make. > > I don't think there's any indication in RFC 1123 that the MTA should > > then do an MX lookup on the canonicalized host, though this does make > > some sense. > > This is also the behaviour of sendmail; don't know about other MTAs but > I would expect it to be the same. But the point is the standards don't seem to specify that behavior, and therefore it is "undefined" with respect to the standard. IOW you can't count on it. > > But this is just another example of a good reason not to > > use CNAMEs. I never use them... they only create problems. > > They're useful as long as you know what you're doing :-) > Too bad too many people don't :-( I don't really agree; they're totally redundant. You're better off just using an A record. That will always behave intuitively and completely avoids all the stupid problems associated with CNAMEs. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
Attachment:
pgpCtBQLx9mow.pgp
Description: PGP signature
