UUCP and preservingply-to: how?
Rodney Thayer
rodney at sabletech.com
Thu Apr 4 11:33:00 EST 1996
I think the fat Sendmail book from O'Reilly has prose that discusses this.
Unfortunately I also think you need to read the sendmail sources....
At 10:36 AM 4/4/96 EST, you wrote:
>| Dale R. Worley wrote in a message to Mike Bilow:
>|
>| Note also that is illegal to use both a '!' and a '@' in a mail address, such
>| as aaaa!bbbb at cccc. The UUCP side will parse this as "send to aaaa, which
will
>| send it to bbbb at cccc." The SMTP side will parse this as "send to cccc, which
>| will send it to aaaa!bbbb."
>
>Can you quote chapter and verse in some relevant standard for this?
>I've often made similar suggestions when I've seen email addresses
>with both '!' and '@', and been rebuffed by the claim that "everyone
>knows" that one or the other meanings is the correct one. Of course,
>different groups of "everyone" seem to know different interpretations,
>and they can't quote any standard, either. I've looked around for the
>appropriate standards to point people to, to no avail so far.
>
>In my readings, I've gotten the impression that standards documents
>casually ignore such questions. After all, why should an Internet
>standard say anything at all about the interpretation '!'? To them,
>it's a non-syntax character, and they'll usually respond by making it
>clear what they think of people who use competing packages like UUCP.
>Similarly, any UUCP standard (if such even exists ;-) is unlikely to
>deal explicitly with '@', since it's not a significant character.
>
>You can make a reasonable argument that, once you admit that UUCP
>exists, there is a semi-definition that says "foo!joe at bar" should be
>parsed as "foo!(joe at bar)". The argument goes as follows: The UUCP
>definition is that an email address is of the form node!recipient,
>where node is the name of a machine reachable via any transport
>mechanism, and recipient is either 1) a user id known on that machine,
>or 2) an email address that makes sense to the mailer on that machine.
>In case 1), the mail is delivered to the user; in case 2), the mail is
>delivered to the /bin/rmail command for forwarding. Thus, if you are
>using UUCP, *any* string is valid after the '!', as long as the mailer
>on the node can decipher it. Thus, "foo!(joe at bar)" is a legal
>interpretation of "foo!joe at bar", if you have a UUCP-style mailer on
>your own machine. Whether it will work depends on whether foo has an
>rmail command that can parse "joe at bar".
>
>How about the "(foo!joe)@bar" interpretation? Well, RFC821 says that
>the only thing legal before an '@' is a user's login id, and "foo!joe"
>isn't a valid login id on any known OS. Later RFCs have extended what
>is allowed after the '@', to include FQDNs, but they haven't added any
>sort of forwarding syntax for the recipient field. The '%' kludge is
>just that. It isn't supported by any Internet standard; it's just a
>convenience until we reach the ideal state in which any Internet host
>can make a TCP connection directly to port 25 on any other host. The
>dogma on the Internet is that forwarding isn't necessary, since all
>hosts can connect directly to all others. If this doesn't work, you
>shouldn't kludge the email system, you should fix your network. Thus
>"(foo!joe)@bar" is not a valid SMTP address, and there don't seem to
>be any other email standards that use '@', so this isn't a legal
>parsing according to any standard.
>
>In summary, "foo!(joe at bar)" is a legal parsing of "foo!joe at bar" using
>the rules of one known email package (UUCP), while "(foo!joe)@bar" is
>not legal using any mailer's rules. Whether this is relevant to you
>depends on which email package you have installed.
>
>We are, of course, getting further away from the ideal of universal
>interconnection. Once the concept of "firewall" appeared, the game was
>pretty much over; we can safely predict that the SMTP dogma tht no
>forwarding is needed will never come true. Still, if you make
>suggestions in the appropriate newsgroups about how to do SMTP
>forwarding, the inevitable result is that you get lots of flames
>telling you what an idiot you are for thinking that such kludgery is
>necessary. Just fix your network, turkey, and it'll all work without
>any forwarding. And anyway, you shouldn't need to use something like
>"(foo!joe)@bar", because only an idiot would use UUCP, right? (Only an
>idiot that likes reliable, configurable email, right?) Well, I've
>gotten lots of such flames over the years. (They somehow never explain
>how I am to get superuser access to all the other machines on the net
>so as to implement their suggestions. ;-)
>
>So I'd conclude that "(foo!joe)@bar" isn't a legal interpretation,
>because it implies that SMTP mailers can do forwarding. Granted, all
>competent mailers *can* do forwarding, but that's just an temporary
>and unnecessary kludge, according to the established SMTP dogma. On
>the other hand, "foo!(joe at bar)" is legal if you have a UUCP mailer,
>because it implies that UUCP mailers can forward to SMTP mailers. They
>can, and it's an officially sanctioned operation in the UUCP arena. If
>you run smail, such inter-mailer forwarding is clearly and openly
>supported. If you don't, well, you are at the mercy of whatever your
>mailer's authors thought about the whole religious issue.
>
>Now if the programmers that develop email software could be taught the
>uses of parens, as I've done above. I mean, mathematicians figured
>this out several centuries ago, and most people who build programming
>languages have picked up on the idea. But just try finding an email
>package that allows the use of parens to disambiguate expressions. Oh,
>well; I guess I shouldn't gripe too much. After all, we are still
>being saddled with software written by people that haven't learned
>about the number zero, and haven't heard of null strings.
>
>
>
Rodney Thayer :: rodney at sabletech.com
Sable Technology Corp :: +1 617 332 7292
246 Walnut St :: Fax: +1 617 332 7970
Newton MA 02160 USA :: http://www.shore.net/~sable
"Developers of communications software"
More information about the Discuss
mailing list