🚀 go-pugleaf

In article <27710AE7.1356@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:

>>I contend that the envelope return should be used by uucp sites
>>unless they are quite sure that the headers are always usable.

>Well, that's great, unless replies are to be routed according to a
>local paths database, like here.  So we use Reply-To: and From:.

In practice, it should be pretty rare that the recipient's response
should go a different route than an error return.  If the Reply-To:
is munged as well and you want to use it, then you have a problem.
Using !-notation for the addressing is not at odds with paths routing,
though.

>Unfortunately, due to the header munging I decry, I found it necessary
>to add to Elm a "domainize" feature, which converts "x!y!z" to "z@y".
>I don't consider this Rabid Rerouting, incidentally, because it is
>done in the User Agent at user request.

I'm not arguing *for* header munging - I don't think any host should
prepend their own name to the header lines.  But if it were not
for encouraging that practice I wouldn't object to the domain!user
re-write. 

>Forgive me, but I don't see that this statement has any supporting
>evidence.  Surely it doesn't assert that a UUCP-based mail link is
>incapable of complying with RFC822?

Given the proper support software there is no particular problem in
delivering to domain style addresses and assuming you have a registered
domain name there is no problem in putting it in the From: line.

The place where the philosophical difference arises is when you want
to generate a group-reply from the To: and Cc: lines.  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?

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

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

No, it's asking to save non-trivial amounts of money by not having 
to ascii-ize everything, not to mention training everyone involved
to know the difference between ascii and non-ascii.  A seat-of-the
pants guess is that it would raise our phone bills about $10K/year
if everything that is being sent as attachments grew by a third
from being encoded.

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.

Les Mikesell
  les@chinet.chi.il.us