Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.mail.misc
Subject: Re: Which headers may Sendmail re-write?
Message-ID: <1990Dec22.014625.22543@Think.COM>
Date: 22 Dec 90 01:46:25 GMT
References: <1990Dec19.171943.18595@chinet.chi.il.us> <27710AE7.1356@tct.uucp> <1990Dec21.193938.29940@chinet.chi.il.us>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 73

In article <1990Dec21.193938.29940@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In practice, it should be pretty rare that the recipient's response
>should go a different route than an error return.  

You contradict this later in the same message:

>The place where the philosophical difference arises is when you want
>to generate a group-reply from the To: and Cc: lines.

Which, in my experience, is extremely common.  Most of the users here have
their UA's reply command configured to do this by default.  Another case
that may be common in some organizations is a secretary sending mail for
the boss; the envelope return address and the 822 Sender: field should be
the secretary, but the From field should be the boss.  Finally, mailing
list exploders should arrange for error messages to go to the maintainer of
the list, but replies should go to the author of the message.

At various times during this discussion Post Office analogies have been
used, so here's another (somewhat imperfect) one: the closest analogy to
the email envelope is the PO's postmark.  The From field is like the return
address, the Reply-To field is the inside address, and the Sender field is
the secretary's initials below the closing.

>  The domain
>philosophy says that the addresses are absolute and can be simply
>extracted and used as-is (assuming they haven't been modified in
>transport).  The uucp philosophy says that addresses are relative
>to the sender and are only valid in the sender's context.  So,
>my mailer will happily deliver a message like so:
> 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.

A day or so ago, someone (maybe you) mentioned that pure UUCP hosts will
only look at the From_ field.  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.).  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.

>>Sending non-ASCII in a mail message is just asking for trouble.  And I
>>don't mean only from UUCP mailers.

>I'd say that not being able to deliver whatever the mail transport
>receives is asking for trouble and will force you to either work
>around the limitations or provide an alternative service.

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.  This is the
reason the FTP protocol has an explicit command to perform binary
transfers.  RFC-821 also allows MTA software that has a fixed-size input
line buffer by imposing a maximum line length (256 characters, I think).
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.

--
Barry Margolin, Thinking Machines Corp.

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