Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

UUCP and preservingply-to: how?



| 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.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org