Thread View: comp.mail.sendmail
28 messages
28 total messages
Started by tron@Veritas.COM
Sun, 01 Sep 1991 07:24
Smail3, RFC1123, and the ! and % operators
Author: tron@Veritas.COM
Date: Sun, 01 Sep 1991 07:24
Date: Sun, 01 Sep 1991 07:24
43 lines
2085 bytes
2085 bytes
In RFC1123 paragraph 5.2.16 states: An embedded source route is sometimes encoded in the "local-part" using "%" as a right-binding routing operator. For example, in: user%domain%relay3%relay2@relay1 the "%" convention implies that the mail is to be routed from "relay1" through "relay2", "relay3", and finally to "user" at "domain". This is commonly known as the "%- hack". It is suggested that "%" have lower precedence than any other routing operator (e.g., "!") hidden in the local-part; for example, "a!b%c" would be interpreted as "(a!b)%c". I consider this interpretation to be incorrect and prefer a!(b%c), which is how Smail3 operates right now. I would really like to know what opionions people have on this topic. If all mailers conform to RFC1123, then people who know the RFC1123 will have some idea of what to expect from a remote site. From that standpoint, Smail3 should probably be changed. However, I consider it incorrect from the standpoint of correct operation in the world of UUCP. Perhaps from the standpoint of Internet operation it makes somewhat more sense. What do people think? Somebody has sent me a set of "fixes" to smail which, among other things, defines a flag for whether to use the old behavior or the RFC1123 behavior. This doesn't seem like the kind of decision that a site should make on its own. If one site considers % to be a high-precedence operator, in the sense of the existing Smail3, then it can turn a%b@c into x!y!z!c!a%b. If site y considers % to be a low-precedence operator, then it will deliver z!c!a to site b, which is not what the original site wanted. Comments and opinions would be appreciated. My current intention is to either leave smail alone or make the new behavior mandatory. Having a flag seems the worst of both worlds. -- tron |-<=>-| ARPAnet: veritas!tron@apple.com tron@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron
Re: Smail3, RFC1123, and the ! and % operators
Author: rickert@mp.cs.ni
Date: Sun, 01 Sep 1991 15:21
Date: Sun, 01 Sep 1991 15:21
61 lines
3204 bytes
3204 bytes
In article <1991Sep01.072418.15414@Veritas.COM> tron@Veritas.COM (Ronald S. Karr) writes: >In RFC1123 paragraph 5.2.16 states: >[...] > local-part; for example, "a!b%c" would be interpreted as > "(a!b)%c". > >I consider this interpretation to be incorrect and prefer a!(b%c), >which is how Smail3 operates right now. > >I would really like to know what opionions people have on this topic. >If all mailers conform to RFC1123, then people who know the RFC1123 >will have some idea of what to expect from a remote site. From that RFC1123 is itself ambiguous. The notation (a!b)%c is really meaningless for email addresses. The authors of RFC1123 apparently intended it to mean -> c -> a -> b , which seems to contradict the term "lower precedence". Before RFC1123 there were many mailers, including smail and most sendmail configurations which interpreted a!b%c as -> a -> c -> b . There were other mailers which by default interpreted it the way RFC1123 intended since they did not treat '!' a routing character at all. Since RFC1123 there is been little change in the way mailers interpret these mixed addresses. Changing the interpretation tends to break too many things. There has, however, been some degree of change in the formats of addresses created. Many have concluded that the only reasonable reaction to RFC1123 is to avoid ever mixing '%' and '!' in an address. If an address already contains '!' and you wish to add additional routing, better to use another '!'. In the sendmail/IDA rulesets, I did design the parsing so that if the address contains an '@' the RFC1123 order is followed, but if there is no '@' the smail order is followed. However the rule which makes that distinction is commented out so that the smail order is used to interpret all incoming addresses. This seems to still be more reliable. >What do people think? Somebody has sent me a set of "fixes" to smail >which, among other things, defines a flag for whether to use the old >behavior or the RFC1123 behavior. This doesn't seem like the kind of >decision that a site should make on its own. If one site considers % >to be a high-precedence operator, in the sense of the existing Smail3, >then it can turn a%b@c into x!y!z!c!a%b. If site y considers % to be a It is better to turn that into x!y!z!c!b!a . Most mail software which can handle '!' can deal with this. In most cases site 'c', after stripping off its name, would convert the remaining 'b!a' into 'a@b' as long as there is at least one '.' in 'b'. If by some chance 'c' does not do this conversion, but sends to 'b' anyway, the chances are that 'b' will still handle it correctly. The only time problems occur is when the site 'c' does not convert but sends to a site 'b' which does not understand the '!' operator. Mostly this occurs when 'c' is a unix system with a very old or very badly botched sendmail configuration and 'b' is a BITNET gateway. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
Re: Smail3, RFC1123, and the ! and % operators
Author: vjs@rhyolite.wpd
Date: Sun, 01 Sep 1991 22:13
Date: Sun, 01 Sep 1991 22:13
26 lines
1124 bytes
1124 bytes
In article <1991Sep1.152150.18422@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil Rickert) writes: > ... > RFC1123 is itself ambiguous. The notation (a!b)%c is really meaningless > for email addresses. The authors of RFC1123 apparently intended it > to mean -> c -> a -> b ,... > ... > It is better to turn that into x!y!z!c!b!a . I think this is all true, expect for the "authors ... intended". I got the impression that the multiple-% stuff is present only because one or two participants were postmasters in the North East who were great fans of long %-routes. (They may still like them.) I think the vast majority of well connected sites avoid multiple %'s, rewriting into multple !'s or RFC-822 source routes, and that almost everyone looks for % after paying attention to @ and !. Does "lower precedence" mean "binds more" or "less tightly". English is too sloopy for such stuff. Regardless of whether authors of 1123 might agree that it is ambiguous, many people will choose the opposite of whichever was meant. Thus, pragmatic considersations require avoidng mixing % and !. Vernon Schryver, vjs@sgi.com
Don't even jest it! (Smail3, RFC1123, !%, and the world!)
Author: lear@turbo.bio.n
Date: Mon, 02 Sep 1991 01:06
Date: Mon, 02 Sep 1991 01:06
11 lines
313 bytes
313 bytes
What this world needs are fewer routing operators. Let's help end the % hack in our lifetime. Oh, and source routes, when used, are generally illegal according to RFC 822. Each name in a source route is supposed to be a registered FQDN. Often times this is not the case. -- Eliot Lear [lear@turbo.bio.net]
Re: Smail3, RFC1123, and the ! and % operators
Author: urlichs@smurf.su
Date: Mon, 02 Sep 1991 09:24
Date: Mon, 02 Sep 1991 09:24
21 lines
1087 bytes
1087 bytes
In comp.mail.misc, article <1991Sep1.221351.14463@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: < < I got the impression that the multiple-% stuff is present only because one < or two participants were postmasters in the North East who were great fans < of long %-routes. (They may still like them.) I think the vast majority < of well connected sites avoid multiple %'s, rewriting into multple !'s or < RFC-822 source routes, and that almost everyone looks for % after paying < attention to @ and !. < I second the thought (which seems to be more-or-less generally accepted) that the most sensible order of evaluation is @-!-%. However, rewriting %-adddresses is not a good idea. Unless you are the machine to the right of the last %, you shouldn't mess with these addresses; and even then the only thing you should do is to convert the last % to a @ and run the address through the router again. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/
Re: Smail3, RFC1123, and the ! and % operators
Author: tron@Veritas.COM
Date: Mon, 02 Sep 1991 10:35
Date: Mon, 02 Sep 1991 10:35
36 lines
1746 bytes
1746 bytes
In article <1991Sep1.221351.14463@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Does "lower precedence" mean "binds more" or "less tightly". English is >too sloopy for such stuff. Regardless of whether authors of 1123 might >agree that it is ambiguous, many people will choose the opposite of >whichever was meant. The example and the text of RFC1123 are in agreement and do not agree with the behavior I currently use. > Thus, pragmatic considersations require avoidng >mixing % and !. I can't say I ever use them myself. However, smail has to do something Thus, the question is not whether people should use % and or !, but how smail should behave when given one. There is, I think, a simple convincing argument for doing it the way that Smail currently does it. Consider an address X@Y. According to RFC976 (the UUCP/Internet gateway standard) UUCP sites convert X@Y into path!...!Y!X. Also, according to other RFC's, X should be interpreted by site Y, and no other site. Thus, if X is a%b, the result should be path!...!Y!a%b. If X were a!b, this would be correct. This should be correct even if X were a%%%!!b, and site Y had a user with that name (although the Postmaster of such a site might receive obnoxious mail every once in a while, and users on his site might receive less mail than others in the greater E-mail community). In order to make Smail conform to the RFC, I believe that I have no choice but to turn a%b@Y into path!...!Y!b!a. NOTE: nothing in these arguments apply to header addresses. The arguments (and the problems) arrise only in envelope addresses. -- tron |-<=>-| ARPAnet: veritas!tron@apple.com tron@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron
Re: Smail3, RFC1123, and the ! and % operators
Author: barrett@daisy.ee
Date: Mon, 02 Sep 1991 20:54
Date: Mon, 02 Sep 1991 20:54
33 lines
1360 bytes
1360 bytes
In article <1991Sep01.072418.15414@Veritas.COM>, tron@Veritas.COM (Ronald S. Karr) writes: > In RFC1123 paragraph 5.2.16 states: rfc1123> It is suggested that "%" have lower precedence rfc1123> than any other routing operator (e.g., "!") hidden in the rfc1123> local-part; for example, "a!b%c" would be interpreted as rfc1123> "(a!b)%c". > I consider this interpretation to be incorrect and prefer a!(b%c), > which is how Smail3 operates right now. Some RFC822 mailers understand @ and %, but do not understand ! (sorry, no example here). Others understand @, % and ! but make ! bind more tightly than % (PMDF is an example of this class). Some UUCP mailers understand ! and @, but either do not understand % (like vanilla smail2.x) or make % bind more tightly than ! (like some modified versions of smail2.x) Ancient UUCP mailers understand ! but do not understand @ and %. It is not possible to be compatible with all existing mailers, so hybrid addresses should really be avoided. Personally, I would go with the RFC1123 requirement of making % bind less tightly than other routing operators, so a!b%c means (a!b)%c. John Klensin, are you out there? --apb Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa RFC822: barrett@ee.und.ac.za Bang: m2xenix!quagga!undeed!barrett
Re: Smail3, RFC1123, and the ! and % operators
Author: mills@ccu.umanit
Date: Mon, 02 Sep 1991 23:51
Date: Mon, 02 Sep 1991 23:51
29 lines
1066 bytes
1066 bytes
In <ch2bhbr@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >However, rewriting %-adddresses is not a good idea. Unless you are the >machine to the right of the last %, you shouldn't mess with these addresses; Here's how I would do it: 1) determine that your host is the one responsible for interpreting the address. It must look like either ``localstuff@your.dom.ain'' or ``your.dom.ain!restofit'', meaning an Internet domain address. 2) if so, remove your domain, making it a possibly-local address. 3) look for the rightmost ``%'' and change it to a ``@''. 4) if found, route it to the responsible host. 5) look for the leftmost ``!'' and the preceeding node name. 6) if found, route it to the responsible host. 7) it's a local address. do local delivery. This is how my sendmail.cf (based on one written by Eric Fair) does it. Now, if the address contains no ``@'' and it's addressed to your UUCP node name, the interpretation could be different. -- -Gary Mills- -Networking Group- -U of M Computer Services-
Re: Smail3, RFC1123, and the ! and % operators
Author: rickert@mp.cs.ni
Date: Tue, 03 Sep 1991 12:34
Date: Tue, 03 Sep 1991 12:34
37 lines
1871 bytes
1871 bytes
In article <1991Sep02.205429.7343@daisy.ee.und.ac.za> barrett@daisy.ee.und.ac.za (Alan P Barrett) writes: >Some RFC822 mailers understand @ and %, but do not understand ! (sorry, >no example here). Others understand @, % and ! but make ! bind more The IBM mailers on VM systems understand @ and % but not !. There are many of these, and with the current move of many BITNET hosts to join Internet, the number is growing. >Ancient UUCP mailers understand ! but do not understand @ and %. Fortunately these are a vanishing breed, and mostly separated from internet by some other host which knows how to deal with the problem. >It is not possible to be compatible with all existing mailers, so hybrid >addresses should really be avoided. Personally, I would go with the >RFC1123 requirement of making % bind less tightly than other routing >operators, so a!b%c means (a!b)%c. This is the statement I don't like. It says less than it seems. Like RFC1123 it is confusing. What does it mean to say '%' binds less tightly than '!', or to use parentheses to specify binding? It is better to think of '!' as a unary operator binding to its left operand, and '%' as a unary operator binding to its right operand. What does it mean when RFC1123 says that '!' has higher precedence, but does not specify whether it is ordering precedence from low to high, or from high to low? In mathematical terms, the binding, or the use of parentheses, specifies the associativity of operators. The problem here with email addressing operators is instead one of commutativity. Can we use clear unambiguous terminology? -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
Re: Smail3, RFC1123, and the ! and % operators
Author: peter@ficc.ferra
Date: Tue, 03 Sep 1991 17:35
Date: Tue, 03 Sep 1991 17:35
32 lines
1493 bytes
1493 bytes
In article <1991Sep01.072418.15414@Veritas.COM> tron@Veritas.COM (Ronald S. Karr) writes: > I consider this interpretation to be incorrect and prefer a!(b%c), > which is how Smail3 operates right now. > I would really like to know what opionions people have on this topic. I would agree with smail3 on this topic, since it is more useful: it allows one to send to bang!inetuser%inet. Since ! is already at a higher priority than @, you can already send to bang!banguser@inet. Thus the RFC1123 definition adds no functionality. On the other hand, from the internet side things change. If you want to route to inet1, then to inet2, and then to bang!banguser you would need to use RFC1123's semantics and use bang!banguser%inet2@inet1. If you think of % as a nested @, these semantics seem obvious. This means you can't use uucp to connect two internets, but you shouldn't have to: generally you only need to do this sort of mess at the internet-othernet interface. So, which way is more useful depends on where you're coming from. Since RFC1123 is the standard, it would be best to stick to it. Since you can pretty much assume RFC976 conformance from any site on the interface by now, you would use bang!inet!inetuser or inet!bang!banguser. The functionality that smail-3's semantics provide is already present I would say, then, change smail. -- Peter da Silva Ferranti International Controls Corporation Sugar Land, TX 77487-5012; +1 713 274 5180 "Have you hugged your wolf today?"
Re: Smail3, RFC1123, and the ! and % operators
Author: koreth@twitterpa
Date: Tue, 03 Sep 1991 22:57
Date: Tue, 03 Sep 1991 22:57
24 lines
1135 bytes
1135 bytes
In <1991Sep3.123457.10922@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <1991Sep02.205429.7343@daisy.ee.und.ac.za> barrett@daisy.ee.und.ac.za (Alan P Barrett) writes: >>a!b%c means (a!b)%c. > Can we use clear unambiguous terminology? The parentheses weren't, I think, intended to be part of a mail address, but instead to emphasize the precedence. So read it, "a!b%c means go to host c, then to host a, then to address b." Another example (and incidentally, I agree that this should be made standard somehow; it's very confusing for new mail users to navigate through networks that parse this stuff in different ways): a!b!c%d!e%f!g!h%i should be the same as i!f!g!h!d!e!a!b!c Frankly, I'm a little mystified by the RFC822 authors' decision to use the ugly @x,@y,@z:a@b syntax instead of standardizing an existing mail routing character or two for the same purpose. --- Steven Grimm koreth@eng.sun.com Moderator, comp.{sources,binaries}.atari.st "We must be brave, and not let them know how frightened we really are." -- OPEN LOOK Graphical User Interface Functional Specification
Re: Smail3, RFC1123, and the ! and % operators
Author: csvned@jarthur.C
Date: Wed, 04 Sep 1991 04:07
Date: Wed, 04 Sep 1991 04:07
7 lines
204 bytes
204 bytes
Actually, PMDF can be configured to bind either % or ! more tightly, and this can be done on a per-channel basis. I've never heard of anyone using this feature for any useful purpose, however. Ned
Re: Smail3, RFC1123, and the ! and % operators
Author: chip@tct.com (Ch
Date: Wed, 04 Sep 1991 21:06
Date: Wed, 04 Sep 1991 21:06
14 lines
682 bytes
682 bytes
According to rickert@mp.cs.niu.edu (Neil Rickert): >In article <1991Sep01.072418.15414@Veritas.COM> tron@Veritas.COM (Ronald S. Karr) writes: >>If one site considers % to be a high-precedence operator, in the sense of >>the existing Smail3, then it can turn a%b@c into x!y!z!c!a%b. > >It is better to turn that into x!y!z!c!b!a. I would avoid any interpretation of "%", unless there are no other routing operators to be found in the address. In other words: Put no interpretation on the "local-part" unless the address is local. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "He's alive; he's fat; and he's fighting crime. He's Elvis: FBI."
Re: Smail3, RFC1123, and the ! and % operators
Author: fitz@wang.com (T
Date: Wed, 04 Sep 1991 23:09
Date: Wed, 04 Sep 1991 23:09
27 lines
1157 bytes
1157 bytes
tron@Veritas.COM (Ronald S. Karr) writes: > I would really like to know what opionions people have on this topic. > If all mailers conform to RFC1123, then people who know the RFC1123 > will have some idea of what to expect from a remote site. From that > standpoint, Smail3 should probably be changed. However, I consider it > incorrect from the standpoint of correct operation in the world of > UUCP. Yah, rah. Since UUCP sites are forced to rewrite @ into !, those two operators should be next to each other in precedence. Following RFC1123, regardless of its inherent virtues as a standard, causes mail to be misrouted. > Comments and opinions would be appreciated. My current intention is to > either leave smail alone or make the new behavior mandatory. Having a > flag seems the worst of both worlds. Agreed - when half the sites in the world configure it one way and half the other way, nobody will know how to address mail to get it through. I think smail 3.1 should keep working the way it is. I wish RFC 1123 could be changed. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
Re: Smail3, RFC1123, and the ! and % operators
Author: fitz@wang.com (T
Date: Wed, 04 Sep 1991 23:21
Date: Wed, 04 Sep 1991 23:21
36 lines
1641 bytes
1641 bytes
rickert@mp.cs.niu.edu (Neil Rickert) writes: > RFC1123 is itself ambiguous. The notation (a!b)%c is really meaningless > for email addresses. The authors of RFC1123 apparently intended it > to mean -> c -> a -> b , which seems to contradict the term "lower > precedence". The authors seem to be using "lower precedence" to mean "binds more loosely", which does kinda make sense. This interpretation is the only thing that makes the document read consistently, anyway. > Many have concluded that the only reasonable > reaction to RFC1123 is to avoid ever mixing '%' and '!' in an address. > If an address already contains '!' and you wish to add additional > routing, better to use another '!'. This is a good rule of thumb for humans but doesn't help mailers much. A UUCP mailer has to rewrite @ addresses into ! paths to get them through layers of UUCP hosts to a possibly-smart machine on the other side. If the possibly-smart machine wants to see a % address there's no way to rewrite it without getting a mix of ! and % addresses. >> then it can turn a%b@c into x!y!z!c!a%b. If site y considers % to be a > It is better to turn that into x!y!z!c!b!a . Most mail software which > can handle '!' can deal with this. Well, you're rewriting the local-part of somebody else's address here. I can't find it right now but I think RFC 1123 has a recommendation against this. Also, there are some mailers that can understand % addresses but can't understand !. Older Wollongong TCP/IP packages are like this, I believe. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
Re: Smail3, RFC1123, and the ! and % operators
Author: fitz@wang.com (T
Date: Wed, 04 Sep 1991 23:34
Date: Wed, 04 Sep 1991 23:34
31 lines
1342 bytes
1342 bytes
peter@ficc.ferranti.com (Peter da Silva) writes: > On the other hand, from the internet side things change. If you want to > route to inet1, then to inet2, and then to bang!banguser you would need > to use RFC1123's semantics and use bang!banguser%inet2@inet1. Why not "inet2!bang!banguser@inet1"? inet2 must be able to handle ! syntax since it's apparently about to pass the message off to a UUCP-only machine. Or, since you're on the Internet, "@inet1:bang!banguser@inet2"? Yes, it's disgusting to me too but it's legal. I'm not sure your example is relevant anyway. Users on the Internet rarely need to hand-route through 2 relays to get to a destination site, while this is common for the UUCP net. > If you > think of % as a nested @, these semantics seem obvious. This means you can't > use uucp to connect two internets, but you shouldn't have to: We've got a company internet here that's not connected to the real Internet, and we'd like to get mail through. There are hundreds of other organizations in the same position. > So, which way is more useful depends on where you're coming from. Since > RFC1123 is the standard, it would be best to stick to it. I think RFC 1123, despite being standard, causes problems. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
Re: Smail3, RFC1123, and the ! and % operators
Author: barrett@daisy.ee
Date: Thu, 05 Sep 1991 11:28
Date: Thu, 05 Sep 1991 11:28
55 lines
2690 bytes
2690 bytes
In article <1991Sep3.123457.10922@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil Rickert) writes: > >It is not possible to be compatible with all existing mailers, so hybrid > >addresses should really be avoided. Personally, I would go with the > >RFC1123 requirement of making % bind less tightly than other routing > >operators, so a!b%c means (a!b)%c. > > This is the statement I don't like. It says less than it seems. Like > RFC1123 it is confusing. What does it mean to say '%' binds less tightly > than '!', or to use parentheses to specify binding? I think of ! as a binary operator that associates from the left, and of % as a binary operator that associates from the right. If ! binds more tightly than %, then the a!b portion of a!b%c is considered as one unit when the % operator is applied, so the address means (roughly) ``tell system c to send to a!b''. On the other hand, if % binds more tightly than ! then b%c is considered as one unit when the ! operator is applied, so the address means (roughly) ``tell system a to send to b%c''. The parentheses in ``(a!b)%c'' don't go anywhere the mailer; they are simply there to tell people what the address ``a!b%c'' *means*. (Or, rather, what one possible interpretation of the address means.) > It is better to think of '!' as a unary operator binding to its left > operand, and '%' as a unary operator binding to its right operand. Unary operators? I see stuff on both sides of the !'s and %'s. > What does it mean when RFC1123 says that '!' has higher precedence, > but does not specify whether it is ordering precedence from low to > high, or from high to low? The (a!b)%c example in RFC1123 clarifies what they mean by ``higher precedence''. Clearly, they want a!b%c to mean ``tell system c to send to a!b''. > In mathematical terms, the binding, or the use of parentheses, > specifies the associativity of operators. The problem here with email > addressing operators is instead one of commutativity. I don't think there is a problem with commutativity. I think we all agree that the addressing operators are *not* commutative (``a!b'' and ``b!a'' mean completely different things); that ``a!b'' means something like ``tell system a to send to b''; and that ``a%b'' means something like ``tell system b to send to a''. What we don't all agree on is the meaning of hybrid addresses containing both ! and % operators. > Can we use clear unambiguous terminology? That would be nice. But first we have to find a suitable terminology. --apb Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa RFC822: barrett@ee.und.ac.za Bang: m2xenix!quagga!undeed!barrett
Re: Smail3, RFC1123, and the ! and % operators
Author: peter@ficc.ferra
Date: Thu, 05 Sep 1991 14:21
Date: Thu, 05 Sep 1991 14:21
15 lines
543 bytes
543 bytes
In article <bb92tg.7au@wang.com> fitz@wang.com (Tom Fitzgerald) convinced me that I was wrong... > We've got a company internet here that's not connected to the real > Internet, and we'd like to get mail through. There are hundreds of other > organizations in the same position. I think you're right. RFC1123 conflicts with RFC976, and so should be changed. Smail's current behaviour is correct. -- Peter da Silva Ferranti International Controls Corporation Sugar Land, TX 77487-5012; +1 713 274 5180 "Have you hugged your wolf today?"
Re: Smail3, RFC1123, and the ! and % operators
Author: woods@eci386.uuc
Date: Thu, 05 Sep 1991 16:39
Date: Thu, 05 Sep 1991 16:39
24 lines
1175 bytes
1175 bytes
In article <28C54AE9.6102@tct.com> chip@tct.com (Chip Salzenberg) writes: > According to rickert@mp.cs.niu.edu (Neil Rickert): > >In article <1991Sep01.072418.15414@Veritas.COM> tron@Veritas.COM (Ronald S. Karr) writes: > >>If one site considers % to be a high-precedence operator, in the sense of > >>the existing Smail3, then it can turn a%b@c into x!y!z!c!a%b. > > > >It is better to turn that into x!y!z!c!b!a. > > I would avoid any interpretation of "%", unless there are no other > routing operators to be found in the address. In other words: Put no > interpretation on the "local-part" unless the address is local. That's exactly what lmail-2.7 does. FYI, there's a new lmail-3.0 in beta now, soon to appear in c.s.m. It fixes a number of silly bugs, has a new locking mechanism based on the SysVr4 maillock() routine which is backward compatible with AT&T mailers, and does more error checking than you can imagine! -- Greg A. Woods woods@{eci386,gate,robohack}.UUCP VE3TCP Elegant Comm. & UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario; CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
Proposed resolution for Smail and RFC1123
Author: tron@Veritas.COM
Date: Sat, 07 Sep 1991 04:16
Date: Sat, 07 Sep 1991 04:16
34 lines
1660 bytes
1660 bytes
After corresponding with a few people on the subject and reading the various messages that have been posted (thanks everybody), I have decided that a hybrid approach is most appropriate. The basic problem with the % operator, UUCP, and RFC1123 is that RFC976 turns ! into a routing operator in the message envelope. In such envelopes, the @ operator disappears. As such, the address a%b@Y may become path!Y!a%b. This, correctly, allows Y to handle the a%b address as local, for possible interpretation under the rules of RFC1123. Since an address of the form path!Y!a%b is not an internet-conforming address, anyway, it does not need to be interpreted outside of the scope of RFC976, so RFC1123 need not apply. If host Y is given an address a!b%c@Y, then Y has been given an internet-conforming address, it should use the internet rules (including RFC1123) for handling its local address. Thus, the % operator is used to break it up into a host c and a user a!b. If c is also host Y, it is then free to use the rules of RFC976 to break it up into host a and user b. In other words, my proposed new rule for smail: if an address was originally in the form X@Y, where the local part X contains arbitrary ! and % operators, then obey the rules of RFC1123 when interpreting X. Otherwise, use the existing Smail3 rules and consider % to have a higher precedence than !. This should allow for correct operation on both the Internet and in the UUCP zone, with consistent interpretation of conforming internet addresses in both zones. -- tron |-<=>-| ARPAnet: veritas!tron@apple.com tron@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron
Re: Proposed resolution for Smail and RFC1123
Author: urlichs@smurf.su
Date: Sat, 07 Sep 1991 14:27
Date: Sat, 07 Sep 1991 14:27
35 lines
1730 bytes
1730 bytes
In comp.mail.misc, article <1991Sep07.041609.16213@Veritas.COM>, tron@Veritas.COM (Ronald S. Karr) writes: < < If host Y is given an address a!b%c@Y, then Y has been given an < internet-conforming address, it should use the internet rules < (including RFC1123) for handling its local address. Thus, the % < operator is used to break it up into a host c and a user a!b. If c is < also host Y, it is then free to use the rules of RFC976 to break it up < into host a and user b. < There's only one problem -- suppose somebody mails to address a%b@c. (Whether that % is a routing character or something else is irrelevant.) C decides that this should be sent through UUCP, and generates g!f!e!d!a%b. G decides to send that to E via (B)SMTP, and generates a RFC822 address of either e!d!a%b@f or d!a%b@e. BANG. Unfortunately, G doesn't have any other choice, except possibly to convert the whole bang address to an RFC822 source route (not good), or a %-hack source route (not good), or to ignore RFC822 and send a @-less address (not good). Hmmm... Let's look at the problem pragmatically -- how do mixed !-% addresses get created in the first place? I'm only aware of %-@ addresses getting converted into !-% (UUCP routing) and possibly into @-!-% (as in the above example). I can _not_ think of a reasonable example for a mailer to insert %-routes into addresses while ignoring !-routes in front; if you want to do source routing, RFC822 already has an equally ugly mechanism for this, and any user who uses such addresses will have big problems anyway. ;-) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/
Re: Smail3, RFC1123, and the ! and % operators
Author: kre@cs.mu.oz.au
Date: Sun, 08 Sep 1991 02:31
Date: Sun, 08 Sep 1991 02:31
101 lines
4732 bytes
4732 bytes
This entire discussion is right off the wall - its a completely pointless exercise. Both ! and % occur only in the "local part" of an address (assuming we're talking about rfc822 type addresses) and so have no defined meaning at all. Its possible that some sites (perhaps many sites) may decide to define one or both as a routing character to be used when there's no @ in the address, but that's not certain in any particular case - even less is it certain that any particular site will treat both of them as routing characters. Its only when that particular co-incidence happens that this particular ambiguity raises its ugly head. Since you can't possibly tell what some remote site may be choosing to treat as characters with routing related semantic meanings in local parts, and even less can you require it, its completely meaningless to attempt to provide any kind of standard meaning to this construct. Sites will do whatever they want - usually whatever the author of the mailer (or sendmail.cf file) chose for them, and they're perfectly entitled to do just that. So, users can't rely on this kind of thing, and given that, it simply doesn't matter what sites do - though its helpful if having once chosen a behaviour they stick with it, so the users will at least have consistency, if not predictability. However, the way I read this... >In RFC1123 paragraph 5.2.16 states: > It is suggested that "%" have lower precedence > than any other routing operator (e.g., "!") hidden in the > local-part; for example, "a!b%c" would be interpreted as > "(a!b)%c". is in line with standard mathematical notation, the words "lower precedence" mean the same here as they would were the operaters "+" and "*" and the operands numbers, and the example with the parentheses is the natural result of that. Just as with numbers, to me that example means "evaluate a!b, take the result of that and use it in result%c". Now, to "evaluate a!b" in a mailer (which happens to be treating ! as a routing character) I "send the mail to host a, and give it "b" to act on. So, now I have sent the mail to a, and have (b)%c, in which the parentheses are clearly redundant, so I have b%c at a. To evaluate b%c, assuming I am using % as a routing chacter, I send the mail to host c, and give it b to act on. So according to my reading of rfc1123 I am obviously advised (should I happen to wish to treat both ! and % as routing characters) to send the mail along the path "a" to "c" then to "b". Furthermore, I contend that quite apart from the way that others seem to have been interpreting this paragraph, this is the only possible interpretation you can reasonably give it. That is, other people look at the example, see the parentheses, immediately interpret them in a more tradional "mailer" sense, as "hide what's in here till later" and come to the opposite conclusion, and then have to somehow make sense of that. However, look at it again more closely... > It is suggested that "%" have lower precedence > than any other routing operator Read that aloud several times, then think about it a bit. "lower precedence than any other routing operator"... Clearly "@" is a routing operator, and "%" must be intended to have lower precedence than "@", so now we have a reference point for deciding just what "lower preference" is really intended to mean. Its unquestionable that in an address with both @ and %, the "@" is "acted upon" first, in the sense that the mail is sent to the host associated with the "@" first, and then to the host associated with the "%". Now, since "%" is suggested to have lower precedence than "!" as well, the same must happen, or "precedence" would have no meaning at all, ie: if both "!" and "%" occur (and there is no "@" in the address), send the mail to the host associated with the "!" first, and then to the host associated with the "%". No other interpretation makes any sense. Finally, to pacify the clowns ... I repeat again, all of this is site dependant, sites can do whatever they like, this paragraph of rfc1123 is nothing more than a suggestion, nor could it be more. Also, 1123 is "requirements for internet hosts" and has nothing whatever to do with hosts which aren't on the internet - so if you're a uucp only host or something, this need not have anything to do with you at all, unless you want it to. The bozo who suggested that this doesn't apply to internet hosts because internet addresses are required to contain @ characters should go back and ponder what an internet host is supposed to do with an address that ends "@my.domain" - its in this circumstance that the question arises. kre
Re: Proposed resolution for Smail and RFC1123
Author: tron@Veritas.COM
Date: Sun, 08 Sep 1991 03:12
Date: Sun, 08 Sep 1991 03:12
38 lines
1829 bytes
1829 bytes
In article <xq7b=7#@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >There's only one problem -- suppose somebody mails to address a%b@c. >(Whether that % is a routing character or something else is irrelevant.) >C decides that this should be sent through UUCP, and generates g!f!e!d!a%b. >G decides to send that to E via (B)SMTP, and generates a RFC822 address >of either e!d!a%b@f or d!a%b@e. BANG. That's it, just throw a monkey wrench into my perfect solution to solve all of the world's mail problems. Hmmm... I think that this runs into a crucial problem with respect to the UUCP zone and SMTP: UUCP requires source routing, and SMTP (combined with RFC1123) doesn't really provide source routing. >Unfortunately, G doesn't have any other choice, except possibly to convert >the whole bang address to an RFC822 source route (not good), or a %-hack >source route (not good), or to ignore RFC822 and send a @-less address >(not good). Hmmm... Actually, @-less addresses may be a solution. I will (perhaps incorrectly) contend that this problem should only arrise when SMTP is used for transfering mail within the UUCP zone. As such, the rules of RFC976 apply, rather than the rules of RFC822. If the transfer is Smail3-to-Smail3, there won't be a problem. Smail3 will accept addresses in SMTP messages that don't have a @. Does anyone envision any situations where this will present a problem? There would have to be a mailer transport flag indicating RFC976 or RFC822 behavior. Also, this change to the SMTP protocol would only be required when encountering !-% addresses. If a !-only or %-only address were encountered, conversion to !-@ or %-@ should still be performed. -- tron |-<=>-| ARPAnet: veritas!tron@apple.com tron@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron
Re: Smail3, RFC1123, and the ! and % operators
Author: fitz@wang.com (T
Date: Mon, 09 Sep 1991 23:09
Date: Mon, 09 Sep 1991 23:09
28 lines
1244 bytes
1244 bytes
kre@cs.mu.oz.au (Robert Elz) writes: > Both ! and % occur only in the "local part" > of an address (assuming we're talking about rfc822 type addresses) > and so have no defined meaning at all. ... until the mail reaches the machine on the right hand side of the @, at which time it had better have a defined meaning. ! and % matter a lot at that point. > Its possible that some > sites (perhaps many sites) may decide to define one or both as > a routing character to be used when there's no @ in the address, > but that's not certain in any particular case - even less is it > certain that any particular site will treat both of them as routing > characters. Its only when that particular co-incidence happens that The vast majority of sendmail sites, which is to say the vast majority of UNIX Internet sites, treat both ! and % as routing characters. Certainly every sendmail.cf I've read does this. The only sites I've found that don't route using % are running smail 2.5 or a dumb UUCP mailer. The only ones I've found that don't route using ! are VMS sites. This "particular coincidence" seems to be extremely widespread. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
Re: Proposed resolution for Smail and RFC1123
Author: mills@ccu.umanit
Date: Tue, 10 Sep 1991 03:21
Date: Tue, 10 Sep 1991 03:21
15 lines
742 bytes
742 bytes
In <xq7b=7#@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >There's only one problem -- suppose somebody mails to address a%b@c. >(Whether that % is a routing character or something else is irrelevant.) >C decides that this should be sent through UUCP, and generates g!f!e!d!a%b. >G decides to send that to E via (B)SMTP, and generates a RFC822 address >of either e!d!a%b@f or d!a%b@e. BANG. But, if somebody mails to a%b@c, when it arrives at C, C must interpret the local part. C is the responsible host. It can't just prefix a bang path and forward it somewhere else. C must make it into a valid address for whatever transport it uses. -- -Gary Mills- -Networking Group- -U of M Computer Services-
Re: Smail3, RFC1123, and the ! and % operators
Author: moore@wilma.cs.u
Date: Fri, 27 Sep 1991 04:00
Date: Fri, 27 Sep 1991 04:00
105 lines
4926 bytes
4926 bytes
In article <1991Sep01.072418.15414@Veritas.COM>, tron@Veritas.COM (Ronald S. Karr) writes: |> In RFC1123 paragraph 5.2.16 states: |> |> An embedded source route is sometimes encoded in the |> "local-part" using "%" as a right-binding routing |> operator. For example, in: |> |> user%domain%relay3%relay2@relay1 |> |> the "%" convention implies that the mail is to be routed |> from "relay1" through "relay2", "relay3", and finally to |> "user" at "domain". This is commonly known as the "%- |> hack". It is suggested that "%" have lower precedence |> than any other routing operator (e.g., "!") hidden in the |> local-part; for example, "a!b%c" would be interpreted as |> "(a!b)%c". |> |> I consider this interpretation to be incorrect and prefer a!(b%c), |> which is how Smail3 operates right now. |> |> I would really like to know what opionions people have on this topic. |> If all mailers conform to RFC1123, then people who know the RFC1123 |> will have some idea of what to expect from a remote site. From that |> standpoint, Smail3 should probably be changed. However, I consider it |> incorrect from the standpoint of correct operation in the world of |> UUCP. Perhaps from the standpoint of Internet operation it makes |> somewhat more sense. |> |> What do people think? Somebody has sent me a set of "fixes" to smail |> which, among other things, defines a flag for whether to use the old |> behavior or the RFC1123 behavior. This doesn't seem like the kind of |> decision that a site should make on its own. If one site considers % |> to be a high-precedence operator, in the sense of the existing Smail3, |> then it can turn a%b@c into x!y!z!c!a%b. If site y considers % to be a |> low-precedence operator, then it will deliver z!c!a to site b, which is |> not what the original site wanted. First of all, the correct interpretation of an address is dependent on where the address comes from. Any discussion of "how do you treat address 'x'" is meaningless without stating the source of address 'x'. Now, assuming that the address node!user%domain%relay3%relay2@some.domain arrives via Internet mail (SMTP over TCP) at the primary mail exchanger for "some.domain", the "correct" interpretation of the local-part of the address is however that mailer wants to treat it. Ideally, there should be no assumption on the part of the mailer software that enforces how local-parts are interpreted. A reasonable default in this case (assuming that '%' cannot appear in a local mailbox name) is to strip the '@some.domain', change the last '%' to an '@', and interpret the resulting string as an Internet mail address. The other "obvious" interpretation would treat the address as a UUCP address with the first hop named "node". I feel that this interpretation is less desirable than the first one, because it is mixing the (admittedly unofficial) addressing conventions of the Internet with those of UUCP. If the same address had appeared on the envelope of a message which arrived via "uux rmail", I would choose the latter interpretation. Of course, e-mail users are well advised to avoid ambiguous addresses. Domain-style addresses are then interpreted right-to-left (using the '%' hack when necessary), and UUCP and DECnet addresses are interpreted left-to-right, each for as many hops as possible. |> Comments and opinions would be appreciated. My current intention is to |> either leave smail alone or make the new behavior mandatory. Having a |> flag seems the worst of both worlds. Any 'flag' governing how to interpret addresses needs to be specific to the addressing conventions of the incoming transport. A system-wide choice which is right for the Internet would be wrong for UUCP or DECnet. If the primary address interpretation strategy failed, others could be tried. So e.g. for Internet: (assuming the local mailer is a primary MX for "some.domain", strip the '@some.domain' off, and:) a) try the percent hack (attempt to relay msg to "relay2" via SMTP/TCP) b) if that fails (i.e. no host or MX for "relay2"), treat it as a uucp address c) if that fails (i.e. "node" isn't a known uucp host), bounce the message And for UUCP: a) try sending to "node" using uucp b) if that fails ("node" isn't a known uucp host), try relaying it to 'some.domain' c) otherwise bounce the message Finally, addresses should only be rearranged when crossing a boundary between one network and another. If a message comes in via UUCP and leaves via UUCP, it should look exactly as if a bare-bones UUCP system would have handled it. (so mail to a!b!c@d would be relayed to b!c@d in care of a) -- Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN 37996-1301 Internet: moore@cs.utk.edu BITNET: moore@utkvx
Re: Smail3, RFC1123, and the ! and % operators
Author: davecb@nexus.yor
Date: Sat, 28 Sep 1991 20:47
Date: Sat, 28 Sep 1991 20:47
107 lines
4893 bytes
4893 bytes
Once upon a time, ron@Veritas.COM (Ronald S. Karr) wrote: | [rfc1123 says] "a!b%c" would be interpreted as "(a!b)%c". | I consider this interpretation to be incorrect and prefer a!(b%c), | which is how Smail3 operates right now. moore@wilma.cs.utk.edu (Keith Moore) writes: |First of all, the correct interpretation of an address is dependent on |where the address comes from. Any discussion of "how do you treat address |'x'" is meaningless without stating the source of address 'x'. [and an analysis which resolves the interpretation problem by applying a channel-specific disambiguation rule] Well, I'm going to agree with you in general, but disagree with you in a particular but important case. I agree that between addressing zones, an address which contains routing information in what the zone considers to be the local-part should only be routed in terms of the **rest** of the address. In our example, a!b%c in a zone which assumes rfc822 really means send to ``c, local-part is a!b''. On first glance, this might mean that in the uucp zone, a!b%c is ``send to a, local-part is b%c''. However, I claim that it is bad public policy to make this distinction. I argue (a) technological simplicity, (b) universality and (c) the desirability of interworking with the broader internet support the opposite conclusion. a) Technological simplicity: Some mailers used in a uucp environment are perfectly capable of dealing with mail in rfc822 format and resolving the address into ``pure'' or ``old'' uucp notation without losing information. For example, on lethe the address ``davecb@yorku.ca'' resolves to yorku.ca!davecb, a legal command component to pass to the uux program (yunexus!davecb is the older form of the same thing). Others are incapable of this transformation, but can deal with non-local machine names in peculiar formats by the simple process of not trying to interpret them. telly!yorku.ca!davecb at last appears processable by everyone who talks to telly, since they only need the information to the left of the first ``!'' to send to. Given this ability to deal with 822-style addresses, by transformation and by information-hiding, I argue that it is easy to honor the rfc1123 clarification at the transformational level. That this question was raised at all also argues that selecting a ``correct'' interpretation is not technologically difficult (:-)) b) Universality I claim that context-dependent addressing is a **bad thing**. As a postmaster, I am prepared to use heuristics to deal with some of the mail that lands in the dead-letter office. After the fact I can often manually forward mail whose address is context-dependent by mentally simulating the context and guessing at where the mail was supposed to go. However, since my customers insist on assuming mail is a reliable bidirectional communications channel, I'd be facing a significant risk (of dismissal!) if this heuristic had to become part of day-to-day operations. (c) the desirability of interworking I claim that the mechanisms used in the internet (domain-based absolute addresses) and in x.400/x.500 (attribute-based absolute addresses) are more suitable than routes, as used in raw uucp. I sincerely wish to encourage better cooperation between the community which happens to use uucp transport and that which uses IP transport: I don't see an advantage to religious wars if one of the sides already has picked up much of the notation and techniques of the other. Therefor I argue against anything that would pull the uucp-using community farther away from the internet community, and claim that context-dependent interpretation of mail addresses is such a danger. I see no reason why humans who happen to use uucp shouldn't be able to send mail using ``person@place.domain'' notation, even if the lower-level transport requires that be turned into routes, numeric addresses or the names of postmen's horses. I therefor argue against addresses of the form a!b%c at all, and argue for a single, universal interpretation if they do occur. As a side point to the above, I have made representations to a national user group that they lend their good offices to the registration of all my province's uucp-using sites in the internet domain name system, with suitable forwarders for each of these sites in .on.ca... --dave (money follows mouth) c-b I only wish one form of address, one including the attributes <personal-name|userid>, <organizational subunit|machine>, <organization> and <upper-level organizing construct>. That implies that I'm partial to either of two notations: internet and x400. And I'd far prefer only one notation, too! c) -- David Collier-Brown, | davecb@Nexus.YorkU.CA | lethe!dave 72 Abitibi Ave., | Willowdale, Ontario, | Today's featured dish: CANADA. 416-223-8968 | Sun-dried alligator.
Re: Smail3, RFC1123, and the ! and % operators
Author: tron@Veritas.COM
Date: Sun, 29 Sep 1991 22:44
Date: Sun, 29 Sep 1991 22:44
48 lines
2421 bytes
2421 bytes
In article <davecb.686090823@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes: > I agree that between addressing zones, an address which contains >routing information in what the zone considers to be the local-part >should only be routed in terms of the **rest** of the address. In our >example, a!b%c in a zone which assumes rfc822 really means send to ``c, >local-part is a!b''. > On first glance, this might mean that in the uucp zone, a!b%c is ``send >to a, local-part is b%c''. > > However, I claim that it is bad public policy to make this >distinction. I argue (a) technological simplicity, (b) universality >and (c) the desirability of interworking with the broader internet >support the opposite conclusion. I agree that this is bad policy. However, RFC976, RFC822, and RFC1123 fundamentally disagree on the matter. As such the argument of universality breaks down, along with the desirability of internetworking. Essentially, internetworking and address universality requires that the address operators be context sensitive. The technological simplicity argument is meaningless if it doesn't accomplish the goal of making mail networks work correctly. Simply stated, if someone says that their address is user%host@local.gateway and neither gateway nor host recognize the ! operator, then a UUCP zone host has no choice but to use the address: neighbor!path!internet.gateway!local.gateway!user%host This is how UUCP zone hosts send mail to machines on the Internet, as described very explicitly in RFC976. RFC976 does not discuss the % operator, but through implication with RFC822 it must be considered part of the local-part for the host "gateway". As I see it, conformance to RFC976, RFC822, and RFC1123, along with correct operation on both the Internet and the UUCP zone, requires context-sensitive parsing of addresses is the only alternative. However, the context can be limited purely to noting the existence of an @ operator in an address. The address a!b%c@d is handled according to the rules of RFC1123, the address a!b%c is handled according to the rules of RFC976. This is not an argument for how net software and standards should work. It is an argument for how mail software must work for existing mail addresses to work on existing networks. -- tron |-<=>-| ARPAnet: veritas!tron@apple.com tron@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads