John Klensin writes:
(1) >From:
allied!Ron_Gallagher/O=AEROSPACE/OU=HQ(_at_)mhs(_dot_)attmail(_dot_)com
>Message-Version: 2
(2) >>To: internet!ics.uci.edu!stef/STANDARD/REPORT
(3) >Date: Sat Aug 24 19:01:53 -0400 1991
>...
(4) >End-of-Header:
>EMail-Version: 2
>...
(5) >End-of-Protocol:
(6) >Content-Type: text
(7) >Content-Length: 2122
Sigh.
If you were here, you'd hear the sound of clapping. Bravo, John, for doing
such a masterful analysis. I only want to add a couple of observations.
...
Stef, is the original address, ignoring the "allied!" part, but
without a tag on Ron_Gallagher, a legal/plausible X.400 address
presentation syntax?
As far as I know, this is not legal or plausible. Ron_Gallagher looks to
me like a vaguely RFC1148-like mapping of
/S=Gallagher/G=Ron
but as far as I know, once you use the /= syntax, all attributes have to
be specified using this form.
Are there systems around that might decide this
meant "/allied=Ron_Gallaher/O=AEROSPACE/OU=HQ", for example?
Certainly, although my RFC1148 parser simply says "that's illegal".
(2) I've run across RFC822 parsers that get very irritated if they
encounter a non-alphabetic characters as the first character of a field
name. Note the ">To" here.
I don't believe this actually violates RFC822, however.
(3) This date is in incorrect format. Systems that try to canonicalize
date fields for internal formats are unlikely to be able to process it.
I've rarely seen a message bounce for this reason, but I've certainly
seen them encapsulated by RFC821/822-conforming systems.
Recently I've encountered an increasing number of systems where illegal
date formats can cause delivery failures. In particular, it now seems to be
a popular thing to reject messages that are dated in the future, or too
far in the past. I've been bitten a couple of times now by gateways that
don't know about 4 digit dates, and think such dates are too far in the future,
or, if the gateway chooses to read only the first two characters, think that
year 1919 means the message is expired.
This approach seems especially popular on PC/Mac e-mail gateways; I suppose
because they use different date formats and thus you do have to parse the
header for conversion.
(4), (5) I've run across RFC822 parsers that get very irritated if
they encounter a header name with no field values.
Again, it is worth noting that this is not illegal.
(6) Those who believe that RFC-XXXX can appropriate the field name
"Content-type" and put it to specific purposes, assuming that any header
that contains it is RFC-XXXX compliant, should note this header.
Amusingly enough, the usage here does not seem to be incompliant. The message
is, after all, text.
(7) Same comment as (6) about various Content-length proposals.
This header may be useful for gateways that want to detect ATTMAIL ;-)
[A series of rude comments about this situation, and about holding it up
as a norm to which the rest of us should conform, are omitted here out
of a sense of decency.]
Complete agreement here.
Ned