Stef writes....
Just out of curiosity, what kinds of problems might be expected from
this sort of thing floating out into the internet from ATTMAIL?
...
(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.
Well, based on personal experience, and questions over the years on
info-nets, let me hit the high points :-)
(0) A significant fraction of mail addresses sent into the Internet
from ATTMAIL turn out non-reversible, i.e., "reply" applied to the
"From" addresss does not work, even if that address does not contain
bang paths.
(1) As a sender, I should not care, but it is not clear whether
ATTMAIL, on return, will send this to "allied", or whether "allied" is
part of the whatever-the-untagged-first-X.400-field is (SN?). Of
course, if this hits a (non-Internet compliant) bang-path-primary host,
it will promptly be turned into something completely amazing. As a
different example, note that, if they passes through a gateway into
BITNET at present, it will be calmly turned into
allied!Ron_Gallagher/O=AEROSPACE/OU=HQ%mhs(_dot_)attmail(_dot_)com(_at_)gateway-domain
and, after that, what happens, is anyone's guess, since some systems,
trying to protect the user, rewrite that into
mhs.attmail.com!allied!Ron_Gallagher/O=AEROSPACE/OU=HQ(_at_)gateway-domain
and/or
gateway-domain!mhs.attmail.com!allied!Ron_Gallagher/O=AEROSPACE/OU=HQ
and/or
Ron_Gallagher/O=AEROSPACE/OU=HQ%allied%mhs(_dot_)attmail(_dot_)com(_at_)gateway-domain
and other systems just have creative ways to interpret such things.
Stef, is the original address, ignoring the "allied!" part, but
without a tag on Ron_Gallagher, a legal/plausible X.400 address
presentation syntax? Are there systems around that might decide this
meant "/allied=Ron_Gallaher/O=AEROSPACE/OU=HQ", for example?
(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.
(3) This date is in incorret 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.
(4), (5) I've run across RFC822 parsers that get very irritated if
they encounter a header name with no field values.
(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.
(7) Same comment as (6) about various Content-length proposals.
[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.]
--john