🚀 go-pugleaf

In article <1992Apr8.164249.10851@husc3.harvard.edu> utterbac@husc10.harvard.edu (Margot Utterback) writes:
>Recently, I contacted a workstation vendor about the mail system
>that comes with the workstation.  The operating system is based
>on System V release 4.  The mail system failed when the host portion
>of an address was an alias or nickname.  The response was that 
>RFC821 and RFC822 specify that the address must be the official
>domain name and that the entries in the host file and any 
>cname records in the DNS are irrelevent.
>
>This seems a little farfetched to me.  First, the rfcs in theis
>case seem to be irrelevent.  Don't they only specify what would
>be in the headers, not the address given to the mailer?  

Yes, they only specify the format and protocol used between hosts;
mechanisms within a system, or between systems using other protocols, are
not constrained by these RFC's.

However, if the mailer is documented as requiring its input to be a valid
RFC-822 message (perhaps because it simply transmits the message as given,
without reformatting it), then you are not providing valid input.  You'll
have to convince your vendor to change the requirements of the mailer.

>							  Second,
>why limit the address even in the header? You get the host portion,
>ask the DNS what the MX record is.  It will respond with the
>IP address and the canonical name.  Bingo, you have the official
>name, just use that in the rest of the processing.  
>So, do any of you out there see any reason for the limitation?

I believe one of the original reasons for CNAMEs was to ease the migration
from the pre-DNS host names to the DNS host names.  When a machine was
switched to using a DNS name, its old name would be left as a nickname.
The expectation was that many of these nicknames would be temporary.  They
wanted to prevent these transient names from being captured in many
peoples' mail files.  The assumption is that the primary name is likely to
stick around longer.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

   Date: 10 Apr 92 03:16:29 GMT
   From: kyle@uunet.uu.net (Kyle Jones)

   Not quite.  If CNAME's were allowed for mail then you'd have to
   do an extra lookup.  One lookup to map the aliases to the
   canonical name, and another lookup for any MX records for the
   canonical name.

Bzzzz.  Sorry, Kyle.

CNAME lookup is completely transparent.  Your DNS resolver should do
it for you on the fly.  Ie, you look for the MX RR and if the name is
really a CNAME you get back both the CNAME and the MX RR to which the
CNAME points.  Eg, given RRs:

    MISKATONIC-CTHULHU.ARPA.  IN  CNAME  CTHULHU.MISKATONIC.EDU.
    CTHULHU.MISKATONIC.EDU.   IN  MX   1 CTHULHU.MISKATONIC.EDU.
    CTHULHU.MISKATONIC.EDU.   IN  A      256.6.6.6

a single query for the triple <MISKATONIC-CTHULHU.ARPA, IN, MX> should
get you all three RRs.  Please see RFCs 1034 and 1035 for details.

--Rob Austein <sra@asylum.sf.ca.us>

utterbac@husc10.harvard.edu (Brian (Margot?) Utterback) writes:
 > Recently, I contacted a workstation vendor about the mail system
 > that comes with the workstation.  The operating system is based
 > on System V release 4.  The mail system failed when the host portion
 > of an address was an alias or nickname.  The response was that 
 > RFC821 and RFC822 specify that the address must be the official
 > domain name and that the entries in the host file and any 
 > cname records in the DNS are irrelevent.
 > 
 > This seems a little farfetched to me.  First, the rfcs in theis
 > case seem to be irrelevent.  Don't they only specify what would
 > be in the headers, not the address given to the mailer?

RFC 821 (the SMTP protocol spec) definitely specifies addresses
that are to be given to the mailer.

Also, specific RFC 822 headers are used to generate reply
addresses, and these addresses are the ones given to the mailer.
So the addresses in the headers must be acceptable to the
transport system.

 > Second, why limit the address even in the header? You get the
 > host portion, ask the DNS what the MX record is.  It will
 > respond with the IP address and the canonical name.  Bingo,
 > you have the official name, just use that in the rest of the
 > processing.

Not quite.  If CNAME's were allowed for mail then you'd have to
do an extra lookup.  One lookup to map the aliases to the
canonical name, and another lookup for any MX records for the
canonical name.

For mail, MXs are the way to alias host names.  For everything
else use CNAMEs.  If you need both, then use both.

