🚀 go-pugleaf

In article <1990Dec18.155353.5024@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:

>>What do you expect to happen when the "site!user@domain" form goes back off
>>the internet down a path to a uucp destination? 

>  I expect the internet -> UUCP gateway to transform the address to
>'site!user' if the gateway happens to be 'domain', and to transform it to
>'domain!site!user' (or perhaps 'gateway!domain!site!user') otherwise.  Most
>Internet to UUCP gateways do this, Chip Salzenberg to the contrary
>notwithstanding.  In that case prepending another 'node!' by a site along the
>way doesn't totally massacre the address.

That's correct for the uucp "envelope" (From_ line and rmail destination
of course, but it is as bad for my mailer to see something like that in
the headers as it is for yours - would you do that to a local delivery?
In any case, this doesn't seem to be handled consistantly.  Some sites
leave the site!user@domain form in the headers which is pretty much a
disaster any way you look at it.  Also, many sites will prepend their
names in the headers *only* if there is already a "!" there.

>>In the case of fb.com it will look pretty much the way you write it but
>>my machines deliberately interpret the !-path first to accomodate a
>>broken (but not replacable) UA that generates group replies by making
>>a path back to the sending machine prepended to the To: and CC: addresses.
>>(But my reply to the sender will work anyway because it will use the
>>uucp From_ line).
>
> Oh.  You mean that while complaining about everyone else's software, you
>own software is hopelessly broken!

Broken is kind of a harsh word - let's say the UA is optimized for
relative addressing.  It expects to find To: and Cc: addresses the
way the sender wrote them and constructs group replies by using the
From_ line to build a path back to the originating site, then tacking
on whatever the sender used and optimizing away the redundent hops.  
From the uucp perspective that you *can't* know anything beyond your
neighbors, that is the correct approach but of course alternate names
for the same machines make it less than optimal.  It is clear that
this approach will not work at all though, if the addresses the sender
put on the To: and Cc: lines have been altered in transport.  In any
case this particular UA (AT&T's PMX-mailers) has some functions that
aren't available in anything else that I've seen (multiple binary
attachments, versions that run on PC's with background communications, etc.)
and I don't have source, so anything that needs to be fixed has to be
done at the transport level.  Also, I have to be able to continue to
talk to the attmail service which wants and generates uucp-looking headers.

Regarding your suggestion in another thread about putting an additional
set of headers in the body portion of the message, this UA would
be upset if anything touches the body.  It inserts a Content-Length:
header and expects to be able to use it to separate attachments.

> As pointed out by others, the name space for which I have authority to
>create names may not be an appropriate name space for my UUCP neighbors.
>This is a side effect of the organizational orientation of the Internet
>names. 

What I am suggesting is that you create a new domain solely for the
purpose of establishing an organization where none currently exits.
The intent of the organization would be to maintain sanity in the
mail system.   

Les Mikesell
  les@chinet.chi.il.us