🚀 go-pugleaf

In article <1907@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>I also propose that standard header names and syntax be used for
>standard header lines, e.g. "To:" rather than ">To:" and "Message-ID:"
>rather than "Ua-Message-Id:".  I also find it curious that they
>actually followed the RFC822 standard by using "X-" as a prefix on
>local header fields -- but only for one of the nine nonstandard headers
>they added.

There is a standard for "Mapping between X.400 and RFC822" by S. E.
Kille of University College London, June 1986, UCL Technical Report 120,
Request for Comments (RFC) 987. It avoids almost all the nasties you
cite above.  Perhaps it would be nice if AT&T adopted it.

Regards,
Alan Young	awy@concurrent.co.uk  or ...!{backbone}!ukc!concurrent!awy

Yup. X.400 is here to stay. There are several very nice features to this
superset protocol (and no I didn't write the requirement spec.). It is
called MTA (Mail Transport Agent) and is used by several mailers. It is
quite comprehensive including support for binary format messages and
attachments.

I get sick of the various GARGANTUA mail headers that come down the wire
but what is really needed are better user agent programs, not RFC822. It
is not sufficient beyond ASCII text messages and most of the planet doesn't
grok alphabetic.

   Steve Blasingame (Oklahoma City)
   bsteve@gorgo.att.com
   ihnp4!occrsh!gorgo!bsteve

Steve Blasingame of AT&T asserts that the CCITT X.400 mail standard is
here to stay. While this is likely the case (as much as some people
might otherwise wish that it would go away), it is not the standard
used by the UUCP network, the BITNET, the MAILNET, the USENET or the
ARPA Internet. If AT&T wishes to continue to communicate with any of
the networks that I just listed, the relevant standard for mail header
format is RFC822, not X.400.

For those sites that *insist* upon running X.400 mailers, I strongly
suggest that you obtain RFC987, which lists mappings between X.400 and
RFC822, and implement the recommendations therein. To fail to do so
will be to fail to communicate.

	holding out the forlorn hope that someone in AT&T is listening,

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu

In article <717@sl10c.concurrent.co.uk> alan@concurrent.co.uk (Alan Young) writes:
>In article <1907@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>>I also propose that standard header names and syntax be used for
>>standard header lines, e.g. "To:" rather than ">To:" and "Message-ID:"
>>rather than "Ua-Message-Id:".  I also find it curious that they
>>actually followed the RFC822 standard by using "X-" as a prefix on
>>local header fields -- but only for one of the nine nonstandard headers
>>they added.
>
>There is a standard for "Mapping between X.400 and RFC822" by S. E.
>Kille of University College London, June 1986, UCL Technical Report 120,
>Request for Comments (RFC) 987. It avoids almost all the nasties you
>cite above.  Perhaps it would be nice if AT&T adopted it.

There is an NBS committee currently working on an NBS standard to map
between 822 and X.400.  They used RFC 987 as a starting point, but it
appears there were a few bugs in 987 they are resolving.  AT&T is on
the committee, and I expect they will probably base a future version
of their internal MTA standard on the NBS result.

But please realize that MTA predates RFC 987, and they see no point in
987-ifying MTA with the NBS standard coming up.  Also, MTA has extensions
that aren't in 987.

>To: is like the From_ line (often seen as >From) - it's an envelope
field, specifying who this copy of the message it to be delivered to.
X.400 has several message-id's, and the UA Message ID is just one of
them, as I understand it.

	Mark