madison@vms.ecs.rpi.edu (Matt Madison) (02/25/90)
Having just finished writing some new E-mail software for our VMS system,
I have spent several hours studying both RFC 821 and RFC 822 to ensure that
this software complies with these standards. After all, these standards
are used by all the systems on the Internet, right?
As soon as this software went into production use, we started experiencing
problems exchanging mail with (you guessed it) some UNIX systems on our
network (and elsewhere). There have been three problems so far, and trivial
though they may be, they have been rather aggravating.
Problem 1. In implementing a gateway between VMS MAIL coming in over
DECnet and SMTP, my software generates return addresses of the form
<"node::user"@domain>. The quotation marks are necessary because colons
are considered "special" by RFC 822. This immediately started to cause
problems because (I'm told) sendmail by default strips quotation marks
from the user portion of an address. So when UNIX users tried to reply
to messages sent from my system, the replies would be rejected by my
SMTP server becuase <node::user@domain> is not valid RFC 822.
Problem 2. RFC 821 states that all lines sent should be terminated with a
carriage return/line feed sequence. It turns out that some UNIX-based
SMTP implementations do not adhere to this and by default terminate lines
simply with line feeds. Now, I can understand this behaviour in older UNIX
implementations. But we're talking recent versions of ULTRIX and SGI's
UNIX (whatever it's called)!
Problem 3. Some UNIX mail systems appear to generate return addresses of
the form
real name <user@domain>
Where "real name" is simply pulled from the passwd file (or wherever this
information is obtained on UNIX systems), without verifying that it can be
left unquoted and still comply with RFC 822. This means that anyone who has
included their middle initial with their name, with a dot, will have a
return address that violates the standard (dots are not allowed in the
leading phrase before the address). Parsing 822-compliant addresses is
complicated enough without having to deal with crap like this.
What really burns me up about this, is that it's considered _my_ fault that
this stuff doesn't work! Argh.
--
Matthew Madison, Systems Programmer | "First they built the world's standard.
Engineering Computing Services | Then they added standards no one else
Rensselaer Polytechnic Institute | had." - an ad for SCO Xenix
Troy, New York 12180-3590 USA |
madison@vms.ecs.rpi.edujeh@simpact.com (02/25/90)
In article <00932CA6.30EE8E00@vms.ecs.rpi.edu>, madison@vms.ecs.rpi.edu (Matt Madison) writes: > Problem 1. In implementing a gateway between VMS MAIL coming in over > DECnet and SMTP, my software generates return addresses of the form > <"node::user"@domain>. The quotation marks are necessary because colons > are considered "special" by RFC 822. This immediately started to cause > problems because (I'm told) sendmail by default strips quotation marks > from the user portion of an address. So when UNIX users tried to reply > to messages sent from my system, the replies would be rejected by my > SMTP server becuase <node::user@domain> is not valid RFC 822. I suggest that you do what we (the DECUS uucp folks) do for our "user base": We have an address rewrite mechanism that, for From addresses on outbound mail, can be set up to rewrite node::user to user@node.rest_of_domain eg, stuff coming from SKYVAX::user here ('here' is simpact.com) ends up coming from user@skyvax.simpact.com. This is in concert with most domain naming schemes anyway, where the second-level domain ('simpact' in our case) specifies which company within .com, and the third-level specifies which machine within .simpact.com . Our rewrite rules can get fancier; for example, if there may be overlaps between DECnet nodename space and some other internal network's namespace to which you must also delivery mail, you can choose to rewrite to something like user@node.decnet.simpact.com or even user%node@decnet.simpact.com (but a lot of other mailers don't do what you want with %'s) And, of course, for To: addresses on inbound mail, we can look for things that match whichever of the above patterns the user wants, and rewrite to node::user for inbound delivery. This works for us (simpact), even in a horribly mixed decnet/tcp-ip/uucp environment, and we don't even use PMDF (yet). > ...[descriptions of other hassles deleted] > What really burns me up about this, is that it's considered _my_ fault that > this stuff doesn't work! Argh. Being chief recipient for e-mail and phone calls regarding DECUS uucp, I know EXACTLY what you mean. (And thanks to all of you who have communicated thanks to us for the package; you are keeping us going!) The above commentary is in no way meant to suggest that mailers Out There ought NOT to take "anything_at_all"@domain and pass the stuff in quotes intact. But suggesting that they do so is probably tilting at windmills. (p.s.: DECUS uucp is uucp for VMS with full mail and netnews support. It is essentially free. Send mail to me for info.) --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
lear@turbo.bio.net (Eliot) (02/26/90)
[From RFC1123]
1.2.2 Robustness Principle
At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability:
"Be liberal in what you accept, and
conservative in what you send"
UNIX doesn't let you forget that.
--
Eliot Lear
[lear@TURBO.BIO.NET]csvned@jarthur.Claremont.EDU (Ned Freed) (02/26/90)
Welcome to the real world of mailers! As the primary author of PMDF, a very popular mail system for VMS machines, I've run into all the problems you cite on numerous occasions. You've only just started -- there are lots more waiting for you. Now some advice. You'll never get mailers to accept "node::user"@domainhost format. It is a hopeless task. So I'd recommend using something of the form user%node@domainhost if possible. This even generalizes to multiple nodes if you need them. Note that this does not solve the entire problem of how to handle all the wierd stuff VMS MAIL likes to use, but it will get you started at least. The problem of mailers inserting some bogosity into the personal name field in an address is well-known too. My advice on this one is to simply ignore it. You should not be looking at header lines for delivery purposes anyway. The envelope should suffice, and personal name fields are flagrantly illegal in an envelope (PMDF accepts them but strips them for reasons that I won't get into in this forum). You can either insert a sanitized header line in place of the incorrect line or just pass it on unchanged and let the next mailer downstream worry about it. If it rejects it your hands are clean -- that's a battle between the offending mailer and the picky mailer! A final note. All the standards say that a blank address is completely legal in various places, e.g. an SMTP MAIL FROM: line. Watch out for those. Several UNIX mailers (you know who you are) go into infinite loops when they get one of these. And if you think you've had trouble with users whose mail got lost in the past, you've got a new treat when you deal with a sysmgr whose load average was at 50 before he wiped out all those looping mail processes. Not a pretty sight. Good luck on your project. I saw an announcement of your system on the JNET-L list, I believe. Sounds good. Ned Freed ned@ymir.claremont.edu
jef@well.sf.ca.us (Jef Poskanzer) (03/03/90)
} "Be liberal in what you accept, and } conservative in what you send" In my experience, the typical postmaster who quotes this aphorism wants others to abide by the first part, so that he doesn't have to abide by the second. Not Eliot, of course. But every other time this bullshit has appeared, that has been what was actually going on. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef Now how much would you pay?
peter@ficc.uu.net (Peter da Silva) (03/03/90)
> } "Be liberal in what you accept, and > } conservative in what you send" > In my experience, the typical postmaster who quotes this aphorism wants > others to abide by the first part, so that he doesn't have to abide by > the second. Not Eliot, of course. But every other time this bullshit > has appeared, that has been what was actually going on. One does not always have the option of abiding by the second, unless you use the newfangled meaning of the word "conservative" (i.e., reactionary). Those of us at sites with proprietary mail software that can't economically be replaced are kind of stuck. Even if we generate standard UUCP version 2 headers (which conform to RFC822 via a grandfather clause, according to people I've spoken to) we're out of luck for sites running smail 3.0. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'