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?



| You have put far more time into writing your reply than I would have done.  In
| any case, my objection boils down to a disagreement with your assertion that
| "foo!joe at bar" is not a legal RFC822 mail address.  As far as the software is
| concerned, it is indistinguishable from a legal address in which "foo!joe" is a
| mail recipient at "bar".  There is no way to know whether this is, in fact,
| true without resorting to knowledge outside of the message at hand.

Um, perhaps, but consider:  When an SMTP client sends a RCPT  message,
it gets a reply back saying whether the recipient was ok or not.  This
does seem to be part of the protocol, and it gives the client a direct
way  of  determining whether, say, "foo!joe" is acceptable to whatever
system is on the other end of the  connection.   Of  course,  in  many
cases, the mailer just says that anything is ok, so the response isn't
very reliable.

| It implies that "foo!joe" is a mail recipient.

Only if the other end says "Recipient ok". Which is presumably part of
why it works in some cases and not in others.

| Have you actually read RFC822?

Read? Yes. Totally understood? No. For instance, there's the alternate
notation  with  an initial '@'.  I find the description totally opaque
and incomprehensible. I've read explanations elsewhere, but even after
reading  them,  when  I go back to RFC822, I find it incomprehensible.
I've seen evidence that others, including many  who  have  implemented
SMTP,  have  a  similar  reaction.   Maybe idiots like us shouldn't be
allowed to write (or configure) mailers?

| You may find that there are some very
| surprising things which are explicitly allowed, but which you never see in
| practice.  However, the rules are very clear on issues like this.

I'd disagree with the "very clear".

| You also may not be aware of some of the historical problems of interoperation
| of mail systems which are not compliant with RFC822.  For example, Banyan uses
| a "user at system@domain" format for mail.

Yeah; I've seen that. The only problem is the technicality that you're
not  supposed  to  use  '@'  more than once; that's why the '%' kludge
arose.  Actually, if you say "user%system at domain", it really means the
same   as   "user at system.domain".   Almost  all  mailers  now  support
"recipient at domain" now, after all, meaning to send it to some  machine
registered  in  the  domain,  which  will forward it as necessary.  If
"recipient" is of the form "user at system", what's the problem?

| If you are really interested in
| writing long essays on how the mail system should be fixed, you would probably
| enjoy getting involved with the X.500 standards people. :-)

Nah; I can't personally afford all the airfare and  hotel  rooms  that
it'd take. Maybe if I can get a job with some company who wants to pay
my way.  But in the hundreds of interviews I've been to, not a  single
one was interested in implementing an email package.  That's something
that you just get with your workstation, right?   You  spend  maybe  5
minutes configuring it, and you never have a problem with it, right?

Just for a lark, I've written my own programs that try to  talk  X.400
or  X.500  to  the other end.  I've yet to stumble across another node
that accepts such messages.  (I've also  written  some  programs  that
produce  SGML,  and  found  that  no  existing  Web  browser  seems to
understand.  So much for standards.  ;-)





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