Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!olivea!orc!inews!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.misc
Subject: Re: Which headers may Sendmail re-write?
Message-ID: <1991Jan02.202222.1818@chinet.chi.il.us>
Date: 2 Jan 91 20:22:22 GMT
References: <277A64CD.4C4B@tct.uucp> <1990Dec31.190906.328@chinet.chi.il.us> <2781581A.6663@tct.uucp>
Organization: Chinet - Public Access UNIX
Lines: 48

In article <2781581A.6663@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to les@chinet.chi.il.us (Leslie Mikesell):
>>How would you handle the RFC822-legal path!user@domain syntax when
>>handing it to a uux-ed rmail?

>For the envelope (rmail argument), make it domain!path!user.  For the
>header, *don't change it*.  Remember the basic argument: the From:
>line is an RFC822 animal.  Software that parses From: must therefore
>do so by the rules of RFC822, or by definition it's broken.

Well, that may be your basic argument, but there are other views.  My
personal view is that whatever starts out in the From: line should
stay there, with the exception of possibly adding the domain name
(if you happen to have one) on messages leaving your domain.  However
this is already violated by necessity when an internet gateway forwards
a message received without a FQDN.  Hardly anyone would knowingly
use an address like path!user@domain from a uucp site, but they show
up in headers all over the place.
At&t also has a different view, and you won't find any FQDN's in
the headers of messages through attmail, and you must generate
group replies by interpreting the From_ line to get the context
for the To: and Cc: lines.  Too bad that whoever first
used the "From:" line didn't patent it (just joking....).

>The only form of Rabid Rerouting performed at TCT is done in our mail
>user agent (Elm) and only at explicit user request (the header edit
>screen has a "domainize" command).  I thus avoid the common fallacy
>that machine X knows better than person Y, which is always false for
>appropriate values of Y.  (The value of X doesn't matter.)

Of course the real problem is the fact that this is false.  The machines
should get it right.  However, the software designers should have
anticipated the problem and allowed an alternative syntax for routes
that should or shouldn't be optimized - too late now, I suppose.

>My point in requesting the cessation of u@d.m -> d.m!u rewriting is
>that even my own mild form of Rabid Rerouting wouldn't be needed if
>only RFC822 headers could get to my site without being mangled.

And my point in arguing about it is not to favor the rewriting but
to point out that the real problem is the later sites who prepend
their uucp names and that this is equally likely to happen to
RFC822-legal path!user@domain headers with worse results.  It is
the sites that prepend their uucp names to the headers that cause
the damage.

Les Mikesell
  les@chinet.chi.il.us