moore@cygnusx1.cs.utk.edu (Keith Moore) (05/08/89)
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
rayan@ai.toronto.edu (Rayan Zachariassen) (05/12/89)
In article <882@utkcs2.cs.utk.edu> moore@cygnusx1.cs.utk.edu (Keith Moore) writes:
# It appears
# that the RFC's only require that the _first_ of the "@host" names in
# a route-addr be registered.
Actually the requirement is for all of the RHS's of @'s to be official
canonical for-real Internet domain names. For various reasons this is
problematic and the proposed solution (in a future draft of the hosts
requirement RFC) will be to deprecate the @: routes in favour of %@ routes.
The stuff between the % and @ then does not have to be in the DNS, as
long as the stuff to the RHS of the @ *is*. No change in semantics, but
% becomes official.
# 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.
You have the exact right idea in my opinion, problem is that few others
have done it this way. I've tried to lobby for universal agreement on
some syntax for representing non-Internet routes in the Internet. If the
%@ proposal goes through, it would be an opportunity for all the gateways
to do it right:
a!b!c -> c%b@a.dom
a::"b!c" -> c%b@a.dom
a!@b:c@d -> !@#$&*@(^%
no more mixed-syntax addresses, please...
fat chance.
rayanvjs@rhyolite.SGI.COM (Vernon Schryver) (05/13/89)
In article <89May11.183003edt.11589@neat.ai.toronto.edu>, rayan@ai.toronto.edu (Rayan Zachariassen) writes: > .... If the > %@ proposal goes through, it would be an opportunity for all the gateways > to do it right: > > a!b!c -> c%b@a.dom > a::"b!c" -> c%b@a.dom > a!@b:c@d -> !@#$&*@(^% > > no more mixed-syntax addresses, please... What should be done done with a!b!c!d!e ? More than one % ? Keep some of the !'s ? Bounce it if the next hop, 'a', cannot be reached by UUCP, even though we are of course assuming it is a valid, registered, approved domain (or has such an synonym according to the maps)? I've seen more than a couple of such relatively benign things pass both ways through SGI's gateway. I'm just asking for the revealed wisdom of the coming RFC and what the big gateways will do, and not intending to attack anybody or anything. Vernon Schryver Silicon Graphics vjs@sgi.com