🚀 go-pugleaf

In article <8120004@hpfclp.HP.COM> diamant@hpfclp.HP.COM (John Diamant) writes:
>All these [RFC{822,920,976}]
>standards explicitly require "@" precedence, and indeed, the whole point of
>SMAIL was to make the UUCP world RFC compliant.

This was my observation; I want to quote it here to help drill in two points:
1- every known Internet RFC that mentions it at all requires @-precedence;
2- SMAIL is compliant with the RFC's -- that's its reason for existing.

>[Paul Vixie writes:]
>> There is also no need rewrite the envelope unless the destination CANNOT
>> deal with it, so only gateways should have to do it, right?  And a UUCP to
>> RFC822 gateway can always produce a <> route, and a RFC822 to UUCP gateway
>> can always produce a ! route, right?
>
>I wish it were that simple.  Obviously, this is what you would have in an
>ideal world (only gateways worry about address translation), but it isn't
>that simple, unfortunately.
>
>First of all, RFC-822 source routes can only be
>used if each element is a registered domain (there are subtle points in the
>wording of RFC-822 which mandate this).  This means, unregistered UUCP hosts
>cannot be put in source routes.

Feh.  I hadn't read this anywhere, but it sounds like a nasty.  I gateway
between UUCP and SMTP internally all the time, and I certainly don't check
any list to see if the site is registered before writing it into an RFC822
route-addr.  Perhaps this restriction only applies to real live Internet
mail, and is a political thing meant to keep DDN from being used as a
carrier for non-DDN-destined messages?  I know that that political restriction
exists (though it is widely, er, "bent" :-)); is this just another form of
it?  I expect that a lot of sites use RFC822-style route-addrs at some point
in their internal networks without checking to see that each element of the
route is a registered domain.

Thanks for bringing this up, John.  Now, can we discuss it some?

>One more problem is how to handle "%." Since
>it isn't specified by any standard, it must remain untouched, which might work
>O.K.  if the precedence everywhere were always "@", "!", any other characters
>(including "%"), but some sites don't know anything about "!" and so interpret
>"%" as higher precedence than "!."

Gag me with a hetrogeneous network.  This IS a problem -- % is widely used,
but undocumented.  This is a major hole in the Internet mail standards, and
it's what lets SMTP be ambiguous about what it will do with an address.

Still, the % operator is not absolutely neccessary in a pure RFC822 or UUCP
world -- there is a way in each standard to specify a route unambiguously.
Therefore a gateway from a net that had local usage of "%" could do whatever
the local users expect when parsing the "%"'s, and put out either a !-path
or a route-addr when passing the message into the RFC-compliant network.

If there are networks which have members that put out ambiguous addresses,
the members should be encouraged not to do that.  Internet and UUCPnet differ
somewhat in this respect -- UUCPnet is a free-for-all.  But even in UUCPland,
an address/route that contains only words, dots, and bangs will be very hard
to misunderstand.  A gateway (or even a single site) that wants to be able
to accept addresses with @'s or %'s in it can rewrite according to local
customs when putting the message out onto the UUCPnet.  Or the Internet.

>When you translate from "!" addresses to
>RFC style addresses, how do know whether to use a source route or a "%?"

I'd say always use a source route.  Is this unfeasable?  Are there Internet
sites (here I mean DDN-only sites) that don't grok source-routes, and need
%-routes?  This sounds like the point to push, if so.

>[Paul Vixie again:]
>> It is much more likely that we can get fixed gateways than asking all
>> sites in the universe to perpetuate the confusion between a route and an
>> address.  What Rahul is asking is a new way to write routes, and we already
>> have perfectly unambiguous ways to do that.
>
>It certainly would be easier if all we needed is to get only gateways fixed,
>but I don't know how to hide all this from the non-gateway machines.

If we take "gateway" to mean a mail transport program on some host that
generates messages into a network (UUCP or SMTP, in this discussion) where
the source of the messages is either a local user or a non-public (i.e.,
internal) network, then the "gateway" is responsible for rewriting the
source and destination addresses into something acceptable to the public
network (UUCP or SMTP).  The major public networks, UUCP and SMTP, have
(as far as I know) unabiguous syntaxes for full source routes -- either
	UUCP:	host1!host2!host3!finalhost!user
or	SMTP:	<@host1,@host2,@host3:user@finalhost>

Addresses containing operators or combinations of operators which have no
standard meaning in the public network (like %, or combinations of %/@, or
%/!, or !/@) can rewrite according to local (host or internal network)
custom.

Okay, pour it on: what am I missing?

>John Diamant
>TSBU				UUCP:  {hplabs,hpfcla}!hpfclp!diamant
>Hewlett Packard Co.		ARPA Internet: diamant%hpfclp@hplabs.HP.COM
>Fort Collins, CO

-- 
Paul A Vixie Esq
329 Noe Street       {ptsfa, crash, hoptoad, ucat}!vixie!paul
San Francisco        ptsfa!vixie!paul@ames.arc.nasa.gov
CA  94116            paul@vixie.UUCP     (415) 864-7013