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.