Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id EAA10040; Sun, 13 Oct 1996 04:01:03 -0400 Received: by CS.UTK.EDU (bulk_mailer v1.7); Sun, 13 Oct 1996 03:59:07 -0400 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id DAA09801; Sun, 13 Oct 1996 03:59:03 -0400 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id HA32159; Sun, 13 Oct 1996 17:58:45 +1000 (from kre@munnari.OZ.AU) To: Eric Thomas Cc: drums@cs.utk.edu Subject: Re: CNAME/1123 breakage In-Reply-To: Your message of "Sun, 13 Oct 1996 05:10:16 +0200." Date: Sun, 13 Oct 1996 17:58:38 +1000 Message-Id: <27477.845193518@munnari.OZ.AU> From: Robert Elz Date: Sun, 13 Oct 1996 05:10:16 +0200 From: Eric Thomas I'm talking about a *remote* CNAME, not one for the local host. A remote CNAME to you is a local CNAME to me... All I'm saying is that mail clients like Eudora or Pegasus aren't going to respect the 1123 CNAME requirement I wouldn't expect they would. I woudn't expect they would actually attempt to be Internet mail delivery agents. Certainly here all the Eudora mail users simply dump their mail on a mailserver that does the delivery. I don't think there's much doubt but that mail submission is a special case, and that the rules there need to be different, in lots of ways. This is where a dedicated protocol has been mooted from time to time. However, if a Eudora/pegasus/qvnet/... mailer is going to actually do end to end mail delivery, then it had better plan on following the rules. That includes nameserver lookups - the dest name needs to be looked up to find its MX record in that case anyway, if there is a CNAME, the nameservers should return the CNAME as a by product of doing the MX lookup (or the A lookup if the canonical name has no MX), the translation comes for free here. For now, please let's leave aside the case of dumb clients that just want to get the mail to a real server, and concentrate on the heart of the protocol, which is where the real server does delivery across the internet. At that point, if a CNAME is found in a delivery address it MUST be translated to the canonical name. If you fail to do it, and the mail fails, it is your fault, you cannot place any of the blame at all on the remote server. HOME.EASE.LSOFT.COM is one of our machines and it certainly knows to accept mail for this address. Does it (home.dc.LSOFT.COM I presume) know how to accept mail for lsoft-home.cs.mu.oz.au? That is a CNAME for the same canonical name? CNAMEs have lots of uses, one is so that I (the owner of the domain containing the CNAME) can create an alias for any other host on the Internet it suits my purposes to create - because the name I create is defined to be exatly the same thing as the canonical name, and to be translated to the canonical name whenever it appears anywhere on the net where it would be visible (like in RCPT To commands), this is a nice safe way to create local short-hand names for remote hosts that are used frequently. Please don't go breaking what works now to suit some fancied demand that so far doesn't look to have any basis in reality. kre