In article <1992Apr8.164249.10851@husc3.harvard.edu> utterbac@husc10.harvard.edu (Margot Utterback) writes:
>Recently, I contacted a workstation vendor about the mail system
>that comes with the workstation.  The operating system is based
>on System V release 4.  The mail system failed when the host portion
>of an address was an alias or nickname.  The response was that 
>RFC821 and RFC822 specify that the address must be the official
>domain name and that the entries in the host file and any 
>cname records in the DNS are irrelevent.
>
>This seems a little farfetched to me.  First, the rfcs in theis
>case seem to be irrelevent.  Don't they only specify what would
>be in the headers, not the address given to the mailer?  

I find no references to CNAMEs in RFC 821 or RFC 822, so perhaps your vendor
was shooting from the hip. However, assuming you're using SMTP to send the 
mail from one host to another AND assuming that you wish your sending host to 
meet the Internet Host Requirements, then I believe the following section 
from RFC 1123 (Requirements for Internet Hosts -- Application and Support) 
governs:

---

5.2.2  Canonicalization: RFC-821 Section 3.1

         The domain names that a Sender-SMTP sends in MAIL and RCPT
         commands MUST have been  "canonicalized," i.e., they must be
         fully-qualified principal names or domain literals, not
         nicknames or domain abbreviations.  A canonicalized name either
         identifies a host directly or is an MX name; it cannot be a
         CNAME.

---

Under SMTP (as opposed to UUCP or whatever), the RCPT command corresponds to 
"what is given to the mailer", so, yes, you MUST use a canonicalized name if 
you want to pass muster under the Internet Host Requirements.

>Second,
>why limit the address even in the header? You get the host portion,
>ask the DNS what the MX record is.  It will respond with the
>IP address and the canonical name.  Bingo, you have the official
>name, just use that in the rest of the processing.  

I'm not sure whether CNAMEs *ARE* prohibited in the header, given the absence
of mention in RFC 821 & RFC 822. Perhaps someone can clarify?

Even if they are prohibited, perhaps the rationale is that canonicalization
is better done in the MUA rather than the MTA (??)

------------------------------------------------------------------------------
kevin@cfctech.cfc.com 		  | Kevin Darcy, Unix Systems Administrator
...sharkey!cfctech!kevin 	  | Technical Services (CFC)
Voice: (313) 759-7140 		  | Chrysler Corporation
Fax:   (313) 758-8173 		  | 25999 Lawrence Ave, Center Line, MI 48015
------------------------------------------------------------------------------

In article <1992Apr8.164249.10851@husc3.harvard.edu> utterbac@husc10.harvard.edu (Margot Utterback) writes:
>Recently, I contacted a workstation vendor about the mail system
>that comes with the workstation.  The operating system is based
>on System V release 4.  The mail system failed when the host portion
>of an address was an alias or nickname.  The response was that 
>RFC821 and RFC822 specify that the address must be the official
>domain name and that the entries in the host file and any 
>cname records in the DNS are irrelevent.

>This seems a little farfetched to me.  First, the rfcs in theis
>case seem to be irrelevent.  Don't they only specify what would
>be in the headers, not the address given to the mailer?  
 
YES! The RFCs have NOTHING to do with the user interface!

I think everyone is missing the point here. RFC-1123 requires the envelope name
(RCPT line) to include the fully qualified domain name. This has NOTHING to do
with what the mailer accepts from the user. Any reasonable mailer should make a
reasonable attempt to use aliases and local names by converting them into
FQDNs. I've never seen one which wouldn't, although I know of one System V
Release 4 vendor whose sendmail is so messed up that it really cannot be said
to work at all. Wonder if it's the same one? I won't speak their name, but they
just bought the company that makes most of their CPU chips.

The key issue here is the user interface to mail. While I personally prefer to
see FQDN used all of the time, most users never send mail outside of our local
domain and don't realise the significance of the llnl.gov on the end. They just
send to user@node and are done with it. sendmail then converts user@node to
user@FQDN and uses this address.

>Second,
>why limit the address even in the header? You get the host portion,
>ask the DNS what the MX record is.  It will respond with the
>IP address and the canonical name.  Bingo, you have the official
>name, just use that in the rest of the processing.  

Huh? If you send mail to me with an entry of user@node in the header, unless
there is some other information, I have no way to know where a given node is.
Not everyone is at Harvard. Some folk are at MIT and a few are not even east of
the rockies! Specifically, the "From:", "Sender:", "Reply to:" and any other
header used to derive the reply address MUST use the FQDN. No substitutes are
permitted. Some mail agents do allow the name, as entered by the user, to be
included in a special header line, but never in any of the RFC-822 mandated
header lines.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman1@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

