Received: from WISCVM.WISC.EDU by MIT-MC.ARPA 11 Dec 85 02:17:05 EST Received: from (JCURRAN)UMASS.BITNET by WISCVM.ARPA on 12/10/85 at 13:21:20 CST Date: Tue, 10 Dec 85 09:59:36 EST From: JCURRAN%UMASS.BITNET@WISCVM.ARPA To: HEADER-PEOPLE@MIT-MC.ARPA Subject: A suggestion for preventing machine mail loops It occurs to me that the rfc822 document has very good provisions for handling machine generated mail and preventing 'loops' per se. In a server or demon, one can simply provide the following set of fields in a out-going message: From: Server-name@node Sender: Person@node Reply-to: <> In this way, the actual origin is specified, but will never be used as an address; all errors should be sent to the person responsible for the server, and any attempts at replies to the server should be disallowed since the reply-to field is null. -- John Curran -- Umass/Amherst  Received: from SRI-IU.ARPA by MIT-MC.ARPA 11 Dec 85 03:07:24 EST Date: Wed 11 Dec 85 00:05:58-PST From: Peter Karp Subject: Re: A suggestion for preventing machine mail loops To: JCURRAN%UMASS.BITNET@WISCVM.WISC.EDU Cc: HEADER-PEOPLE@MIT-MC.ARPA Message-ID: In-Reply-To: Message from " JCURRAN%UMASS.BITNET@WISCVM.ARPA" of Tue, 10 Dec 85 09:59:36 EST I think I must be missing something in this discussion of automatically generated replies. You don't want to use a line like: Reply-To: <> to stop mailers from returning undeliverable messages. This is not the address that mailers (or programs) are supposed to use for this purpose, and in fact this address SHOULD have some value (particularly for program-generated messages) so that people receiving the messages know how to contact a person responsible for the program's behavior. In fact mailers are supposed to return undeliverable messages to the address specified in the SMTP "MAIL FROM" command. This address is normally written to a "Return-Path:" field in the header upon actual delivery in a person's mailbox. Programs which generate messages should have the brains to tell their outgoing mailer to use a null address in the "MAIL FROM" command - particularly when these programs are mailers which are in fact returning a message to its sender. I thought this is all laid out fairly clearly in 821 and 822. Peter -------  Received: from WISCVM.WISC.EDU by MIT-MC.ARPA 11 Dec 85 11:25:57 EST Received: from (JCURRAN)UMASS.BITNET by WISCVM.WISC.EDU on 12/11/85 at 10:23:15 CST Date: Wed, 11 Dec 85 11:08:06 EST From: JCURRAN%UMass.BITNET@WISCVM.WISC.EDU (Local UMass address is Avenger@Mailer.CY175) Subject: automatic generation of replies To: Header-people@mit-mc.arpa I don't think that rfc822 CLEARLY pointed out that automatically generated replies should have a "return-path" of null. In fact, rfc822 discusses computer generated messages and states that since computer programs cannot be held accountable, the SENDER field of the message should contain an path of the human responsible. This means that a good header specification resulting from a demon could be: From: Demon@Node... Sender: Demon-fixers@node.. By rfc822, Demon-fixers will recieve "notices of any problems in transport or delivery of the original messages" while Demon@node will recieve any replies. This works very well except when the server/demon doesn't want any replies sent to it. It can either discard them as the arrive, or since a REPLY-TO field is the address that "the reply should go to.. and not the FROM field" the demon could simply indicate on its messages that it does not wish replies (of any kind, automatic or 'real') by including a REPLY-TO field of Null. Comments? -- John Curran -- Umass/Amherst  Received: from USC-ISIB.ARPA by MIT-MC.ARPA 11 Dec 85 13:36:28 EST Date: 11 Dec 1985 10:00:09 PST From: POSTEL@USC-ISIB.ARPA Subject: re: automatic generation of replies - return path To: header-people@MIT-MC.ARPA John Curran: The "return-path" is discussed in RFC-821. --jon. -------  Received: from WISCVM.WISC.EDU by MIT-MC.ARPA 11 Dec 85 16:00:56 EST Received: from (MAILER)DBNGMD21.BITNET by WISCVM.WISC.EDU on 12/11/85 at 14:55:33 CST Date: Wed, 11 Dec 85 18:34 CET To: Header People From: Peter Sylvester +49 228 303245 Subject: (Copy) Re: A suggestion for preventing machine mail loops Where is the return-path: header field in the following message? ---------------------------- Text of forwarded message ----------------------- Received: (from SMTPUSER@WISCVM for GRZ027@DBNGMD21 via NJE) (RSCS6516-6516; 35 LINES); Wed, 11 Dec 85 18:12:35 CET Received: from MIT-MC.ARPA by wiscvm.wisc.edu on 12/11/85 at 02:32:58 CST Received: from SRI-IU.ARPA by MIT-MC.ARPA 11 Dec 85 03:07:24 EST Date: Wed 11 Dec 85 00:05:58-PST From: Peter Karp Subject: Re: A suggestion for preventing machine mail loops To: JCURRAN%UMASS.BITNET@WISCVM.WISC.EDU Cc: HEADER-PEOPLE@MIT-MC.ARPA Message-ID: In-Reply-To: Message from " JCURRAN%UMASS.BITNET@WISCVM.ARPA" of Tue, 10 Dec 85 09:59:36 EST .... In fact mailers are supposed to return undeliverable messages to the address specified in the SMTP "MAIL FROM" command. This address is normally written to a "Return-Path:" field in the header upon actual delivery in a person's mailbox. ....  Received: from sri-spam.arpa by MIT-MC.ARPA 11 Dec 85 16:28:34 EST Received: by sri-spam.arpa (5.4/4.16) id AA10452; Wed, 11 Dec 85 13:25:55 PST Date: Wed, 11 Dec 85 13:25:55 PST From: gds@sri-spam.ARPA (Greg Skinner) Message-Id: <8512112125.AA10452@sri-spam.arpa> To: header-people@mc Subject: Re: Need for new field in RFC and MHS standards > From @MIT-MC.ARPA:mcvax!ace!teus@seismo.CSS.GOV Wed Dec 11 01:37:39 1985 > Received: from MIT-MC.ARPA by sri-spam.arpa (5.4/4.16) > id AA01923; Wed, 11 Dec 85 01:37:39 PST > Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:28:49 EST > Return-Path: ... > Message-Id: <8512101018.AA16148@sunrel1> It might be the case that we also want to modify our mailers so that upon receipt and full delivery of a message with a given Message-ID, all subsequent messages received with that same Message-Id are dropped on the floor (no need to advise anybody automagically of duplicates, since we don't want to see exponential growth of looping mail :-). I don't know if this is an MHS requirement or not but it is essential in a conferencing system (where the same messsage might come from different nodes in a network) and would relieve us of seeing duplicates. The only problem is that not all mailers generate Message-IDs at the source of the message, plus a redistributor may replace (or add) its own Message-ID. We should limit the number of Message-IDs to one per message. --gregbo  Received: from SRI-IU.ARPA by MIT-MC.ARPA 11 Dec 85 18:22:04 EST Date: Wed 11 Dec 85 15:16:36-PST From: Peter Karp Subject: "Where is the Return-Path line?" To: header-people@MIT-MC.ARPA Message-ID: Peter Sylvester: It appears that your mail system didn't write one. The important concept here is that associated with every SMTP message is an out of band (i.e., not in the header) address which is where the message is suposed to be returned to if it cannot be delivered. As a message hops from host to host, each one is supposed to suffix its name to this return path. The Tops-20 mail system is nice enough to write this address into a Return-Path: field in your message header when it delivers it to your mailbox. I don't believe this is part of any official specificiation, but it does come in handy. This out of band address is transmitted in the SMTP "MAIL FROM" command. For example, when I send this message to header-people, it starts at SUMEX, goes to MIT-MC, and then gets relayed to each of you. Here is what the mailers tell each other along the way: SUMEX to MIT-MC: MAIL FROM: MIT-MC to yourarpa host: MAIL FROM:<@MIT-MC.ARPA:PKARP@SUMEX-AIM.ARPA> Well, hopefully this gives you the idea. As Jon says, this stuff is discussed in RFC821. Note by the way that I'm not arguing that all this is an ideal state of affairs, I'm merely saying how to use the current system correctly. One might argue that having both out of band address information and address information in the header is a very bad idea since the two can become inconsistent. But clearly it makes mail system code a lot simpler since SMTP only has to deal with the out of band band info - it doesn't have to parse message headers. This allows SMTP to deal with messages as featureless blocks of text and leave all header issues to mail reading/composition programs. Or at least it could if it weren't for gateways between different mail protocols. Anyone care to start a discussion of how to rewrite message headers when messages are relayed across protocol boundaries? A lot of sites are doing this but I have yet to see any official specification of how to do it or even a formal statement of the rules that are used. For example, this is how lovely addresses like: tuna!user%spam@turkey!beaver@phred get created. Peter (Karp) -------  Received: from WISCVM.WISC.EDU by MIT-MC.ARPA 12 Dec 85 09:45:00 EST Received: from (JCURRAN)UMASS.BITNET by WISCVM.WISC.EDU on 12/12/85 at 08:42:22 CST Date: Thu, 12 Dec 85 08:33:53 EST From: jcurran%UMass.BITNET@WISCVM.WISC.EDU (John Curran (413) 545-2690) Subject: Internet formats To: Header-people@mit-mc.arpa Please notice that many internetwork gateways do not allow the sender control over any of the SMTP commands sent other then indirectly.. As such, it becomes crucial that all essential information about a message envelope can be expressed not only in SMTP commands, but in fields in the message. In the past, when mentioning machine generated mail and the potential for "looping" of replies, references to the MAIL FROM field in the SMTP envelope be null. This solution might work for SMTP to SMTP mail but it is questionable of whether it will succeed in an net-gateway-net situation. Examine the problem of 'dueling reply demons' whereby two mail system users, each on their own network, have left on vacation and have installed a reply-demon that automatically inform the sender that his mail have been recived and will be read when the account owner returns. In a SMTP network, the first automatic reply gets a MAIL FROM field of null, the second reply can never be send for lack of destination. In an internet message there is no SMTP fields and depending upon the transformations done via the gateway, it is possible that the replies will go on and on.. Now there is a choice of either making the "return-addr" or "From" field null if the geteway program has reason to believe (like a null MAIL FROM field on a SMTP header) that the message was machine generated. Also, mail systems (and demons) must be prepared to handle such an occurance. John Curran Umass/Amherst  Received: from A.CS.CMU.EDU by MIT-MC.ARPA 12 Dec 85 12:29:43 EST Date: Thu, 12 Dec 85 12:15 EST From: Craig.Everhart@A.CS.CMU.EDU To: Header-People@MIT-MC.ARPA Subject: Re: Internet formats CC: jcurran%UMass.BITNET@WISCVM.WISC.EDU (John Curran (413) 545-2690) In-Reply-To: "jcurran%UMass.BITNET@WISCVM.WISC.EDU's message of 12 Dec 85 08:33-EST" Message-Id: <12Dec85.121525.RD00@A.CS.CMU.EDU> So it's the responsibility of the inter-net gateway to transmit the proper semantics of the null SMTP MAIL FROM:<> address through the other network. In fact, it's the responsibility of the other network to provide such semantics, and it's the responsibility of the inter-net gateway to translate that net's semantics to the null SMTP MAIL FROM: form. If this means putting some information in a header field as mail moves from SMTP-land to some other place, and reading that header field in messages from that other place to figure out what to use for the MAIL FROM: contents, so be it. Craig Everhart  Received: from hplabsd by MIT-MC.ARPA 12 Dec 85 15:55:35 EST Received: by hplabsd ; Thu, 12 Dec 85 12:14:41 pst To: veeger!hpcnof!hplabs!Header-People@MIT-MC.ARPA Date: Thu, 12 Dec 85 11:04:45 MST From: hpcnou!dat@hplabsd (Dave Taylor) Subject: X-* headers Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.3] As a response to a recent request for headers that are in X-* form, (or should be) an excerpt from my List of Mail Headers... (requests for the full document should be mailed to me at either of the signature addresses) -- Dave Taylor hpcnof!dat@HPLABS or ihnp4!hpfcla!d_taylor ---------- Extensions and User Defined Fields ---------------------------------- There are many more headers that can be found in electronic mail (some of which are listed below) and often the personal headers are prefixed by "X-", since it is guaranteed that any extensions to the mail headers will not begin with these two letters. It is important to note that this section is by no means complete - there are a great number of strange headers floating about. I've tried to document the most common and most interesting ones here. 37. Latitude: This header indicates the relative Latitude and Longtitude (geographic location) of the sender. Theoretically, if you have a "Great Circle" program, you could feed it these entries and your own location and figure out how far away from you they are. It's of dubious use, though. Example: Latitude: 40.4166 Longitude: 86.9166 38. Organization: This is a quite common header (with it's European variant "Organisation:") and indicates the organization that the sender works for or is attending (in the case of a University). Examples: Organisation: the Antelope project, Kruislaan 312, Amsterdam Organization: Hewlett Packard, Colorado Networks Operation 39. Origin: This is mostly used to verify that the sending username is actually the person who sent it. it contains the tty device sending the message, the hostname of the machine and the date sent. Example: Origin: tty613 on hpccc; Mon, 23 Sep 85 09:48:38 PDT 40. Phase-Of-The-Moon: This is a strangely popular header that is presumed to indicate what phase the moon is in at the senders' site...more dubious infor- mation! Example: Phase-Of-The-Moon: Waning Crescent (18% of Full) 41. Phone: The telephone number by which the sender can be reached (usu- ally their work phone number). Example: Phone: +31 20 5924122, +31 20 947183 42. Postal-Address: The "overland" (non-electronic) mail address for the sender of the message. Example: Postal-Address: Dave Taylor, HP Colorado Networks, 3404 East Harmony Road Fort Collins, Colorado 80525 43. Status: This header is generated and used at the receiving end by the (Berkeley) mailx mailer and it's derivatives, and indicates the "status" of the individual message. Known values for the field are: N - new R - read RO - read, old (saved to file and re-read) Example: Status: RO 44. Sunrise: What time sunrise and sunset are at the senders location. Example: Sunrise: 6:23 Sunset: 19:08 (CST) 45. Telephone: This is the same as 'Phone:' above. Example: Telephone: (415) 857-5875 46. X-Location: This is the geographic location of the sender. Example: X-Location: Fort Collins, Colorado, USA 47. X-Mailer: This indicates what mailer the sender used to compose and actu- ally transmit the message. It's usually used to indicate non- standard mailers... Example: X-Mailer: fastmail [version 1.0] 48. X-Sent-By-Nmail_Version: This is the same as the "X-Mailer:" header, only much more specific. It should, in fact, be absorbed into the previous header. Example: X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46  Received: from hplabsd by MIT-MC.ARPA 17 Dec 85 15:51:27 EST Received: by hplabsd ; Tue, 17 Dec 85 12:27:12 pst To: veeger!hpcnof!hplabs!cak@Purdue.EDU Date: Tue, 17 Dec 85 11:03:43 MST From: hpcnou!dat@hplabsd (Dave Taylor) Subject: More on bizarre headers Cc: veeger!hpcnoe!hpfcla!hplabs!Header-People@MIT-MC.ARPA, msg-group@hplabsd In-Reply-To: Message from "Christopher A. Kent" of Dec 12, 85 at 9:35 pm Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.3] Chris Kent at Purdue informs me that I missed his contribution to the mail header mania... ---------------- From root Tue Dec 17 10:48:25 1985 To: hpcnou!dat@hplabs.arpa (Dave Taylor) Subject: Re: X-* headers National-Indulgence-Of-The-Day: Lager From: "Christopher A. Kent" Dave, Somehow you've missed my contribution to mail header explosion (see above.) Chris ---------- My response is: Gee you have a wonderful header there. So do some other friends of mine: Phase-of-the-Day: management by objectives Fruit-of-the-Day: apple Buzzword-of-the-Day: user-friendly Mood-of-the-Moment: happy Neuron-Firing-Level: high Libido-Level: very high Weather: sunny with a 30% chance of rain this evening Temperature: 80 degrees, +/- 5 degrees and so on. My real reaction - the arbitrary headers are fine...no biggie...but I'm not about to start adding every random header to the list just to give people vicarious thrills. Y'know what I mean? (Besides, it would increase the size of the list without bounds once I started) If you can get a number of people at a number of different sites to start using your header then it will make it into the document I transmitted since that's the way I decide... While I'm at it, I'd like to poll the readers of this message about their reactions to my posting this list every so often, including all updates, to the newsgroup "net.mail". Any comments? It seems like this would be a pretty useful addition to the net... Sorry to seem so untractable, Chris, but I'd really like to avoid a replay of the header-wars that first hit when people realized they can put just about any random junk in the headers of their outbound messages. My worst nightmare is to start getting messages like: ----------- From root Subject: how about THESE headers! Alternative-Subject: more headers for inclusion in your list Mail-Generated-By: typing it in, of course. From: John Public Really-From: God Almost-From: Ronald Reagan Political-Stance-of-the-Day: ban the bomb! Start-Body: Line-1: Dave, Line-2: Line-3: Just thought you'd appreciate this message with it's wonderful Line-4: headers and would consider it for inclusion in your list of Line-5: mail headers... End-Body: Signed: John Q. Public Authorized-by: jqp at 4:50 pm hi ---------- or something equivalent. -- Dave Taylor Hewlett Packard  Received: from hplabsd by MC.LCS.MIT.EDU 18 Dec 85 15:10:29 EST Received: by hplabsd ; Wed, 18 Dec 85 12:07:10 pst To: veeger!hpcnoe!hpfcla!hp-sdd!ken@hplabsd Date: Wed, 18 Dec 85 10:03:37 MST From: hpcnou!dat@hplabsd (Dave Taylor) Subject: Quiz - Parse this From line Cc: veeger!hpcnoe!hpfcla!hplabs!Header-People@MIT-MC.ARPA In-Reply-To: Message from "Ken Stone" of Dec 17, 85 at 2:36 pm Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.3] Ken Stone of HP-SDD sent me his copy of my recent note and the return address is the strangest I've seen yet on this network... >From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Tue Dec 17 13:35:41 1985 The question is - how does one parse this? There are a LOT of ambiguities here ... including two '@' addresses and such. It seems to me that a decent return address would be parsable in a unique fashion, rather than this "if the destination machine is an ARPA gateway then it'll send to (?) hplabsd, if not, then if it's a BITNET gateway it'll send to MIT-MC.ARPA (through an ARPA gateway?) else it'll just send it to noscvax and let THEM deal with it... Anyone have any pearls of wisdom about all this? ----- for further amusement, the modified From line too...(now wrong) ---- From: noscvax!hpcnou!dat@hplabsd.ARPA (Dave Taylor) ----- Are we having fun yet? -- Dave  Received: from ucbarpa by MC.LCS.MIT.EDU 18 Dec 85 16:28:33 EST Received: by ucbarpa (5.31/1.7) id AA24747; Wed, 18 Dec 85 12:38:44 PST Date: Wed, 18 Dec 85 12:38:44 PST From: jordan@ucbarpa.BERKELEY.EDU (Jordan Hayes) Message-Id: <8512182038.AA24747@ucbarpa> To: header-people@mit-mc.arpa Subject: Re: Quiz - Parse this From line From: hpcnou!dat@hplabsd (Dave Taylor) >> From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Simple. If there's a leading '@', use source-routing. If not, look for the right-most '@' ... so, send the return message to "hplabsd" ... Ah, they say -- "but that's not the truth ..." Humbug. You can't parse it correctly unless you make some assumptions about where that address showed up at. If it showed up at a dumb UUCP host connected to noscvax, you may not have a problem returning it to there and having noscvax send to mit-mc which would send to hplabsd which would send to hpfcla!hpcnoe!veeger!hpcnou!dat ... *ugh* !! However, if the site it came from recieved the message *via* uucp, but is also an arpanet host (can you say "seismo" "ucbvax" "topaz" "sdcsvax" "harvard" + a cast of thousands ...), you have a problem, since it will try to do the "correct" thing I mentioned above about sending it to hplabsd (BTW: how about your own return address, Dave?) Such a silly question to ask ... the answer is clear: you can't parse addresses with multiple (conflicting) syntaxes ... I thought we cleared this question up a few years ago ... *sigh* Now: how about the solution? As simple as the answer to Dave's Question ... uucp needs to use 822 addresses if they expect to get decent service when getting gatewayed into/out of the Arpanet. They can do whatever they want between themselves, but when in Rome ... /jordan  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 19 Dec 85 15:14:08 EST Received: from hplabs.arpa by CSNET-RELAY.ARPA id a012273; 19 Dec 85 15:01 EST Received: by hplabsd ; Thu, 19 Dec 85 12:00:38 pst Date: Thu, 19 Dec 85 10:02:56 pst From: Scott McGregor To: hplabs!hpcnou!dat%hplabs.arpa@csnet-relay.arpa, veeger!hpcnoe!hpfcla!hp-sdd!ken%hplabs.arpa@csnet-relay.arpa Subject: Re: Quiz - Parse this From line Cc: mcgregor@hplabs.arpa, veeger!hpcnoe!hpfcla!hplabs!Header-People%mit-mc.arpa@csnet-relay.arpa Hey, I can answer this one (sort of). **Warning** **Warning** **Warning** **Warning** **Warning** **Warning** ** ** ** Lengthy reply follows, Cognoscenti may wish to trash message now! ** ** ** **Warning** **Warning** **Warning** **Warning** **Warning** **Warning** First let me explain how it can be correctly parsed, and then go over the assumptions. There are three basic forms here: RFC 822 simple address: user@host RFC 822 explicit routing: @relay:user@host UUCP routing: host1!host2!...!user Lets build up the address from its parts: hpfcla!hpcnoe!veeger!hpcnou!dat is a legal UUCP routing address. Since RFC 822 doesn't describe any substructure for the "user" field, this can be treated as the "user" portion of a RFC 822 address (user@hplabsd). hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd At this point, we can go from an RFC 822 simple address to an explicit routing address where MIT-MC.ARPA is the relay. @MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Now, UUCP routing doesn't break up user parts either. So we can treat the above as the user part ofnoscvax!user. noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd This address will work as a TO address IF the following are true: - The machine originating the message only talks UUCP syntax. - noscvax can receive UUCP traffic from the machine sending the mail. - noscvax can send RFC822 mail to MIT-MC.ARPA - MIT-MC.ARPA either ONLY understands RFC-822, or MIT-MC.ARPA always gives RFC822 precedence over UUCP, or MIT-MC.ARPA talks to hplabsd using RFC822, but not to hpfcla using UUCP - hplabsd must be able to receive RFC822 mail form MIT-MC.ARPA - hplabsd must be able to send UUCP mail to hpfcla. - hpfcla must be able to send UUCP mail to hpcnoe. - hpcnoe must be able to send UUCP mail to veeger. - veeger must be able to send UUCP mail to hpcnou. - hpcnou must have a local user named dat. - no machine tries to short-cut or parse the "user" portion of the address when they have it. The interesting problem of course is what if one or more of the sites does support both RFC822 and UUCP syntax, without the explicit precedence rules. In particular, confusion can arise if: - MIT-MC.ARPA can talk RFC 822 to hplabsd, *and* UUCP to hpfcla. If the mail were accidentally UUCP mailed to hpfcla, then hpcnoe would be told to deliver to dat@hplabsd. If hpcnoe doesn't talk RFC 822 or doesn't talk to hplabsd then the mail would fail. If it does talk RFC 822 to hplabsd then the mail could be successfully delivered to "dat" there if that was a legal mail name there. Obviously the dat@hplabsd could be a different than the hpcnoe!dat. It shouldn't matter to noscvax that there are two at-signs in the address when it sees it, since they are in valid RFC 822 routing format, so there should be no conflict in whether to send to hplabsd with the rest being the user field vs. sending to MIT-MC.ARPA. By the rules of 822 it MUST be sent to MIT-MC.ARPA. Of course, if the mailer is not completely RFC 822 standard (and many are not) there could be a problem and the mail could be acccidentally sent to hplabsd instead. That of course would be disasterous, since the "user" field handed to hplabsd would be neither valid RFC 822 nor UUCP routing form. By the way, there is no indication of any BITNET syntax here at all. The remaining question is left for the user, namely, why is >From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Tue Dec 17 13:35:41 1985 in an UUCP ">From" line rather than in a RFC 822 "From:" line?: From: noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Scott McGregor {...!hplabs, ...!hpcea, ...!hpisla}!hpccc!mcgregor HP Corporate Computing Center  Received: from sri-spam.arpa by MC.LCS.MIT.EDU 19 Dec 85 15:28:59 EST Received: by sri-spam.arpa (5.4/4.16) id AA07164; Thu, 19 Dec 85 12:26:18 PST Date: Thu, 19 Dec 85 12:26:18 PST From: gds@sri-spam.ARPA (Greg Skinner) Message-Id: <8512192026.AA07164@sri-spam.arpa> To: header-people@mc Subject: Re: Quiz - Parse this From line >> From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Since Dave Taylor said that the message came from someone at hp-sdd, whic is not on the ARPA Internet as far as I know, and is not constructing 822 addresses, the From line can be read as such: hp-sdd <-- noscvax noscvax <-- mit-mc mit-mc <-- hplabsd hplabsd <-- hpcnou (though 4 hops) The reply works in this case because MIT-MC saw fit to do source routing, which is probably not a bad idea for mail coming from UUCP. If the message came from someone on a smart UUCP site that did 822 header munging, or was on both ARPA and UUCP, the rightmost @ would be favored, that's where the mess begins. It is possible for UUCP sites to address outside of UUCP using bang format. For example, the above address could be folded into: noscvax!hplabsd.arpa!....!hpcnou!dat Note I left MIT-MC out of the picture. MIT-MC just redistributed the message -- it did not originate it, and has no right to be included in reply text. I suspect possible munging of From or From: lines. However, if you insist on seeing MIT-MC in there, noscvax!mc.mit.lcs.edu!hplabs.arpa!....!hpcnou!dat Gateways/mail bridges *ought* to do the transformation between ! and 822 formats, that's what they're there for. One of the purposes of a gateway is to do protocol transformations on messages which is clearly what is needed here. No one in UUCP need know about @ or any other such nonsense -- as long as they know the qualified names of the sites they are sending to, they should be free to construct paths through the gateways with legal UUCP syntax, with the gateways doing the appropriate transformations. --gregbo  Received: from ucbarpa by MC.LCS.MIT.EDU 19 Dec 85 17:05:03 EST Received: by ucbarpa (5.31/1.7) id AA11462; Thu, 19 Dec 85 14:01:31 PST Date: Thu, 19 Dec 85 14:01:31 PST From: jordan@ucbarpa.BERKELEY.EDU (Jordan Hayes) Message-Id: <8512192201.AA11462@ucbarpa> To: header-people@mit-mc.arpa Subject: Re: Quiz - Parse this From line From: gds@sri-spam.ARPA (Greg Skinner) noscvax!hplabsd.arpa!....!hpcnou!dat Note I left MIT-MC out of the picture. MIT-MC just redistributed the message -- it did not originate it, and has no right to be included in reply text. I suspect possible munging of From or From: lines. However, if you insist on seeing MIT-MC in there, noscvax!mc.mit.lcs.edu!hplabs.arpa!....!hpcnou!dat Gregbo, You clearly have shown your parsing skills, but I think what is missing from this little point you made is the assumption that just because noscvax is on the Internet that it will know about the hp site (by the way, the original said "hplabsd" and you have "hplabsd.arpa" which does not exist ... "hplabsd" is a nick-name for "hplabs.arpa" -- no "d" in the .arpa-ized form. This is because the people running sendmail on that machine have the local name go out on mail, instead of the official name ... *sigh*) Anyways, what i wanted to say was that the reference to mit-mc was in fact necessary, and should indeed be included, unless you are absolutely sure you can get to the hp site by yourself. When an exploder is doing its work, it definately should put itself in the address. What if I on a machine "foo" that is on a local ether with mit-mc send to the list that redistributes to someone on a machine one UUCP hop away from noscvax ... should the return be noscvax!foo!jordan ...? or should it be noscvax!mit-mc.arpa!foo!jordan ...? Although it certainly may be true that noscvax could theoretically have an entry for foo in its /etc/hosts file (nosc, as you recall, is on MILNET and does not need to have resolvers running yet ...) and *could* make the smtp connection to foo itself, it should go back to mit-mc. Manual editing of headers from list exploders is a mail wizards hobby. Not for the children at home ... /jordan  Received: from hplabs.ARPA by MC.LCS.MIT.EDU 31 Dec 85 17:08:09 EST Received: by hplabs.ARPA ; Tue, 31 Dec 85 14:04:17 pst To: veeger!hpcnoe!hpfcla!hplabs!Header-People@MIT-MC.ARPA Date: Tue, 31 Dec 85 13:38:00 MST From: hpcnou!dat@hplabs.ARPA (Dave Taylor) Subject: Info on Organization wanted... Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.3b] Hello everyone! I've just been reading an article in Software News about electronic mail, and they mention a group called the "Electronic Mail Association". What I'd like to find it is: has anyone heard of the group? Are they worth joining? If so, how does one contact them (ie mailing address) More generally, does anyone know of a journal/magazine/?? that deals with the general electronic mail topics and issues?? Thanks!! -- Dave Taylor hpcnof!dat@HPLABS ps: Happy New Year y'all!  Received: from OFFICE-1.ARPA by MC.LCS.MIT.EDU 31 Dec 85 18:03:09 EST Date: 31 Dec 85 14:57 PST From: William Daul / McDonnell-Douglas / APD-ASD Subject: Re: Electronic Mail Association To: Header-People@MIT-MC Message-ID: I am getting my notes off of tape regarding the EMA meeting of Nov. 14-15. When I have them I will forward them to you. --Bi//  Received: from hplabs.ARPA by MC.LCS.MIT.EDU 1 Jan 86 16:22:35 EST Received: by hplabs.ARPA ; Wed, 1 Jan 86 13:18:34 pst To: veeger!hpcnoe!hpfcla!hplabs!Header-People@MIT-MC.ARPA Date: Wed, 1 Jan 86 13:21:55 MST From: hpcnou!dat@hplabs.ARPA (Dave Taylor) Subject: Another thing... Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.3b] Speaking of electronic mail (aren't we always?) I've always been annoyed by the plethora of blank lines appended to messages I receive through electronic mail. I usually have 5-10 lines blank at the end of the message!! What I suspect happens is that certain mailers (perhaps sendmail/rmail) add a trailing '\n' to the last line of the file when it copies it in from the phone line...over the course of a half-dozen hops it adds up to a considerable percentage of the total lines of a message!! Am I right? Has anyone else noticed this pesky problem?? Mailed without ANY trailing blank lines, from Dave Taylor  Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 8 Jan 86 11:35:01 EST Received: from (R21)DDATHD21.BITNET by WISCVM.WISC.EDU on 01/08/86 at 10:35:49 CST Received: from THDNET (V0.11) by DDATHD21.BITNET Date: 8 Jan 86 17:02:06 +0100 From: XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU (YD14@BR1.THDNET) Subject: Mailer problem To: header-people@mit-mc We at DDATHD21.BITNET received a mail with the following header: > Received: from columbia.edu by wiscvm.wisc.edu on 01/07/86 at 13:19:50 CST > Received: by columbia.edu (5.31/5.10) id AA06692; Tue, 7 Jan 86 14:18:14 EST > From: phri!pluto!warren@columbia.edu > Received: by phri.UUCP (4.12/4.7) > id AA23384; Tue, 7 Jan 86 13:57:29 est > Date: Tue, 7 Jan 86 13:57:29 est > Message-Id: <8601071857.AA23384@phri.UUCP> > To: XBR1YD22%DDATHD21.BITNET@wiscvm.wisc.edu > Subject: ( deleted due to data security ) > In-Reply-To: your article <902@caip.RUTGERS.EDU> The header is OK. But the mail was not addressed to "XBR1YD22" as specified in the RFC-header. The mail was delievered to "SEISMO!X". The ARPA <-> BITNET gateway at WISCVM truncates f.e. the user field "SEISMO!XBR1YD22" of "SEISMO!XBR1YD22@DDATHD21.BITNET" to "SEISMO!X" because only 8 characters are allowed in BITNET. Some mailer must have forgotten to remove the "SEISMO!" in the transport information. Whose mailer doesn't process such mails correctly? Reinhard Goeth Technical University of Darmstadt Fed. Rep. of Germany ARPA address: XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU BITNET address: XBR1YD14 @ DDATHD21 (no NETDATA please)  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 22 Jan 86 17:49:55 EST Date: Wed, 22 Jan 1986 17:48 EST From: "Karen R. Sollins" Message-ID: <[XX.LCS.MIT.EDU].SOLLINS.22-Jan-86 16:54:01> To: arpanet-bboards@MC.LCS.MIT.EDU, tcp-ip@SRI-NIC.ARPA, msggroup@BRL-AOS.ARPA, header-people@MC.LCS.MIT.EDU, namedroppers@SRI-NIC.ARPA, info-nets@OZ.AI.MIT.EDU Subject: IMPORTANT NOTICE ABOUT MC.LCS.MIT.EDU Many rumors have been spreading about MC.LCS.MIT.EDU. The following are the facts: * The maintenance contract on the machine will be discontinued at the end of March. * MIT will continue to support the mail and mailing list activities that have run historically on MC. After the end of March this service will reside on other hardware that will be named MC.LCS.MIT.EDU. * The KL-10 will not evaporate immediately, although its name and possibly internet address will change. Karen R. Sollins Director of Computing Resources MIT/Laboratory for Computer Scinece  Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 15 Feb 86 23:45:06 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2686350397650951@MIT-MULTICS.ARPA>; 15 Feb 1986 19:26:37 est Date: 15 Feb 86 18:07 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Subject: Loop control mechanisms in mailing lists Message-ID: <153372@QZCOM> Do mailing lists in Arpanet, Csnet, UUCP etc. usually contain loop control, and if so which kind of loop control. The most common methods for loop control are: (1) Do not send a message to a member of the mailing list, if that member is already in the TO, CC or BCC fields of the incoming message, or possibly also some other field like SENDER, FROM? (2) Save at least the Message-ID-s of the message passing the list, and do not allow a message with the same ID to pass the list twice. (3) Organize the lists and sublists so that no loop occurs in the structure. (4) Expand all lists and sublists at one time at the original sending of the message. QZCOM at present uses method (1) and (2). I know that UUCP/USENET uses method (2). A problem with method (1) is that the name of the same recipient can be given in many alias forms, and this will make it difficult to understand that the name in the list and the name in the message is the same. A problem with method (2) is that all messages do not have any Message-ID-s. Because of this, QZCOM always adds Message-ID-s to messages sent to us and forwarded again from us to the nets. At present we construct these Message-ID-s as <...@QZCOM>, but a neater way would be to construct them from a checksum of the from, date and contents, and then present them as <...@CHECKSUM> as I have proposed in a message about a year ago. I would be very interested to know which methods of loop controls other mailing lists apply, and their experience with them.  Received: from Xerox.COM by MC.LCS.MIT.EDU 16 Feb 86 04:02:34 EST Received: from Salvador.ms by ArpaGateway.ms ; 16 FEB 86 01:00:00 PST Sender: "Donald W. Gillies.osbunorth"@Xerox.COM Date: 15 Feb 86 23:54:18 PST (Saturday) Subject: Re: Subject: Loop control mechanisms in mailing lists From: gillies.osbunorth@Xerox.COM To: Jacob_Palme_QZ%QZCOM.Mailnet@MIT-MULTICS.ARPA, header-people@MC.LCS.MIT.EDU In-Reply-to: SenderNameTooLong%MC.LCS.MIT:EDU's message of 15 Feb 86 20:57:54 PST (Saturday) Message-ID: <860216-010000-3354@Xerox> another method of loop control used by some of our mail gateways: (5) Each host physically appends a [post]mark to the message that identifies it as "A message already acted on here". Refuse to process [kill] the message if it shows up later at the same host with one of your [post]marks still in tact. This is a good way for a gateway to prevent looping. However, it won't work if you're sending mail through a dumb gateway that strips off this information to accomplish format conversion. Don Gillies  Received: from SRI-IU.ARPA by MC.LCS.MIT.EDU 17 Feb 86 01:57:35 EST Date: Sun 16 Feb 86 23:01:18-PST From: Peter Karp Subject: Re: Subject: Loop control mechanisms in mailing lists To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people@MC.LCS.MIT.EDU Message-ID: In-Reply-To: Message from " Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA" of 15 Feb 86 18:07 +0100 I believe that Unix Sendmail counts "Received:" lines in message headers, assuming that it has detected a mail loop if this number gets past some threshold. Simple but effective... Peter -------  Received: from USC-ISIB.ARPA by MC.LCS.MIT.EDU 17 Feb 86 13:49:46 EST Date: 17 Feb 1986 10:47:15 PST From: POSTEL@USC-ISIB.ARPA Subject: loop detection by hop count To: header-people@MC.LCS.MIT.EDU I think that loop detection by hop count is a bad idea. The problem is that it will work for awhile, until we have forgotten all about it, then some messages that ought to go through won't. The world will get bigger, and what was once a reasonable choice for "max hops" will be smaller than the diameter of the mail world. --jon. -------  Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 17 Feb 86 20:35:10 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2686526283721442@MIT-MULTICS.ARPA>; 17 Feb 1986 20:18:03 est Date: 17 Feb 86 21:25 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: header-people@MC.LCS.MIT.EDU, gillies.osbunorth@XEROX.COM Cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: Subject: Loop control mechanisms in mailing lists Message-ID: <153766@QZCOM> In-Reply-To: <860216-010000-3354@Xerox> Your solution of appending a postmark on the message is a variant of my method (2). This method should have been formulated in more general terms, to append some kind of trace information on the message. I prefer to put the postmark in the TO field for the following reasons: (a) What you want to stop is not the same message looping back to the same host. This, in fact, can be perfectly legal in some cases. What you want to stop is the message looping back to the same mailing list. (b) The TO: field is one of the safest field from being munged by header-munging systems. Best of course would be to have an additional, special field in the headers intended for this kind of trace information - provided that all systems accept and are willing to handle this trace field in the proper manner.  Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 17 Feb 86 20:35:10 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2686526283721442@MIT-MULTICS.ARPA>; 17 Feb 1986 20:18:03 est Date: 17 Feb 86 21:25 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: header-people@MC.LCS.MIT.EDU, gillies.osbunorth@XEROX.COM Cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: Subject: Loop control mechanisms in mailing lists Message-ID: <153766@QZCOM> In-Reply-To: <860216-010000-3354@Xerox> Your solution of appending a postmark on the message is a variant of my method (2). This method should have been formulated in more general terms, to append some kind of trace information on the message. I prefer to put the postmark in the TO field for the following reasons: (a) What you want to stop is not the same message looping back to the same host. This, in fact, can be perfectly legal in some cases. What you want to stop is the message looping back to the same mailing list. (b) The TO: field is one of the safest field from being munged by header-munging systems. Best of course would be to have an additional, special field in the headers intended for this kind of trace information - provided that all systems accept and are willing to handle this trace field in the proper manner.  Received: from dione.rice.edu by MC.LCS.MIT.EDU 17 Feb 86 22:17:23 EST Received: by dione.rice.edu (AA21250); Mon, 17 Feb 86 21:10:19 CST Date: Mon, 17 Feb 86 20:48:25 CST From: Paul Milazzo Subject: Re: loop detection by hop count To: POSTEL@USC-ISIB.ARPA Cc: header-people@MC.LCS.MIT.EDU Message-Id: <1986.02.17.20.48.26.610.20870@dione.rice.edu> In-Reply-To: <8602171916.AA13887@tethys> Jon Postel writes: "The problem is that [loop detection by hop count] will work for awhile, until we have forgotten all about it, then some messages that ought to go through won't." Well, I've seen some amazingly long UUCP paths recently, and that they will get longer still seems difficult to contest. However, the same objection can be made to dropping packets with TTL <= 0, and the interim solution of increasing the hop count threshold can be pushed rather a long way. More importantly, however, the original topic was loop detection in *mailing lists*, and there the hop count mechanism is completely inappropriate. With a hop count of 30 and a queue interval of 10 minutes, a loop in a piece of personal mail will be broken within five hours. The same is true of a mailing list, save for a small side effect: as many as 30 copies of the message might be mailed to thousands of list recipients. In short, since even one duplicate of a mailing list message represents an enormous waste of resources, distribution list software should employ algorithms which can detect a loop on the first iteration. Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX Domain: milazzo@rice.EDU BITNET: milazzo@ricenet, milazzo@ricecsvm UUCP: {cbosgd,convex,hp-pcd,sun,ut-sally,waltz}!rice!milazzo  Received: from ucbarpa.berkeley.edu by MC.LCS.MIT.EDU 18 Feb 86 02:27:07 EST Received: by ucbarpa.berkeley.edu (5.45/1.8) id AA02302; Mon, 17 Feb 86 23:24:42 PST Date: Mon, 17 Feb 86 23:24:42 PST From: jordan@ucbarpa.berkeley.edu (Jordan Hayes) Message-Id: <8602180724.AA02302@ucbarpa.berkeley.edu> To: header-people@mc.lcs.mit.edu Subject: Re: loop detection I'm all for exploders that remove their real From: address and make it a Really-From: header, so replying goes to the list and not the sender ... then, the exploder has to look for itself in the From: field and forward to the owner ... is this so hard or am I kidding myself? /jordan  Received: from Dewey.UDEL.EDU by MC.LCS.MIT.EDU 18 Feb 86 09:29:52 EST Received: from localhost by Dewey.UDEL.EDU id a029373; 18 Feb 86 9:18 EST Reply-To: header-people@mc.lcs.mit.EDU To: Jordan Hayes cc: header-people@mc.lcs.mit.EDU Subject: Re: loop detection In-Reply-To: Your message of Mon, 17 Feb 86 23:24:42 PST. <8602180724.AA02302@ucbarpa.berkeley.edu> Date: Tue, 18 Feb 86 09:18:48 -0500 Message-ID: <29371.509120328@dewey> From: James M Galvin > I'm all for exploders that remove their real From: address and make it > a Really-From: header, so replying goes to the list and not the > sender I don't agree. I'm all for mail systems that require a From: field and reject mail without it. Actually, what you are suggesting is available internally from MMDF. BRL wrote a list processor which changes the From: field as it is known to the MTA's to "list-request". This means the actual message itself is not altered, but as the message is passed from host to host, each host is told that the From: address is "list-request". Now, if we could teach the remaining mail systems to keep this information around instead of looking in the message for it the world would be a better place. The next step is to teach mail user agents about a "Reply-To:" field. If they would let you insert one then individuals could specify to keep the discussion on the mailing list, not in his/her personal mailbox. Note mine. Time to be quiet. I am beginning to sound religious. Jim  Received: from ucbarpa.berkeley.edu by MC.LCS.MIT.EDU 18 Feb 86 13:19:48 EST Received: by ucbarpa.berkeley.edu (5.45/1.8) id AA09320; Tue, 18 Feb 86 10:17:25 PST Date: Tue, 18 Feb 86 10:17:25 PST From: jordan@ucbarpa.berkeley.edu (Jordan Hayes) Message-Id: <8602181817.AA09320@ucbarpa.berkeley.edu> To: header-people@mc.lcs.mit.edu Subject: Re: loop detection From galvin@dewey.udel.EDU Tue Feb 18 06:31:43 1986 The next step is to teach mail user agents about a "Reply-To:" field. If they would let you insert one then individuals could specify to keep the discussion on the mailing list, not in his/her personal mailbox. Note mine. Also note that you not only sent the list a copy, but me a personal one as well, even though I'm on the list. Not a big deal on the internet, but a very big deal in csnet/phonenet or UUCP world (even mailnet). Hmmm ... you're correct about needing smarter user agents, but I think that the concept of "mailing list" means that if you have something to add, you should add to it, and not reply directly. So, making the exploder claim responsibility and adding a "Reply-To:" field makes dumb UAs send replys to the list, which is what it should do. The problem you run into is error detection. If there is an error somewhere down the line, mailer-daemons "return to sender" which now is the entire list. This is bad. So, the exploder need only check for itself in the From: field, and forward to the list maintainer. I sorta like the idea that rn has about having an {r,R} reply to the sender, and a {f,F} reply to the list. Not both. /jordan  Received: from Cs by MC.LCS.MIT.EDU 18 Feb 86 15:39:42 EST Received: from geca.cardiff.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a000780; 18 Feb 86 15:23 GMT To: Peter Karp <@cs.ucl.ac.uk,@cs.ucl.ac.uk:PKARP@sri-iu.arpa> From: Ralph Martin (on ICF GEC 4090 at Cardiff) Date: Tue, 18 Feb 86 14:10 GMT In-reply-to: Message-Id: <18 FEB 1986 14:10:46 XACF03@CFGA> Subject: Re: Subject: Loop control mechanisms in mailing lists Cc: header-people <@cs.ucl.ac.uk,@cs.ucl.ac.uk:header-people@mc.lcs.mit.edu> Counting received lines is simple, and STUPID. How many hops do you think your message took to reach me here in Wales ? Well, perhaps it didn't take quite that many, but I certainly wouldn't like to rely on that !  Received: from GW.UMICH.EDU by MC.LCS.MIT.EDU 18 Feb 86 15:53:24 EST Date: 18-Feb-86 20:47:40-UT From: hwb@gw.umich.edu Subject: Sun header processing (sendmail). To: header-people@mit-mc.arpa cc: hwb@GW.UMICH.EDU Hi: I have some problems in getting a Sun(3) sendmail configuration to work with domain names. It does not necessarely need to resolve the names via domain requests, just from hosts.txt would be fine for now. Does any one have a working sendmail.(main.)cf file which would work and which I could copy? -- Hans-Werner Braun -------  Received: from sri-spam.arpa by MC.LCS.MIT.EDU 19 Feb 86 03:08:10 EST Received: by sri-spam.arpa (5.4/4.16) id AA08869; Wed, 19 Feb 86 00:07:48 PST Date: Wed, 19 Feb 86 00:07:48 PST From: gds@sri-spam.ARPA (Greg Skinner) Message-Id: <8602190807.AA08869@sri-spam.arpa> To: header-people@mit-mc.ARPA Subject: loop control Hello everyone. Remember this event? > From @MIT-MC.ARPA:mcvax!ace!teus@seismo.CSS.GOV Wed Dec 11 01:37:39 1985 > Received: from MIT-MC.ARPA by sri-spam.arpa (5.4/4.16) > id AA01923; Wed, 11 Dec 85 01:37:39 PST > Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:28:49 EST > Return-Path: ... > Message-Id: <8512101018.AA16148@sunrel1> This was the solution I previously proposed. > It might be the case that we also want to modify our mailers so that > upon receipt and full delivery of a message with a given Message-ID, all > subsequent messages received with that same Message-Id are dropped on > the floor (no need to advise anybody automagically of duplicates, since > we don't want to see exponential growth of looping mail :-). I don't > know if this is an MHS requirement or not but it is essential in a > conferencing system (where the same messsage might come from different > nodes in a network) and would relieve us of seeing duplicates. The only > problem is that not all mailers generate Message-IDs at the source of > the message, plus a redistributor may replace (or add) its own > Message-ID. We should limit the number of Message-IDs to one per > message. Given the growing number of "conferences" (actually Usenet groups) which are fed into the ARPA Internet as mailing lists, I think we should honor the Message-ID's generated at their source and refuse to process anything arriving with a Message-ID that has previously been processed. Although Usenet lists arrive in the ARPA Internet through single points of entry (commonly known as "gateways"), the increasing load to these machines may cause them to use multiple entry points. This increases the possibility of a loop if the gateways have common forwarding entries. Also, in our current mail environment, mail looping is caused for other, more obscure reasons. I've never looked into the part of sendmail which handles Message-IDs, but I imagine it wouldn't be too difficult to modify sendmail to refuse to process a message with an ID which has already been processed. There is a fundamental difference between Mailnet, Usenet and the ARPA mailing lists, in that the ARPA lists are not currently conferenced. I was wondering if anyone here is on the multimedia conferencing project, will there be standards set for converting our mailing lists into conferences, so we can read the mail as a conference? Also, the NNTP work can help solve looping problems caused by generation of duplicate postings. --gregbo  Received: from CSNET-SH.ARPA by MC.LCS.MIT.EDU 19 Feb 86 23:47:44 EST To: Greg Skinner cc: header-people@mc.lcs.mit.edu, cic@CSNET-SH.ARPA Subject: Re: loop control In-reply-to: Message from Greg Skinner posted Wed, 19 Feb 86 00:07:48 PST. Date: Wed, 19 Feb 86 23:42:37 -0500 From: Dennis Rockwell From: Greg Skinner Date: Wed, 19 Feb 86 00:07:48 PST Subject: loop control [ ... ] I think we should honor the Message-ID's generated at their source and refuse to process anything arriving with a Message-ID that has previously been processed. For end-delivery duplicate deletion, that would work OK, except in the presence of resenders (not forwarders) that add annotations. However, for loop detection and breaking, the stroke is too broad; some simple cases break down. Consider our case (RELAY.CS.NET, admittedly not your typical host): we see a submission go by for header-people from one of our PhoneNet sites with message-id 1234.foo@pudunk.edu. You scheme would have us drop the posting of that message to everybody behind relay.cs.net! That doesn't seem quite right, somehow. With more local hosts being hidden behind mail relays (when the MX namesolver implementations percolate out), this sort of situation will be much more common than it is now. It's already bad for relay.cs.net, because we'll accept any mail message that we think we can deliver, so some sites on the Internet use us as a staging host to get to hard-to-reach sites. The list exploder can't change the message-id, or direct recipients wouldn't be able to filter out duplicates. I'm all for loop control, but more information needs to be processed to determine whether there's been a loop. We use a very generous hop count, and we would like something that would catch loops sooner. Possibly a repeated pattern or sequence of received postmarks would do it? Unfortunately, that requires that at least two mailers in the loop insert postmarks (if only one mailer does, it reduces to hop count, which is probably a good last-ditch scheme) which *most* mailers do. Of course, any mailer trying to do loop detection should add its own postmark before checking for a loop! I don't think that simply checking for our own postmark would work, either; consider a mail message being resent (as opposed to forwarded) to multiple people or mailing lists by multiple senders; all messages would have the original message-id. What heuristics do *you* use when looking at a message to detect a loop? Can you write code that executes in reasonable time (specifically, that you would be willing to add to the incoming message processing) to implement it? This isn't the AI Digest, but... Dennis Rockwell CSNET Technical Staff  Received: from USC-ECL.ARPA by MC.LCS.MIT.EDU 20 Feb 86 05:25:30 EST Received: from ECLD by ECLA with DECnet; Thu 20 Feb 86 02:24:23-PST Date: Thu 20 Feb 86 02:24:17-PST From: Bob Larson Subject: Re: loop control To: dennis@CSNET-SH.ARPA cc: gds@SRI-SPAM.ARPA, header-people@MC.LCS.MIT.EDU, cic@CSNET-SH.ARPA In-Reply-To: Message from "Dennis Rockwell " of Wed 19 Feb 86 21:17:55-PST Message-ID: <12184828912.50.BLARSON@USC-ECLD.Internet> It seems to me that the best idea is to have each mailing list keep a list of message id's that have been sent to the list, and avoid resending a message with a duplicate id. (Preferably complaining to the list maintainer.) This of course does not work if something deletes/changes the message id, so should be backed up with another form of loop control. (P.S: I just added mailing lists to our local prime mailer-- currently without any form of loop control. I should probably be planning for the future, especially since we do have a (flaky) link to the outside world...) Bob Larson Blarson@Usc-Ecl.Arpa sdcrdcf!oberon!blarson -------  Received: from ucbvax.berkeley.edu by MC.LCS.MIT.EDU 20 Feb 86 11:16:10 EST Received: by ucbvax.berkeley.edu (5.45/1.9) id AA18480; Thu, 20 Feb 86 07:54:49 PST Received: from DBNGMD21.BITNET by ucbjade.Berkeley.Edu (4.19/4.41.3) id AA21631; Thu, 20 Feb 86 07:54:39 pst Message-Id: <8602201554.AA21631@ucbjade.Berkeley.Edu> Date: Thu, 20 Feb 86 16:51 CET From: Peter Sylvester +49 228 303245 Subject: Re: loop control To: dennis@csnet-sh.arpa Cc: gds@sri-spam.arpa, header-people@mc.lcs.mit.edu, cic@csnet-sh.arpa To: Bob Larson Bob: How long do You want to keep ids of old messages in Your system? One year? Ten years? How much disk space do You have? Although the idea is correct it is not praticable in a large network environment I guess. Our local mailer has mailing lists. When messages arrive from the outside, it knows that he must not use outside addresses. This avoids loops in that special case. The situation we are talking about is that we have cascades of lists with one list pointing to the other or a loop in a list. We should try to avoid such situations: First, we should distinguish between general redistribution lists i.e. with lists that have a "global" target. Those lists should not be placed into other global lists. The second type are more local lists that cover a local node or a subdomain. Those lists can be contained in global lists and can contain global list when the following procedure is used: The list processor must have a "responsibility list", i.e a list or an algorithm to determine what members of the target are to be selected. A special case is a "local" redistribution list. where message are delivered to all local members when the message comes from outside. When the message comes from a local user the message can be delivered to all users or to remote users only when it is known that one of the remote users is a global lists containing this list. Even if that is not done, the local users will get about two copies (perhaps some more if more lists are involved.) In addition it would be helpful to have a centralized data base or server that contains the names of ALL global lists. Sometimes I get messages from anywhere that tells: Now we a have new list here at the "white house" where You can discuss technical things about SDI or whatever. The general problem is that normal users will have those information earlier than a postmaster. Then it happens that a user quits his job etc. and the postmaster has the poor job to find out the source of the distribution, i.e all subscriptions. "local" redistribution lists must not be contained in that data base. only global lists, I guess there are current about 200 global list? Peter Sylvester GMD Bonn  Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 21 Feb 86 10:46:36 EST Received: from (MAILER)CUNYVM.BITNET by WISCVM.WISC.EDU on 02/21/86 at 09:44:46 CST Received: by CUNYVM (Mailer X1.23) id 2386; Fri, 21 Feb 86 10:41:31 EST Date: Fri, 21 Feb 1986 10:36 EST From: Henry Nussbacher Subject: Stopping loops To: This may not be the best method but it works for me today and for Annette Deschon who manages the gateways that respond to mail for Telemai/Mcimail/ Dialcom. We scan the From: line for one of the following character strings: MAILER SMTPUSER DAEMON DATABASE POSTMAN POSTMAST MMDF SUBSYSTEM If the From field contains one of these character strings the mail is placed in a holding area and is not processed until there is some human intervention. I would prefer to see a special RFC header that indicates that the mail being received was created by a program and not by a human but I guess that will never happen. In the meantime, this works for Database@Bitnic.Bitnet and has stopped countless loops between networks and within Bitnet. Hank  Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 21 Feb 86 17:33:35 EST Date: Fri 21 Feb 86 14:17:58-PST From: Peter Karp Subject: Minor correction To: header-people@MC.LCS.MIT.EDU Reply-To: Peter D. Karp Message-ID: <12185220976.41.KARP@SUMEX-AIM.ARPA> I made a slight error in my previous message in refering to ancestors and descendants of packets interchangeably. A loop occurs when a packet that is a (proper or not) descendant of a packet you have seen before arrives and is destined for the same recipients. A packet which is a proper ancestor of a packet you've seen before may or may not have looped (one of the packets in my example falls under this category). Peter -------  Received: from DEEP-THOUGHT.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 FEB 86 19:12:02 EST Date: Fri 21 Feb 86 19:11:46-EST From: Robert Lenoil Subject: Re: FYI To: info-nets@OZ.AI.MIT.EDU cc: header-people@MC.LCS.MIT.EDU Message-ID: <12185241694.19.LENOIL@DEEP-THOUGHT.MIT.EDU> I had heard that there was a field for bouncing messages, but that it is no longer used because other networks do bad things with that address. Personally, I'd like to see a "Errors-To:" field become a standard on the internet. Another possibility would be a field that simply says don't bounce at all; sort of the mail equivalent of a datagram, i.e. an unreliable mail message. Such a field would look like "Don't-Return:", or perhaps an "Errors-To:" field with a blank address. BTW, the appropriate place for this discussion is probably header-people@mc. I've remailed the previous articles in this discussion there, and suggest that interested persons start reading header-people - they talk about just this kind of stuff. Robert Lenoil -------  Received: from SRI-IU.ARPA by MC.LCS.MIT.EDU 22 Feb 86 14:19:55 EST Date: Fri 21 Feb 86 11:47:35-PST From: Peter Karp Subject: Mail looping To: header-people@MC.LCS.MIT.EDU Cc: pkarp@SRI-IU.ARPA Message-ID: I believe I have at least a good theoretical understanding of how to prevent mail loops. In the previous messages on this topic it hasn't been clear to me how one could theoretically prevent mail loops, or if this is even possible. I believe I do know how to do it in theory; if you all buy this argument then we can talk about the implementation later. I apologize if this is obvious to everyone; it wasn't obvious to me and on re-consideration of the messages I've seen it still doesn't appear obvious. Consider the following example. A message originates on Host-A, and is set to a mailing list called "LIST@Host-B". One element of LIST on Host-B is the address SUB-LIST-1@Host-C. An element of SUB-LIST-1 on Host-C is SUB-LIST-2@Host-B, from which it gets distributed to various individuals. Let us postulate that the original message was also set to "USER@Host-B", and that "USER@Host-B" is also a member of SUB-LIST-1. Thus, "USER@Host-B" should receive two copies of the message: one direct from Host-A, and one with return path: @Host-C,@Host-B:Originator@Host-A. Notice that the "same message" gets routed through Host-B several times, and that it would be incorrect for Host-B to think it has detected a loop simply based on the Message-ID created by the message originator (this has been pointed out before). Also note that the "same message" gets sent to the same recipient several times (USER@Host-B), and it would also be incorrect for Host-B to suppress the duplicate simply because it sees two messages with the same Message-ID going to the same recipient. Both of these conditions look like loops but are not. So, what's the solution? Consider an abstraction. Imagine that a mail message is simply a packet getting switched between the nodes of a network. Mail packets are special in that any one packet can be duplicated into several other packets at other nodes as mailing lists are expanded. These child packets then go their own way in the network. There are two strcutures of interest here. One is the path a given packet follows through the network. The other is the mailing-list-based packet-synthesis tree which shows how one initial message packet gets duplicated into a whole swarm of child packets which eventually get either dropped on the floor or land in someone's mailbox. A loop condition occurs when a packet P with the following properties has arrived at a network node: a) either that same packet or one of its ancestors in the packet- synthesis tree, P', has been to that node before. b) Packet P and packet P' were both addressed to the same recipient. How can a host detect a loop condition? Simple: when it relays a packet it puts a mark on that packet which it will recognize if that packet or any of its descendants ever arrives at that host again. It also must record what recipients the packet was destined for, and check all incoming packets to determine if it has seen them or an ancestor of theirs before, addressed to the same recipient(s). So again, if this looks right we can start worrying about implementation. Peter -------  Received: from UCI.EDU by MC.LCS.MIT.EDU 23 Feb 86 07:00:27 EST Received: from localhost by UCI.EDU id a004810; 22 Feb 86 15:39 PST To: header-people@mc.lcs.mit.edu Subject: Re: Mail looping In-reply-to: Peter Karp message of Fri 21 Feb 86. Date: Sat, 22 Feb 86 15:39:26 -0800 Message-ID: <4807.509499566@uci.edu> From: Einar Stefferud Long ago in a discussion group not too far away, we discussed one aspect of this "distribution" problem that I think is relevant in this current looping discussion. The original topic was failure return addresses, and hinged on the question of what is legit for a distributor to do to a message it is distributing to a list. Can it ethically and morally change the From: Sender: Reply-to: or Return-Path: fields to divert mail the might result from downstream events like failure, or reply, or whatever. Also, is it a violation of the sanctity of the seal for a LIST DISTRIBUTOR to look inside the header in the first place. As I recall the discussion, it was concluded that a LIST DISTRIBUTOR is in fact operating as a "USER AGENT" and not as a "MAIL TRANSFER AGENT" so it is fine for the list distributor to do anything its administrator wants it to do to the content of any distributed item. If there is any kind of contract between the administrator and the subscribers, it is that agreement that governs the administrator's actions. With this in mind, it seems simple enough to me for any LIST DISTRIBUTOR to put a special header field (like DIST-ID: ) which is can look for in any incoming item. If it sees such a thing it should shunt it aside for manual inspection, and this will prevent loops through that LIST DISTRIBUTOR, as long as no intervening transfer agants or user agents or LIST DISTRIBUTORS, et al, remove or change the magic in any DIST-ID: fields. This does not take care of other kinds of loops, but it would simply take care of LIST DISTRIBUTOR LOOPS. For those of you who are wondering what was decided about the earlier failure return question, we simply decided to have the list distributor insert a new "RETURN-PATH: list-request@host" field in place of the original RETURN-PATH field, without deciding what to do with the old one. ---- Stef  Received: from ucbvax.berkeley.edu by MC.LCS.MIT.EDU 26 Feb 86 01:21:51 EST Received: by ucbvax.berkeley.edu (5.45/1.9) id AA12821; Tue, 25 Feb 86 22:21:04 PST Received: by ucbjade.Berkeley.Edu (4.19/4.41.3) id AA24895; Tue, 25 Feb 86 21:41:33 pst Date: Tue, 25 Feb 86 21:41:33 pst From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO) Message-Id: <8602260541.AA24895@ucbjade.Berkeley.Edu> To: header-people@mc.lcs.mit.edu Subject: Re: Mail looping Handling of mailing list error messages (Reply-to, Errors-to, etc) was discussed at length in this mailing list group about a year or two ago. The final conclusion was that "mailing list exploders" should generate a new message (ie. with a new Message-ID). (The "Errors-to" header was also disapproved if I remember rightly.) In reply to: Date: Fri 21 Feb 86 11:47:35-PST From: Peter Karp Subject: Mail looping To: header-people@mc.lcs.mit.edu Cc: pkarp@sri-iu.arpa Message-Id: ... Thus, "USER@Host-B" should receive two copies of the message: one direct from Host-A, and one with return path: @Host-C,@Host-B:Originator@Host-A. The first message would have the original Message-ID and the new message would have a new Message-ID generated by the exploder. Notice that the "same message" gets routed through Host-B several times, and that it would be incorrect for Host-B to think it has detected a loop simply based on the Message-ID created by the message originator (this has been pointed out before). Also note that the "same message" gets sent to the same recipient several times (USER@Host-B), and it would also be incorrect for Host-B to suppress the duplicate simply because it sees two messages with the same Message-ID going to the same recipient. Both of these conditions look like loops but are not. To avoid this problem, I suggest that each SUB-LIST exploder also replace the Message-ID with a new Message-ID. (ie. Mailing list exploders at any level should generate a new message.) The mail exploder should also change the envelope and/or mail heading so that error messages are returned to that exploder's administrator. (ie. to the lowest level exploder). There is a basic assumption about mailing lists that may be wrong. Can we assume that list mail goes from the root to all branches without going through the same node twice? Bill Wells netinfo%ucbjade@Berkeley.EDU  Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 26 Feb 86 04:22:01 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 26 Feb 86 01:06:19-PST Date: Wed 26 Feb 86 00:12:44-PST From: Mark Crispin Subject: Re: Mail looping To: netinfo%ucbjade@UCBVAX.BERKELEY.EDU cc: header-people@MC.LCS.MIT.EDU In-Reply-To: <8602260541.AA24895@ucbjade.Berkeley.Edu> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12186377826.8.MRC@PANDA> Bill Wells - You cannot assume that list mail goes from the root to all branches without going through the same node twice. This is especially true with mailers which do not differentiate between "mail exploders", "mail aliases", and "mail forwardings". Add to this swamp the large numbers of individuals who regularly use multiple hosts (I have two primary, two secondary, and dozens of tertiary Internet hosts in addition to my DEC-20 at home) and who have "classed mailboxes" and forwardings all over the place and it isn't hard to see how you can lose big. I'd argue that if you really care about loop abatement you will use what SMTP provides to help you out from this -- the EXPN command. That is, the sender fully resolves the destination list. It isn't hard to detect loops when you do this. -------  Received: from su-pescadero.arpa by MC.LCS.MIT.EDU 26 Feb 86 12:26:17 EST Received: by su-pescadero.arpa with Sendmail; Wed, 26 Feb 86 09:25:43 pst Date: Wed, 26 Feb 86 09:25:43 pst From: Joseph I. Pallas Subject: Re: Mail looping To: MRC%PANDA@sumex-aim.ARPA, netinfo%ucbjade@UCBVAX.BERKELEY.EDU Cc: header-people@MC.LCS.MIT.EDU Mark, you of all people should know just how futile it would be to attempt to resolve the entire destination list of a message using EXPN. Aside from the fact that some of the destinations may go outside of SMTP, there's no guarantee that EXPN will return meaningful information. Several implementations don't support it, and most that do don't deal correctly with naming-domain boundary crossings (including yours). joe  Received: from LOCUS.UCLA.EDU by MC.LCS.MIT.EDU 26 Feb 86 14:13:43 EST Date: Wed, 26 Feb 86 10:57:10 PST From: Rich Wales To: HEADER-PEOPLE@MC.LCS.MIT.EDU Subject: Non-domain host names in mail Message-ID: <509828230-13014-wales@DIANA.LOCUS.UCLA.EDU> [NOTE: I had planned to send this message out several weeks ago, but a mail problem at MC.LCS.MIT.EDU -- which apparently put the Header-People mailing list out of commission for a while -- got in the way. Apologies for any of the following information which is out of date. -- RBW] Here's yet another chapter in the ongoing saga of "bad" and "semi-bad" host names in mail. This message has to do with "non-domain-style" host names (i.e., nicknames which appear in the NIC host name table, but which do not contain periods). A subsequent message will discuss host names which do not appear in the NIC table at all. The following non-domain-style host names were observed in connection with mail received by LOCUS.UCLA.EDU between 6 December 1985 and 15 Jan- uary 1986. Most of these names could be converted into valid (i.e., defined) domain-style names by adding ".ARPA" to them. Those names which do not occur with the ".ARPA" suffix in the NIC host name table are indicated by asterisks. Since non-domain-style host names are NEVER going to be listed in the domain data base, I would strongly encourage the hosts listed below to stop using them NOW and use the correct domain-style names instead. ************************************************************************ * I would also again urge the NIC to set a deadline for phasing * * all non-domain-style names out of the host name table. (Note * * that I am NOT advocating that ALL nicknames be removed -- only * * that nicknames without periods be removed.) No matter what * * anyone may say about transition to the domain data base -- and * * no matter what anyone may say about only using a host's * * "official" name -- the fact remains that as long as these names * * appear in the table, people are going to continue to use them. * ************************************************************************ Also, I would suggest again to those hosts which are using the domain data base that -- when they see a non-domain-style nickname in a mail address -- they should try adding ".ARPA" to the name and look up the result in the data base before giving up. This should be thought of as a temporary "hack", to get around the unfortunate fact that it is likely to be some time before non-domain-style nicknames have been utterly and completely eradicated from our midst. Before anyone asks: I am NOT going to try to send individual letters to system adminstrators about this issue this time. The last time I did this, I got very few responses. Most people seemed to simply ignore me (witness the size of the lists below!). One person (who shall remain nameless unless he chooses to make himself known) even said he planned to keep on using his non-domain-style nickname, because he liked to make waves! Predictably, said host is still on my list, and the wizard in- volved is no doubt very proud of this fact. Sigh. My apologies for any typos which might have made it into this list. Also, my apologies if any hosts listed below have since fixed things. Again, host names indicated below with (*) do not have ".ARPA" counter- parts; an attempt (as described above) to make sense of these names by tacking ".ARPA" onto them would fail. (1) Non-domain-style host names used in return addresses of mail: Name used Domain-style name ================================= AERO (*) AEROSPACE.ARPA AIDS-UNIX AIDS-UNIX.ARPA BBNCCM BBNCCM.ARPA, CCM.BBN.COM BBNCCP BBNCCP.ARPA CIT-750 CIT-750.ARPA, CIT-750.CALTECH.EDU FORD-WDL1 FORD-WDL1.ARPA GLACIER (*) SU-GLACIER.ARPA, GLACIER.STANFORD.EDU GSWD-VMS GSWD-VMS.ARPA HPLABSD (*) HPLABS.ARPA LASSPVAX LASSPVAX.ARPA, LASSPVAX.TN.CORNELL.EDU MEDEA (*) MEDEA.BERKELEY.EDU NRL-AIC NRL-AIC.ARPA PARCVAX PARCVAX.ARPA, PARCVAX.XEROX.COM SRI-SPAM SRI-SPAM.ARPA SRI-UNIX SRI-UNIX.ARPA SU-PSYCH SU-PSYCH.ARPA, PSYCH.STANFORD.EDU TOR (*) NTA-VAX.ARPA UMN-UCC-VA UMN-UCC-VA.ARPA YALE-VENUS YALE-VENUS.ARPA (2) Non-domain-style host names used in SMTP HELO commands: Name used Address Domain-style name =============================================== ALMSA-1 26.1.0.61 ALMSA-1.ARPA ATHENA (*) 18.58.0.1 MIT-ATHENA.ARPA, ATHENA.MIT.EDU BBNCCM 8.7.0.14 BBNCCM.ARPA, CCM.BBN.COM BBNCCP 8.2.0.4 BBNCCP.ARPA FORD-WDL1 128.5.32.1 FORD-WDL1.ARPA GLACIER (*) 36.40.0.205 SU-GLACIER.ARPA, GLACIER.STANFORD.EDU HPLABSD 192.5.58.10 HPLABS.ARPA MEDEA (*) 128.32.0.15 UCBMEDEA.ARPA, MEDEA.BERKELEY.EDU MEDIA-LAB 18.85.0.2 MEDIA-LAB.ARPA, MEDIA-LAB.MIT.EDU MIT-EDDIE 18.62.0.6 MIT-EDDIE.ARPA, EDDIE.MIT.EDU NRL-AIC 26.1.0.8 NRL-AIC.ARPA NRL-CSS 192.5.17.112 NRL-CSS.ARPA PREP (*) 128.52.22.14 MIT-PREP.ARPA, PREP.AI.MIT.EDU SU-PSYCH 36.36.0.202 SU-PSYCH.ARPA, PSYCH.STANFORD.EDU UCBARPA (*) 10.0.0.78 UCB-ARPA.ARPA, UCBARPA.BERKELEY.EDU YALE (*) 10.2.0.9 YALE-GW.ARPA -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA ARPA: wales@LOCUS.UCLA.EDU -or- wales@UCLA-LOCUS.ARPA UUCP: ...!(ucbvax,ihnp4)!ucla-cs!wales  Date: Wed, 26 Feb 86 15:05:40 EST From: David Vinayak Wallace Subject: Mail looping To: netinfo%ucbjade@UCBVAX.BERKELEY.EDU cc: HEADER-PEOPLE@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 25 Feb 86 21:41:33 pst from netinfo%ucbjade at BERKELEY.EDU (Postmaster + BITINFO) Message-ID: <[MC.LCS.MIT.EDU].831513.860226.GUMBY> Date: Tue, 25 Feb 86 21:41:33 pst From: netinfo%ucbjade at BERKELEY.EDU (Postmaster + BITINFO) The final conclusion was that "mailing list exploders" should generate a new message (ie. with a new Message-ID). (The "Errors-to" header was also disapproved if I remember rightly.) ...I suggest that each SUB-LIST exploder also replace the Message-ID with a new Message-ID. (ie. Mailing list exploders at any level should generate a new message.) What if I accidentally get two compies of a message? If they've come through different forwarders there'll be no way for my mail reader do detect this condition and delete excess copies.  Received: from ucbvax.berkeley.edu by MC.LCS.MIT.EDU 27 Feb 86 00:35:42 EST Received: by ucbvax.berkeley.edu (5.45/1.9) id AA03981; Wed, 26 Feb 86 21:33:48 PST Received: by ucbjade.Berkeley.Edu (4.19/4.41.3) id AA14125; Wed, 26 Feb 86 21:33:24 pst Date: Wed, 26 Feb 86 21:33:24 pst From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO) Message-Id: <8602270533.AA14125@ucbjade.Berkeley.Edu> To: header-people@mc.lcs.mit.edu Subject: Re: Mail looping In reply to: Date: Wed 26 Feb 86 00:12:44-PST From: Mark Crispin Subject: Re: Mail looping Message-Id: <12186377826.8.MRC@PANDA> I'd argue that if you really care about loop abatement you will use what SMTP provides to help you out from this -- the EXPN command. That is, the sender fully resolves the destination list. It isn't hard to detect loops when you do this. ------- Unfortunately, mail lists are not limited to the SMTP/RFC822 mail world. So this is only a partial solution. I suspect there is not one fail-safe method and that a varies of methods will be needed to used to reduce looping. One alternative that is less subject to looping is the USENET news distribution system. It is available for Unix systems and shortly will be available for IBM CMS systems. I would prefer to see large mailing lists converted to news groups. It is much nicer to see one message going between news/conference systems than to see several duplications of the same message resulting from mail list explosion being transmitted. I suggest that the USENET article/batch formats be adopted as a standard method of transporting collective address messages between news and conferencing systems. Bill Wells netinfo%ucbjade@Berkeley.EDU  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 FEB 86 05:16:11 EST Date: Thu, 27 Feb 86 05:18:43 EST From: "Pandora B. Berman" Subject: Request to be added to Header-People To: BURNUM%VANDVMS1.BITNET@WISCVM.WISC.EDU cc: HEADER-PEOPLE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].16642.860227.CENT> Date: 26 FEB 86 09:49-CST From: BURNUM%VANDVMS1.BITNET@WISCVM.WISC.EDU To: HEADER-PEOPLE-REQUEST@MIT-MC.ARPA Subject: Request to be added to Header-People This is a request to be added to the Header-People distribution list. I do not know if it is reasonable for you to do this but I am interested in seeing the activity in this group. My mail address is not on Internet but on BITNET; please try to let me know if this cannot be handled. Thanks for considering my request. My mail address is: BURNUM@VANDVMS1.BITNET or possibly BURNUM%VANDVMS1.BITNET@WISCVM.ARPA if the BITNET node names are not immediately known to your mail router. Denson Burnum Vanderbilt University what's a -REQUEST list for but to deal with exactly this sort of situation? welcome to Header-People. recent mail to this list lives in the file KSC;HEADER MINS on MC, with older archives in KSC;HEADER MINS09 through MINS14. these files are accessible via FTP over the Arpanet; beyond there is up to you.  Received: from USC-ECL.ARPA by MC.LCS.MIT.EDU 27 Feb 86 16:49:23 EST Received: from ECLD by ECLA with DECnet; Thu 27 Feb 86 13:45:01-PST Date: Thu 27 Feb 86 13:44:34-PST From: Bob Larson Subject: Mail looping, changing message ID To: header-people@MC.LCS.MIT.EDU Message-ID: <12186787760.51.BLARSON@USC-ECLD.Internet> Changing the message ID is counter-productive in detecting mail looping. (Adding one if there isn't one isn't.) Take the trivial case where list A and list B have each other as members. List A changes the message ID, sends the message to B who changes the message ID and sends it back to A. A hasn't seen the message with B's new ID, so the process continues... This is also a very bad idea for mailing lists gated to usenet newsgroups. Usenet normally has loops purposefully put in its newsgroup distribution, (to reduce the time it takes to get any specific message, and to add reliability by redundancy) which are taken care of by unique message IDs. There has been a proposal (in testing, I think) for multiple arpanet to usenet gateways for arpa mailing lists, increasing this redundancy. This would be broken by changing message IDs. There are numerous good reasons for not expanding a mailing list on one host. One is the world isn't SMTP, so it won't discover the hard to find loops anyway. Another is some hosts probably will answer with local only addresses. (Do you know how to get mail to ECLD, KYLARA, and HARVEY? ECLA (usc-ecl.arpa) does.) Probably the biggest objection is the load it places on the originating host and the network. There are already problems with duplicated messages due to hosts crashing in the middle of sending a message to a long list. Bob Larson -------  Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 9 Mar 86 19:34:07 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2688251359663107@MIT-MULTICS.ARPA>; 09 Mar 1986 19:29:19 est Date: 19 Feb 86 00:42 +0100 From: Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people@MC.LCS.MIT.EDU Subject: Re: loop detection Message-ID: <154125@QZCOM> In-Reply-To: <29371.509120328@dewey> Loop detection == Group Distributor Agent (GDA) answering the question "Have I seen this message before?". "this message" can be identified by its MessageID. "seen before" = "MessageID IN GDA.distribution_log" Therefore, 1) Require unique MessageID's on all messages passing a GDA. If one is missing, generate one! 2) Teach GDA's to generate a sufficiently large round-robin log of MessageID's that have passed. 3) Do not (re-)distribute a message if its MessageID is in this log. 4) (. Call the network police to extrincate any system that removes an existing MsgID .) This will (I think) be a solution for X.400 too, provided that either (a) the GDA resides in both P1 and P2 space, or (b) the P1.UaContentID is made mandatory and == P2.Heading.IPMessageID. This means that all the Via's (Recieved-by, P1.TraceInformation) can be discarded in this matter. I have a feeling that one could mathematically prove that (for messages involved) "the set of GDA-log's is equivalent to the set of all P1.TraceInformation", just differently distributed. Comments? Tommy  Received: from SIMTEL20.ARPA by MC.LCS.MIT.EDU 30 Apr 86 09:59:54 EDT Date: Wed 30 Apr 86 07:58:46-MDT From: William G. Martin Subject: When you know you'll have problems To: header-people@MC.LCS.MIT.EDU cc: WMartin@SIMTEL20.ARPA, wmartin@ALMSA-1.ARPA Message-ID: <12202955893.16.WMARTIN@SIMTEL20.ARPA> Hi! Haven't seen any "header-people" traffic for some months now, so I don't know if the list is still active, or this address (wmartin@simtel20) got dropped off, or what... Anyway, I thought I'd try the "MIT-MC" list address, since it was still listed in the Interest-groups file at SRI-NIC as being valid, even though I expected MIT-MC list addresses to stop being usable. Hope this gets through. Anyway, the point of this is to ask the following question: I'm an administrative-type systems administrator on the ALMSA-1 host. (Not a mail maintainer -- that's handled by another division -- in case that is important.) Every now and then, we know in advance that our system will be off the net for some extended period of time, like three days for air conditioning work [which just happened this past weekend]. I know that there are some mailer systems that will only queue mail for three days (the one here at Simtel20, for example) and will then bounce it back to the sender as undeliverable. In this particular instance, not only were we down for the expected three days, but some other problems delayed our coming back on the net in a fully-operational mode for some time after that. So I am sure that some mail to us, from various sites across the network(s), was either lost, or sent back as "undeliverable". Is there anything I can do, prior to our having such scheduled downtime, or, from another host [like I am sending this message], during such downtime or times of system troubles, to automatically inform the net that any mail addressed to "ALMSA-1" addressees should be treated differently than usual -- maybe to extend the automatic cut-off timer for some extra number of days, or to expect system difficulties and only attempt sending on a more infrequent interval, so that other systems don't waste their resources trying to send to us every 15 minutes for the whole time we are down or unavailable? In the past, I've sent messages to the "ARPA-BBOARDS" address to inform people of this, but that is slow, and also a manual process; I don't want to pester people to do something manually about this -- I would like to send out some sort of "control" message that would interact with the mail system automatically and inform it about this, maybe turning on some switch or flag associated with my host's name. Then, when things are fixed, I could send another "control message" turning off such flags. Does this exist, or has such a mechanism been proposed? Will Martin -------  Date: Thu, 1 May 86 03:50:27 EDT From: "Pandora B. Berman" Subject: list moving To: HEADER-PEOPLE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33378.860501.CENT> The HEADER-PEOPLE mailing list has moved (back) to MIT-AI, also known now as AI.AI.MIT.EDU. Recent mail to the list lives in the file KSC;HEADER MINS on AI, while older archives are in VAFB;HEADER MINS09 through MINS14, also on AI. These files are trivially accessible over the Arpanet via FTP; we regret that this is not of much help to those list members not on the Arpanet. Please remember to address your add/remove/change requests to HEADER-PEOPLE-REQUEST@AI, not to the main list. This move, by the way, is indeed to be taken as a sign that COMSAT, the ITS mailer daemon, is fixed. It no longer has to keep the host tables in its address space, which leaves all that room to be taken up by other data, like longer messages. A lot of mail, especially to lists like this which live on ITSs, has been sidetracked over the past few months while the local hackers were fixing COMSAT. We expect to start sending out this backlog during the next week; the process will take several days, in order to avoid overloading COMSAT or overworking us. An ArpaNet-BBOARDS msg explaining this retransmission will be broadcast sometime in the next few days.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 MAY 86 13:22:42 EDT Received: from SH.CS.NET by MC.LCS.MIT.EDU 1 May 86 13:20:38 EDT To: "William G. Martin" cc: header-people@MC.LCS.MIT.EDU, wmartin@ALMSA-1.ARPA, cic@SH.CS.NET Subject: Re: When you know you'll have problems In-reply-to: Message from "William G. Martin" posted Wed 30 Apr 86 07:58:46-MDT. Date: Thu, 01 May 86 13:10:52 -0500 From: Dennis Rockwell From: "William G. Martin" Subject: When you know you'll have problems Is there anything I can do [ ... ] to automatically inform the net that any mail addressed to "ALMSA-1" addressees should be treated differently than usual [ ... ] If the domain server system were more stable, you could request that your domain server replace your address and MX records with an MX pointing to some host that you know will hold the mail for a period comfortably longer than your downtime. Of course, this will only help those hosts whose mailers look at MX records (not just A records), which will not include the MILnet community or the Sendmail users for quite some time. Dennis Rockwell CSNET Technical Staff  Date: Thu, 1 May 86 21:59:36 EDT From: John Whorfin Sender: SRA@AI.AI.MIT.EDU To: HEADER-PEOPLE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].4.860501*XPER*.SRA> this is a test message. please ignore it.  Date: Thu, 1 May 86 22:32:20 EDT From: John Whorfin Sender: SRA@AI.AI.MIT.EDU To: HEADER-PEOPLE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].6.860501*XPER*.SRA> this is a test message. please ignore it.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 03:56:42 EDT Date: Fri, 2 May 86 03:56:38 EDT From: "Pandora B. Berman" Subject: open mouth, insert foot To: HEADER-PEOPLE@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33875.860502.CENT> Moving this list to AI shook loose a number of bugs, probably within the timing of the ITS address resolver rather than inside COMSAT. This sad situation is being worked on. Until it is corrected, HEADER-PEOPLE is moved back to MC, which being a KL runs faster than AI (a KS).  Date: Fri, 16 May 86 21:14:09 EDT From: "Pandora B. Berman" Subject: testing To: HEADER-PEOPLE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42071.860516.CENT> This is a test of COMSAT, the mailer that is shot from gunz.  Received: from WISCVM.WISC.EDU by AI.AI.MIT.EDU 19 May 86 14:11:04 EDT Received: from (XBR1YD14)DDATHD21.BITNET by WISCVM.WISC.EDU on 05/19/86 at 13:09:50 CDT Received: from BR1.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 19 May 86 20:00:12 Date: Mon, 19 May 86 19:58:24 +0200 From: XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU (Reinhard Goeth - TH Darmstadt HRZ) Subject: Timezone To: HEADER-PEOPLE@AI.AI.MIT.EDU , XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU X-VMS-To: X%"HEADER-PEOPLE%AI.AI.MIT.EDU@WISCVM.WISC.EDU",X%"XBR1YD14%DDATHD21.B ITNET@WISCVM.WISC.EDU" What's the timezone code for Central European Time? Some nodes use +0100 others use -0100. I think +0100 (or A military time) is correct. So for example EST would be equivalent to -0500 or R. Is that correct? Regards Reinhard Goeth (Techn. Univ. of Darmstadt; Fed. Rep. of Germany)  Received: from SPHINX.LOCUS.UCLA.EDU by AI.AI.MIT.EDU 19 May 86 16:47:38 EDT Date: Mon, 19 May 86 13:09:02 PDT From: Rich Wales To: Reinhard Goeth CC: HEADER-PEOPLE@AI.AI.MIT.EDU Subject: Re: Timezone Local-Timezone: PDT (Pacific Daylight Time -- GMT-7h, -0700, or T) In-reply-to: Message of Mon, 19 May 86 19:58:24 +0200 from "XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU (Reinhard Goeth - TH Darmstadt HRZ)" Message-ID: <860519.200902z.13298.wales@DIANA.LOCUS.UCLA.EDU> Reinhard -- Replying to your message: What's the timezone code for Central European Time? Some nodes use +0100 others use -0100. I think +0100 (or A military time) is correct. So for example EST would be equivalent to -0500 or R. Is that correct? That is correct. Central European Time is indeed "+0100" or "A" (in summer, "+0200" or "B"). Eastern Standard Time (in North America) is "-0500" or "R". The sites that use "-0100" -- indeed, *any* European or Middle Eastern sites which use a negative time zone -- are either configured wrong or are taking a holiday in the Atlantic Ocean :-}. With regard to the single-letter time zone designators, by the way, ARPA RFC822 has things backwards. I have been told by several people (who ought to know) that "A" means GMT+1h (i.e., Central European Time), not GMT-1h as shown on page 26 of RFC822. I'm not sure why so many European sites seem to be using the wrong time zone. It might be because some people were confused by the pre- viously mentioned mixup in RFC822 and incorrectly concluded that "-0100" meant GMT+1h. More likely -- at least in the case of sites running Berkeley "sendmail" -- it might be because UNIX's internal time zone information is set up in terms of an offset *west* of GMT (which may make sense if you consider that all time zones in the USA, where UNIX was first developed, are west of GMT). In any case, though, any site in Europe or the Middle East which is using a negative time zone for its local time stamps is *wrong* and should fix its software. Lest anyone accuse me of bias :-}, let me also state that any North American site using a *positive* time zone for its local time stamps is wrong and should fix its software. -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA wales@LOCUS.UCLA.EDU ...!(ucbvax,ihnp4)!ucla-cs!wales "Sir, there is a multilegged creature crawling on your shoulder."  Received: from USC-ECL.ARPA by AI.AI.MIT.EDU 23 May 86 21:11:44 EDT Received: by FNS1; Fri, 23 May 86 16:51:12 Date: Fri, 23 May 86 16:10:16 From: Bob Larson Subject: Mail headers To: header-people%ai.ai.mit.edu@USC-ECL.ARPA Cc: r.larson@FNS1 The message is from a mail system under developement. (It is running on a prime under primos.) As far as I know, the only rfc822 violation in the headers is the lack of time zone. Does anyone see any other violations? This is also a test of how Usc-Ecl.Arpa mungs the From: line, if it does. (Message-id is a planned addition, but low priority.) Bob Larson R.Larson%Fns1@Usc-Ecl.Arpa or Blarson@Usc-Ecl.Arpa  Received: from WISCVM.WISC.EDU by AI.AI.MIT.EDU 27 May 86 01:16:02 EDT Received: from (XBR1YD14)DDATHD21.BITNET by WISCVM.WISC.EDU on 05/27/86 at 00:14:11 CDT Received: from BR1.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 27 May 86 03:32:35 Date: Tue, 27 May 86 03:32:22 +0200 From: XBR1YD14%DDATHD21.BITNET@WISCVM.WISC.EDU (Reinhard Goeth - TH Darmstadt HRZ) Subject: Mail-Header To: Blarson@Usc-Ecl.ARPA , Header-People@AI.AI.MIT.EDU X-VMS-To: X%"Blarson@Usc-Ecl.ARPA",X%"Header-People%AI.AI.MIT.EDU@WISCVM.WISC.ED U",YD14 >Received: from AI.AI.MIT.EDU by wiscvm.wisc.edu on 05/23/86 at 23:02:48 CDT >Received: from USC-ECL.ARPA by AI.AI.MIT.EDU 23 May 86 21:11:44 EDT >Received: by FNS1; Fri, 23 May 86 16:51:12 >Date: Fri, 23 May 86 16:10:16 >From: Bob Larson >Subject: Mail headers >To: header-people%ai.ai.mit.edu@USC-ECL.ARPA >Cc: r.larson@FNS1 > > ... > >Bob Larson R.Larson%Fns1@Usc-Ecl.Arpa or Blarson@Usc-Ecl.Arpa Dear Bob, I think your From-Field is wrong. It should show your address. You should use From: Bob Larson or From: Bob Larson Regards Reinhard Goeth (Techn. Univ. of Darmstadt - Comp. Center)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86 14:02:55 EDT Received: from hplabs.ARPA by MC.LCS.MIT.EDU 27 May 86 14:02:34 EDT Received: from hpldat by hplabs.ARPA ; Tue, 27 May 86 11:00:17 pdt Received: by hpldat ; Tue, 27 May 86 11:04:08 pdt From: Dave Taylor Message-Id: <8605271804.AA05956@hpldat> To: Header-People@mit-mc Date: Tue, 27 May 86 11:04:04 PDT Subject: Mail headers (from Bob Larson) Organization: Hewlett-Packard Laboratories, Knowledge Technologies Lab. X-Mailer: ELM [version 1.0] Bob Larson asked if his headers are okay... Well, here's what I received; From @AI.AI.MIT.EDU:R.LARSON%FNS1.#USCnet@USC-ECL.ARPA Fri May 23 19:00:41 1986 Received: from hplabs.ARPA by hpldat ; Fri, 23 May 86 19:00:35 pdt Message-Id: <8605240200.AA04767@hpldat> Received: from AI.AI.MIT.EDU by hplabs.ARPA ; Fri, 23 May 86 18:55:58 pdt Received: from USC-ECL.ARPA by AI.AI.MIT.EDU 23 May 86 21:11:44 EDT Received: by FNS1; Fri, 23 May 86 16:51:12 Date: Fri, 23 May 86 16:10:16 From: Bob Larson Subject: Mail headers To: header-people%ai.ai.mit.edu@USC-ECL.ARPA Cc: r.larson@FNS1 [message body] My comments on the above; First off, that's a pretty damn bizarre return address! In fact, this could possibly be a honourable mention in the strange addresses contest! The question of parsing becomes pretty incredible with this; @AI.AI.MIT.EDU:R.LARSON%FNS1.#USCnet@USC-ECL.ARPA If my local mailer knows "true" 822 addressing, it'll try to grab the AI.AI.MIT.EDU part and send to that...if it knows Internet addressing, it'll grab the "USC-ECL.ARPA" part...if it knows (?USC?) addressing, it'll send it through the gateway, and if it just knows "uucp" addressing, it'll toss it's proverbial cookies!! Secondly, what is this "#" in the address?? I don't recall that being part of the legal alphabet for addresses. [Does anyone know how to parse that part? Is it the gateway that Bob refers to that's adding this??] Third, note that the Message-Id has been added by my local machine. This means that it didn't have one when it got here - either it was stripped off on the way (a frightening implication) or it never got one... Fourth, it's a bit odd looking that the "R.LARSON@FNS1" in the From: line is all uppercase, but the "r.larson@FNS1" in the Cc: is in lowercase. I understand why this happens and all, but in an aesthetic sense it's not particularly thrilling... Finally, and this is something that Bob alluded to, the date really needs to have a timezone attached! Other than that :-) it looks good! -- Dave Taylor HP Labs - taylor@hplabs  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 02:02:48 EDT Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 28 May 86 02:02:27 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 27 May 86 22:59:48-PDT Date: Tue 27 May 86 22:02:07-PDT From: Mark Crispin Subject: Re: Mail headers (from Bob Larson) To: taylor%hpldat@HPLABS.ARPA cc: Header-People@MC.LCS.MIT.EDU In-Reply-To: <8605271804.AA05956@hpldat> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12210198232.7.MRC@PANDA> Dave Taylor - The return path is perfectly legit. The "%FNS1.#USCnet" is part of the mailbox and you have no business even thinking about parsing it. His From: line was bogus though, since nobody outside of USC knows what FNS1 is. The ".#" stuff is an artifact of the TOPS-20 mailer, and refers to a physical network link that the message uses, in this case the USC DECnet. It should have been .#DECnet, but the USC people didn't understand that the name really does refer to a physical hardware transport and had nothing to do with any proper names. So, they "improved" it by calling it .#USCnet, leading to no end of confusion in the outside world from people who think that some proper named entity called "USCnet" is involved. It isn't. The .# stuff simply tells the TOPS-20 mailer which local interface it should use to send the mail out on. It NEVER (at least in the distributed versions of the TOPS-20 mailer) appears to the right of the "@" in mail sent on the net. Its purpose is to allow a user to distinguish between, say, an Internet host named FOO and a completely other machine also called FOO on the local DECnet. It is relevant ONLY to the host named to the right of the "@"; in other words: user%FOO.#DECnet@HOST-1.ARPA and user%FOO.#DECnet@HOST-2.ARPA do NOT refer to the same host named FOO or for that matter to the same DECnet! I'm sorry for inflicting this lengthy explanation on everybody else, but it is necessary to explain why this clumsy syntax exists. To my knowledge, the TOPS-20 mailer is the only mailer that even tries to be able to mail to two different machines named "FOO" on two different networks that happen to be connected to the local machine. Unix just picks the network it prefers and you can't mail at all to the FOO host on the network it doesn't prefer. This syntax provided an unambiguous, if ugly, means of referring to the two different FOO's and solved a real problem that has actually come up at multiple times. -- Mark -- -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 15:32:53 EDT Received: from USC-ECLB.ARPA by MC.LCS.MIT.EDU 28 May 86 15:32:43 EDT Date: 28 May 1986 12:30 PDT (Wed) Message-ID: Sender: TLI@USC-ECLB.ARPA From: Tony Li To: Mark Crispin Cc: Header-People@MC.LCS.MIT.EDU, taylor%hpldat@HPLABS.ARPA Reply-to: Tli@Usc-Eclb Subject: Mail headers (from Bob Larson) Home: 1115 E. Cordova St. Apt. 110, Pasadena CA., 91106 (818) 793-3342 In-reply-to: Msg of 27 May 1986 22:02-PDT from Mark Crispin From: Mark Crispin The ".#" stuff is an artifact of the TOPS-20 mailer, and refers to a physical network link that the message uses, in this case the USC DECnet. It should have been .#DECnet, but the USC people didn't understand that the name really does refer to a physical hardware transport and had nothing to do with any proper names. So, they "improved" it by calling it .#USCnet, leading to no end of confusion in the outside world from people who think that some proper named entity called "USCnet" is involved. Yes, Mark, we do understand what your code does. However, USCnet is NOT just our local DECNET. It is a logical network which uses a variety of transport mechanisms. In fact, FNS1 is a Prime machine which is not on DECNET. Cheers, Tony ;-)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86 13:24:35 EDT Received: from OFFICE-1.ARPA by MC.LCS.MIT.EDU 4 Jun 86 13:13:44 EDT Date: 4 Jun 86 13:07 EDT From: Bill Barns Subject: Status of long lines vs. MMDF? To: header-people@MIT-MC.ARPA Message-ID: Some time back (2-3 years) it came out that the MMDF SMTP server couldn't cope with lines longer than 255 characters in the "DATA" (822 message). Messages with such lines always elicited a 400 series reply code with some generic "try again later" text. When I learned this, I asked around and was told that the necessary change to MMDF code (to handle 1000 character lines as specified in RFC 821) was non-trivial but would be done in MMDF II. In recent months, I've somehow gotten the idea that MMDF II now exists. But I still see my SMTP mailer encounter this behavior with some sites. What is the current truth of the situation? Is there now an MMDF version that handles 1000 character lines? If there is, maybe those sites just need to be told how to get it. If there isn't, will there be one "soon"? If not, is there any prospect of getting the 4xx reply code changed to something like 554 with some appropriate explanatory text, so my mailer will know not to "try again" repeatedly and unsuccessfully for N days before giving up? Bill Barns (WWB.TYM@OFFICE-1.ARPA)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86 14:21:45 EDT Received: from isi-vaxa.ARPA by MC.LCS.MIT.EDU 4 Jun 86 13:47:41 EDT Received: by isi-vaxa.ARPA (4.12/4.7) id AA04562; Wed, 4 Jun 86 10:46:14 pdt From: jeff@isi-vaxa.ARPA (Jeffery A. Cavallaro) Message-Id: <8606041746.AA04562@isi-vaxa.ARPA> Date: 4 Jun 1986 1046-PDT (Wednesday) To: Bill Barns Cc: header-people@MIT-MC.ARPA Subject: Re: Status of long lines vs. MMDF? In-Reply-To: Your message of 4 Jun 86 13:07 EDT. I have been working with a "pre-release" of MMDF-II. The symbolic name in question is LINESIZE, and in my pre-release, it is still 256. I hear that MMDF-II is to be released with 4.2BSD. I cannot speak for that version. Jeff  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86 15:19:49 EDT Received: from SRI-NIC.ARPA by MC.LCS.MIT.EDU 4 Jun 86 15:02:41 EDT Date: Wed 4 Jun 86 12:01:17-PDT From: Ole Jorgen Jacobsen Subject: Re: Status of long lines vs. MMDF? To: jeff@ISI-VAXA.ARPA cc: OLE@SRI-NIC.ARPA, header-people@MC.LCS.MIT.EDU In-Reply-To: <8606041746.AA04562@isi-vaxa.ARPA> SRI-International: (415) 859-4536 Home: (415) 325-9427 Message-ID: <12212186003.36.OLE@SRI-NIC.ARPA> I think you mean "...is to be released with 4.3BSD." It is my understanding that MMDF-II does indeed come with 4.3BSD. Ole -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86 15:24:24 EDT Received: from UMD2.UMD.EDU by MC.LCS.MIT.EDU 4 Jun 86 15:05:39 EDT Date: Wed, 04 Jun 86 14:36:09 EDT From: Ben Cranston To: ARPA Internet Mail Interest List , BitNet Mail Interest List <@UMD2.UMD.EDU:MAIL-L@BITNIC.BITNET> Subject: Technical Question on User Agent "reply" command Message-ID: When you tell a mail user agent to REPLY to a message, precisely which of the (possibly many) addresses in the header gets used? This question does become nontrivial when you consider REPLY-TO: fields, RESENT- fields, etc. Because certain user agents do forwarding with RESENT- fields, this pathological situation arises: From: director@admin From: director@admin To: teamleader@research To: teamleader@research . . . . . . . . . . . . . . Resent-From: teamleader@research . Resent-To: mem1@pc1, member2@pc2, etc . . . . . . . . . . . . . . . . . . . . . . ------------------ V ----------------------- V --------------- | director@admin |----->| teamleader@research |------+---> | member2@pc2 | ------------------ (1) ----------------------- (2) | --------------- ^ ^ | : : (4) +---> etc : : | : (5) ------------ | :.....................| mem1@pc1 |<----------+ ------------ (3) (1) DIRECTOR@ADMIN sends message to TEAMLEADER@RESEARCH. (2) TEAMLEADER tells user agent at RESEARCH to forward message to his staff. (3) MEM1@PC1 does REPLY command. Does user agent at PC1 follow RESENT-FROM: field and reply to TEAMLEADER (4), or does it follow original FROM: field and reply to DIRECTOR (5)? I am considering using the truncated sequence RESENT-REPLY-TO:, REPLY-TO:, FROM:, thus leaving out RESENT-FROM: fields. This may seem like the wrong thing to do, but hear me out. What I want to do is give the FORWARDER a chance to select which of the two plausable behaviors REPLY might eventually do. If replies are to go back to the original sender (5), then forwarder does nothing: From: director@admin From: director@admin To: teamleader@research To: teamleader@research . . . . . . . . . . . . . . Resent-From: teamleader@research . Resent-To: mem1@pc1, member2@pc2, etc . . . . . . . . . . . . . . . . . . . . . . ------------------ V ----------------------- V --------------- | director@admin |----->| teamleader@research |------+---> | member2@pc2 | ------------------ (1) ----------------------- (2) | --------------- ^ | : +---> etc : | : (5) ------------ | :.....................| mem1@pc1 |<----------+ ------------ (3) (3) MEM1@PC1 gives mail REPLY command. Since RESENT-REPLY-TO: field is not present, mail follows FROM: field and replies to original sender (5). But, if forwarder wants to be "in the loop" for replies, then he supplies a RESENT-REPLY-TO: field pointing to himself: From: director@admin From: director@admin To: teamleader@research To: teamleader@research . . . . . . . . . . . . . . Resent-From: teamleader@research ====>Resent-Reply-To: teamleader@research . Resent-To: mem1@pc1, member2@pc2, etc . . . . . . . . . . . . . . . . . . . . . . ------------------ V ----------------------- V --------------- | director@admin |----->| teamleader@research |------+---> | member2@pc2 | ------------------ (1) ----------------------- (2) | --------------- ^ | : (4) +---> etc : | ------------ | | mem1@pc1 |<----------+ ------------ (3) (3) MEM1@PC1 gives mail REPLY command. Mail follows RESENT-REPLY-TO: field and replies to FORWARDER (4). I realize this breaks the strict correspondance between RESENT- and normal fields, but it does give us a capability we would like to have. If anybody has objections or even observations please let me know what you think. Ben Cranston UMD5.UUCP ZBEN @ UMD2.UMD.EDU UMD2.BITNET  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86 16:43:56 EDT Received: from LOKI.BBN.COM by MC.LCS.MIT.EDU 4 Jun 86 16:43:39 EDT To: wwb.tym@office-1.arpa cc: header-people@mit-mc.arpa Subject: MMDF and Long Lines Date: Wed, 04 Jun 86 16:37:20 -0400 From: Craig Partridge Bill, This bug was fixed some time ago. We have tested and can confirm that it is not present in MMDF2b, which will be released shortly. We believe, but have not checked, that it is also fixed in MMDF2a (which came out last year). Craig Partridge CSNET Technical Staff & MMDF2b Co-Coordinator  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86 10:06:27 EDT Received: from ALMSA-1 by MC.LCS.MIT.EDU 5 Jun 86 10:06:00 EDT Received: from almsab by ALMSA-1.ARPA id a011128; 5 Jun 86 8:07 CDT Date: Thu, 5 Jun 86 7:45:52 CDT From: Rich Zellich To: ZBEN@UMD2.ARPA cc: Header-People@MIT-MC.ARPA, MAIL-L%bitnic.bitnet@UMD2.ARPA Subject: Re: Technical Question on User Agent "reply" command As I recall, the official way is to use Reply-To if present, From if it is present and Reply-To is not, and finally Sender if neither Reply-To nor From are present. I don't remember the extended field-names like Resent-* entering into the equation at all but, personally, I like the idea of including Resent-Reply-To at the head of the chain (if anyone has a mail agent that will let you include such a field).  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86 12:04:00 EDT Received: from Dewey.UDEL.EDU by MC.LCS.MIT.EDU 5 Jun 86 12:03:47 EDT Received: from localhost by Dewey.UDEL.EDU id a003062; 5 Jun 86 12:00 EDT Reply-To: James M Galvin To: Rich Zellich cc: ZBEN@umd2.umd.EDU, Header-People@mc.lcs.mit.EDU, MAIL-L%bitnic.bitnet@umd2.umd.EDU Subject: Re: Technical Question on User Agent "reply" command In-reply-to: Your message of Thu, 05 Jun 86 07:45:52 CDT. Date: Thu, 05 Jun 86 11:59:20 -0400 Message-ID: <3047.518371160@dewey> From: James M Galvin > From: Rich Zellich > Date: Thu, 5 Jun 86 7:45:52 CDT > As I recall, the official way is to use Reply-To if present, From if it is > present and Reply-To is not, and finally Sender if neither Reply-To nor From > are present. Actually, I don't know of any "official" way but I do know of three different interpretations. Berkeley Mail as distributed with 4.[23]BSD does one of the following: 1. reply to FIRST address listed in Reply-To: field ONLY 2. reply to From: address and To: and Cc: fields 3. reply to Sender: address and To: and Cc: fields Now MMDF msg does one of the following: 1. reply to Reply-To: address(es) and To: and Cc: fields 2. reply to From: address and To: and Cc: fields And finally, Berkeley Mail as distributed with MMDF does one of: 1. reply to Reply-To: address(es) and To: and Cc: fields 2. reply to From: address and To: and Cc: fields 3. reply to Sender: address and To: and Cc: fields I would probably following MMDF's msg. I am not convinced we need the utility of "Resent-Reply-To" though. Why not just redistribute the message and then include the additional recipient in any replies you generate. If the additional recipient replies to the message you redistributed then s/he will receive replies to that message and so will you. If the redistributor wants to be the only one receiving replies from the additional recipient then the message should be forwarded not redistributed. Jim  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86 14:40:18 EDT Received: from hplabs.ARPA by MC.LCS.MIT.EDU 5 Jun 86 14:40:01 EDT Received: from hpldat by hplabs.ARPA ; Thu, 5 Jun 86 11:38:12 pdt Received: by hpldat ; Thu, 5 Jun 86 11:40:58 pdt From: Dave Taylor Message-Id: <8606051840.AA16858@hpldat> To: Header-People@mit-mc Date: Thu, 5 Jun 86 11:40:53 PDT Subject: More on mail address priorities... Organization: Hewlett-Packard Laboratories, Knowledge Technologies Lab. X-Mailer: ELM [version 1.0] From what I understand, and what my mailer knows, the scheme for generating a return address is; 1. If the message has a "Reply-To:", use it. 2. If the message has a "From:", use it. 3. If the message has a "Sender:", use it, but not for textual, user-originated, replies. Rather, this should be used just for delivery/routing problems and other error notification. The example in RFC-822 indicates that `Sender:' could most commonly be considered the address of a secretarial-type person... 4. If the message has none of the above, it is considered to not have a valid return address and the mailer agent can optionally refuse to generate a reply address; '822 requires that any minimal legal mail message contain; a date stamp ("Date:"), an indication of whom the mail is from ("From:") and some indication of whom the mail was sent to ("To:" or "Bcc:" <- "bcc" can be an empty list). Given this, we can assume that a conformant mailer can indeed refuse to reply to mail without a From: or Reply-To: header. As we know, though, a great deal of mail (especially on "uucp" sites, like my own) would then be dropped post haste!! *sigh* As far as the priority of the "Resent-Reply-To:" I think that this would be a dangerous header to generate - the correct behaviour of a mailer when mail is resent is to leave the Reply-To: header alone. (The problem with this, though, is that say Rich Zellich sends me a message, with a Reply-To: to him. I then resend it to a friend. That resending fails, though, and the mailer generates a failed-message error. Should that error go to Rich or myself?) (we could use the "Errors-To:", but that's a field that I don't know of ANY mailers/transport systems using...) ------------- To wax philosophical for a bit, it seems to me that this whole issue is indicative of a problem with the 822 specification. What is needed is a clear, unambiguous set of headers for a message that contain the following information in some manner or other; o The name and address of the person(s) sending the message. o The name and address of the person(s) to reply to. o The name and address of the person who originated the message. o The (name and) address of the person to send errors to. These are not necessarily all required. Furthermore, there is a problem of address versus route (e.g. my email address is taylor@hpldat.HP.COM, but my route might very well be "ihnp4!hplabs!hpldat!taylor"). It seems like the current problem with the network is that there is too little distinction between these two forms of address. Consider the "should the intermediate hosts alter the From:/Reply-To: lines" debate - some hosts say that they shouldn't, because it's an address, and others say they should since it's a route. My proposed solution, based on the information sketchily described in '822, is to have the originating mail system attach a new header "Reply-Path:" to the header of the message. All intermediate machines would then be REQUIRED to attach their hostname/routingname to this path but would NOT be allowed to alter the contents of the Reply-To: or From: headers. The receiving user agent would then be able to use "Reply-Path:" to reply to the message IF it needed to use a 'route' address, or simply use the Reply-To:/From: if it knew about `formal' addresses. A few examples; [the first is a pure UUCP address] From uucp From: Dave Taylor Date: Reply-Path: hpfcla!hplabs!hpldat!taylor To: j_richards@hpfclq.HP.COM Subject: automatic, correct, reply addresses [message body] [the next has a Reply-To field. Note that the Reply-Path: header is for the Reply-To, NOT the From: field!] From mmdf From: Dave Taylor Reply-To: Computers And Society Digest Date: Reply-Path: emoryu2!gatech!hplabs!hpldat!cas-request To: gatech!emoryu2!emoryu1!janet Subject: More on Science and Technology... [message body] Any thoughts? -- Dave Taylor taylor@hplabs (soon .HP.COM) ps: While I'm sending mail to the group, is there any consensus on a preferred order for headers in a message? The order of the To:/Subject:/ From:/Date:/etc fields seems pretty darn random...  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86 17:02:16 EDT Received: from isi-vaxa.ARPA by MC.LCS.MIT.EDU 5 Jun 86 17:01:43 EDT Received: by isi-vaxa.ARPA (4.12/4.7) id AA05188; Thu, 5 Jun 86 14:00:26 pdt From: jeff@isi-vaxa.ARPA (Jeffery A. Cavallaro) Message-Id: <8606052100.AA05188@isi-vaxa.ARPA> Date: 5 Jun 1986 1400-PDT (Thursday) To: Ole Jorgen Jacobsen Cc: OLE@SRI-NIC.ARPA, header-people@MC.LCS.MIT.EDU, jeff@ISI-VAXA.ARPA Subject: Re: Status of long lines vs. MMDF? In-Reply-To: Your message of Wed 4 Jun 86 12:01:17-PDT. <12212186003.36.OLE@SRI-NIC.ARPA> Yes, I meant MMDF-II is to be released with 4.3BSD. A little typo there.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 JUN 86 22:14:36 EDT Received: from Dewey.UDEL.EDU by MC.LCS.MIT.EDU 7 Jun 86 21:40:32 EDT Received: from localhost by Dewey.UDEL.EDU id a001221; 6 Jun 86 20:51 EDT Reply-To: James M Galvin To: Dave Taylor cc: Header-People@mc.lcs.mit.EDU Subject: Re: More on mail address priorities... In-reply-to: Your message of Thu, 05 Jun 86 11:40:53 PDT. <8606051840.AA16858@hpldat> Date: Fri, 06 Jun 86 20:50:50 -0400 Message-ID: <1213.518489450@dewey> From: James M Galvin > From: Dave Taylor > Date: Thu, 5 Jun 86 11:40:53 PDT > > (The problem > with this, though, is that say Rich Zellich sends me a message, with a > Reply-To: to him. I then resend it to a friend. That resending fails, > though, and the mailer generates a failed-message error. Should that error > go to Rich or myself?) Obviously the correct thing to do is to give you the error message. Now, if MMDF is your transport agent, you do get the error message. The recipients and sender of a message are maintained separately from the message, although the construction of this file may require looking at the message. This is exactly how the "list channel" of MMDF operates. Distribution list are processed via the "list channel" which sets the return address in this file to be "LIST-request". This file is used during the SMTP dialog. Now, if we could only get other mailers to remember this information rather than assuming it is contained in the message. > ps: While I'm sending mail to the group, is there any consensus on a > preferred order for headers in a message? The order of the > To:/Subject:/From:/Date:/etc fields seems pretty darn random... This is a user agent problem, not a transport agent problem. In MH, a user can completely specify the order and format of all displayed messages. Jim  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 8 JUN 86 20:23:27 EDT Received: from titan.arc.nasa.gov by MC.LCS.MIT.EDU 8 Jun 86 20:09:22 EDT Received: by titan.arc.nasa.gov (5.45/1.7) id AA07643; Sun, 8 Jun 86 17:06:20 PDT Date: Sun, 8 Jun 86 17:06:20 PDT From: Jordan Hayes Message-Id: <8606090006.AA07643@titan.arc.nasa.gov> To: header-people@mc.lcs.mit.edu Subject: A funny thing happened on the way to my mailbox ... Cc: kpetersen@simtel20.arpa, s.pae@deep-thought.mit.edu Did anyone else get this or am I just hosed? Date: Tuesday, 3 June 1986 16:20-MDT Message-Id: Sender: "Philip A. Earnhardt" From: "Philip A. Earnhardt" To: TELECOM@mc.lcs.mit.edu Subject: MNP Protocol Resent-From: KPETERSEN@simtel20.arpa Resent-To: Info-Modem7@simtel20.arpa I changed the wierd character to how it comes out on my editor (^? I would imagine is something like ascii 127 ... Where did this strangeness come from? Will it go away? /jordan  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 05:21:57 EDT Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 9 Jun 86 05:21:31 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 9 Jun 86 02:19:30-PDT Date: Mon 9 Jun 86 00:51:24-PDT From: Mark Crispin Subject: timezones and RFC 822 To: Header-People@MC.LCS.MIT.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12213374776.7.MRC@PANDA> Rich Wales is correct that RFC 822 has military timezones backwards. Continental Europe time (GMT+1 hour, known in Germany as MEZ) is military timezone "A". Timezones "M" and "Y" refer to the same zone, except that "M" is west of the international date line and "Y" is east. The PANDA version of TOPS-20 implements these timezones (it is better than DEC TOPS-20's behavior of showing no timezone at all outside of the USA or GMT), and I decided to go with the military standard instead of what RFC 822 claimed. Is it at all possible that we can revise RFC 822 to correct this and other obvious errors? To emphasize that it is not a new standard (ala RFC 733 => RFC 822), let's call the new document RFC 822(1) or something. It would not hurt to make the description of things like domains and domain literals be more in keeping with RFC 821 and the other domain documents, but let's keep this sweet and simple. At the very least, let's have an RFC with all the known bugs in RFC 822 and make that available as an appendix to any further hardcopy printing of RFC 822. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 11:36:11 EDT Received: from harvard.HARVARD.EDU by MC.LCS.MIT.EDU 9 Jun 86 11:32:22 EDT Received: from endor.HARVARD.EDU (endor) by harvard.HARVARD.EDU; Mon, 9 Jun 86 11:25:44 EDT Date: Mon, 9 Jun 86 11:25:41 EDT Received: by endor.HARVARD.EDU; Sun, 8 Jun 86 18:06:03 EDT From: macrakis@harvard.HARVARD.EDU (Stavros Macrakis) To: header-people@mit-mc.arpa Cc: GUMBY@AI.AI.MIT.EDU Subject: Failed messages to mailing lists As far as I know, there is no way to specify that you're not interested in failed mail messages from a particular message. When I am sending, e.g., bug notes, I want to be sure my message reaches the redistribution host, but once it gets there, I'd like to have the list administrator be responsible for failed mail. This is good both for the individual senders to the list and for the list administrator. As a sender in such cases, I really don't care if there is a delay in the message getting through to one of the 100 readers of the list. On the other hand, as a list administrator, I'd like to be able to prune my list according to failed mail problems. If I can't get this, I'd at least like to have the ability of saying `tell me only if it never gets through'. There have been messages where I've gotten 2-3 `temporary' NAK's (host down for a day, will try again, etc. etc.) before getting the final NAK (host down for a week, I won't continue trying, take it back). -s  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86 08:23:27 EDT Received: from rand-unix.ARPA by MC.LCS.MIT.EDU 10 Jun 86 08:16:33 EDT Received: from localhost by rand-unix.ARPA; Tue, 10 Jun 86 03:52:52 pdt Message-Id: <8606101052.AA11352@rand-unix.ARPA> To: Jordan Hayes Cc: header-people@mc.lcs.mit.edu Subject: Re: A funny thing happened on the way to my mailbox ... In-Reply-To: Your message of Sun, 8 Jun 86 17:06:20 PDT. <8606090006.AA07643@titan.arc.nasa.gov> Date: Tue, 10 Jun 86 03:52:13 PDT From: greep@rand-unix.ARPA Looks like maybe it was some internal form that was never supposed to make it to the outside world. 4.2bsd Unix sendmail plays games like that (although in this case it is evidently not a Unix site), and screwing up sendmail's config file can have that effect. I've also seen funny internal forms come out of Xerox once in a while.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86 09:22:15 EDT Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 10 Jun 86 09:22:39 EDT Date: Tue, 10 Jun 86 08:53 EDT From: "John C. Klensin" Subject: timezones and RFC822 To: header-people@MC.LCS.MIT.EDU Message-ID: <860610125356.810321@MIT-MULTICS.ARPA> If such a revision were to be made, it would be helpful to authorize the NAMES (or at least some names) for some of the timezones that don't cross the continental US. At one level, we should have named zones that span Alaska and Hawaii. At another, with ARPANET (not MILNET) sites in Western Europe and BITNET/EARN sites all over the place using RFC822, it would be at a minimum to have support for what those folks call their zones. This is especially important in internetwork dealings with the BITNET/EARN sites who seem to feel a deep need to use a locally-named zone (e.g., MEZ), rather than an (especially backwards) [US] military zone code. Those local zones are fine as long as they stay within their own network, but, when messages cross over into the Internet, as least some mail agents get upset with them because the dates are not RFC822-legal. The other question, of course, is how one arranges a transition from a "backwards" standard to a "forwards" one, given that mail-producing codes to generate the older type of zone codes will probably linger somewhere in the works for years.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86 14:18:38 EDT Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 10 Jun 86 14:17:21 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 10 Jun 86 11:15:08-PDT Date: Tue 10 Jun 86 10:19:19-PDT From: Mark Crispin Subject: Re: A funny thing happened on the way to my mailbox ... To: greep@RAND-UNIX.ARPA, jordan@AMES-TITAN.ARPA cc: header-people@MC.LCS.MIT.EDU In-Reply-To: <8606101052.AA11352@rand-unix.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12213740307.7.MRC@PANDA> Actually, that particular internal form (with DEL's around the host name) comes out of the TOPS-20 mailer. Normally, the mailer is forbidden from doing any header modification, but if the mail composer puts DEL's around the host name it says "I think this is the right host name, but I can't be sure, and the message may get relayed to a third party, so look this name up and fix it up, doing whatever %-type conversion you think is necessary." I'm not sure why it "bogued out", but my suspicion is that the host name in the header was bad, but the name in the envelope was not. The mailer will always deliver a message if the envelope is okay irregardless of what trash may appear in the header. If it is completely unable to fix up a "hostname" entry, it assumes that it wasn't really such an entry at all but instead was a legitimate text DEL and leaves it alone. Supporting this suspicion is the Message-ID, which indicates that the "Babyl" mail composer (instead of MM) composed this message. Babyl is written in TECO (a text editing programming language) and I believe it does not do any validation of host names. MM won't let you do this, but conceivably it is possible for a Babyl user to have a different host name in the envelope from the header, and blow it on the latter. I apologize for the confusion it may have caused you. There isn't too much the mailer could have done; it's classic GIGO. If you would like to talk with the people who might be able to do something about Babyl's generating this garbage, try BUG-BABYL@MC.LCS.MIT.EDU. -- Mark -- -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86 15:02:20 EDT Received: from decwrl.DEC.COM by MC.LCS.MIT.EDU 10 Jun 86 15:02:05 EDT Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.05/4.7.34) id AA00401; Tue, 10 Jun 86 12:01:06 pdt Message-Id: <8606101901.AA00401@decwrl.DEC.COM> Date: 10-Jun-1986 1417 From: covert%covert.DEC@decwrl.DEC.COM (John R. Covert) To: header-people@mc.lcs.mit.edu Subject: Zone names >If such a revision were to be made, it would be helpful to authorize the >NAMES (or at least some names) for some of the timezones that don't >cross the continental US. Oh no! This is an incredible rathole! Do this and you have to worry about conflicts between BST=British Summer Time and BST=Bering Standard Time. These two happen to be exactly twelve hours apart. Of course, Alaska changed all their timezones recently: BST doesn't even exist any more and Anchorage is one timezone east of where almost every reference shows it (it's now only one hour west of California). To top this off, people in Alaska call their timezone AST=Alaska Standard Time even though that conflicts with AST=Atlantic Standard Time! And then there's EST=Eastern Standard Time in both the U.S. and Australia. How many languages shall we use for the abbreviation of Central European Time? German, French, Italian, Spanish, Dutch, Danish, ... And the French and the French speaking Swiss can't agree on the abbreviation for Central European Summer Time: HECE and HEEC! Forget the abbreviations; they just aren't useful except possibly as a comment field! /john  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUN 86 17:13:39 EDT Received: from NRTC-GREMLIN.NORTHROP.COM by MC.LCS.MIT.EDU 10 Jun 86 16:55:02 EDT Received: from localhost by NRTC-GREMLIN.NORTHROP.COM id a006168; 10 Jun 86 13:52 PDT To: "John R. Covert" reply-to: header-people@mc.lcs.mit.EDU cc: header-people@mc.lcs.mit.EDU Subject: Re: Zone names In-reply-to: Your message of 10 Jun 86 14:17:00 +0000. <8606101901.AA00401@decwrl.DEC.COM> Date: Tue, 10 Jun 86 13:52:08 -0700 Message-ID: <6166.518820728@nrtc-gremlin.northrop.com> From: Marshall Rose The zone name business is a classic user agent vs. user interface problem. Let me relate an lengthy experience. I have the misfortune of being one of the MH maintainers. MH is this message handling system for UNIX. In RFC822, you get three choices for a timezone, e.g., "-0050", "E", or "EST". When a date is displayed to a user, they prefer the third form of timezone because it's more meaningful. Sadly, many user agents understand and generate other, non-standard, abbreviations for timezones. You all know about how BST (Bering Standard Time) is different from BST (British Summer Time) depending on whether you're in Alaska or the U.K. Although local tables of user-friendly timezones are desirable, values generated from them are typically un-meaningful (or even anti-meaningful) when found outside of the local environs. An extreme example is EVT (Eastern Virtual Time) which was being generated by an IBM host because you couldn't change the timezone string in the mailsystem without re-configuring the operating system. So, to discourage this type of behavior, and set an example for mailsystems everywhere, MH was modified to generate to use only numeric (unambiguous, globally meaningful) timezones when posting mail. Considering the volume of hate mail I got when this new version of MH was released, most people had extraordinarily minimal user interfaces! That is, their user interface didn't try to convert the numeric timezone to a locally meaningful abbreviation. The reason for these minimal interface implementations, supposedly, goes back to the RFC822 basis in ASCII text. "Since everything's just text", reason some implementors, "why not just output it directly to the user's terminal without interpretation?" Hopefully, implementations of X.400 won't suffer from this problem, since dates in MHS are IA5 strings but not very easy to read (e.g., "860610135005-0500"). To summarize this long-winded reply: NO GLOBAL TABLES, REPEAT, NO GLOBAL TABLES. Local tables are fine so long as you guarantee they NEVER escape from the domain where they are meaningful (e.g., the host originating the mail). /mtr  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 JUN 86 19:23:35 EDT Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 11 Jun 86 19:04:57 EDT Date: Wed, 11 Jun 86 19:03 EDT From: "John C. Klensin" Subject: Re: time zones To: header-people@MC.LCS.MIT.EDU Message-ID: <860611230319.475119@MIT-MULTICS.ARPA> I capitulate, and apologize for bringing it up. Seems to me that a very good argument is being made for striking the eight zone names permitted by RFC822, since they are ultimately not entitled to special preference and their presence encourages the transmission of local innovations over the network. It also suggests an additional set of rules/guidelines for gateways of the character of "you may permit that nonsense on your network, but we expect them to be cleaned up into numeric values before the message cross over into the Internet". So --- revised and quite opposite version of the suggestion: if RFC822 is to be opened up and corrections made, how would people feel about "correcting" the existing eight zone names out of there? It is also clear that the easiest way to "solve" the compatibility problems with the ascending or descending letters is to "correct" that convention by banning both the ascending and descending forms, insisting on numerics. That provides better X.400 compatability, as pointed out indirectly in an earlier message, and, if user agents can manage locally-referenced zone names, they can certainly manage to convert numbers to letters in a locally-acceptable scheme. The lives of such agents would certainly be easier if there were only one, unambiguous, form -- effort could be devoted to making a clean local interface rather than to parsing and near-heuristics.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 JUN 86 23:43:55 EDT Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 11 Jun 86 23:38:25 EDT Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 11 Jun 86 20:36:10-PDT Date: Wed 11 Jun 86 19:28:57-PDT From: Mark Crispin Subject: Re: time zones To: Klensin@MIT-MULTICS.ARPA cc: header-people@MC.LCS.MIT.EDU In-Reply-To: <860611230319.475119@MIT-MULTICS.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12214102509.6.MRC@PANDA> John Klensin - I think it is pretty much hopeless to expect the RFC 822 world to abandon US timezones. A much more sensible approach is to think about X.400 instead. -- Mark -- -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86 02:35:47 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUN 86 02:33:29 EDT Received: from ALMSA-1 by MC.LCS.MIT.EDU 9 Jan 86 11:10:10 EST Received: from almsab by ALMSA-1.ARPA id aa05813; 9 Jan 86 10:02 CST Date: Thu, 9 Jan 86 10:02:20 CST From: Will Martin -- AMXAL-RI To: arms-d@MIT-MC.ARPA, human-nets@RUTGERS.ARPA, sf-lovers@RUTGERS.ARPA, arpanet-bboards@MIT-MC.ARPA, header-people@MIT-MC.ARPA, info-terms@MIT-MC.ARPA, space@MIT-MC.ARPA cc: zellich@ALMSA-1.ARPA Subject: Host MIT-MC may vanish abruptly Some of you might have heard rumors or indications that the longtime ARPANET mail-relay and list-archive storage computer, MIT-MC, is due to be retired. These rumors are true; I append below a message from one of the system managers confirming this. Therefore, if you have been relying on having MIT-MC around as a source for archived mailing-list files, or as a mail-forwarder, be warned that it is likely to disappear abruptly in the near future. It would be good if all the list archives could be moved to other hosts which would also support the traditional ARPA "anonymous FTP", and also that mailing-list addresses should be changed to no longer rely on forwarding or list expansion by MIT-MC. I hope that this information is disseminated as widely as possible, so as to reach all list-maintainers and the whole community of users and list readers and contributors. Those of us who have been involved with the ARPANET for some years all owe a debt of gratitude to MIT-MC and the support staff that ran it over the past decade or so; that host was the seminal point for the entire mailing list and Digest phenomenon. It's sad to see it go, but we all know that hardware progress makes such changes inevitable. Regards, Will Martin ----- Forwarded message # 1: Date: Wed, 8 Jan 86 19:17:46 EST From: "Christopher C. Stacy" Subject: Future of MIT-MC? To: wmartin@ALMSA-1.ARPA cc: POSTMASTER@mit-mc.ARPA Message-ID: <[MC.LCS.MIT.EDU].777682.860108.CSTACY> Will, I am afraid that the rumors about MIT-MC's future are true. The maintenance contract for MIT-MC expires in a few months (at the end of February, I think). After that, the next time the machine breaks badly, it will be retired from service. There are few KS-10 (DEC2020) machines in the building now, and one of them is actually running ITS and calling itself MIT-AI. This tiny machine not on the Internet yet, although it probably will be before too long. However, MIT-AI will not have anywhere near the capacity of MC, and won't be able to service the world in general. There really isn't any machine available at MIT to take over the services MC has provided; the structure of the community and its associated resources has changed. People should be moving off of MIT-MC rapidly; the machine really will be decommissioned with little warning in the near future. Also, people should move their data, as files may not be retrievable once it's gone. Cheers, Chris ----- End of forwarded messages  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86 02:59:42 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUN 86 02:33:36 EDT Received: from hplabs.ARPA by MC.LCS.MIT.EDU 9 Jan 86 17:11:01 EST Received: by hplabs.ARPA ; Thu, 9 Jan 86 14:10:24 pst To: veeger!hpcnof!hplabs!Header-People@MIT-MC.ARPA, veeger!hpcnof!hplabs!MsgGroup@BRL.ARPA Date: Thu, 9 Jan 86 14:21:44 MST From: hpcnou!dat@hplabs.ARPA (Dave Taylor) Subject: Questions on ARPA/Domain naming... Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.4] Recently I've hooked my mailer up to ues the pathalias database distributed on the usenet system and have been trying to improve the search to hit ratio through various techniques. My current algorithm is: 1. Extract the host name from the address 2. Remove all the domain information 3. Translate the entire name to lower case letters 4. Search in table 5. If the search fails, return the original host name otherwise return the expanded address The question is, since the database is a mixture of USENET and ARPANET (and presumably CSNET, BITNET, ??NET too) is it safe to consider each host machine as a unique identifier? On ARPA machines, the addresses are case insensitive, so it's rather obvious that the third step in the algorithm above is okay. What about on USENET? Finally, are there any cases where there are two machines with the same name and differ only on domain? (like 'vax.att.com' versus 'vax.harvard.edu') Any input on these problems, or (perhaps) other equally successful techniques for searching the database would be appreciated. -- Dave Taylor Hewlett Packard hpcnof!dat@HPLABS.ARPA ps: Speaking of which, is it possible to get the ARPA hostname table? (anyone at SRI-NIC reading this?) pps: Also, has anyone considered modifying pathalias to allow not only the '
' information but also an organizational entry for each machine? The user could then do queries like "Where is this mail from?" "what is this machine?" and so on...  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86 02:59:46 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUN 86 02:33:39 EDT Received: from BRL-SEM.ARPA by MC.LCS.MIT.EDU 9 Jan 86 19:39:53 EST Date: Thu, 9 Jan 86 19:35:54 EST From: Ron Natalie To: Dave Taylor cc: header-people@mit-mc.arpa Subject: Re: Questions on ARPA/Domain naming... There are many cases of the sort vax.att.com and vax.harvard.edu. Check the tables for the host "sam" for instance. sam.cs.ucl.ac.uk sam.cs.cmu.edu sam.brl.mil to name a few. -Ron  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86 13:51:05 EDT Received: from titan.arc.nasa.gov by MC.LCS.MIT.EDU 12 Jun 86 13:51:04 EDT Received: by titan.arc.nasa.gov (5.45/1.7) id AA12374; Thu, 12 Jun 86 10:47:29 PDT Date: Thu, 12 Jun 86 10:47:29 PDT From: Jordan Hayes Message-Id: <8606121747.AA12374@titan.arc.nasa.gov> To: header-people@mc.lcs.mit.edu Subject: Re: Questions on ARPA/Domain naming... Cc: hpcnou!dat@hplabs.hp.com From: hpcnou!dat@HPLABS.HP.COM Thu, 9 Jan 86 14:21:44 MST since the database is a mixture of USENET and ARPANET (and presumably CSNET, BITNET, ??NET too) is it safe to consider each host machine as a unique identifier? First of all, "usenet" is a method of distributing news around. I guess you are refering to the UUCP network. Second, it's not safe to assume that. There are few hostname collisions left in the table, and you shouldn't be putting csnet and bitnet sites in your data -- they each have a well defined relay point. You don't really need to know what those networks look like -- just bundle up a user%host@relay and shove it to hplabs.hp.com and they'll know what to do with it. That should take care of the Internet, BITNET, CSNET, MAILNET even Australia's ACSNet stuff (ship it out to seismo -- they can handle it). I believe the maps now have some domained uucp addresses, so you shouldn't strip any of the domain information. On ARPA machines, the addresses are case insensitive, so it's rather obvious that the third step in the algorithm above is okay. What about on USENET? No, in the UUCP land, hostnames are case sensitive. You must preserve case. Finally, are there any cases where there are two machines with the same name and differ only on domain? (like 'vax.att.com' versus 'vax.harvard.edu') Like Ron Natalie said, *tons* ... But for UUCP there aren't going to be too many until the domaining starts to take hold -- up until now, most places that wanted to get into the map files had to work something out about namespace collisions (opus -> hropus is the classic example) -- since your Internet mail shouldn't touch the pathalias stuff, you shouldn't have to worry about it for now. Any input on these problems, or (perhaps) other equally successful techniques for searching the database would be appreciated. Well, I think it's pretty evil to take a long path and try to optimize it. It's almost always a bad idea. Mostly because if you have an address like a!b!c!d!e!user you have no idea which "e" that person is on. Maybe it's not a documented machine, but has the same name as one that is in your data, so you change the address to f!g!h!other_e!user, and it bounces. I think it's only feasible (notice I didn't say "reasonable") to do that with an address like user@host.uucp God, I don't want this to turn into net.mail.flame.automatic-routing Speaking of which, is it possible to get the ARPA hostname table? You could uucp it from hplabs.hp.com ... it lives in /etc/hosts Also, has anyone considered modifying pathalias to allow not only the '
' information but also an organizational entry for each machine? The user could then do queries like "Where is this mail from?" "what is this machine?" and so on... Pathalias only cares about the routing information, but John Quarterman wrote some scripts to extract the other information from the maps and there's an RFC (915) which describes a network service for the info. I wrote a server that does this plus can answer queries about the organization, etc. /jordan  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86 21:12:09 EDT Received: from ucbvax.Berkeley.EDU by MC.LCS.MIT.EDU 12 Jun 86 21:11:21 EDT Received: by ucbvax.Berkeley.EDU (5.51/1.14) id AA21221; Thu, 12 Jun 86 18:10:31 PDT Received: by ucbjade.Berkeley.Edu (5.31 (CFC 4.21)/5.4) id AA23659; Thu, 12 Jun 86 18:09:55 PDT Date: Thu, 12 Jun 86 18:09:55 PDT From: netinfo%ucbjade@BERKELEY.EDU (Postmaster + BITINFO) Message-Id: <8606130109.AA23659@ucbjade.Berkeley.Edu> To: header-people@mc.lcs.mit.edu Subject: Re: Zone names The solution is to use one date/time (eg: "UT", "GMT", or "Z") in all date/time fields of messages sent between Mail Transfer Agents (MTA). The military, several governments, civil aviation, and other world-wide communication systems have been doing this for years. I do not recommend having User Agent programs converting UT into local time because humans reference messages by the orginator's name and the date/time of the message. Bill Wells UC Berkeley Academic Computing Services netinfo%ucbjade@Berkeley.EDU  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUN 86 21:34:41 EDT Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 12 Jun 86 21:34:59 EDT Received: from iowa-state by csnet-relay.csnet id ab15313; 12 Jun 86 21:28 EDT Received: by isucs1.UUCP (4.12.01/2.02) id AA23693; Thu, 12 Jun 86 10:43:59 cdt Date: Thu, 12 Jun 86 10:43:59 cdt From: Dave Shaver To: header-people@MC.LCS.MIT.EDU Subject: Questions on ARPA/Domain naming... I'm quoting Dave Taylor with the >'s. > [I]s it safe to consider each host machine as a unique identifier [across > all the networks]? I'm certainly not an expert, but I think you are asking for trouble. It's bad enough trying to get unique hostnames within the UUCP `domain.' > On ARPA machines, the addresses are case insensitive [...] > What about on USENET? Although most people say, "Don't use ANY caps when naming your UUCP host," some people still mix-in uppercase letters. Glacier and Shasta come to mind off the top of my head. I don't know what kind of work-arounds are out there at these hosts, but I'm pretty sure that 'Glacier' is not the same as 'glacier' in the UUCP world. > [...] are there any cases where there are two machines with the > same name and differ only on domain? (like 'vax.att.com' versus > 'vax.harvard.edu') Yes. I believe that's a big reason for having domains. It allows names to be the same, but different since they are in different domains. When naming a host, you only need to worry about being unique within your own region. > [H]as anyone considered modifying pathalias to [...] allow an > organizational entry for each machine? The user could then do > queries [on the real-life location of the machine and whatnot] No need to hack on pathalias. The program uuhosts does all that and more. It accesses the UUCP maps posted to mod.map on USENET. I can supply more information or the program source to those asking. Cheers, /\ Dave Shaver -=*=- Located at Iowa State University -- Ames, IA \/ {okstate,umn-cs,csu-cs}!isucs1!shaver or shaver@iowa-state.CSNET  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 JUN 86 11:18:23 EDT Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 13 Jun 86 11:18:34 EDT Date: Fri, 13 Jun 86 10:45 EDT From: "John C. Klensin" Subject: Re: Zone names To: header-people@MC.LCS.MIT.EDU Message-ID: <860613144509.852045@MIT-MULTICS.ARPA> Bill, The solution -- one date/time system -- is, in essence, what X.400 does. Even if it permits an offset, it at least forces a single system. The problem, in this regard, with RFC822 is that it permits any of three separate systems which, to make things worse, might be described as - one parochial - one confusing and (according to Mark) very hard to cope with on some systems. - and one wrong. ..not that it permits offsets in some form. What I don't understand is your last comment. Would you suggest that the user agents report the time in UT? I used to keep an extra clock on my desk that always showed that, but I bet most of our academic colleagues would dislike the idea. Both "referring to the message I sent to you at