Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!midway!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: <1990Dec19.171943.18595@chinet.chi.il.us>
Date: 19 Dec 90 17:19:43 GMT
References: <2766B2E7.276@tct.uucp> <1990Dec13.131236.25304@mp.cs.niu.edu> <276D0D6A.6581@tct.uucp>
Organization: Chinet - Public Access UNIX
Lines: 75

In article <276D0D6A.6581@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:

>However, the policy that Mr. Rickert supports -- pessimistically
>rewriting all mail headers for the greatest common denominator,
>namely, stock Unix /bin/mail -- disinfranchises all those UUCP sites
>who have registered domains under the Internet DNS.

Actually, the original /bin/mail does not use anything in the
headers nor does it even require headers to be present.  Replies
are constructed using the From_ line(s).  Since error returns
are virtually always sent back the envelope-from (the collapsed
From_ line path) in uucp mail, a working mail connection requires
this to generate a usable route back to the sender.  This remains
true regardless of any header munging - if you don't get a working
envelope the connection is badly broken.

The perverse systems that would be helped by munging are using
a version of mailx that attempts to generate replies using the
header From: but neither it nor the local transport understand
the things that are likely to appear there if you have a link
to systems bound by the requirements of RFC822.

I contend that the envelope return should be used by uucp sites
unless they are quite sure that the headers are always usable.
Keep in mind that if this doesn't work, the sender isn't going
to get any error message if he misspells the user name.

>I contend that rewriting "user@host.valid.domain" into
>"host.valid.domain!user" in the *header* is a Bad Thing because:

> 1.  Any people who are exchanging mail with Internet sites had
>     better understand RFC822 addresses, if only in their minds,
>     or else they're not going to have much success anyway.

Not necessarily true.  RFC976 style addressing works quite well
(path!domain!user) to connect non-RFC822 uucp sites to ones
that use domain addressing, as long as the relevant machines
handle that form correctly.  Thus the inversion doesn't really
hurt anything (i.e. if your uucp site understands RFC822, it
should also understand RFC976).  The real problem is that this
form is much more likely to have additional changes made to
it as it is forwarded on to the destination.  Still, if you
build the replies from the envelope, it doesn't matter.  The
unresolved problem is what to do about group replies.  Uucp
demands relative addressing since you don't have a handy name
service claiming to know every other machine in the universe.
Thus you have to build routes in the context of the original
sender - a goal that is at odds with absolute addressing.
If you admit the existence of unregistered machines, then you
have build the group addresses from the To: and Cc: lines by
sending back to the originating machine and letting it interpret
them.  This is pretty much impossible if anyone has touched
those headers before you get them.

> 2.  UUCP is only a transport.  Sites which are fully compliant with
>     all relevant Internet standards for E-Mail should not have their
>     headers munged just because their mail is transported via UUCP.
>
>In other words, a site's choice of mail transport should not affect
>the address format.

Unfortunately that isn't the case, and I don't see anything that can
be done about it at this point.  Perhaps anyone who mungs the headers
should be required to insert an X-Original-From: (etc.) so that the
final delivery agent could put if back.  Otherwise there is a serious
loss of information. 

>If unmunged mail headers result in bang-only sites having some
>problems with replying to mail, then I say: "Let them install smail."

In my case, smail 2.5 would not have sufficed, because it does not
pass NULL characters and I need a binary transparent transport.

Les Mikesell
  les@chinet.chi.il.us