gnu@hoptoad.uucp (John Gilmore) (03/19/87)
I got a message recently from someone in AT&T and it arrived as: From: ihnp4!ihlpa!sft Received: by ihnp4.ATT.COM id AA16275; 12 Mar 87 08:07:23 CST (Thu) Message-Version: 2 >To: /addr=ihnp4!hoptoad!gnu Date: Thu, 12 Mar 1987 08:06 CST Message-Service: Mail Message-Protocol: EMail End-Of-Header: Email-Version: 2 X-Postmark: scott.thompson attbl ih5c422 55669 3129792594 ihlpa!sft To: hoptoad!gnu Subject: Re: Wanted: agef program Ua-Message-Id: <post.sft.Thu, 12 Mar 1987 08:03 CST> End-Of-Protocol: Thank you for the reply, but I already received a copy. THANKS :-) (And you thought sendmail was bad! :-) I was so boggled that I forwarded a copy to Mark Horton, asking where this bogosity came from and whether it could be stopped. He said: > You guessed it, it's an X.400 work-alike. AT&T actually has a documented > mail standard that includes all this stuff. I think they are ugly too, > but I know it can't be stopped. I suggest you use the "ignore" command > in your .mailrc file. Of course, virtually every bit of the trash in there can be filtered out, since every message coming through will have the same values. I also presume that when ordinary uucp mail finds its way into the X.400 system, these verbose values are supplied by default. Therefore I propose that values which are set to the default NOT be inserted into outgoing headers. AT THE GATEWAY, not in each recipient in the whole Internet's .mailrc file! 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. I hope the general run of the mill X.400 gateway-of-the-future does a lot better than this! -- (C) Copyr 1987 John Gilmore -- no restricted redistribution permitted. {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu Love your country but never trust its government. -- from a hand-painted road sign in central Pennsylvania
alan@concurrent.UUCP (03/20/87)
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
mark@cbosgd.UUCP (03/30/87)
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