Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!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: <1990Dec23.071649.10558@chinet.chi.il.us>
Date: 23 Dec 90 07:16:49 GMT
References: <27710AE7.1356@tct.uucp> <1990Dec21.193938.29940@chinet.chi.il.us> <1990Dec22.014625.22543@Think.COM>
Organization: Chinet - Public Access UNIX
Lines: 98

In article <1990Dec22.014625.22543@Think.COM> barmar@think.com (Barry Margolin) writes:
  >>  The uucp philosophy says that addresses are relative
  >>to the sender and are only valid in the sender's context. 
  >> To: attmail!somewhere!someone
  >> Cc: someone@machine.bitnet
  >>Can anyone's mailer handle a group reply to that?

>Only if the bang path is updated whenever the message is forwarded.

On the contrary - the recipient's UA can easily construct the path back
to the sending machine from the uucp From_ line, but then it can
build the destination address only if the headers have been untouched.

>A day or so ago, someone (maybe you) mentioned that pure UUCP hosts will
>only look at the From_ field.

I said that stock /bin/mail only uses the From_ line(s).

>The reality is that few hosts are "pure
>UUCP".  Most hosts using UUCP mail transport also have generic mail user
>agents (MH, MUSH, Emacs RMAIL, etc.).

Perhaps, if you are talking about the set of machines that participate
in usnet.  There are lots of machines that just have what someone loads
out of the box.  Others have commercial alternatives like AT&T's PMX-mailers.

>Because of the mix of protocols
>being used, most of these will recognize many different mail formats, and
>try to deal with them sensibly.  If the message looks roughly like RFC-822
>format they'll handle it; the UA rarely needs to parse the address portion
>of a header, all it has to do is hand it to the system's MTA.  So, even
>though the To field in the above example is invalid 822 format there's no
>reason for a UA to mind; the UA expects the MTA to deliver messages
>containing addresses that it is willing to have returned to it.

It is exactly this mix of protocols that causes the problem, and any
work-around requires an unfortunate intimacy between the MTA and the UA
(and worse, your neighbors MTA). In particular, if the UA wants to 
handle the relative addressing portion, then the MTA has to leave the
To: and Cc: headers alone.  If the UA wants the addresses already
relative to the local host, then the MTA has to fix them.  But, if your
MTA "fixes" them for your UA and also anything it passes to your neighbor
who doesn't want them fixed, you have created a problem.  A reasonable
solution would be to adjust the paths so they are relative to the local
machine only at final delivery and only if you know the locally used
UA's want it that way.  I can see a slight advantage in letting the
MTA do it in that you may have alternate names for the local machine that
the UA doesn't know about which may result in Cc:s to users on the same
machine as the recipient having their reply routed back through the
sender's host.  However the MTA doesn't really know when delivery is
complete since the first recipient may forward his copy on to someone
else. 

[...non ascii]
>I don't know about UUCP mailers, but RFC-821 mailers are definitely
>text-only.  Newlines are required to be converted to a standard format so
>that mail can be sent between systems with differing newline conventions,
>and not all such transformations are perfectly invertible.

The uucp mail transport is built on top of a more general file transfer
utility and thus will handle anything you throw at it. However, the normal
/bin/mail program and the common replacements that parse the addresses
and handle forwarding and local delivery are not binary-transparent.
Mostly they will lose NULLs due to the way fgets/fputs works.  I haven't
had any problem with smail 3.1 and I'm using it's bsmtp over uucp on
a couple of machines where large lists are active.  So far no one has
complained about any attachments failing to work when detached so it
must be inverting the transformation properly.
I don't really expect the attachments to work anywhere but my own uucp
links and through the attmail service, but that's where the traffic is.

>This is the
>reason the FTP protocol has an explicit command to perform binary
>transfers.

But I don't have a network link and I don't want the users to have
to wait for the operation to complete.  My traffic tends to be
about 100K/day with each of about 60 sites (basically one per state
plus a few others) which makes it hard to justify anything but
dial-up access.  I also don't want to train users in 50 states how
to transfer one type of file one way and another type another way
and how to tell the difference.  

>RFC-821 was designed for transfer of text mail; there are other protocols
>being developed to solve the more general problem.
>You can hammer a nail with a screwdriver, but don't complain to the
>screwdriver manufacturer if it's not easy.

That portion of the AT&T PMX mailers works just fine.  My problem was that
I wanted to send mail to users on BITNET and have them reply using their
normal reply command instead of having to retype the address as
user%afbf05@uunet.uu.net.  It turned out to be non-trivial to accomplish
that without breaking the extensions provided by the PMX-mail programs,
and there are still some unresolved loose ends (but that is a symptom
of a more general problem).

Les Mikesell
  les@chinet.chi.il.us