Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!harvard!adelie!cdx39!jc From: jc@cdx39.UUCP (John Chambers) Newsgroups: comp.mail.headers Subject: Re: I hate smail Message-ID: <540@cdx39.UUCP> Date: Fri, 9-Jan-87 10:21:22 EST Article-I.D.: cdx39.540 Posted: Fri Jan 9 10:21:22 1987 Date-Received: Sat, 10-Jan-87 22:43:10 EST References: <14227@amdcad.UUCP> <32@auspyr.UUCP> <14237@amdcad.UUCP> <1987Jan8.120027.23351@utcs.uucp> Organization: Codex Corp, a division of Motorola; Canton, MA, USA Lines: 54 Summary: Parens, anyone? > > What I liked to do a lot of was to take an address like > > fred@site.dec.com and ship it off to decwrl to handle with > > decwrl!fred@site.dec.com. Now smail says "ah, @ takes precendence". > > How am I supposed to dump addresses on a smarter site like decwrl now? > > Try fred%site.dec.com@decwrl > Which brings up an opportunity to remake an old observation: Many of the problems with email paths are due to the existence of a lot of "operators" like '!', '@', '%', '.', and so on, without agreement among the mailers about their precedence. Imagine the fun if the people who write compilers each had their own ideas about the "right" operator precedence. No, you don't have to imagine it; just use some complicated expressions in C that involve the non-traditional operators (i.e., anything other than "+-*/"). Experienced C programmers often throw up their hands at the task of memorizing the precedence table, and just use lots and lots of "unnecessary" parentheses. It has been centuries since mathematicians worked figured out that parentheses are valuable; they even conventionally use several types of "brackets" for readability: (a*[b/sqrt(c)-{x/y}]*17). Scanning for parens is easy to code. Occasionally I've seen the hint that mailers should do this, and (if you have the source code), it could be profitably added to all existing mailers. Instead of using paths like those above, we should start putting pressure on anyone responsible (i.e., anyone with source code :-) to add code that in effect says "This mailer only understands the parts of a mail path that is outside all bracketing characters, after first stripping off all outside brackets, of course". Anything within barckets would be passed to the next mailer for it to ponder. If we could pressure the folks with source to all the mailers, we could then use paths like: decwrl!(fred@site.dec.com) {decwrl!fred@}site.dec.com [fred%site.dec.com]@decwrl fred%(site.dec.com@decwrl) and the results would be unambiguous. This would allow us to force mail through a known working path, even when the "intelligent" mailers were (typically through no fault of their own; the map data isn't good) not able to do it correctly. Hey, you guys with the source code, what do you think of this? It's worked for mathematicians for ages; it can work for us, too. How fast can you add it to your mailer? -- 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: If we can't fix it, it ain't broke.