🚀 go-pugleaf

Just catching up on my news, and I had the following comments to add:

1.  In article <1635@ur-cc.UUCP>, Mark Sirota <msir@uhura.cc.rochester.edu> 
writes:
[in response to a suggestion that someone use an address of the form
 "user%machine1@machine2.dom"...]
>
>That is not a legal RFC822 address, either.  Please never recommend the
>use of '%' in addresses.  Please consider using something like
>
>        @machine2.dom:user@machine1
>
>Unfortunately, this is not quite legal either, is it?  I seem to recall
>that route-addrs need an accompanying phrase and should be in <>'s, as in:
>
>       Mark Sirota <@relay.cs.net:msir@cc.rochester.edu>

Others have pointed out that it's perfectly legal, though frowned upon,
to use '%' in the local part of an address (according to RFC822).
I would add that although RFC822 does require the accompanying phrase,
and some mailers go so far as to add a phrase if one does not already exist,
the draft host requirements RFC says that the phrase is not necessary.
The brackets are still required, however, to disambiguate the situation
where multiple routes are used.  Otherwise, "@domain1,@domain2,user@domain3"
would be parsed as three seperate addresses.


2.  In article <53257@uunet.UU.NET>, Rick Adams <rick@uunet.uu.net> writes:
>Source routes such as you "recommend" are strongly discouraged. They
>are a pain to parse and often end up being an undeliverable address.

This is true.  But they are legal, and all Internet mailers should handle 
them.  And they are useful.  Their main use is in generating nondelivery error 
messages, which should if possible traverse the inverse of the SAME PATH
that the undeliverable message traversed before being bounced.  Having
a syntax for source routed addresses makes this possible, and increases
the probability that the sender will be notified if a message is 
undeliverable.

The source routing syntax is also useful when sending mail across
multiple mail networks with different domain-name spaces, though it
doesn't often seem to be used for this purpose.  (more on this below)

Use of source routes is indeed discouraged in message _headers_, but 
is entirely proper in the SMTP message envelope.


3.  In article <oYImy1y00VsL80WYtI@andrew.cmu.edu>, 
Craig Everhart <cfe+@andrew.cmu.edu> writes:
>RFC822 requires that all ``@host'' names used in a route-addr be registered
>(presumably with a domain parent or with the root administrator).

I have heard this argument before, but I remain unconvinced.  It appears
that the RFC's only require that the _first_ of the "@host" names in
a route-addr be registered.  In fact, RFC821 contains some discussion as
to how to handle mail that is gatewayed between mail systems with different
domain name spaces.  For instance, part of section 3.6 reads:
  ``When a server-SMTP deletes its identifier from the forward-path and
  inserts it into the reverse-path, it must use the name it is known by
  in the environment it is sending to, not the environment the mail came
  from, in case the server-SMTP is known by different names in different
  environments.''

It seems unnecessary (and not always possible) to convert _all_ of the 
"@host" names in a source-route when gatewaying between two mail systems, 
and the language used here and elsewhere within RFC821 seems to imply 
that this is not actually required.  Section 3.7 does read:
  ``Whenever domain names are used in SMTP only the official names are used,
  the use of nicknames or aliases is not allowed.''
but I do not interpret this as a prohibition against the use of "offical"
names from _other_ mail networks (including, perhaps, your own local network)
in source-route addresses.

Am I missing something here?  It seems like the source-routing mechanism
is well-designed and tailor-made for sending mail across gateways into
other mail systems, but isn't being widely used because (a) many mailers
still do not support source routing even eight years after the RFCs
were issued, and (b) the RFCs do not make it absolutely clear that such 
use of source routing is appropriate.


4.  In article <6916@bsu-cs.bsu.edu>, Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
writes:
>This points out an omission in the Internet RFCs.  There is no
>provision for a bracketing syntax, e.g.
>
>     a!<b%c>@d
>     <a!b%c>@d
>     a!<b%c@d>
>

Actually, as far as the RFCs are concerned, you could use a quoted string
to encapsulate the "foreign" address as a single token in the local-part
of an RFC822 address.  One problem with this is that the quotes will almost 
certainly get stripped before the message makes it to the gateway.  Another 
problem is that the gateway has to strip the quotes from the address if
and only if the entire local-part of the address is quoted.  Needless to 
say, this is difficult to do with sendmail.  

I've used this technique in a DECnet-to-RFC822 mail gateway, by putting
quotes around multiple-hop DECnet source routes in the From: address.
The resulting addresses are indeed ugly, but they are also both legal
and unambiguous.

>We are stuck for the moment with a horrible design decision.  I hope
>X.400 is better.

Again, I think this the purpose for which the source routing mechanism was
designed, and it would work well if widely adopted.  I'll reserve
judgement on X.400 until I've reread the specs another time or two, but
my current impression is that its addressing syntax is very awkward, and the
routing mechanisms currently in use in the X.400 world are several years
behind that of the Internet DNS.  It will be awhile before things improve.

Keith Moore
UT Computer Science Dept.	Internet/CSnet: moore@utkcs2.cs.utk.edu
107 Ayres Hall, UT Campus	BITNET: moore@utkvx
Knoxville Tennessee 37996-1301	Telephone: +1 615 974 0822


Keith Moore
UT Computer Science Dept.	Internet/CSnet: moore@utkcs2.cs.utk.edu
107 Ayres Hall, UT Campus	BITNET: moore@utkvx
Knoxville Tennessee 37996-1301	Telephone: +1 615 974 0822