Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!gatech!utkcs2!cygnusx1.cs.utk.edu!moore From: moore@cygnusx1.cs.utk.edu (Keith Moore) Newsgroups: comp.mail.sendmail Subject: Re: sendmail parsing questions - my comments Message-ID: <882@utkcs2.cs.utk.edu> Date: 8 May 89 10:00:42 GMT References: <1635@ur-cc.UUCP> <53257@uunet.UU.NET> <6916@bsu-cs.bsu.edu> Sender: news@utkcs2.cs.utk.edu Reply-To: moore@cygnusx1.cs.utk.edu (Keith Moore) Organization: CS Dept -- University of TN, Knoxville Lines: 124 Just catching up on my news, and I had the following comments to add: 1. In article <1635@ur-cc.UUCP>, Mark Sirota 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 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 , Craig Everhart 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 writes: >This points out an omission in the Internet RFCs. There is no >provision for a bracketing syntax, e.g. > > a!@d > @d > a! > 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