don.provan@CMU-CS-A.ARPA (10/15/84)
I've seen this problem a couple of times, including once last night, so perhaps it's time to talk about it. Apparently, someone (at SIMTEL20) told their mailer to send mail to '"Webb Mike"@lll-mfe' with the single quotes being mine. the mailer, spotting the double quotes, said "ah ha! those are not legal, so I must quote them." my mailer dutifully removed the quotes of the quotes, looked at the string '"Webb Mike"' and said "I see no one here by that name," since none of our names have double quotes. I guess I just want to start some discussion on what went wrong here and what we can do about it. I don't see any reason for me not to run the destination mail box through the dequoter until it finds no more quotes, but since I don't control all the names our mail receiver handles, that means I'm restricting the names other sites here can use. On the other end, I can tell our users to give out names like Webb Mike without quotes, but i assume this will not be understood by most mailers (although there are still a lot of mailers that can't handle the quotes, either.)
MRC@SU-SCORE.ARPA (Mark Crispin) (10/16/84)
Yes, the TOPS-20 SMTP sender/mailer (a.k.a. MMailr) will recognize that an address has "special" characters and will quote the address if so. It uses double-quote quoting when possible; if not, it uses backslash quoting (for the really hairy cases). What could have happened is that the process which queued the mail to MMailr (which I bet wasn't MM) misunderstood the quote application rules and applied SMTP quoting to the address in the envelope. Since MMailr performs this service, it was done twice. Perhaps you'll be able to tell from the message header what mail composition program wrote the message and its maintainers can be notified. On a related topic, it's been two years now and people are still using " at " in addresses (ala RFC 733). Noted culprits in the PDP-10 world are DECmail/MS and old versions of Hermes and Babyl. Something ought to be done to stamp this old software out! -------
WANCHO@simtel20.ARPA ("Frank J. Wancho") (10/17/84)
Mark and Don, I'm the guilty party who sent the message in question, and I used the latest version of BABYL to do it. I also deliberately put the double quotes around the name "Webb Mike" as I knew BABYL doesn't handle the unquoted case properly, and MM doesn't handle it (No such local user as "Webb"), unless the double-quotes *are* used. However, Mark's analysis of the mis-quoting done by BABYL in the envelope appears correct. I will pass this exchange on to the maintainers. On the related topic, the current BABYL properly handles the " at " cases, and has for quite some time. I have yet to be able to induce HERMES to cause that form of address to slip out, yet I know one of users on another machine was able to generate that in a header... Still checking. --Frank
mrose@uci-750a.ARPA (Marshall Rose) (10/17/84)
Sadly, addresses aren't the only thing which a lot of mailers/agents are botching. A surprisingly large number of date fields that get generated aren't 822. Of course, you never notice these things until you try using a routine that actually tries to *parse* the date string. Oh well, /mtr
MRC@SU-SCORE.ARPA (Mark Crispin) (10/17/84)
I confess that MM and friends are guilty of botching the syntax of the date. That's because, with all the zillions of date/time syntaxes the TOPS-20 IDTIM% system call can parse and ODTIM% can generate, RFC 822 takes great pains to pick one that isn't among those zillions. Actually, I don't think it was really done deliberately, but one wonders. So, the code picks a nearest approximation, and DEC has been asked to define a new bit meaning "RFC 822 format". Where we blow it is that we don't have a comma after the day-of-week and have a hyphen before the timezone. I swear, though, if after we finally get into full compliance with RFC 822 dates they change the syntax to something incompatible AGAIN, I'll get the %&#@! -------
mrose@udel-dewey.delaware (Marshall Rose) (10/17/84)
Actually, I wasn't knocking TOPS-20 systems (MM, et. al., in particular),
but a few of the really obscure sites that are using something that is
completely unlike the 822 syntax. The date parser I use doesn't have any
problem with ODTIM%-generated strings, but can't pull a rabbit out of a
hat...
/mtrJacob_Palme_QZ@QZCOM.MAILNET (10/23/84)
FROM: Mark Crispin <MRC@SU-SCORE.ARPA>
I swear, though, if after we finally get into full compliance
with RFC 822 dates they change the syntax to something
incompatible AGAIN, I'll get the %&#@!
Surely they will. Do you not know that there is an international
standard for calendar dates. Something like this, I believe:
1984-10-23-17.43.59
for todays date.DESJARDINS@USC-ISI.ARPA (10/24/84)
Jacob is right: the DOD policy is that if there is an international standard already in existence for something, and the standard meets the military requirements, then the standard would be used in preference to inventing something new. I would think that policy applies to calendar date/time strings (but I can't verify from my own knowledge that the syntax Jacob gave is correct). Barry Leiner or Bob Kahn could give a more definitive statement of the policy, but this is the essence of it. --Dick dJ