In article <1992Apr11.211356.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:

:with what the mailer accepts from the user. Any reasonable mailer should make a
:reasonable attempt to use aliases and local names by converting them into
:FQDNs. I've never seen one which wouldn't, although I know of one System V

Just for the record, VMS MAIL (with most TCP/IP implementations)
experiences this problem.  You Cc: a local/user alias/symbol/logical
and that never gets FQDNized.  It's quite annoying.

						...Mike

-- 
 Mike O'Connor                     |  Ford Motor Company, USA
 Applications Systems Analyst      |  CPD P&MS ECC Core Software
 Phone #:  +1 (313) 390-4008       |  P.O. Box 2053, ECC MD-7
 Fax #:    +1 (313) 845-0576       |  Dearborn, MI  48121-2053

In article <1992Apr12.162426.25161@fmsrl7.srl.ford.com>, moconnor@pms704.pms.ford.com (Mike O'Connor) writes:
> In article <1992Apr11.211356.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:
> 
> :with what the mailer accepts from the user. Any reasonable mailer should make a
> :reasonable attempt to use aliases and local names by converting them into
> :FQDNs. I've never seen one which wouldn't, although I know of one System V
> 
> Just for the record, VMS MAIL (with most TCP/IP implementations)
> experiences this problem.  You Cc: a local/user alias/symbol/logical
> and that never gets FQDNized.  It's quite annoying.

Sounds like a configuration problem, to me. It is specific to the mailer and
has nothing to do with the TCP/IP implementations. Of course, it's quite
possible that the mailer was included.

I am the postmaster on a VMS system and, while mail only passes FQDNs out the
door, it certainly accepts lots of other things, even things like
QUICKMAIL::SMITH, where QUICKMAIL is an IP MX entry. Of course I have to admit
that I'm running a proprietary commercial mail product. PMDF.

I suspect that a change in BIND in 4.8.3 may be behind this whole thing. In
earlier versions of BIND, the default behavior was to try to resolve an address
by appending the local domain to it. I believe that BIND now tries to resolve
the name exactly as it is received. If it's not a FQDN, the lookup fails.

The merits of this change have been heavily debated in BIND forums, but that is
probably the reason for the situation. My mailer trys to append the local
domain name to all queries which are not otherwise in a valid domain or locally
defined aliases or systems.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman1@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

In article <ku70m3INNi37@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Apr8.164249.10851@husc3.harvard.edu> utterbac@husc10.harvard.edu (Margot Utterback) writes:
>I believe one of the original reasons for CNAMEs was to ease the migration
>from the pre-DNS host names to the DNS host names.  When a machine was
>switched to using a DNS name, its old name would be left as a nickname.
>The expectation was that many of these nicknames would be temporary.  They
>wanted to prevent these transient names from being captured in many
>peoples' mail files.  The assumption is that the primary name is likely to
>stick around longer.


Well, CNAME has uses beyond just that one.

For instance ... it supports `resource discovery' (of a limited sense)
with the advantage that the administrator can move the *location* of
the resource without the users having to reconfigure anything.

Concrete example:

You have a system with an e-mail -> FAX gateway installed.  You point people
to the FAX machine by telling them to send to 

	phone-number@fax-gateway.local.dom.ain

In your DNS you install CNAME records which map fax-gateway to the
system providing the real service.  If that machine breaks or is
upgraded or otherwise has to change its name, noooo problem.

You can repeat this solution `n' times.  The most common use might
be a distributed BSD/lpr environment.  Printers, after all, are a
touch more likely to move around than fax-gateway's...

It is also useful to have abbreviations for systems so you don't
have to remember to type

	rlogin herkimer
when	rlogin he

will do....



To answer the original question: having the e-mail system ignore CNAME's
and other forms of host-aliasing is bogus, IMO.  Regardless of what
it says in RFC-822 (remember, 822 is rather old) from a usability standpoint
it is silly and anal-retentive to require addresses to not be an alias.
The HR RFC likely has (nicer) words to this effect.

	David


-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<-
<- As for the prevalence of gratuitous stupidity in modern life, well,
<- need I say more than "MS-DOS"? -- Bill Janssen