matt@ncr-sd.UUCP (01/28/87)
What is the status of using
@host1:@host2:user@host3 # 1
versus the 'correct' but ugly
@host1,@host2:user@host3 # 2
Do InterNet routers correctly handle the colon form of the address?
I've noticed that sendmail sites tend to use form #1, and MMDF sites
(on CSNET) tend to use form #2. What I'd really like to know is if
form #1 is enough of an unofficial standard (like the magic '%' rule)
to make it universally acceptable?
--
Matt Costello, matt.costello@SanDiego.NCR.COM (registered w/ CSNET)
{sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!mattdpk@brl-sem.UUCP (02/03/87)
In article <1322@ncr-sd.UUCP> matt@ncr-sd.UUCP (Matt Costello) writes: >What is the status of using > @host1:@host2:user@host3 # 1 >versus the 'correct' but ugly > @host1,@host2:user@host3 # 2 > Only the second form (#2) is correct and only if the address above is preceded by a phrase and enclosed in angle brackets. See RFC-822 for details and read the grammer. It's quite explicit. In an SMTP transaction the phrase and angles can be dropped as the address is enclosed in angles already. To quote the standard (page 27 of RFC-822): Standard for ARPA Internet Text Messages 6. ADDRESS SPECIFICATION 6.1. SYNTAX address = mailbox ; one addressee / group ; named list group = phrase ":" [#mailbox] ";" mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec route-addr = "<" [route] addr-spec ">" route = 1#("@" domain) ":" ; path-relative =====================^ Indicates a comma separated list (see section 2.7) addr-spec = local-part "@" domain ; global address local-part = word *("." word) ; uninterpreted ; case-preserved domain = sub-domain *("." sub-domain) sub-domain = domain-ref / domain-literal domain-ref = atom ; symbolic reference >Do InterNet routers correctly handle the colon form of the address? No. >I've noticed that sendmail sites tend to use form #1, and MMDF sites >(on CSNET) tend to use form #2. What I'd really like to know is if >form #1 is enough of an unofficial standard (like the magic '%' rule) >to make it universally acceptable? No. Don't use it. If SENDMAIL is then its wrong and should be fixed. >Matt Costello, matt.costello@SanDiego.NCR.COM (registered w/ CSNET) > {sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!matt I am certainly not going to defend it as being the most elegant standard that could have been chosen, but its the one we have and it must be conformed with as it exists. -Doug- Ballistics Research Laboratory, <dpk@brl.arpa>
jc@cdx39.UUCP (02/04/87)
In article <608@brl-sem.ARPA>, dpk@brl-sem.ARPA (Doug Kingston <dpk>) writes: > In article <1322@ncr-sd.UUCP> matt@ncr-sd.UUCP (Matt Costello) writes: > >What is the status of using > > @host1:@host2:user@host3 # 1 > >versus the 'correct' but ugly > > @host1,@host2:user@host3 # 2 > > Only the second form (#2) is correct and only if the address above > is preceded by a phrase and enclosed in angle brackets. See RFC-822 for > details and read the grammer. It's quite explicit. In an SMTP transaction > the phrase and angles can be dropped as the address is enclosed in angles > already. To quote the standard (page 27 of RFC-822): > Standard for ARPA Internet Text Messages > 6. ADDRESS SPECIFICATION > 6.1. SYNTAX > address = mailbox ; one addressee > / group ; named list > group = phrase ":" [#mailbox] ";" > mailbox = addr-spec ; simple address > / phrase route-addr ; name & addr-spec > route-addr = "<" [route] addr-spec ">" > route = 1#("@" domain) ":" ; path-relative > =====================^ Indicates a comma separated list (see section 2.7) > addr-spec = local-part "@" domain ; global address > local-part = word *("." word) ; uninterpreted > ; case-preserved > domain = sub-domain *("." sub-domain) > sub-domain = domain-ref / domain-literal > domain-ref = atom ; symbolic reference Say what? According to my eyeballs, and to this editor (vi), there are no commas at all within these lines. Note that the original message wasn't asking for the syntax of things like routes or domains; he was asking for the part that described commas. You seem to have quoted all the relevant stuff except the answer to his question. BTW, what does the comma notation *mean*? Is it a list of hosts to send the mail to, i.e., a route? Is is a list of alternatives? Is it a list of other places the mail can be delivered to if host3 isn't available? To use it correctly, you have to know more than the syntax; you have to understand the semantics. So far, I have seen a lot of people toss the syntax around, without any hint as to what it means. How about someone posting that portion of the RFC? > I am certainly not going to defend it as being the most elegant standard > that could have been chosen, but its the one we have and it must be > conformed with as it exists. One quibble: "must" should be replaced with "should". It's clear from the plethora of mailers out there that there is nothing that they *must* do (except reject or drop my mail:-). In fact, I have yet to see the above syntax in even a single piece of mail that I've ever received. Has anyone out there implemented it? If so, please send me some mail, so I won't be able to make the above claim anymore (;-). [To satisfy the requirement that my text lines outnumber the quoted lines.] -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: Uucp me out of here, Scotty; there's no AI on this node!
cfe#@andrew.cmu.edu (Craig F. Everhart) (02/05/87)
ReSent-From: postman#@andrew.cmu.edu ReSent-To: nntp-xmit#@andrew.cmu.edu Return-path: <cfe#@andrew.cmu.edu> X-Trace: MS Version 3.21 on ibm032 host apollo, by cfe (469). To: outnews#ext.nn.comp.mail.headers@andrew.cmu.edu In-Reply-To: <1322@ncr-sd.UUCP> Neither @host1:@host2:user@host3 nor @host1,@host2:user@host3 is correct. The correct form is <@host1,@host2:user@host3> If the first form is surrounded by angle-brackets, it corresponds to an early draft of RFC822, so there's some chance that more sites will recognize it than by chance. But then again, we can ask why you're looking for ways to bend standards? Why not generate the correct form?
jsdy@hadron.UUCP (02/06/87)
In article <1322@ncr-sd.UUCP> matt@ncr-sd.UUCP (Matt Costello) writes: > @host1:@host2:user@host3 # 1 > @host1,@host2:user@host3 # 2 >I've noticed that sendmail sites tend to use form #1, ... Clarification: a route may only be used inside <>'s, but is not needed. The "phrase" bit is to allow: Joseph S. D. Yao <jsdy@hadron.COM> type addresses. The "phrase" can be null: <@brl,@seismo:jsdy@hadron.COM> Sendmail (on 4.2BSD and Ultrix 1.0 and 1.1) is supposed to respect the quoting power of <>'s. Actually, tests show that it respects the separating power of commas more. Therefore, the above legal address gets turned into two illegal addresses: <@brl , @seismo:jsdy@hadron.COM> As with some other not-quite-legalisms, sendmail uses the @...:@...: form as input, and on output translates to @...,@...: (or should ... it did and does on machines for which I've tuned sendmail.cf). -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised)
jsdy@hadron.UUCP (Joseph S. D. Yao) (02/06/87)
In article <450@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: >Clarification: a route may only be used inside <>'s, but is not >needed. The "phrase" bit is to allow: > Joseph S. D. Yao <jsdy@hadron.COM> >type addresses. The "phrase" can be null: > <@brl,@seismo:jsdy@hadron.COM> Apologies: the "null" phrase must be in quotes: "", since a phrase must be either a quoted string or one or more words (of one or more chars each). The rest of the article is correct. I was misled by the fact that many sites actually use no phrase (a null phrase w/o quotes), and re-reading RFC822 straightened that out. I hope you didn't waste net time flaming the last letter for this. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised)
kyle@xanth.UUCP (02/06/87)
In article <608@brl-sem.ARPA>, dpk@brl-sem.ARPA (Doug Kingston <dpk>) writes: > In article <1322@ncr-sd.UUCP> matt@ncr-sd.UUCP (Matt Costello) writes: > >What is the status of using > > @host1:@host2:user@host3 # 1 > >versus the 'correct' but ugly > > @host1,@host2:user@host3 # 2 > > ... > >I've noticed that sendmail sites tend to use form #1, and MMDF sites > >(on CSNET) tend to use form #2. What I'd really like to know is if > >form #1 is enough of an unofficial standard (like the magic '%' rule) > >to make it universally acceptable? > No. Don't use it. If SENDMAIL is then its wrong and should be fixed. The bug is not in sendmail itself but rather in a widely used sendmail configuration file. There is a line in ruleset 3 which converts all commas to colons in an address to simplify route-addr parsing. # make sure <@a,@b,@c:user@d> syntax is easy to parse -- undone later R@$+,$+ @$1:$2 change all "," to ":" Unfortunately the line in ruleset 4 which is supposed to undo this looks like this: R@$+:$+:$+ $@@$1,$2:$3 <route-addr> canonical which changes the first colon to a comma and leaves the rest of them untouched. Change the line to R@$+:$+:$+ @$1,$2:$3 <route-addr> canonical and the correct route-addr syntax is restored. -- kyle jones, odu computer science ARPA: kyle@xanth.cs.odu.edu CSNET: kyle@odu.csnet UUCP: kyle@xanth.uucp
zben@umd5.UUCP (02/10/87)
In article <643@cdx39.UUCP> jc@cdx39.UUCP (John Chambers) writes: >> route = 1#("@" domain) ":" ; path-relative >> =====================^ Indicates a comma separated list (see section 2.7) > Say what? According to my eyeballs, and to this editor (vi), there are > no commas at all within these lines. Note that the original message wasn't > asking for the syntax of things like routes or domains; he was asking for > the part that described commas. You seem to have quoted all the relevant > stuff except the answer to his question. And you seem to have shot from the hip before READING the quoted poster. It even SAYS "comma separated list"... With POINTERS and STARS and such. Sheesh. The full reference is section 2.7 (page 4) of RFC822: 2.7 #RULE: LISTS > A construct "#" is defined, similar to "*", as follows: > <l>#<m>element > indicating at least <l> and at most <m> elements, each separated > by one or more commas (","). This makes the usual form of lists > very easy; a rule such as '(element *("," element))' can be shown > as "1#element". Wherever this construct is used, null elements > are allowed, but do not contribute to the count of elements > present. THat is, "(element),,(element)" is permitted, but > counts as only two elements. Therefore, where at least one ele- > ment is required, at least one nun-null element must be present. > Default values are 0 and infinity so that "#(element)" allows any > number, including zero; "1#element" requires at least one; and > "1#2element" allows one or two. It is interesting to consider the implications of the null element stuff. Seems like: Yours Truly <@wiscvm.wisc.edu,,,,,@umd2.umd.edu:zben@umd5> is legal (gack). Fascinating... > BTW, what does the comma notation *mean*? Is it a list of hosts to send > the mail to, i.e., a route? Is is a list of alternatives? Is it a list > of other places the mail can be delivered to if host3 isn't available? > To use it correctly, you have to know more than the syntax; you have to > understand the semantics. So far, I have seen a lot of people toss the > syntax around, without any hint as to what it means. How about someone > posting that portion of the RFC? I diligently searched all of 822 and could not find one example. However, those familiar with the companion RFC821 and further having decent pattern matching neuro-ware may realize that the out-of-band back-path maintained in accordance with section 3.6 on page 14 is exactly the same animal: > 3.6. RELAYING > The forward-path may be a source route of the form > "@ONE,@TWO:JOE@THREE", where ONE, TWO and THREE are hosts. This > form is used to emphasize the distinction between an address and a > route. The mailbox is an absolute address, and the route is > information about how to get there. The two concepts should not > be confused. I believe a little study of the rest of the section will make the semantics more than clear. > [To satisfy the requirement that my text lines outnumber the quoted lines.] Gee, guy, I take the time to trim quoted text down to minimal form. That is what the software is trying to enforce by counting your lines. -- umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92 umd2.BITNET "via HASP with RSCS"
mouse@mcgill-vision.UUCP (02/12/87)
In article <oU9vpky00VsLQCE5fm@andrew.cmu.edu>, cfe#@andrew.cmu.edu (Craig F. Everhart) writes: > Neither > @host1:@host2:user@host3 > nor > @host1,@host2:user@host3 > is correct. The correct form is > <@host1,@host2:user@host3> > > But then again, we can ask why you're looking for ways to bend > standards? Why not generate the correct form? Because too much existing software barfs on it. I've run into this problem here. I redid our sendmail configuration so that it generates RFC-style routes (I won't call them compliant because they contain internal pseudo-domains). However, when the route gets long enough to contain a comma, there are problems. Problem 1 is that, as you point out, there must be <>s around it. So we add <>s. But someone, somewhere, insists on adding another set, resulting in an address like <<@foo,@bar:user@baz>> which is rather distasteful, even though I have managed to make the software accept it (does such a mess Conform to the Standard?). This way we don't get things like From: @bar:user@baz, @foo out of sendmail. But wait, there's a worse problem: /usr/ucb/Mail takes the above <<@a,@b:c@d>> and strips off both angle brackets and then insists on treating the comma as a separator, resulting in (again!) two separate addresses. I'm about ready to go to percent signs, which at least work. I don't like to though, the Conforming addresses should work (and I shouldn't have those stupid double <<>>!!). Does anybody have any suggestions for a way out of this mess? der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu