Date: 12 May 1983 2217-PDT From: POSTEL at USC-ISIF Subject: Errors-To, round 2 To: header-people at MIT-MC Here are some remarks in response (and i hope responsive to) the comments on my suggestion for an "Errors-To:" header field. The most often mention concern was the appropriate placement of this type of function in the "envelope" vs in the "message", and the question of the relationship of this proposed header field and the SMTP MAIL FROM command (and its resulting Return-Path: field). Lets look at the existing SMTP mechanism that seems like it might do the job i suggested for Errors-To. This is the information passed from mailer to mailer in the SMTP MAIL FROM command. This information is recorded in the delivered message as the Return-Path: field. This information is intended as an audit trail of where the message actually went. This is also used by mailers to send error reports back when things go wrong with message delivery. So indeed, this SMTP MAIL FROM information could be used to provide the function of sending error reports to the proper place. However, we have to decide what the proper implementation of this information is for the case of a mail exploder like Header-People. There are two views: (1) that there are two separate mail transactions - (a) the author sends a message to the exploder, and (b) the exploder send the message to the list; and (2) there is one transaction - the author send the message to the list via the exploder mailer as a relay. In the first case, we would have in the first transaction a path back to the author, but in the second transaction a path bact to the exploder (perhaps even the list maintainer). In the second case we would have a path back to the author via the exploder host. If the implementation were required to be the first case, there might not be any call for any other mechanism such as the suggested Errors-To. The current implementation of the exploder function on MIT-MC is the second case. I suggest that we seriously consider requiring the two transaction model. Comments on this? There is another example for the potential use of Errors-To that might not be properly handled by using the SMTP MAIL FROM information. There is an application level service that uses computer mail to interact with its customers. That is, there is a program that takes its input from incoming mail and produces as output outgoing mail. It would really like to have reports of delivery errors in its outgoing mail sent to a different mailbox than its primary input mailbox. For example, lets call the primary mailbox of the application APPSRV, and the mailbox for error reports APPERR. Users of the application send mail to APPSRV and may in the content of the message give information that causes the application to try to send mail to an arbitrary mailbox (perhaps one different from any indicated in the header of the input message). When the application sends the message it is appropriate for it to be from APPSRV and if the mail is delivered sucessfully replies should be sent to APPSRV, but if something goes wrong it would be best if the error reports went to APPERR. It is not at all clear how the application as an ordinary user of the mail system can influence the error reports to go to a special error reports mailbox. Since the SMTP MAIL FROM information is an audit trail, it does not seem appropriate to fudge the apparent starting point to be APPERR. We ought, also, to consider the larger world where mail procedures other than SMTP are used, but do use headers at least similar to the 822 headers. In this world there are also mailing lists and the possibility that error reports should be sent to other than the author of a message. There were some suggestions that while "Errors-To" was a nice idea, it was a pretty small one, and there were lots of other factors that should be considered. That is, the notion should be generalized. Fine. There is room for many proposals for features in the context of the current mail rules. One does need to be careful of syntax and parsing though. Suggestions that have lots of keywords and parameters that can occur in many combinations don't fit well with the current syntax rules. It was mention that if Error-To is accepted as the way to do this, it should be clear that if there is an error and there is no Errors-To the report goes to the author (From:). If my suggestion that the mailing list exploder insert the Errors-To field in the message is followed, there is a question about what happens if there is already an Errors-To field? Does the program inserting an Errors-To have to search the header to see if there is one already, and (a) not insert its own if there is, or (b) delete the existing one and replace it with a new one. Or, does the program just blindly add a new Errors-To? And if there is an error and there are multiple Errors-To fields which one is used to report the error? The first one found? All this would have to be specified in detail. For this discussion i would like to focus on the functionality of what i have suggested, and the issue of doing the job at the SMTP MAIL FROM level of the Errors-To header field level. --jon. -------  Date: 13-May-83 00:02 PDT From: RICH.GVT@OFFICE-3 Subject: Re: Errors-To ??? To: POSTEL@USC-ISIF Cc: header-people@MIT-MC Message-ID: <[OFFICE-3]GVT-RICH-2E7BF> In-reply-to: EXT-POSTEL-2E6NV I thought the Return-Path was supposed to fulfill exactly that function; am I wrong? -Rich  Date: Fri 13 May 83 23:57:55-PDT From: Mark Crispin Subject: Re: Errors-To, round 2 To: POSTEL@USC-ISIF.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "POSTEL at USC-ISIF" of Thu 12 May 83 22:17:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) With some greater thought on my part, I am now opposed to the idea of an Errors-To header line, and greatly supportive of an SMTP enhancement that implements this functionality. In other words, something like: MAIL FROM: ERRS TO: RCPT TO: Of course, SMTP senders must be prepared to receive 500 errors from various SMTP receivers, since nobody presently implements this. It is then up to the SMTP sender to properly specify this. -- Mark -- -------  Date: 14 May 83 19:54:59 MDT (Sat) From: lepreau@utah-cs (Jay Lepreau) Subject: Re: Errors-To, round 2 Message-Id: <8305150154.AA12556@UTAH-CS.ARPA> Received: by UTAH-CS.ARPA (3.320.6/3.7.9) id AA12556; 14 May 83 19:54:59 MDT (Sat) To: header-people@mit-mc A problem with putting Errors-To strictly in the SMTP messages is that it won't work over non-SMTP channels. There are a lot of them in the little-i-internet. (It turns out that Eric Allman's sendmail has supported an Errors-To header line for a long time. And domains, and ....)  Date: Sat 14 May 83 19:30:41-PDT From: Mark Crispin Subject: Re: Errors-To, round 2 To: lepreau@UTAH-CS.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "lepreau@utah-cs (Jay Lepreau)" of Sat 14 May 83 19:54:59-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) My experience as a little-i-internet implementor is that the non-Internet networks are either going to have totally cooperative individuals who will go all out to assist internet mailing with Internet, or totally uncooperative individuals who think they're completely right and the rest of the universe is wrong. In some cases, you have both. What I am trying to say that if the Errors-To functionality is useful enough for the non-Internet implementors to do something about it, they'll create some means to send it out of band of the message header, just as I'm proposing would be done with SMTP. If not, they won't teach their mailers to parse Errors-To in the header. Because of this, I don't think this is a problem. It is much easier (and more reliable) for my internet mailer to use the Errors-To information in a transaction if it received it in the message transport instead of having to parse a message header. We on Internet should do things right. Our responsibility to internet is not to preclude internet mailing; and in this our weakest point is that we have no way of having absolute internet addresses that are acceptable to Internet. The cleaner and more robust our protocols, the better our arguments for convincing non-Internet networks to use them. I know of several DECnets which are going over to use SMTP layered over DECnet, simply because SMTP is better. -------  Received: from Sierra by SCORE with Pup; Sat 14 May 83 20:09:04-PDT Date: 14 May 1983 20:04 PDT (Sat) From: David Eppstein To: Header-People@MIT-MC Subject: Errors-to: I think it is better to have a SMTP command for this functionality than to keep it in the message headers. This would most likely be easier for most SMTP-based mail systems to deal with. Also, it makes it easier to have multiple error-to recipients. Suppose mail comes in to MIT-MC for List@MC and AnotherList@MC. MC notices that in List@MC there is a recipient Foo@Score and in AnotherList there is recipient Bar@Score. The mailer wants errors for Foo to go to List-Request and Bar to go to AnotherList-Wizards. It could accomplish this using Errors-to: by building two different sets of headers and delivering the message twice to Score, once for Foo with Errors-to: List-Request and the other time to Bar. If error disposition were handled in SMTP the whole thing might be done in one transaction, as ... ERRS TO: RCPT TO: ERRS TO: RCPT TO: ... If there were recipients with no explicit error handler address after the mailing lists the sending mailer should probably do another ERRS with the original sender as argument. Of course, this causes problems for mail forwarding to non-arpa sites. One possible solution to this would be to also support Errors-to: header fields. Presumably SMTP error dispositions would override anything in the message headers. David  Date: Sat, 14 May 83 12:16:25 CDT From: David.Chase Return-Path: Subject: Amused, or disgusted?? To: header-people@mit-mc Message-Id: <1983.05.14.12.16.25.350.00129@dione.rice> Via: Rice; 14 May 83 23:31-PDT Thought you might be interested: ------------------------------------------------------------------------------ Date: 13 May 83 08:18:46 PDT (Fri) From: fateman%UCBKIM@Berkeley Return-Path: Received: from UTEXAS-20 by UTEXAS-20; Fri 13 May 83 17:08:06-CDT Received: from UCBVAX by UTEXAS-20; Fri 13 May 83 10:40:34-CDT Received: by UCBKIM.ARPA (3.310/3.5) id AA05323; 13 May 83 08:18:46 PDT (Fri) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.339/3.28) id AA00474; 13 May 83 08:37:35 PDT (Fri) Received: from UTEXAS-20 by rand-relay.ARPA ; 13 May 83 16:06:20 PDT (Fri) Subject: Re: VAX Pictures? ? Mail-From: CC.PADGETT created at 13-May-83 14:21:44 Return-Path: Message-Id: <8305131518.5323@UCBKIM.ARPA> To: CC.PADGETT@UTEXAS-20 Remailed-Date: 13 May 1983 1421-CDT Remailed-From: Steve Padgett Remailed-To: info-graphics@UTEXAS-20 Remailed-Date: 13 May 1983 1707-CDT Remailed-From: Steve Padgett Remailed-To: info-graphics@UTEXAS-20 Via: UDel; 13 May 83 21:44-CDT there are tools of this nature in use at Bell Labs that work with UNIX and TROFF. There are picture-drawing tools at UC Berkeley, but they produce separate pictures (which have to be pasted in). ------------------------------------------------------------------------------  Date: 15 May 1983 0707-PDT (Sunday) From: mo@LBL-CSAM Subject: Re: Errors-To and Sendmail Return-Path: Message-Id: <8305151407.AA05300@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.320/3.21) id AA05300; 15 May 83 07:07:24 PDT (Sun) To: lepreau@utah-cs (Jay Lepreau) Cc: header-people@mit-mc In-Reply-To: Your message of 14 May 83 19:54:59 MDT (Sat). <8305150154.AA12556@UTAH-CS.ARPA> Sendmail also tries to implement an automatic Errors-to: facility for mailing lists it supports. It infers a standard destination from the list title and checks the alias database to see if it is defined. If so, error indications regarding list delivery go to that mailbox. -Mike  Date: 15 May 1983 0715-PDT (Sunday) From: mo@LBL-CSAM Subject: Re: Errors-To: Against out-of-band Errors-to: Return-Path: Message-Id: <8305151415.AA05339@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.320/3.21) id AA05339; 15 May 83 07:15:59 PDT (Sun) To: Mark Crispin Cc: header-people@MIT-MC.ARPA In-Reply-To: Your message of Sat 14 May 83 19:30:41-PDT. <8305150239.AA01563@LBL-CSAM.ARPA> But Mark, putting the Errors-to: information in the header is one way we can help little-i-internet people do the right thing. HOWEVER, If we are going to FINALLY get religion about separation of Church and State, er, Message and Envelope, then we need to move a bunch of other stuff also. Joe Sventek long ago suggested an ENVELOPE command for SMTP wherein all the header-ish lines (return-path:, hop-by-hop recieved: lines, other postmarks) comprising the envelope would go across with the DATA/. subprotocol, followed by a MESSAGE command for the body. This would allow VERY useful facilities like end-to-end encryption of messages, including "headers". This has been a sore spot for a long time - the current mail system is modelled more on "memos" than on "letters". In fact, we could keep the current MAIL command for existing format letters (mixed-mode message/envelope stuff) and add ENVELOPE and MESSAGE commands (terminated by bare . lines) so people could evaluate the new model. Yours for bigger and better bugs, -Mike  Date: 7 Apr 1977 1712-EST From: Bob Chansler at CMU-10A Reply-To: Lord High Executier@CMU-10A Subject: Re: Close, but no cigar To: BRIAN.REID at CMU-10A CC: chansler@CMU-10A Sender: BOB.CHANSLER at CMU-10A Message-ID: [CMU-10A] 7 Apr 1977 17:12:49 Bob Chansler In-Reply-To: Your message of April 6, 1977 My-Seq-#: 39492094 Yr-Seq-#: 4992488 Class: A Subclass: MCMXLVII Author: fred Typist: fred Terminal: TTY88 FE-L#: 44 Reason: Did Godzilla need a reason? Valid: Not before 12 Apr 1977 1321Z Suspend: After 19 Apr 1977 0000Z Spelling-errors-this-message: 0 Spelling-errors-to-date: 23 Weather: Light rain, fog. Forcast: Clearing by morning Psych-evaluation-of-sender: slightly unstable Security-level: Public Security-sublevel: 0 Authority-to-send: general Authority-to-rcv: general #-people-in-terminal-room: 12 XGP: UP-cutter not working Ht/Wt-sender: 76/205 Machines: M&Ms available but almond machine is empty M&Ms-Last-Nickel: 17 Remailed-To: John.Zsarnay at CMU-10A Remailed-From: Peter.Schwarz at CMU-10A Remailed-Date: Saturday, 22 September 1979 0155-EDT Origin: C410PS20 at CMU-10A; 22 Sep 1979 0155-EDT Remailed-To: Mike.Accetta at CMUA Remailed-From: John.Zsarnay at CMU-10A (A650JZ04) Remailed-Date: 22 September 1979 1615-EDT Origin: A650JZ04 at CMU-10A; 22 Sep 1979 1616-EDT Remailed-To: Fil.Alleva at CMU-10A Remailed-From: Mike Accetta (A650MA33) Remailed-Date: Saturday, 22 September 1979 2004-EDT Via: CMU-10A; 22 Sep 1979 2006-EDT Remailed-To: Ken.Wertz at CMU-10B Remailed-From: Fil.Alleva at CMU-10B (A650FA33) Remailed-Date: Monday, 24 September 1979 1023-EDT Via: CMU-10B; 24 Sep 1979 1025-EDT Remailed-To: Don.Provan at CMU-10A Remailed-From: Krafty Ken Wertz Remailed-Date: Monday, 24 September 1979 1029-EDT Origin: C425KW0F at CMU-10A; 24 Sep 1979 1036-EDT Remailed-To: Carolyn.Councill at CMU-10A Remailed-From: don.provan at CMU-10A Remailed-Date: Monday, 24 September 1979 1054-EDT Origin: C425DP0N at CMU-10A; 24 Sep 1979 1055-EDT Remailed-To: Eddie.Caplan @ CMUA Remailed-From: Carolyn.Councill at CMU-10A (C425CC33) Remailed-Date: Monday, 24 September 1979 1631-EDT Origin: C425CC33 at CMU-10A; 24 Sep 1979 1632-EDT Remailed-To: lawrence.butcher at CMU-10A Remailed-From: eddie caplan Remailed-Date: 24 September 1979 1634-EDT Origin: C425EC0F at CMU-10A; 24 Sep 1979 1635-EDT Remailed-To: Mike Kazar at CMU-10A, Craig Everhart at CMU-10A Remailed-From: Lawrence Butcher at CMU-10A (X335LB50) Remailed-Date: Tuesday, 25 September 1979 1811-EDT Origin: X335LB50 at CMU-10A; 25 Sep 1979 1812-EDT Remailed-To: sipb @ mc Remailed-From: Mike Kazar (C410MK50) Remailed-Date: Wednesday, 26 September 1979 0009-EDT I do not understand your concern about the size of message headers. -------  Date: Sun 15 May 83 10:07:25-PDT From: Mark Crispin Subject: Re: Errors-To: Against out-of-band Errors-to: To: mo@LBL-CSAM.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "mo@LBL-CSAM" of Sun 15 May 83 07:15:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Not at all, Mike. If the little-i-internet people want the Errors-To information, they can enhance their mail transport protocol to allow it. The mail relay is quite capable of interchanging from one to another if it is done in any reasonable fashion. This could even be done as an Errors-To: line in a header for some network, but that is really ugly. -------  Date: 15 May 1983 1242-PDT From: ROODE at SRI-NIC (David Roode) Subject: Errors to revisited To: header-people at MIT-MC, postel at USC-ISIF Location: EJ296 Phone: (415) 859-2774 What a flap! I hope the needed functionality does not get forgotten in all the hoopla. The problem is in sending to a large mailing list, some people would like the errors returned to them, and some people want "someone else" to handle them. The problem is the volume of errors can be quite large and so it may not be operationally practicable to count on this "someone else" so it is a best effort, not a guarantee. I submit that the specification of an arbitrary place to direct errors is too powerful. What if the specified mailbox does not LIKE getting these errors! I believe what we need to do is to extend SMTP to provide for a special type of message known as a "report". RPRT FROM: would behave exactly like MAIL FROM: except that all the recipients would have a transformation applied to them. The message would go to whomever is accepting errors for that mailbox, if any, else discard. Mailers and SMTP servers could use this however they chose. In the headers, I would propose an option with a fixed set of values. "Errors-to" would be okay, but perhaps "Msg-status to:" would be better. The arguments would be "sender", "recipient-mailer", or "both." -------  Date: 15 May 1983 1625-EDT (Sunday) From: don.provan@CMU-CS-A To: header-people@MIT-MC Subject: errors to: Message-Id: <15May83.162513.DP0N@CMU-CS-A> i still don't understand how this "errors-to" destination differs from the "return-path". the idea of the "return-path" being an audit trail doesn't jive with anything i read in the RFCs. the "received" lines are an audit trail, but nothing seems to indicate that "return-path" needs to agree with them. i can't think of a single situation that someone sending mail to an exploder would want to get an error report, except if the sender wanted to maintain the exploder. but if there is some justification, why not add the information to the actual MAIL command? presumably the "from:" is there just for the syntax "mail from: errors:" or some such. no need for a separate command. (you can add it to the RCPT line if you want it different for different recepients.) but can anyone give me an example where "return-path" isn't correct? if so, what's the difference between the errors my server should report to the return-path and the errors it should report to errors-to. i'm glad you all agree for the need, but can someone let me in one the secret?  Date: 15 May 1983 1536-PDT From: ROODE at SRI-NIC (David Roode) Subject: Re: errors to: To: don.provan at CMU-CS-A, header-people at MIT-MC Location: EJ296 Phone: (415) 859-2774 In-Reply-To: Your message of 15-May-83 1325-PDT The return path is supposed to be a way to reach the SENDER, not the person interested in errors, although some might assume these to be the same thing. It is supposed to be a path that can be followed if expansion /interpretation of the address of the sender fails for whatever reason, and is defined to be constructed via such a mechanism that classifying it as an audit trail is not unreasonable. -------  Date: 15 May 1983 1943-EDT (Sunday) From: don.provan@CMU-CS-A To: ROODE@SRI-NIC (David Roode) Subject: Re: errors to: CC: header-people@MIT-MC In-Reply-To: "ROODE@SRI-NIC's message of 15 May 83 17:36-EST" Message-Id: <15May83.194354.DP0N@CMU-CS-A> what you say is fine with me, but does not agree with RFC821. RFC821 specifically says that the return-path is where errors should be sent. there's no indication that it needs to have anything whatsoever to do with the sender. in fact, there was one peice of mail that passed through my server that had "mailer" in this field, even though it was a perfectly normal piece of mail. are we planning to change the meaning of this, or what?  Date: 15 May 1983 1808-PDT From: ROODE at SRI-NIC (David Roode) Subject: Re: errors to: To: don.provan at CMU-CS-A cc: header-people at MIT-MC Location: EJ296 Phone: (415) 859-2774 In-Reply-To: Your message of 15-May-83 1643-PDT I think we are both right, but are placing emphasis on different aspects of 821's definition. On page 24 of the August 1982 RFC 821, it says, relating to the argument to the "MAIL FROM:" command, which constitutes the "Return-path" header line: The reverse-path consists of an optional list of hosts and the SENDER mailbox. When the list of hosts is present, it is a "reverse" source route and indicates that the mail was relayed through each host on the list (the first host in the list was the most recent relay). This list is used as a source route to return non-delivery notices to the SENDER. As each relay host adds itself to the beginning of the list, it must use its name as known in the IPCE to which it is relaying themail rather than the IPCE from which the mail came (if they are different). This does not allow the return of errors other than to the SENDER mailbox (I added the capitalization of this word in the quotes paragraph). So I see the germane interpretation of this as being "here is a bullet-proof way to get to the sender" with a secondary idea of "send errors to the SENDER". You seem to see it as "here is the way to return errors" with a secondary "the routing style of specification makes it bullet proof" and discount the emphasis that this is the SENDER being refered to. What I think needs to be addressed is a whole different class of errors, for which it is not desirable to reach the sender. Specifically, if I send to "mail-wizards" at BBN-UNIX, one class of errors concerns getting the message to BBN-UNIX, and having it accepted for processing there, and a second class of errors would be those that BBN-UNIX encounters in processing some part of the "fan-out" of "mail-wizards" which are quite different. I think the first type consists of functional errors which should always go to the sender (using reverse path if need be) and the second type are highly dependent on the context of the remote mailer once it has received the message, and so the sender may not wish to see these errors. Existing mailers have various defacto standards for deriving "responsible party" addresses for certain other "addresses" so that is what I have in mind as being the action taken by the remote mailer if told the sender did not want to see errors, with no particular one of the defacto standards being preferred. Perhaps the sender should be force-fed errors if no other "responsible party" was available. Regarding the Return path specification of "Mailer" that you have seen, I would be concerned about that too. Some of the TOPS-20 mailers do not preserve the reverse path specified to them, and then reconstruct one based on the sender as specified in the headers. This is motivated by the need to not include the return path as a header if the message is relayed. The best strategy would be to preserve the reverse path, but to remove it from the headers on the message when relaying, while at the same time using it to generate the reverse path provided to the SMTP server receiving the relayed copy. -------  Date: 15 May 1983 1825-PDT From: ROODE at SRI-NIC (David Roode) Subject: consider this model: To: Header-people at MIT-MC Location: EJ296 Phone: (415) 859-2774 SMTP is neither the envelope nor the message, but rather something else, the transport protocol. Multiple message/envelope pairs may result from one SMTP transaction. Sure, "errors-to" belongs in the envelope, but the true envelope of arpanet messages has always been the headers. Usually headers have been for the use of the user agent, but in the "fan-out" situation, the "mailer" is acting precisely as a cross between a server and a user agent. If "fan-out" is not involved, then the use of "errors-to" would be superfluous. -------  Date: 15 May 1983 2136-EDT (Sunday) From: don.provan@CMU-CS-A To: ROODE@SRI-NIC (David Roode) Subject: Re: errors to: CC: header-people@MIT-MC In-Reply-To: "ROODE@SRI-NIC's message of 15 May 83 20:08-EST" Message-Id: <15May83.213642.DP0N@CMU-CS-A> but on page 22 it says, "It is possible for the mailbox in the return path be different from the actual sender's mailbox." no wonder we don't agree: the RFC contradicts itself. your example is easily handled by the return-path, since the mail on the way to the exploder has you in the return-path and the mail going from the exploder could have a maintanence account in the return-path. this makes sense to me because i see this as two separate transactions, not one that bounces off the exploder. i don't see the mail i receive from the exploder as being from you (although replies will go to you since your from and reply-to lines are still valid) but rather i see them as being from the mailing list. but of course none of this is valid if the return-path is supposed to be used to route mail back to the originator (as opposed to the sender in the current transaction).  Date: 15 May 1983 2227-PDT (Sunday) From: mo@LBL-CSAM Subject: Re: consider this model: Return-Path: Message-Id: <8305160527.AA11191@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.320/3.21) id AA11191; 15 May 83 22:27:04 PDT (Sun) To: ROODE@SRI-NIC (David Roode) Cc: Header-people@MIT-MC In-Reply-To: Your message of 15 May 1983 1825-PDT. <8305160136.AA09742@LBL-CSAM.ARPA> "the true envelope of arpanet messages has always been the headers" And that, I submit, is at the core of the problem. The Post Office is entirely capable of transferring a letter without access to its contents (in fact, its employees go to jail for violating this proviso - mail implementers, contemplate such a charge!). The sooner we start thinking in terms of electronic Mail instead of electronic Memos the sooner this mess will clear. I don't write messages on the outside of envelopes and the Post Office doesn't have to open my mail to deliver it. -Mike  Date: 16 May 83 01:31:46 PDT (Mon) From: wcwells%Topaz.CC@Berkeley Subject: Re: consider this model: Message-Id: <8305160830.AA00610@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA00610; 16 May 83 01:30:00 PDT (Mon) To: ROODE@SRI-NIC Cc: header-people@mit-mc In reply to: Date: 15 May 1983 1825-PDT From: ROODE@SRI-NIC (David Roode) Subject: consider this model: SMTP is neither the envelope nor the message, but rather something else, the transport protocol. ... the true envelope of arpanet messages has always been the headers. I concur. My "basic message format" is an attempt to better define the "header envelope". Bill Wells topaz.wcwells@BERKELEY.ARPA  Date: 16 May 1983 11:42:42-EST From: Christopher A Kent Reply-to: cak@purdue.ARPA To: mo@LBL-CSAM Cc: ROODE@SRI-NIC, Header-people@MIT-MC Subject: Re: consider this model: In-reply-to: Your message of 15 May 1983 2227-PDT (Sunday). <8305160527.AA11191@LBL-CSAM.ARPA> Message-ID: Hear hear! I'd like to see the separation of envelope and message, too. I am tired of having to see all the junk in the headers as part of the text, when I just want to see the what the sender intended. chris  Date: 16 May 83 17:19:33 EDT (Mon) From: mhb5b!smb@Berkeley (Steven M. Bellovin) Subject: errors-to Message-Id: <8305162110.AQ09368@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AQ09368; 16 May 83 14:10:28 PDT (Mon) To: header-people@mit-mc If there's an "Errors-To" line, there needs to be a "Remailed-Errors-To" as well. That will differentiate between errors in a message being sent to the exploder, and errors in the message from the exploder. --Steve  Date: 16 May 83 16:01:45 PDT (Mon) From: wcwells%Topaz.CC@Berkeley Subject: Re: Errors-To, round 2 Message-Id: <8305162306.AA01440@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA01440; 16 May 83 16:06:50 PDT (Mon) To: MRC@SU-SCORE Cc: POSTEL@USC-ISIF, header-people@MIT-MC Mark, In reply to: Date: Fri 13 May 83 23:57:55-PDT From: Mark Crispin Subject: Re: Errors-To, round 2 Message-Id: <8305161328.AA02730@UCBVAX.ARPA> With some greater thought on my part, I am now opposed to the idea of an Errors-To header line, and greatly supportive of an SMTP enhancement that implements this functionality. In other words, something like: MAIL FROM: ERRS TO: RCPT TO: Of course, SMTP senders must be prepared to receive 500 errors from various SMTP receivers, since nobody presently implements this. It is then up to the SMTP sender to properly specify this. It may work for SMTP, but the world is not all SMTP. How is the non-SMTP mail system going to specify this? Bill Wells topaz.wcwells@BERKELEY  Date: 16 May 1983 1756-MDT From: Lepreau@UTAH-20 (Jay Lepreau) Subject: Re: consider this model: To: cak@PURDUE cc: mo@LBL-CSAM, ROODE@SRI-NIC, header-people@MIT-MC In-Reply-To: Your message of 16-May-83 1042-MDT Chris, that's no argument-- any decent mail reader can suppress display of the user's choice of header lines. To speak to your personal situation, Unix mailers, in particular, used to lack in this respect, but there are versions of Mail with that feature and Spence has hacked on Gosling's Emacs rmail package to do the same. Given its design, I'm sure MH trivially can suppress headers also. You are welocme to have our Mail and rmail.ml. (If that is not good enough, if you want to have just "what the sender intended" be displayed, as you stated in your msg, then a new header could be supported: "Display-these-non-std-headers." Just what we always wanted, a header to suppress headers! I think there are more important problems, and better solutions to that one....) Sure, we should move all the envelope info out of the message, but remember that this is the SIMPLE Mail Transfer Protocol, and I believe explicitly intended as an interim protocol while the general multi-media super-hot general case gets worked out. It was not intended to be "perfect" but to address (sic) the worst problems while not being too radical a departure from the past. Thus its ramifications would not be too difficult to understand, nor its implementation too difficult. Of course, it and 822 will be around for years.... Jon, correct me if I'm wrong (although I'm sure others will take the opportunity as well). -------  Date: 16 May 1983 1749-PDT Sender: BILLW at SRI-KL Subject: Re: Errors-To, round 2 From: BILLW at SRI-KL To: wcwells%Topaz.CC at BERKELEY Cc: MRC at SU-SCORE, POSTEL at USC-ISIF, Cc: header-people at MIT-MC Message-ID: <[SRI-KL]16-May-83 17:49:47.BILLW> In-Reply-To: <8305162306.AA01440@UCBVAX.ARPA> Sure, the ERRS TO smtp command will only work in a SMTP environment. However, there is nothing to stop gateway machines from removing such a command from the envelope (SMTP commands) and putting it in the message itself as an ERRORS-TO header line or whatever. There shouldnt be anything stopping each network (as defined by mail transmission protocols) from using whatever mechanism is best for ITS own use. This of course requires a little more effort on the part of mail gateways, but this is required anyway. [Eg: Although on the Internet, it is generally considered a bad idea to munge the internal headers of a message, this is a common practice going to and from the UUCP world] I think it is relatively clear that in an SMTP environment, it makes more sense to have this information outside of the message. Note that just having seperate HEADERS and MESSAGE commands doesnt necessarilly solve problems because of the extensible nature of rfc822. Having a seperate HEADERS section implys that all of the headers therin should be parseable by any mail receiver, and this is extremely unlikely (Around here, we even have messages going out over our local nets that have things like ROUTE: TWX 123456... in them) BillW  Date: 16 May 1983 1756-PDT Sender: BILLW at SRI-KL Subject: Re: consider this model: From: BILLW at SRI-KL To: Lepreau at UTAH-20 Cc: cak at PURDUE, mo at LBL-CSAM, ROODE at SRI-NIC, Cc: header-people at MIT-MC Message-ID: <[SRI-KL]16-May-83 17:56:57.BILLW> In-Reply-To: Your message of 16 May 1983 1756-MDT HERMES, as an example of a good mail reading program, allows multiple user defined templates for printing messages (also for composing messages, dispaying headers, etc). Thus while my normal template prints out only relevant fields, I can print out the message using LONG-PRINT-FORM, and see everything. BillW  Date: 16 May 1983 1749-PDT Sender: BILLW at SRI-KL Subject: Re: Errors-To, round 2 From: BILLW at SRI-KL To: wcwells%Topaz.CC at BERKELEY Cc: MRC at SU-SCORE, POSTEL at USC-ISIF, Cc: header-people at MIT-MC Message-ID: <[SRI-KL]16-May-83 17:49:47.BILLW> In-Reply-To: <8305162306.AA01440@UCBVAX.ARPA> Sure, the ERRS TO smtp command will only work in a SMTP environment. However, there is nothing to stop gateway machines from removing such a command from the envelope (SMTP commands) and putting it in the message itself as an ERRORS-TO header line or whatever. There shouldnt be anything stopping each network (as defined by mail transmission protocols) from using whatever mechanism is best for ITS own use. This of course requires a little more effort on the part of mail gateways, but this is required anyway. [Eg: Although on the Internet, it is generally considered a bad idea to munge the internal headers of a message, this is a common practice going to and from the UUCP world] I think it is relatively clear that in an SMTP environment, it makes more sense to have this information outside of the message. Note that just having seperate HEADERS and MESSAGE commands doesnt necessarilly solve problems because of the extensible nature of rfc822. Having a seperate HEADERS section implys that all of the headers therin should be parseable by any mail receiver, and this is extremely unlikely (Around here, we even have messages going out over our local nets that have things like ROUTE: TWX 123456... in them) BillW  Date: Mon 16 May 83 18:40:51-PDT From: Mark Crispin Subject: Re: Errors-To, round 2 To: wcwells%Topaz.CC@UCB-VAX.ARPA cc: POSTEL@USC-ISIF.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Message from "wcwells%Topaz.CC@Berkeley" of Mon 16 May 83 16:01:31-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Bill - If the non-SMTP people want this functionality, they can implement it in their transport protocol. I believe it is just as simple to put it in the transport protocol as it is to parse a header line, especially as any reasonable transport protocol has provisions for new options and ignoring unknown options. -- Mark -- -------  Date: 17 May 1983 1038-PDT (Tuesday) From: eric%UCBARPA@Berkeley (Eric Allman) Subject: Re: Errors-To, round 2 Message-Id: <28949.31.422041139@ucbarpa> Received: by UCBARPA.ARPA (3.340/3.28) id AA28950; 17 May 83 10:39:02 PDT (Tue) Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.339/3.28) id AA14623; 17 May 83 10:32:43 PDT (Tue) Phone: (415) 548-3211 To: header-people@mit-mc Fcc: mail Although I agree that the Errors-To: info belongs in the envelope, it is not at all clear to me that the SMTP exchange represents the envelope. Perhaps it should, but it most certainly does not. At least the following lines in the headers belong in the envelope: Received: Return-Path: Errors-To: Resent-Date: Resent-Cc: Resent-To: Resent-Bcc: Resent-Message-Id: Encrypted: The NBS standard also defines some others: Return-Receipt-To: Circulate-To: Circulate-Next: Posted-Date: End-Date: Received-Date: Recipient-Serial-Number: Precedence: I suppose we could put these all in the SMTP protocol, but this does not handle the fundamental problem that the SMTP protocol is not extensible. As such, new envelope fields require a change to untold numbers of implementations. Contrast this with the header fields, where new fields can be added as required. On the other hand, "wrapping" is not cleanly handled in the headers. I consider wrapping one of the fundamental functions of envelopes. You create a message, then wrap it in an envelope. If you want to forward the message (e.g., send it off to your lawyer), you wrap the old envelope in a new envelope. For example, consider the case of a message that has been redistributed several times. The header can potentially have several Resent-*: fields, and since order is specifically insignificant in the header, it is not in general possible to recreate the wrapping. I would propose something like the following. I do not claim that I would do it this way if I were designing the protocols from scratch. Header fields that are in the "envelope" could be preceeded by a special character, say an "@". When a message gets wrapped, previous header lines have another "@" prepended. This would make it easy for mail readers to strip off envelope lines. It is extensible. It highlights the wrapping. For example: @Return-Path: @Received: by your-host from utah-cs ... @@Return-Path: @@Received: by utah-cs from lbl-csam ... @@@Return-Path: <@MIT-MC:eric@Berkeley> @@@Received: by MIT-MC from Berkeley ... @@@Received: by lbl-csam from MIT-MC ... From: Subject: Re: Errors-To:, round 2 To: header-people@mit-mc @@Message-Id: @@From: @@To: @Message-Id: @From: lepreau@utah-cs @To: you@your-host @@@Message-Id: Ok, it's ugly as sin -- but presumably those lines with "@"s are going to be stripped off..... Yours for bigger and better arguments, eric  Date: 17 May 83 11:46:31 EDT (Tue) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Errors-to Message-Id: <8305171546.AA12081@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA12081; 17 May 83 11:46:31 EDT (Tue) Received: by UCBVAX.ARPA (3.339/3.28) id AA00609; 17 May 83 16:24:56 PDT (Tue) To: header-people@mit-mc.ARPA The thing that bothers me about putting the errors-to info into something other than the headers (e.g. an SMTP command) is that this is a bottleneck that would tend to get lost. Some mail systems don't remember non-header information at all. UUCP remembers the "to" address and the text of the message, but nothing else. Any mail sent through UUCP would lose the Errors-To unless it were put into the header. I don't know about MMDF or BITNET but I wouldn't be surprised at a similar result. I'm also worried about existing SMTP implementations being upgraded to support this. If you put the info in the headers, even dumb mailers will pass it along. But if you add a new SMTP command, it will be lost at the first forwarder that doesn't understand it. Mark  Date: 18 May 83 2:27:07 EDT (Wed) From: Doug Kingston To: Mark Horton cc: header-people@mit-mc.arpa Subject: Re: Errors-to I have been quiet until now on the subject of Errors-to: but I think a few of comments are necessary at this time. I am currently the primary implementer for the MMDF system and as part of my work I have implemented a special processor (channel) for handling mailing lists in an intelligent fashion. This entails doing address verification after submission and somehow causing errors to return to the list maintainer instead of the original sender. My first implementation is going to supply an alternate "MAIL FROM:" address to the receiving host. The address to be supplied will be the first found from the following group: a special table entry, -request, original sender, and finally Postmaster. I strongly favor the development of a mechanism for specifying the address to which returned mail should be sent. By "returned mail" I mean mail that is being returned, probably by an automated system (MMDF, SENDMAIL, MAISER, ...), but possibly by a local Postmaster because the mail could not be delivered to the intended recipient. There are two problems to be faced. The first is an immediate need for an alternate return address that MRC, Eric, myself, and others can implement now to spare the contributers of a large number of lists the agony returned messages they can do nothing about. This first problem has to be solved in a manner that will work in the existing system without breaking existing mailers. For the time being, the alternate MAIL FROM: is the only option that will produce results. The second problem is to develop a more explicit mechanism to accomplish the same thing. A method needs to be decided upon, an RFC written, deadlines set and implementation started. From an implementation standpoint I favor passing the Errors-To information in the SMTP level, which is the same level that you pass the Sender and the Recipient addresses. This layer is designed for easy machine interpretion and is the "proper" layer for this information. We don't search the header for the recipients, or the Sender, why should we break the pattern for the error recipient. In addition, I concur that I would prefer to keep the mailer out of the header as much as possible. Remember, in almost all cases, the Errors-To information is going to be generated by the mail-system at some foreign host. This is not to say that I couldn't implement it as a header line, I will probably be one of the first to implement whatever standard is chosen. I am sensitive to the needs of UUCP and other protocols that may not be as capable as SMTP at mail transfer. And don't think that you can easily change any of these protocols. Old protocols die hard. MMDF, SENDMAIL, or any other reasonably intelligent mailer that is serving as a forwarder for one of these lesser protocols will have little or no trouble in supplying the Errors-to address in whatever form the protocol desires. I suspect that in many cases, we will find that the other protocol will have no parallel to Errors-To. The UUCP community is attempting to become as compatable as possible with the ARPA mail standards; the same is probably not true of others. One other anomaly that needs to be discussed is the use of a single Errors-To: or per-addressee Errors-To: fields. Consider for example.... I am a mail-list exploding host's mailer. "Jill" at my host sends a letter to "Jack@Hill, Hill-list". "Hill-list" expands to "a@Hill, b@Hill, c@Hill". I have a address list that looks like "Jack@Hill, a@Hill, b@Hill, c@Hill". The "Hill-list" is maintained by DPK@BRL. Ideally, any error on the address "Jack@Hill" should be sent to original sender, Jill. Any errors on "a", "b", or "c" at Hill should be send to DPK@BRL. This seems to suggest that a per-address specification is necessary in our long-term, ?generalized? solution. I can tell you from experience that this situation occurs on a regular basis in local mail networks where you have messages being exchanged between principals of a project with Cc:'s to local interest lists. Given that you accept the need for a "per-addressee" Errors-To address, the consequences of putting this information in the header are scary. This reinforces my initial feelings that the Errors-to should be given as an ?optional? command in the SMTP exchange. __ / \______ __/ \/______) Returned to Sender... (_) -Doug- __ (_) \___(_)  Date: 18 May 83 4:06:01 EDT (Wed) From: Doug Kingston To: header-people@mit-mc Subject: Separation of Envelope and Header I also support the separation of the "header" as originally sent, and the "envelope" portion which contains stuff tacked on a a later date. Note that both portions should be available to the recipient. -Doug-  Date: 18 May 83 9:24:08-EDT (Wed) From: Dave Crocker Return-Path: Subject: Re: Separation of Envelope and Header To: Doug Kingston Cc: header-people@mit-mc You might consider a modification to the header spec, in order to use header position to indicate envelope headers, versus content headers. In particular, dividing headers into two unordered sets, using a special field as the dividing line, seems quite easy. For example: To: xxxxxxxxxx. cc: xxxxxxxxxx Subject: xxxxxxxxxx. Date: xxxxxxxxxx Envelope: Message-Id: xxxxxxxxxx Received xxxxxxxxxx Received xxxxxxxxxx Return-Path: xxxxxxxxxx Errors-To: xxxxxxxxxx so that the 'Envelope' header separates the two sets of headers. It is strictly a hack, but should be easy to implement. It has the advantage of being transparent to systems that do not know about the convention, as long as you maintain the convention of keeping a flat name space for headers in both groups. Dave  Received: from SCRC-AFGHAN by SCRC-TENEX with CHAOS; Wed 18-May-83 09:21:58-EDT Date: Wednesday, 18 May 1983, 09:20-EDT From: Robert W. Kerns Subject: Re: Errors-To, round 2 To: Eric Allman Cc: header-people@mit-mc In-reply-to: <28949.31.422041139@ucbarpa> Date: 17 May 1983 1038-PDT (Tuesday) From: eric%UCBARPA@Berkeley (Eric Allman) Although I agree that the Errors-To: info belongs in the envelope, it is not at all clear to me that the SMTP exchange represents the envelope. Perhaps it should, but it most certainly does not. It certainly should not represent the envelope. Have you never pulled an envelope out of the trash to check the return address, or the postmark? SMPT represents the transmission medium. The truck that carries mail between offices, if you will. I don't think the envelope is that well distinguished from the message header anyway. Remember, we aren't limitted to modelling the existing USless postal system. Historically, the primary purpose of an envelope has been to protect and conceal. The routing information has been on envelopes, since concealing the text was done by covering it, not by encrypting it or other "high tech" means. Often, however, the need has been felt to duplicate the routing information inside with the text. Note the standard business-letter format, in which the so-called "envelope" information is shifted in possition, but definitely present. However, no postmarks, stamps, and other transmission artifacts are included. I think it's certainly within our reach to filter, in presentation, only that header information we want to see, according to the type of header. Some people would view "In-reply-to:" as a part of the supporting structure, and not wish to see it. Others, myself included, view it as serving to name a specific message being replied to, better than the subject, and want to see it, as well as having commands which make use of it. Is it header, or is it envelope? Wrong question. The right question is "do I want to see it, or do I want to not look at it right now?". The header consists of pieces of information called header fields, each one coming from a different place and serving a different purpose. It is the TEXT which is enclosed.  Date: 18 May 83 11:46:56 PDT (Wed) From: wcwells%Topaz.CC@Berkeley Subject: Re: Separation of Envelope and Header Message-Id: <8305181845.AA02651@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.339/3.28) id AA02651; 18 May 83 11:45:28 PDT (Wed) To: Dcrocker@UDel-Relay Cc: header-people@mit-mc Dave, In reply to: Date: 18 May 83 9:24:08-EDT (Wed) From: Dave Crocker Subject: Re: Separation of Envelope and Header To: Doug Kingston Cc: header-people@mit-mc You might consider a modification to the header spec, in order to use header position to indicate envelope headers, versus content headers. In particular, dividing headers into two unordered sets, using a special field as the dividing line, seems quite easy. Basic idea is good, but lets put the header envelope ahead of the message (content) header so we can have multiple envelopes in the future, if necessary. (That is, I think it is cleaner to put the message inside the envelope.) For example: Post-ID: xxxxxxxxx Posted-Date: xxxxxxxxx Posted-From: xxxxxxxxx Received xxxxxxxxxx Received xxxxxxxxxx Return-Path: xxxxxxxxxx ___ Errors-To: xxxxxxxxxx Message-Follows: Date: xxxxxxxxxx From: xxxxxxxxxx To: xxxxxxxxxx. cc: xxxxxxxxxx Subject: xxxxxxxxxx. Message-Id: xxxxxxxxxx PS. There is still some confusion about what the function of "Message-ID" is. Is it a "Postmark" or a message content identification field? After rereading RFC 822 I think it is suppose to be a content field (for example, a pointer to a file) rather that a post mark. Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720  Date: 18 May 1983 14:05:18-EST From: Christopher A Kent Reply-to: cak@purdue.ARPA To: Dcrocker@UDel-Relay, wcwells%Topaz.CC@Berkeley Subject: Re: Separation of Envelope and Header Cc: header-people@mit-mc I think I like Eric's idea of "wrapping" headers better. Then we can distinguish multiple envelopes easily. chris  Date: Wed 18 May 83 15:19:51-PDT From: David Roode Subject: message envelopes To: Header-people@MIT-MC.ARPA Users are often apt to want to see evidence from the message envelope. If the entire envelope were encoded in SMTP commands, then I think a log of all such commands should be associated with each message received and made available to the user as easily as headers are now. Using the header scheme provides this automatically. What has been missing until now has been an easy way to specify inclusion or exclusion of all envelope-derived header lines. Several of the proposals made recently add that capability. Using this method would also be more efficient in the user process than are existing template systems, or other systems based on checking individual header lines against lists. The default could be made to exclude the envelope, and the user could be given a simple command to display the envelope alone when desired. -------  Date: 18 May 83 10:04:03 EDT (Wed) From: cbosgd!mark@Berkeley (Mark Horton) Subject: envelope vs headers Message-Id: <8305181404.AA07738@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA07738; 18 May 83 10:04:03 EDT (Wed) Received: by UCBVAX.ARPA (3.341/3.29) id AA03719; 18 May 83 20:48:43 PDT (Wed) To: header-people@mit-mc.ARPA Here's another idea for a distinction - this is off the top of my head and may not work, but it seems closer to the spirit of 733 and 822 than extending SMTP or using @ signs. A message looks like Envelope separator1 Headers separator2 Body Envelope and Headers are : style lines like we all know and love. The separator2 remains a blank line. We can't use a blank line for the separator1, much as we'd like to, because of upward compatibility issues, and ambiguities with rewrapping. The separator1 has to look like a header line, with a colon. For example, -: (I'm not sure if this is legal by 822), or possibly Containing: One advantage to this is that mailers can add lines to the front of the Envelope without having to hunt for separators. Another is that a user interface can suppress everything in the envelope by default. (I don't know how other mailers suppress lines, but Mail requires the user to specify a list of header lines to suppress. When new envelope-style lines appear, the user sees them.) Such messages can be rewrapped by adding another separator1 and more envelope lines. Mark  Date: 19 May 83 22:38:59 PDT (Thu) From: wcwells%Topaz.CC@Berkeley Subject: message header format Message-Id: <8305200542.AA03705@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA03705; 19 May 83 22:42:24 PDT (Thu) To: cak@purdue, eric%ucbarpa@Berkeley Cc: header-people@mit-mc In reply to: Date: 17 May 1983 1038-PDT (Tuesday) From: eric@UCBARPA.BERKELEY (Eric Allman) Subject: Re: Errors-To, round 2 Message-Id: <28949.31.422041139@ucbarpa> At least the following lines in the headers belong in the envelope: Received: Return-Path: Errors-To: Resent-Date: Resent-Cc: Resent-To: Resent-Bcc: Resent-Message-Id: Encrypted: I think we are getting confused here. I can accept the "Received", "Return-Path", "Errors-To:" and maybe "Encrypted" as part of the postal heading (postal envelope, if you prefer that term). But, the "Resent" fields to build a readdressal heading are a user header fields, not "mail transport/relay" level fields. To quote RFC 822: "Some systems permit mail recipients to forward a message, retaining the original headers, by adding some new fields...." "... the message is assumed to have been forwarded by an original recipient who attached the 'Resent-" field" I interpret "recipient" to be an individual addressee (reader) of the original message. In reply to: On the other hand, "wrapping" is not cleanly handled in the headers. I consider wrapping one of the fundamental functions of envelopes. You create a message, then wrap it in an envelope. If you want to forward the message (e.g., send it off to your lawyer), you wrap the old envelope in a new envelope. I think things will be a lot easier if the readdressed message is handled as a new message. That is the "postal envelope" information of previous transmissions should be removed before it is reposted to the mail system. Note, that my interpretation, previous "Resent-" fields would not be stripped off since they are not part of the postal envelope. Removing the old audit trail information from the heading will also kept the size of the heading down for multiple readdressals. However to be forgiving to users (or mail submission) programs who do not remove old postal envelope fields, we could prepend a single ">" (or "@" if you prefer) on the "postal envelope" fields. Note: multiple prefix characters are not required since the mail system is only concerned with information needed for the current transmission of the readdressed message. If we are going to do the latter, then I prefer using a ">" prefix to escape the previous "postal envelope" fields, since we are already using that character to escape the "From" at the beginning of a line on Unix. For example, Resent-Date: xxxxxxxx Resent-From: lepreau@utah-cs Resent-To: you@your-host Resent-Message-ID: Return-Path: Received: by your-host from utah-cs ... >Return-Path: >Received: by utah-cs from lbl-csam ... Resent-Date: xxxxxxxx Resent-From: Resent-To: Resent-Message-ID: >Return-Path: <@MIT-MC:eric@Berkeley> >Received: by MIT-MC from Berkeley ... >Received: by lbl-csam from MIT-MC ... Date: xxxxxxxxxxxx From: Subject: Re: Errors-To:, round 2 To: header-people@mit-mc Message-ID: My first preference is to delete the old audit trail fields. For example: Resent-Date: xxxxxxxx Resent-From: lepreau@utah-cs Resent-To: you@your-host Resent-Message-ID: Return-Path: Received: by your-host from utah-cs ... Resent-Date: xxxxxxxx Resent-From: Resent-To: Resent-Message-ID: Date: xxxxxxxxxxxx From: Subject: Re: Errors-To:, round 2 To: header-people@mit-mc Message-ID: Note, there is only one "Message-ID" field, the message identification field of the original message. There may be more than one "Resent-Message-ID", one for each readdressal. Next question, how to handle the multiple "Resent-" fields. I will address that issue in a separate message. Bill Wells topaz.wcwells@Berkeley.ARPA  Date: 20 May 1983 1018-PDT (Friday) From: eric%UCBARPA@Berkeley (Eric Allman) Subject: Re: message header format Message-Id: <9296.31.422299120@ucbarpa> Received: by UCBARPA.ARPA (3.340/3.28) id AA09297; 20 May 83 10:18:42 PDT (Fri) Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.29) id AA00988; 20 May 83 13:24:49 PDT (Fri) Phone: (415) 548-3211 To: wcwells%Topaz.CC@Berkeley Cc: header-people@mit-mc, cak@purdue In-Reply-To: Your message of 19 May 83 22:38:54 PDT (Thu). <8305200541.AA03677@UCBVAX.ARPA> Fcc: mail I disagree about stripping the old information out before you resend. There are several reasons for this. First, fields such as "message-id" has semantic meaning. For example, if I wanted to build a database for my messages that would maintain some reasonable semantic connections, I would need those message-id's, both original and resent, to create the appropriate semantic connections. Although I know of no system that does this today, I view it as one of the long-term important reasons for message-id's. Second, if you wanted to "send a message to your lawyer" you would want to have those fields included -- even the Received: lines, etc. Your "lawyer" might be your mail system maintainer, other people on your faculty, or whatever. Simply putting readdressed messages in a new envelope is not sufficient, since information in the original header needs to be machine accessible. Multiple prefix characters ARE required so that you can associate header fields with the correct reinstantiation of the message. Using ">" instead of "@" because UNIX already does that is a prime example of UNIX chauvinism. It may be that ">" is a more aesthetic choice, but doing it "because" UNIX does it is gratuitous. eric  Date: 22 May 83 14:49:42 PDT (Sun) From: wcwells%Topaz.CC@Berkeley Subject: Re: message header format Message-Id: <8305222156.AA08709@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA08709; 22 May 83 14:56:23 PDT (Sun) To: eric%ucbarpa@Berkeley Cc: cak@purdue, header-people@mit-mc Eric, In reply to: Date: 20 May 1983 1018-PDT (Friday) From: UCBARPA:eric (Eric Allman) Subject: Re: message header format Message-Id: <9296.31.422299120@ucbarpa> I disagree about stripping the old information out before you resend. There are several reasons for this. First, fields such as "message-id" has semantic meaning. For example, if I wanted to build a database for my messages that would maintain some reasonable semantic connections, I would need those message-id's, both original and resent, to create the appropriate semantic connections. Although I know of no system that does this today, I view it as one of the long-term important reasons for message-id's. I did not say to remove "Message-ID" and "Resent-Message-ID" when resending (readdressing) a previously sent message. They are "content" information headings. I said: "My first preference is to delete the old audit trail fields" (ie: "Received" and "Return-Path"). [Take a closer look at my examples.] Second, if you wanted to "send a message to your lawyer" you would want to have those fields included -- even the Received: lines, etc. Your "lawyer" might be your mail system maintainer, other people on your faculty, or whatever. If I wanted to send all those heading lines to "my lawyer" I would quote the message in the text of a new message so that "my lawyer" would receive a copy of the message as I received it. (I think some of the mailers/mail transport agent programs are messing up the heading too much as it is.) Simply putting readdressed messages in a new envelope is not sufficient, since information in the original header needs to be machine accessible. Which fields and why? Let's be specific. With the exception of previous audit trail information, I will agree that the original heading (and any previous readdressal header fields) should be sent to the new addressees. I still think that the "mail transport system" should only be concerned with information of the latest readdressal. Are you intending to send error messages back to the originator of the original message? If someone goofed in resending one of my messages, I would prefer to have the error message go back to the resender, not me. There is another reason why the readdressed message should be handled as a new message. -- The message being readdressed might be very old and the original host and/or originating user mailbox may no longer exist. Multiple prefix characters ARE required so that you can associate header fields with the correct reinstantiation of the message. That is so only if you retain the very random positioning of header fields that we have now. There are other methods of keeping these fields separated. For example, we could required each sub-part of the heading to begin with a date field ("Posted-Date", none, one or more "Resent-Date" and a "Date") with later readdressal sub-parts stacked ahead of previous ones. Using ">" instead of "@" because UNIX already does that is a prime example of UNIX chauvinism. It may be that ">" is a more aesthetic choice, but doing it "because" UNIX does it is gratuitous. Who cares? I would just like them to be the same (whatever is used). Best Regards, Bill Wells topaz.wcwells@BERKELEY  Date: 22 May 1983 1948-PDT (Sunday) From: eric%UCBARPA@Berkeley (Eric Allman) Subject: Re: message header format Message-Id: <6262.31.422506100@ucbarpa> Received: by UCBARPA.ARPA (3.342/3.29) id AA06263; 22 May 83 19:48:22 PDT (Sun) Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.29) id AA11660; 22 May 83 19:47:35 PDT (Sun) Phone: (415) 548-3211 To: wcwells%Topaz.CC@Berkeley Cc: cak@purdue, header-people@mit-mc In-Reply-To: Your message of 22 May 83 14:49:37 PDT (Sun). <8305222155.AA08694@UCBVAX.ARPA> Fcc: mail Yes indeed, we CAN come up with lists of header lines that can be safely deleted. And we CAN come up with another standard that leaves header lines position-dependent in the header. And people who want to send me a copy of a message that took too long or was misrouted CAN quote the routing information -- if they remember. Etc. But my whole point is that this kind of garbage is not necessary. It is upward compatible with existing mail systems, which can and do rearrange headers. It does not require that users remember to quote the right fields (if they remember to send me the message at all). It does not depend on heuristics. It is extensible. It leaves the necessary header and envelope information machine-readable and parsable at all levels, and makes those levels easily determinable. It lets mail readers eliminate the envelope information easily. Your proposals seem to be adding more levels of complexity. We have far too much of this already. eric  Date: 22 May 83 20:56:05 PDT (Sun) From: wcwells%Topaz.CC@Berkeley Subject: Basic Message Format Message-Id: <8305230406.AA12603@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA12603; 22 May 83 21:06:39 PDT (Sun) To: MsgGroup@brl, header-people@mit-mc Cc: DCrocker@UDel-Relay, POSTEL@ISIF, cbosgd!mark@Berkeley Basic Message Format - 3 - "Postal Heading Syntax" Version 1 - 22 May 1983 1. Introduction. This article defines the syntax of header fields used in the Postal Heading. 2. Syntax POSTED-DATE. This is the date the message was posted by the originating "electronic post office". This field is required since it defines the beginning of the Postal Heading. Syntax is the same as "Date": post-date = "Posted-Date" ":" date-time POSTED-FROM. This required field contains the identity of the originating "electronic post office" which enters the message into a Internet type mail system. It is suggested that the "()" comment argument of this field contain the name and version of the posting program. Syntax is the same as "From": orig-post-office = "Posted-From" ":" mailbox POST-ID. This is an optional field that may be added by the originating "electronic post office" to identify the message. Syntax is the same as "Message-ID": orig-post-id = "Post-ID" ":" msg-id POSTMASTER. This optional field contains the identity of the Postmaster at the originating "electronic post office". It is intend for use by sites having several hosts and only one Postmaster. Syntax is: postmaster = "Postmaster" ":" address RETURN-PATH. Defined in RFC 822. RELAY-TO. This optional field may be used with a message containing multiple addresses to tell the relaying and destination "post offices" that that they are only required to deliver to the address indicated. This field is not normally used for single addressee message expect to indicate source routing in the Postal Heading. If this field contains source routing, the source routing indicated in this field will be used instead of the source routing (if any) indicated for the same address in the message heading. This field may be used by the originating "electronic post office" (as opposed to the drafter and his mail format/submission program(s)) to specify source routing for mail systems that require source routing. Unless otherwise indicated in an outer layer (eg. SMTP, or other envelope), the lack of any "Relay-To" fields indicates to the post office that it is responsible for relaying the message to all addresses of the message. If one or more "Relay-To" fields is present, then the post office is only responsible for relaying the message to the addresses indicated in the "Relay-To" field(s). Syntax is: relay-to = "Relay-To" ":" address DO-NOT-RELAY-TO. This optional field may be used with a collective address by the "post office" or drafter to indicate that the message has already delivered (or is being delivered by other means) to the indicated address. Syntax of this field is: do-not-relay = "Do-Not-Relay-To" ":" addr-spec RECEIVED. Defined in RFC 822. Comments? Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720  Date: 22 May 83 20:55:28 PDT (Sun) From: wcwells%Topaz.CC@Berkeley Subject: Basic Message Format Message-Id: <8305230412.AA12691@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA12691; 22 May 83 21:12:03 PDT (Sun) To: MsgGroup@brl, header-people@mit-mc Cc: DCrocker@UDel-Relay, POSTEL@ISIF, cbosgd!mark@Berkeley Basic Message Format - 2 - "Heading Components" Version 2 - 22 May 83 ------------------------------------------------------------------------ Changes in this version: a. "Envelope Heading" and "Envelope Ending" changed to "Postal Heading" and "Postal Ending" to avoid confusion with all the different definitions of "envelope" and "message envelope". b. New header fields have been added for use in the Postal Heading and Message Heading parts of the message. c. "Message-ID" is clearly defined as a user application level field and has been placed in the original message heading. A "Post-ID" field has been defined for use at the "electronic post office" level. ------------------------------------------------------------------------ 1. Introduction. RFC 822 is primarily concerned with "message content" header fields. These header fields are primarily used for obtaining information from the user (drafter of the message) to (a) permit the message to be identified by other users (readers of the message); (b) obtain addressing information to send the message. This article introduces new header fields for use in the Postal Heading of a message. The Postal Heading contains fields that are used by "electronic post offices" to (a) identify the message being sent, (b) supply relay (source routing) information to relaying mail systems, and (c) record audit trail information. In my first article I introduced a Basic Message Structure having the following parts and sub-parts. HEADING Transmission Heading Batch Heading Postal Heading Message Heading TEXT Message Text (Body of Message) ENDING Message Ending Postal Ending Batch Ending Transmission Ending The Internet Text Message as currently defined by the "Standard for the Format of ARPA Internet Text Messages" (RFC 822) has a heading and a text. No ending is defined. This article classifies RFC 822 header fields into two groups, Message Heading and Postal Heading, and adds additional fields for use in the Postal Heading. No attempt has been made to define "Batch" or "Transmission" fields since these are more the concern of the network and transport system being used. 2. Header Fields by Sub-Part and Component. POSTAL HEADING SUB-PART COMPONENT FIELD _____________________________________________________ Postal Postmark Posted-Date: Heading Posted-From: Post-ID: Postmaster: Return Field Return-Path: Relay Instructions Relay-To: Do-Not-Relay-To: Trace Fields Received: _____________________________________________________ MESSAGE HEADING SUB-PART COMPONENT FIELD _____________________________________________________ Readdressal Date-Time Resent-Date: Message Heading(s) Originator's Resent-From: Address Resent-Sender: Resent-Reply-To: Originator's Resent-Message-ID: Message ID. Precedence Resent-Precedence: Receiver's Resent-To: Address Resent-cc: Resent-bcc: Resent-Exempt: _____________________________________________________ Original Date-Time Date: Message Heading Originator's From: Address Sender: Reply-To: Originator's Message-ID: Message ID. Precedence Precedence: Receiver's To: Address cc: bcc: Exempt: Security Classification: Classification Content Subject: Information Keywords: In-Reply-To: References: Encryption Encrypted: Field _____________________________________________________ Heading Comments Comments: Comments Field _____________________________________________________ Notes: (a) Fields not defined in RFC 822 are: Posted-Date, Posted-From, Post-ID, Postmaster, Relay-To, Do-Not-Relay-To, Resent-Precedence, Precedence, Resent-Exempt, Exempt, Classification. (Syntax of postal header fields is defined in my next article.) The order of sub-parts differs from RFC 822 Article 4.1 in that "source" is defined as: source = [trace] [resent] originator (b) Each sub-part of the heading begins with its corresponding date- time field. Fields pertaining to one sub-part may not be placed in another sub-part. With the exception of the date-time field which begins the sub-part, the order of fields within the sub-part is not defined. However the above order is recommended. (c) There may be none, one or more "readdressal message heading" sub- parts in the message heading. If there is more than one "readdressal message heading" the later ones precede the earlier ones. (d) "Relay-To" fields may be deleted by relaying hosts (MTA's) when delivery has been made (or protected) by that host. (e) Relaying hosts will not make changes to the Message Heading within an Internet mail system environment. Gateways to non-Internet mail systems, may translate header fields into other formats. However, if the other mail system is incompatible with Internet, the message should be quoted in the text of the other systems message. The same applies to incompatible messages being entered into an Internet mail system. (f) There may be only one "Date:", "From:", "Sender:" and "Message- ID:" field per original message. Relaying hosts may not add or change the "Message-ID" field. (g) "Exempt" and "Resent-Exempt" fields are optional user fields that may be used with collective addresses to indicate that the drafter (or user resending the message) does not want the message sent to one or more addressees in the collective address. Syntax is same as "To": exempt = "Exempt" ":" 1#address resent-exempt = "Resent-Exempt" ":" 1#address Comments? Bill Wells, RMC, USNR-R topaz.wcwells@BERKELEY.ARPA Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720  Date: 22 May 1983 2135-PDT (Sunday) From: eric%UCBARPA@Berkeley (Eric Allman) Subject: Re: Basic Message Format Message-Id: <7070.31.422512549@ucbarpa> Received: by UCBARPA.ARPA (3.342/3.29) id AA07071; 22 May 83 21:35:51 PDT (Sun) Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.29) id AA12954; 22 May 83 21:35:14 PDT (Sun) Phone: (415) 548-3211 To: wcwells%Topaz.CC@Berkeley Cc: DCrocker@UDel-Relay, POSTEL@ISIF, cbosgd!mark@Berkeley, MsgGroup@brl, header-people@mit-mc In-Reply-To: Your message of 22 May 83 20:56:05 PDT (Sun). <8305230406.AA12603@UCBVAX.ARPA> Fcc: mail I have been quite interested by almost everything you have posted up to this point. Your description of the military message system was extremely educational and was in my opinion at least somewhat apropos. However, at this point I find your suggestions heavy on complexity and low on benefit. Although I agree that there is a real need, I don't believe it requires as large a solution as you are proposing. All computer types should be constantly on guard to insure that their solutions of today do not become the problems of tomorrow..... eric  Date: 23 May 83 02:36:01 PDT (Mon) From: wcwells%Topaz.CC@Berkeley Subject: Re: Basic Message Format Message-Id: <8305230943.AA15251@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA15251; 23 May 83 02:43:57 PDT (Mon) To: eric%ucbarpa@Berkeley Cc: MsgGroup@brl, header-people@mit-mc Eric, Give me a while to discuss the "why's and wherefores" behind my heading format, before you shoot the whole thing down. You may even like a few of the ideas I have put out. I realize I have put a lot out as once. With all the different terms and phrases being used to discuss message formats, I felt it was necessary to define the terms I am using. Let's look at some of the idea's I have presented an idea at a time and see if they are worth implimenting. Best Regards. Bill Wells topaz.wcwells@BERKELEY.ARPA  Date: 23 May 1983 18:45 est From: DBrown.TSDC at HI-MULTICS Subject: Re: Basic Message Format To: wcwells%Topaz.CC at UCB-VAX cc: header-people at MIT-MC In-Reply-To: Message of 23 May 1983 05:33 est from wcwells%Topaz.CC Re advisability of Mr Well's' proposals: I find myself in the annoying position of agreeing with *both* of the last two speakers: we should take extreme care that we do not add complexity, since that multiplies difficulty (and probably "powers" bugs). On the other hand I feel that we should deal with the problem in as great a depth and breadth as possible, so as not to leave out anything obvious or design out any required capabilities. I will therefore quote an associate's design strategy as a possible approach: (1) Get as broad a list of desires (desired capabilities) as possible. (2) Debate the validity and advisability of each. (3) Select the most cohesive set as a desired end-point, making sure that they are not "fuzzy" or have implications in other areas if possible. (4) define a minimal proper subset of these (5) propose these as the target desgn, and the spanning set as the intended aim. (5) argue. --dave  Date: 23 May 83 21:48:05 PDT (Mon) From: wcwells%Topaz.CC@Berkeley Subject: Basic Message Format Message-Id: <8305240458.AA00342@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA00342; 23 May 83 21:58:49 PDT (Mon) To: MsgGroup@brl, header-people@mit-mc Cc: DCrocker@UDel-Relay, POSTEL@ISIF, cbosgd!mark@Berkeley  Date: 23 May 83 21:58:03 PDT (Mon) From: wcwells%Topaz.CC@Berkeley Subject: basic message format discussion Message-Id: <8305240502.AA00413@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.29) id AA00413; 23 May 83 22:02:33 PDT (Mon) To: header-people@mit-mc To reduce the number of copies flying around out there, future "Basic Message Format" messages will be sent only to the MsgGroup mailing list. Cheers. Bill Wells topaz.wcwells@BERKELEY  Date: 25 May 83 22:14:24 PST (Wed) From: Stef.UCI@Rand-Relay Return-Path: Subject: Re: Errors-To, round 2 To: POSTEL@Usc-Isif Cc: header-people@Mit-Mc, stef.UCI@Rand-Relay In-Reply-To: Your message of 12 May 1983 2217-PDT. Via: UCI; 25 May 83 22:31-PDT Having just reviewed all this discussion about Errors-To, round 2, I have chosen to reply to Jon's original round 2 message to specifically recall his two views: "(1) that there are two separate mail transactions - (a) the author sends a message to the exploder, and (b) the exploder send the message to the list"; and "(2) there is one transaction - the author sends the message to the list via the exploder mailer as a relay." Jon further explained: "In the first case, we would have in the first transaction a path back to the author, but in the second transaction a path bact to the exploder (perhaps even the list maintainer). In the second case we would have a path back to the author via the exploder host." And then Jon observed: "If the implementation were required to be the first case, there might not be any call for any other mechanism such as the suggested Errors-To." I want to sound a loud call for adoption of Jon's case 1, where the exploder is considered to be a user agent which has taken posession of the item to be sent to a new list, and thus takes responsibility for the results of the secondary and subsequent mailing, just as though it were a new mailing. We have been using this arangement at UCI since last Fall sometime, and it works very well for us. In addition, we are now implementing a distribution serializer mechanism for our MMDF based ch_bboards channel which will insert an X-DIST-ID: field with a unique value (if one is not yet present), conforming to the 822 requirement that non-822 fields be designated by an "X-" as the initial two field-name characters to signal its non-822-ishness. It should not be an 822 or 821 field!!!!!! Our ch_bboards distributor will first look for the X-DIST-ID: field because this might not be the "root" distributor for the distribution net in question. For example, MsgGroup@BRL is a root distributtor, but when it gets to UCI-MSGGROUP@UCI it gets distributed again, just as it gets redistributed by RAND-MSGGROUP@RAND-UNIX, and several other such cases. Our distributor will keep a log of reasonably recent items for checking against new arrivals for whatever reasons. A recent episode of interest involved a loop out there in the Internet that sent us 34 copies of one item. We would like to catch and avoid further distribution of the extras in such cases. Also, we simply solve the failed mail returns problem beyond our distributor by putting a new SENDER: field in it before posting it as a new item, which I claim it is, in fact. As a User Agent, our distributor assumes the right to do anything it wants to do, since it is not bound the ethics or morality of the sanctity of the seal. My argument is that these kinds of newsnet or groupmail distributions must be removed from inside the 822/821 domain of MTAs, and placed in the UA domain, regardless of what is to be done about any other aspect of ERROR-TO arrangements for other mail. This includes the case that DPK mentions where a group of discussants identified in TO and CC fields, may also copy a distribution list; Those who get their copy direct are not effected, buth those who get it through the list are effected, and properly so. The fact that we might be using Ineternet and internet mail systems to distribute group mail of various kinds should not be allowed to muck up the already complicated problem of failed mail notification processes and procedures. Not separating them out can only add to the complexity of our already over structured and over complex MTA environment. By the way, our basic UCI ch_bboards software has already been given over to DPK and CSnet for their use in any way they may wish. It may have unfortunately beeen misnamed as a "bboard" tool, but it is in fact a User Agent distributor system that fits nicely into an MMDF channel fitting. You are cheerfully urged to seriously consider using this handy tool. The X-DIST-ID: inserter is currently in development at UCI and will be made available as soon as it is available, and after it passes muster testing at UCI. Best - Stef  Date: 24-May-83 22:54:33-UT From: mills@dcn6 Subject: Re: message header formatî To: eric%UCBARPA@Berkeley(EricAllman), wcwells%Topaz.CC@Berkeley, cak@purdue, header-people@mit-mc In response to your message sent 22 May 1983 1948-PDT (Sunday)î hello -------  Date: 26 May 1983 0600-PDT From: MILLS at USC-ISID Subject: Re: message header format To: mills at DCN6, eric%UCBARPA at BERKELEY, To: wcwells%Topaz.CC at BERKELEY, cak at PURDUE, To: header-people at MIT-MC cc: MILLS at USC-ISID, Tester at DCN5 In response to the message sent 24-May-83 22:54:33-UT from mills@dcn6 Folks, Please excuse my previous message, which escaped during testing of our mail system. Regards, Dave -------  Date: 26 May 1983 0600-PDT From: MILLS at USC-ISID Subject: Re: message header format To: mills at DCN6, eric%UCBARPA at BERKELEY, To: wcwells%Topaz.CC at BERKELEY, cak at PURDUE, To: header-people at MIT-MC cc: MILLS at USC-ISID, Tester at DCN5 In response to the message sent 24-May-83 22:54:33-UT from mills@dcn6 Folks, Please excuse my previous message, which escaped during testing of our mail system. Regards, Dave -------  Date: 26 May 1983 0600-PDT From: MILLS at USC-ISID Subject: Re: message header format To: mills at DCN6, eric%UCBARPA at BERKELEY, To: wcwells%Topaz.CC at BERKELEY, cak at PURDUE, To: header-people at MIT-MC cc: MILLS at USC-ISID, Tester at DCN5 In response to the message sent 24-May-83 22:54:33-UT from mills@dcn6 Folks, Please excuse my previous message, which escaped during testing of our mail system. Regards, Dave -------  Date: 26 May 83 15:23:48 EDT (Thu) From: Doug Kingston To: Stef.UCI@rand-relay cc: POSTEL@usc-isif, header-people@mit-mc, stef.UCI@rand-relay Subject: Re: Errors-To, round 2 One must be careful about changing the Sender: field of the message. This makes it difficult/impossible for a recipient to reply to the author of a mailing list message. There appear to be three classes of addresses for any message. The original sender, the recipients, and optionally an error return address if the message has been redistributed. At any one time there will be only one original sender and one error return address. The original sender should never change, but the error return address should change whenever the letter is redistributed. The recipients do not change, and may be added to? Cheers, -Doug-  Date: 27 May 83 12:13:58 PST (Fri) From: Stef.UCI@Rand-Relay Return-Path: Subject: Re: Errors-To, round 2 To: Doug Kingston Cc: POSTEL@Usc-Isif, header-people@Mit-Mc, stef.UCI@Rand-Relay Via: UCI; 27 May 83 14:30-PDT The key and vital difference between Postel's Case 1 and Postel's Case 2 is that Case 1 clearly and unequivically casts redistribution in a "User Agent's User" role which frees the distributor from problems with "The Sanctity of The Seal." DPK's admonition about changing the sender field falls in this category. In Case 1, the redistributed item is in fact a new posting of material that was taken out of the MTS and is being sent as a new piece of mail. If you as a redistributor want to leave the sender field as it is, that is your privilege, but this will mean that failed mail beyond your redistribution point will return to the original sender. I can well imagine some cases where this will be correct, such as with small collegial groups at BRL and elsewhere. But, back to the technical issue, I expect that no matter how you try to jigger things by creating an ERRORS-TO: field, that you will only shift the identical argument to focus on the new field. Whatever you choose to call it, the Redistribution Agent must be allowed to change it to divert error returns to some place other than the originator. This discussion thus can go on forever, with proposals for ERRORS-TO-PRIME: and ERRORS-TO-PRIME-PRIME: and ...ERRORS-TO-...-PRIME-PRIME:. In a separate communication, I have been asked how I can claim that our UCI ch_bboards mechanism can be called a User Agent when it is actually implemented and installed as a real MMDF channel, which puts it at the MTS peer level. My answer to that is that it is the role that it plays, and claims to play, that matters. It reposts the message as a new item with no claim of pristine preservation, and this is what establishes what is right to do from what is wrong to do. As implemented, our UCI ch_bboards will allow for the UCI Postmaster to designate a Group Leader to control the behavior of the X-DIST-ID: field generator for each Group Address. This program, named DISTIZE, will also allow other changes, like insertng a REPLY-TO: , or it could move the contents of a SENDER field into a REPLY-TO field if it does not yet exist, or what ever. (I think all this is planned?) It will cerainly allow me to insert a serial accession number into the SUBJECT field, such as MSGGROUP#2001. As I see it, it should be up to each Groupmail Leader to decide things like this because each group's needs may be different from others. Some group leaders will do things better than others too, but that is not our problem! We must not impose our beliefs and values on them. This is yet another reason to get redistribution of group mail out from the clutches of 822/821. Why should Groupmail Leaders be constrained by a need to compromise on such issues when it is technically possible, and even preferrable, to implement on the User Agent basis of Postel's Case 1. So, I will agree that when a Groupmail Leader decides to replace or insert a SENDER field, this will cause major changes in the way things work for that group. But, I will further argue that it is not the right or privilege of us hackers in the Internet to decide these things for any Groupmail Leader. It is our job here to enable the widest possible variety of use for mail systems. To me this means keeping mail simple and free of as many issues as possible, which means pushing as many issues as possible out to the User Agent level. I for one have no interest in an expanded role for the MTS! Shades of the USPS and the Postal Workers Union! Even they do not object to independent mailing houses that do what is proposed here. In terms of the ISO OSI Model, this means that Groupmail and Newsnet distribution should be done at a level above the User Agent peer level by using the services of User Agents, with all the rights and privileges of a User Agent User. In this view, the Redistributor is a peer of both the SENDER and the RECIPIENT. In many ways, the UUCP Usenet Newsnet is the correct model because it is cast in this mode, but it suffers from being outside the normal mail channels. What I propose thus is that we map the Usenet Newsnet model over our Internet Mail Transfer System by simply using mail as a carrier for Groupmail. And one last note: I do not mean to cast any aspesions on any of the systems and mechanisms that we have known, loved, and used so heavily over the last 5-7 years. ITS COMSAT was a major advance when it was invented, and it has been used to great advantage since. And, it was great when MMDF acquired a similar capability with its aliasing facilities. Likewise for XMAILR. And, UUCP Newsnet has been a powerful tool in its own doman. What I see is that we are getting smarter from our experience, and it is time now to simply fix some problems that those inventions did not solve. Onward! Stef  Date: 27 May 1983 2032-PDT From: POSTEL at USC-ISIF Subject: Errors-To, round 3 To: Header-People at MIT-MC Hi. Thanks for all your comments. I have been persuaded that the functional capability i wanted is best provided (in the context of the current system) by the SMTP procedures and requiring that sending to a mailing list via a mail exploder be treated as a two transaction process. That is, when a user sends a message to a mail exploder there is one transaction when the message travels via SMTP from the user to the exploder. Any errors detected (e.g., misspelling the mailing list name) in this stage will go back to the user. When the mail exploder send the message to the mailing list there is another transaction. Any errors detected at this stage (e.g., a mailbox on the list does not exist) will go back to the "owner" of the mailing list. Several people suggested other functions and capabilities that would be nice but went beyond what i wanted, and sometimes beyond what is reasonable to do in the current system (still, it would be nice if ...). I hope we can keep these in mind in the next time we build a mail system, or have the chance to significantly change this one. --jon. -------  Date: 28 May 83 17:51:41 PDT (Sat) From: wcwells%Topaz.CC@Berkeley Subject: Re: Errors-To, round 2 Message-Id: <8305290101.AA08408@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.31) id AA08408; 28 May 83 18:01:44 PDT (Sat) To: stef.UCI@Rand-Relay Cc: header-people@Mit-Mc Stef, Date: 25 May 83 22:14:24 PST (Wed) From: Stef.UCI@Rand-Relay Subject: Re: Errors-To, round 2 .... I want to sound a loud call for adoption of Jon's case 1, where the exploder is considered to be a user agent which has taken posession of the item to be sent to a new list, and thus takes responsibility for the results of the secondary and subsequent mailing, just as though it were a new mailing. Stef, I agree with you on this one. Life on the network will be much simplier if we require mailing list "exploders" to generate new messages with the "exploder" as the originator of the new message(s) to addressees on their list(s). One simple method for the "exploder" to use, would be to generate a new heading and quote the received message in the text (body) of the new message. A compromise would be for the "exploder" to pass through some of the header fields to the new message. However, if the latter is done, I think we should define a standard for what fields are passed through and what fields may not be passed through. On serialization of messages. In military communications a serialized message sent to a collective address (eg. group mailing list) is called a "General Message"; in Amateur Radio communications it is called a "Bulletin". Both of these serialized message have serial numbers assigned by an user agent who is authorized to send messages to the collective address (eg. the "exploder" of the list maintainer). At the user level, a military general message is identified by its title and a number consisting of a serial number and the calendar year. I think the Internet identification of mailing list messages should be consistent with the method currently used by DOD to identify general message. Since all messages to a Internet mailing list must go through a "root exploder" I suggest that we create a message heading field containing identification of the mailing list and a serial number. This "general message designator" would be part of the header of the new message(s) sent by the "root exploder". The same "general message designator" would be used for all messages generated from the same root exploder input message. I suggest the following header field syntax: "General-Message-ID:" genmsg-title " " genmsg-number "/" year where "genmsg-title" is the title of the general message (for Internet mailing lists I think we should use the root exploder mailbox as the title); genmsg-number is a serial number assigned by the root exploder which is reset to "1" at the beginning of each calendar year; and "year" is the 4-digit calendar year number. For example: General-Message-ID: header-people@mit-mc.ARPA 153/1983 would be be the 153rd message submitted to "header-people@mit-mc" in the calendar year 1983. Adding a general message identifier at the "root exploder" has an added advantage for user agent programs which are programmed to handle general messages. It permits duplicate messages to be trapped even when they are being received from various message systems. (I see it as the only way to eliminate the mailing list message that has been entered into another message system, eg. USENET news, which I may also guarding for messages.) I agree that the checking for duplicate general message should be done at a layer above the mail transport system, but not necessarily by the user (reader of the message). I think this is an appropriate function for the "electronic post office" or "bulletin board" programs to handle. However, to get back to error handling, if we implement general message serialization, at the user agent level we will also need to establish a method of handling (a) skipped numbers, (b) duplicated numbers, and (c) requests for retransmission of missed numbers. I think a set of standard communication service messages would be appropriate. We might want to even implement another mailbox associated with the root exploder (eg. header-people-service@mit-mc) that would accept proforma service message request for retransmission and automatically retransmit the requested missing number message. If the skipped number service message from the root exploder included the last valid number sent and the next valid number it could be used to handle the end of year number change over (back to genmsg-number=1). Regards, Bill Wells topaz.wcwells@BERKELEY PS. I think we disagree on the definition of "user agent". I believe that most of the header fields in RFC 822 are "user agent" fields.  Date: 28 May 83 18:47:53 PDT (Sat) From: wcwells%Topaz.CC@Berkeley Subject: Re: Errors-To, round 2 Message-Id: <8305290157.AA08831@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.31) id AA08831; 28 May 83 18:57:30 PDT (Sat) To: Stef.UCI@Rand-Relay Cc: header-people@mit-mc In reply to: Date: 27 May 83 12:13:58 PST (Fri) From: Stef.UCI@Rand-Relay Subject: Re: Errors-To, round 2 "..... It is our job here to enable the widest possible variety of use for mail systems." "To me this means keeping mail simple and free of as many issues as possible, which means pushing as many issues as possible out to the User Agent level. I for one have no interest in an expanded role for the MTS!" Onward indeed! Now I think we are getting somewhere. Lets get those "electronic post office" and "bulletin board" programs up and working. One question though, do we want to provide for collective routing indicators at the mail transport system level, or at a lower level?. Or put it another way, should broadcast message transmission methods be used to transmit messages to a large number of hosts to reduce the number of messages being transmitted on the network? By broadcasting, I mean sending serialized messages with no reciept from individual MTA's. Reliability is maintained by retransmitting the broadcast message once after a certain time has elapsed, having receiving MTA's log the last message received, and requesting missed numbers from the broadcast MTA's. Broadcasting assumes that at the network level, the MTA's host is always listening for messages (packets?) sent to "all hosts". -- Hmmm. That may not be workable. Since SMTP uses the "receipt method" (all messages are receipted for), perhaps we need a different message transport system for these types of messages. Bill Wells topaz.wcwells@BERKELEY  Date: 28 May 83 23:43:21 PDT (Sat) From: wcwells%Topaz.CC@Berkeley Subject: Separation of the Envelope and Header Message-Id: <8305290652.AA12977@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.31) id AA12977; 28 May 83 23:52:26 PDT (Sat) To: header-people@mit-mc So far we have discussed separation of "envelope" header fields from "content" header fields. We have also discussed the need for separation of multiple resent message header fields. I think we should also discuss separating audit-trail (trace) fields from non-audit-trail fields "envelope" part of the heading. I have heard of one message standard that is kind to the reader and puts the audit-trail information at the bottom of the message (in a message ending). I think the basic questions I am asking is: Where in the "envelope" part of the heading should audit-trail information appear? Should audit-trail information be separated from other header fields? I suggest the following order of header fields if each resend of a message is to be handled as a new message: Envelope Header Fields Postal Envelope Information Audit Trail Information Content Header Fields Resent Header Fields (nth resend) . . . Resent Header Fields (1st resend) Original Content Header Fields However if we decide to include all previous transmission history then the following might be more appropriate: Resent Heading (nth resend) Postal Envelope Information (nth resend) . Audit Trail Information (nth resend) . Resent Header Fields (nth resend) . Resent Heading (1st resend) Postal Envelope Information (1st resend) Audit Trail Information (1st resend) Resent Header Fields (1st resend) Original Heading Original Content Header Fields Audit Trail Information (original) Bill Wells topaz.wcwells@BERKELEY P.S. Yes I am saying the position of header fields should be significant. Can anyone give a good reason why header fields should be in a random order in an Internet message?  Date: 29 May 83 02:35:18 PDT (Sun) From: wcwells%Topaz.CC@Berkeley Subject: Separation of the Envelope and Header Message-Id: <8305290943.AA14680@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.31) id AA14680; 29 May 83 02:43:36 PDT (Sun) To: header-people@mit-mc Whether or not we opt for a physical separation of "envelope" header fields from "content" header fields, I think we should have a functional separation. I would like to suggest that we classify header fields to whether they are "envelope" or "content" header fields, then apply the following rules: The user (and user level) programs may create "content" header fields and may be authorized to create some "envelope" fields. The "electronic post offices" may create "envelope" header fields, but may not create or change "content" header fields except that the "originating electronic post office" may expand addresses in "content" header fields to full domain names. (This does not prevent "electronic post offices" from using information in the "content" header fields.) "Electronic post office" is my term for programs that function below the user agent level (editing, filing, submitting to post office) and the Mail Transport level (eg. SMTP). The "originating electronic post office", in the case of Internet, is the first post office type program entering the message into the Internet mail environment. To sum up, I think separation of "envelope" and "content" header fields (and who can change them) needs to be clearly defined. Bill Wells topaz.wcwells@BERKELEY  Date: 29-May-83 13:33 PDT From: RICH.GVT@OFFICE-3 Subject: Re: Errors-To, round 2 To: header-people@Mit-Mc Message-ID: <[OFFICE-3]GVT-RICH-2I44H> Let's remember that there can be more than one mailing-list "exploder" involved for any given [set of] message[s]. For efficiency purposes, we have the case where exploder #1 sends to some individuals and some additional exploders; the additional exloders then send to more individuals and possibly even to additional exploders, ad infinitum. When this happens, either we'll be adding more levels of encapsulation, or every exploder will have to fiddle with the header again to change such fields as Sender, Resent-by, Errors-to, or whatever we end up deciding to put in the header to cover the general case of mailing list exloders. -Rich  Date: 29 May 83 01:54:39 PST (Sun) From: Stef.UCI@Rand-Relay Return-Path: Subject: Groupmail distributor rules To: wcwells%Topaz.CC@Ucb-Vax Cc: header-people@Mit-Mc, stef.UCI@Rand-Relay In-Reply-To: Your message of 28 May 83 17:51:46 PDT <8305290100.AA08390@UCBVAX.ARPA> Via: UCI; 29 May 83 2:01-PDT Hi Bill - Before we charge off and implement a whole bunch of things to structure the world for group mail exploders, I would like to step back to see if we need to do much of anything at all ... As I see it, we should consider establishment of a newsnet-groupmail RFC to specify some rules for exploders, who should be left to choose among many alternatives. These alternatives include simple forwarding inside a fresh new message with or without digestification, or simple redistribution (remailing) without any more modification than if the exploder were any other normal recipient who remailed a message, or redistribution with partial modification of the header fields. The only thing I see as mandatory at this point is the X-DIST-ID: field if one is not yet present in the message before explosion. But, the exploder should be free to do lots of things beyond that if it makes sense for the purposes of a particular mail-group. Remember, the exploder is operating from the same position as any other user, but with a license from the originator to further distribute to a list associated with the groupmail explosion address. The license is implied by the fact of the originator's posting of the message to the groupmail submission address. The exploder is only constained by the contract if any that exists between the exploder and the group members. For example, in military communications a serialized message can be sent to a group mailing list address as a "General Message"; among Amateur Radio folks it can be called a "Bulletin". Any such messages can have serial numbers assigned by any user agent who is authorized to send messages to the collective address (eg. the "exploder" or the list maintainer). In each case, special fields can be established for the group, or they can use regular defined fields as they wish, including insertions into the SUBJECT or inclusion in the X-DIST-ID field. Checking for duplicate messages should be done at the root exploder and at subsequent exploders, at a layer above the mail transport system, although there is certainly no way or reason to prevent any user from guarding against groupmail duplicates. I do not think this is an appropriate function for the MTS to handle, though it does seem right for a Bulletin Board User Agent program to guard against duplicates. As I see it, exploders that serialize their distributions will simply allow recipients to detect missed numbers and to request retransmission of missed numbers. I do not think a set of standard communication service messages will be appropriate. Perhaps a set of conventions would be helpful, but I think these should be left to each group to select. As with the Military and Amateur Radio groups, they already have conventions for handling their own business, and I am not prone to tell them to change, or to attempt to negotiate a common set of conventions for all groups. As for your concern that we disagree on the definition of "User Agent" we agree that most of the header fields in RFC 822 are "User Agent" fields. They are generally used to facilitate communication between peer User Agents. It is also true however that a few of the 822 fields can be viewed as "envelope" fields, but I am not entirely sure that this makes them "non-User-Agent" fields. I tend to want my User Agent to have access to the "envolope" fields attached to my received mail. I see no reason to deny anyone access to the envelopes in which they receive their mail. I certainly would not be pleased if the USPS conficated the envelopes, or obliterated what was written on them. At this point I might should further clarify my views on MTS/UA/USER relationships. I see USERS communicating as peers, by utilizing the services of a UAs which communicate at a peer level to serve other USERS. USERS employ conventions which could well be called a protocol. They use a common agreed upon language (if they want to communicate), and they use beginnings, and ending, and put sentences and paragraphs in between, et al. And, UAs use the services of the MTS with the service interfaces defined at Posting and Delivery Slots. I find it very useful to consider the USERs as just operating at a level above the UA in the same way as any protocol uses services at the next lower level of the OSI model. And, just in case I have piqued your interest as to where the upper limit might be, I would consider Diplomatic Protocols be the top level. Diplomatic Protocols are what you use when you cannot even directly signal to your peer level communicants! No guarantee that Diplomatic Protocols work though, as recent history has demonstrated. Best - Stef  Date: 29 May 83 02:09:41 PST (Sun) From: Stef.UCI@Rand-Relay Return-Path: Subject: Re: Broadcasting and Flood Mail (Errors-To, round 2) To: wcwells%Topaz.CC@Ucb-Vax Cc: header-people@Mit-Mc, stef.UCI@Rand-Relay In-Reply-To: Your message of 28 May 83 18:47:46 PDT (Sat). <8305290155.AA08793@UCBVAX.ARPA> Via: UCI; 29 May 83 2:11-PDT Per your question: "Do we want to provide for collective routing indicators at the mail transport system level, or at a lower level?." As I understand SMTP (not too perfectly) and XMAILER and MMDF, et al, there are mechanisms for "bundling" between sites and nodes and all that. I think we need to be concerned about such things of course, to allow for efficient transport carrier operations, but I don't see any need for setting up special protocols at the MTS level for newsnets or groupmail. And, I do not see any need for a special system for "Flood Mail" such as you described. I think we can do much better with a web of exploders which each have been given a list to send to. Perhaps we can set up a general broadcast web of this kind, but I am not sure how one might go about controlling access to it unless it operated with secret addresses for web nodes, or was programmed to only accept mail from certain addresses. There are some interesting ideas to be explored here, but I don't see much need for trying to establish standards for it now. I would prefer to see what we can do with mail as it is now to learn more about what might be needed next. Best - Stef  Date: 30 May 83 00:02:27 PDT (Mon) From: wcwells%Topaz.CC@Berkeley Subject: Groupmail distributor rules Message-Id: <8305300711.AA25281@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.341/3.31) id AA25281; 30 May 83 00:11:41 PDT (Mon) To: stef.UCI@Rand-Relay Cc: header-people@mit-mc As a true user agent, prehaps all an exploder should do is quote the received message in the text. For example: Date: XXXXXX From: Exploder-mailbox To: group-list Subject: xxxxxxxxxxxxxxx Comments: The following message was received from ...... at ........ Date: AAAAAAAA From: jkjkjkjkjkj etc. Hmmm - That could make for a lot of header fields in the text. I think that partial modification of the heading under a standard set of rules might be the best way to go. On the X-DIST-ID field. It may be mandatory for your branch of the distribution tree but not necessarily mine. Let's give different exploders some leeway. On serialization at the root exploder. I do not like insertion into the subject file (it should be the same as the input message). I prefer a separate field (such as "General-Message:") so the serial number can be easily stored separately. I agree with you on where the checking for duplicates should be done. On requesting retransmission of missed numbers at the user level --- A service message with a standard text will permit list maintainers (and exploder?) to automate the retransmission process. On "User Agent" fields --- I am not saying that users should not be able to create "envelope" fields, but rather that there are some that they should not (eg. audit-trail fields). That is user creation of "envelope" and lower fields should be controlled. ---- In one military message system I know of, users are permitted enter transport level signals. (It permits Communications personnel to take care of lower level transmission problems and special cases of message transmission. We keep the general user out of trouble by only telling him about the four or so standard signals he can use.) On your USER, UA and MTS levels. I am not sure where my "electronic post-office" fits in. It is either at the bottom of the UA layer or at the top of the MTS layer. (I prefer to think of it as at the bottom of the UA layer since I view the transport agent as an automated circuit operator.) Regards, Bill Wells topaz.wcwells@BERKELEY  Date: Mon 30 May 83 10:24:39-PDT From: Mark Crispin Subject: exploders, etc. To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Here's some gasoline for the flames... Most of what I've read so far has been of the form of a technical solution to some of the problems that exploder mailing lists generate. One should also consider the management aspects of this issue. Much mail to exploder lists tends to be in the "junk mail" category. It is possible that management may be displeased to have programmer time invested in engineering better support for junk mail. In particular, management may feel that the (well-documented) problems with exploders are the proper and necessary price to pay for the luxury of having the facility. -------  Date: 30 May 83 13:10:40 EDT (Mon) From: cbosgd!mark@Berkeley (Mark Horton) Subject: BBoards and Usenet Message-Id: <8305301710.AA17583@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA17583; 30 May 83 13:10:40 EDT (Mon) Received: by UCBVAX.ARPA (3.341/3.31) id AA29507; 30 May 83 10:30:11 PDT (Mon) To: header-people@mit-mc.ARPA Cc: stef%uci.uci@Rand-Relay.ARPA The Usenet standard specifies a format for articles, much like 822. (In fact, it's a restricted 822, and is 100% compatible.) This (almost) makes it practical to use ordinary mail to send news around. However, nobody sends news articles as plain ordinary mail, because there is no Errors-To: field. It's crazy to send an error message to the person who posted the note when two sites have a problem with their link. If this debate establishes a universal standard solution to this problem, it might be practical to use mail to transfer news. As it is, you use whatever means you have available. (Thus, there is no 821 or SMTP equivalent.) Typically this means uux, but over the ARPANET, the message is encapsulated (into a clean envelope, if you like) and sent as mail. The other end opens the envelope, throws it away, and processes the news article. (The article contains its own RFC 822 style headers, which are independent of those on the envelope.) If there is any chance that the mail system will mung the headers in the wrong way, or muck with the body of the article, then the envelope strategy will probably continue to be used. Another issue is batching. There is a high volume of news running around over low bandwidth phone lines. It turns out to be a real win to batch 20 or so articles into one package and ship them all over at once. For performance reasons, it may be a bad idea to change to mail unless mail gets batched as well. (But often people expect instant delivery of mail.) A beauty of Usenet (which, incidently, is not UUCP based - it runs on lots of non-UUCP machines) is that individual sites can experiment with news transfer methods without affecting the net. This is because it isn't necessary for every machine to talk directly to every other machine; each machine has only a few (3 or so) direct neighbors to talk to. So experiments require the cooperation of only a few sites. Very few fields need to be touched in transferring news, and the touching is simple. So if Stef wants to establish a new transfer mechanism (within the Usenet standard) using MMDF, it shouldn't hurt the rest of the net while he experiments, and there is no need to force everyone to convert. However, I do urge him to get a copy of the standard and join Usenet. Mark  Date: 30 May 83 13:19:48 EDT (Mon) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Usenet news standard Message-Id: <8305301719.AA17662@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA17662; 30 May 83 13:19:48 EDT (Mon) Received: by UCBVAX.ARPA (3.341/3.31) id AA29522; 30 May 83 10:30:40 PDT (Mon) To: header-people@mit-mc.ARPA There is a standard for Usenet format. I would be happy to mail it to this list, if everyone wants (it's 20 pages long) or to Jon for entry as an RFC. It's already been discussed at length on Usenet and adopted by Usenet as the standard. It corresponds to RFC 822. Mark  Date: 30 May 83 12:33:47 PST (Mon) From: Stef.UCI@Rand-Relay Return-Path: Subject: Re: Groupmail distributor rules To: wcwells%Topaz.CC@Ucb-Vax Cc: header-people@Mit-Mc, stef.UCI@Rand-Relay In-Reply-To: Your message of 30 May 83 00:02:33 PDT (Mon). <8305300710.AA25259@UCBVAX.ARPA> Via: UCI; 30 May 83 13:38-PDT Hi Bill - Lets first deal with the confusion about what an "electronic post office" might be. I see it as being very simply segregated. If something is a User Agent Function, it is not in the Post Office. In my model, the Post Office operates the circuits, and is fully responsible for mail items between the Posting Slot and the Delivery Slot, just like the USPS. I strongly favor close funtional correlations between the USPS and our Electronic Post Office. This simplifies many decisions about what is right and what is wrong to do. If the USPS delivers something to me, it is then mine and I can do with it whatever is right according to the rules of ownership of that item. If it is copyrighted, then I am limited by copyright rules. If I am under contract in some way to protect it from disclosure, then I must do so. But note that these constaints have nothing to do with postal service rules, electronic, hydraulic, or paper based. Next, I do not want to force any exploder to either enclose, or not enclose, each distribted item down inside the body of a new message. Digestifiers will want to enclose in such a way that undigestifiers can unenclose for recipients, all at the User Agent Level. Some groups will want single messages enclosed, and other groups will not. I see no reason to dictate either way. But, if items are enclosed, then the normal User Agent tools for deaing with the items will be hard to use unless the tools include an unencloser or undigestifier. MsgGroup items have been archived since 1975 with MSGGROUP#nnnn insertions in their subject fields. Long ago, before COMSAT distribution, I used to manually insert and manually REMAIL each item, so list recipients would have the numbers to use for citation puposes. The advanced technology of COMSAT took that away from us because COMSAT needs to adhere to the rules of the Sanctity of the Seal. However, as the MSGRROUP Moderator, I had long before established that my SUBJECT field insertion was a good thing to do, and the subscribers seemed to like it, so I have continued to do the insertion for the archives, after distribution. I feel that deciding about such things should be left to the affected groups to reflect their own needs and values. And last, I don't see any need for your exploder to use my chosen X-DIST-ID field if you do not want to, but if you then want to distribute my MsgGroup mail with your distributor, you may have to forego some useful functionality. This can be your choice. It will only affect you and your distributees. It cannot effect what I do. If my exploder encounters one of your distribution items, it will just insert an X-DIST-ID anyway, unless one already exists. I think there is room to negotiate about the name to be used for my X-DIST-ID function, but I think that my choice is as good as any other. It is reasonably short and descrtiptive of its purpose. It is named to avoid conflicts with future new 822 or 821 fields. It is not misnamed as it would be if called NEWSID or GROUPID. Etc, et al ... In choosing it, we beat around a number of other choices, but did not find anything that seems to fit better than X-DIST-ID, so we stuck with it. If you want to mount a naming contest, that is fine with me. My entry is X-DIST-ID. Until I or someone with greater authority (like the project programmer) chooses to use something else, our code will continue to use it. Democracy may be fun, but explorers get to name their discoveries. Arguments to the contrary are OK, but lets not waste too much time and effort on them. Best - Stef  Date: 31 May 83 13:42:53 EDT (Tue) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Usenet standard text (19 page long message) Message-Id: <8305311742.AA00585@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA00585; 31 May 83 13:42:53 EDT (Tue) Received: by UCBVAX.ARPA (3.341/3.31) id AA01339; 31 May 83 14:52:35 PDT (Tue) To: header-people@mit-mc.ARPA I have received several requests for the text of the Usenet standard, so I am mailing it to header-people. Apologies in advance if the long message breaks any mailers. The document is formatted for a line printer, using CR to overstrike. I hope this won't cause any problems. Note that this standard has already been discussed on and adopted by Usenet. Since it is a news standard, not a mail standard, header-people (and msggroup and namedroppers) was not the appropriate forum. While there is always room for a future document which is different from this one, I'd like to mention that this is NOT a draft, and is not subject to revisions in this version. In particular, software conforming to this standard has already been released and is running on many Usenet sites. Expositional comments (alas, I noticed some typos in skimming it just now) and ideas for future improvements are always welcome. Mark Standard for Interchange of USENET Messages Mark R. Horton 1. Introductionî Introductionî Introductionî Introduction This document defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news, and so on. There are five sections to this document. Section two section defines the format. Section three defines the valid control messages. Section four specifies some valid transmission methods. Section five describes the overall news propagation algorithm. 2. Article Formatî Article Formatî Article Formatî Article Format The primary consideration in choosing an article format is that it fit in with existing tools as well as possible. Existing tools include both implementations of mail and news. (The notesfiles system from the University ofî __________ Illinois is considered a news implementation.) A standard format for mail messages has existed for many years on the ARPANET, and this format meets most of the needs of USENET. Since the ARPANET format is extensible, extensions to meet the additional needs of USENET are easily made within the ARPANET standard. Therefore, the rule is adopted that all USENET news articles must be formatted as valid ARPANET mail messages, according to the ARPANET standard RFC 822. This standard is more restrictive than the ARPANET standard, placing additional requirements on each article and forbidding use of certain ARPANET features. However, it should always be possible to use a tool expecting an ARPANET message to process a news article. In any situation where this standard conflicts with the ARPANET standard, RFC 822 should be considered correct and this standard in error. An example message is included to illustrate the fields. - 2 - Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP Posting-Version: version B 2.10 2/13/83; site eagle.UUCP Path: cbosgd!mhuxj!mhuxt!eagle!jerry From: jerry@eagle.uucp (Jerry Schwarz) Newsgroups: net.general Subject: Usenet Etiquette -- Please Read Message-ID: <642@eagle.UUCP> Date: Friday, 19-Nov-82 16:14:55 EST Followup-To: net.news Expires: Saturday, 1-Jan-83 00:00:00 EST Date-Received: Friday, 19-Nov-82 16:59:30 EST Organization: Bell Labs, Murray Hill The body of the article comes here, after a blank line. Here is an example of a message in the old format (before the existence of this standard). It is recommended that implementations also accept articles in this format to ease upward conversion. From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz) Newsgroups: net.general Title: Usenet Etiquette -- Please Read Article-I.D.: eagle.642 Posted: Fri Nov 19 16:14:55 1982 Received: Fri Nov 19 16:59:30 1982 Expires: Mon Jan 1 00:00:00 1990 The body of the article comes here, after a blank line. Some news systems transmit news in the ``A'' format, which looks like this: Aeagle.642 net.general cbosgd!mhuxj!mhuxt!eagle!jerry Fri Nov 19 16:14:55 1982 Usenet Etiquette - Please Read The body of the article comes here, with no blank line. An article consists of several header lines, followed by a blank line, followed by the body of the message. The header lines consist of a keyword, a colon, a blank, and some additional information. This is a subset of the ARPANET standard, simplified to allow simpler software to handle it. The ``from'' line may optionally include a full name, in the format above, or use the ARPANET angle bracket syntax. To keep the implementations simple, other formats (for example, with part of the machine address after the close parenthesis) are not allowed. The ARPANET convention of continuation header lines (beginning with a - 3 - blank or tab) is allowed. Certain headers are required, certain headers are optional. Any unrecognized headers are allowed, and will be passed through unchanged. The required headers are Relay-Version, Posting-Version, From, Date, Newsgroups, Subject, Message-ID, Path. The optional headers are Followup-To, Date-Received, Expires, Reply-To, Sender, References, Control, Distribution, Organization. 2.1 Required Headersî Required Headersî Required Headersî Required Headers 2.1.1 Relay-Version This header line shows the versionî _____________ of the program responsible for the transmission of this article over the immediate link, that is, the program that is relaying the article from the next site. For example, suppose site A sends an article to site B, and site B forwards the article to site C. The message being transmitted from A to B would have a Relay-Version header identifying the program running on A, and the message transmitted from B to C would identify the program running on B. This header can be used to interpret older headers in an upward compatible way. Relay-Version must always be the first in a message; thus, all articles meeting this standard will begin with an upper case ``R''. No other restrictions are placed on the order of header lines. The line contains two fields, separated by semicolons. The fields are the version and the full domain name of the site. The version should identify the system program used (e.g., ``B'') as well as a version number and version date. For example, the header line might contain Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP This header should not be passed on to additional sites. A relay program, when passing an article on, should include only its own Relay-Version, not the Relay-Version of some other site. (For upward compatibility with older software, if a Relay-Version is found in a header which is not the first line, it should be assumed to be moved by an older version of news and deleted.) 2.1.2 Posting-Version This header identifies theî _______________ software responsible for entering this message into the network. It has the same format as Relay-Version. It will normally identify the same site as the Message-ID, unless the posting site is serving as a gateway for a message that already contains a message ID generated by mail. (While it is permissible for a gateway to use an externally generated message ID, the message ID should be - 4 - checked to ensure it conforms to this standard and to RFC 822.) 2.1.3 From The From line contains the electronic mailingî ____ address of the person who sent the message, in the ARPA internet syntax. It may optionally also contain the full name of the person, in parentheses, after the electronic address. The electronic address is the same as the entity responsible for originating the article, unless the Sender header is present, in which case the From header might not be verified. Note that in all site and domain names, upper and lower case are considered the same, thus mark@cbosgd.UUCP, mark@cbosgd.uucp, and mark@CBosgD.UUcp are all equivalent. User names may or may not be case sensitive, for example, Billy@cbosgd.UUCP might be different from BillY@cbosgd.UUCP. Programs should avoid changing the case of electronic addresses when forwarding news or mail. RFC 822 specifies that all text in parentheses is to be interpreted as a comment. It is common in ARPANET mail to place the full name of the user in a comment at the end of the From line. This standard specifies a more rigid syntax. The full name is not considered a comment, but an optional part of the header line. Either the full name is omitted, or it appears in parentheses after the electronic address of the person posting the article, or it appears before an electronic address enclosed in angle brackets. Thus, the three permissible forms are: From: mark@cbosgd.UUCP From: mark@cbosgd.UUCP (Mark Horton) From: Mark Horton Full names may contain any printing ASCII characters from space through tilde, with the exceptions that they may not contain parentheses ``('' or ``)'', or angle brackets ``<'' or ``>''. Additional restrictions may be placed on full names by the mail standard, in particular, the characters comma ``,'', colon ``:'', and semicolon ``;'' are inadvisable in full names. 2.1.4 Date The Date line (formerly ``Posted'') is theî ____ date, in a format that must be acceptable both to the ARPANET and to the getdate routine, that the article was originally posted to the network. This date remains unchanged as the article is propagated throughout the network. One format that is acceptable to both is Weekday, DD-Mon-YY HH:MM:SS TIMEZONE - 5 - Several examples of valid dates appear in the sample article above. Note in particular that ctime format: Wdy Mon DD HH:MM:SS YYYY is not acceptable because it is not a valid ARPANET date.î ___ However, since older software still generates this format, news implementations are encouraged to accept this format and translate it into an acceptable format. The contents of the TIMEZONE field is currently subject to revision. Eventually, we hope to accept all possible worldwide time zone abbreviations, including the usual American zones (PST, PDT, MST, MDT, CST, CDT, EST, EDT), the other North American zones (Bering through Newfoundland), European zones, Australian zones, and so on. Lacking a complete list at present (and unsure if an unambiguous list exists), authors of software are encouraged to keep this code flexible, and in particular not to assume that time zone names are exactly three letters long. Implementations are free to edit this field, keeping the time the same, but changing the time zone (with an appropriate adjustment to the local time shown) to a known time zone. 2.1.5 Newsgroups The Newsgroups line specifies whichî __________ newsgroup or newsgroups the article belongs in. Multiple newsgroups may be specified, separated by a comma. Newsgroups specified must all be the names of existing newsgroups, as no new newsgroups will be created by simply posting to them. Wildcards (e.g., the word ``all'') are never allowed in a Newsgroups line. For example, a newsgroup ``net.all'' is illegal, although a newsgroup name ``net.sport.football'' is permitted. If an article is received with a Newsgroups line listing some valid newsgroups and some invalid newsgroups, a site should not remove invalid newsgroups from the list. Instead, the invalid newsgroups should be ignored. For example, suppose site A subscribes to the classes ``btl.all'' and ``net.all'', and exchanges news articles with site B, which subscribes to ``net.all'' but not ``btl.all''. Suppose A receives an article with ``Newsgroups: net.micro,btl.general''. This article is passed on to B because B receives net.micro, but B does not receive btl.general. A must leave the Newsgroup line unchanged. If it were to remove ``btl.general'', the edited header could eventually reenter the ``btl.all'' class, resulting in an article that is not shown to users - 6 - subscribing to ``btl.general''. Also, followups from outside ``btl.all'' would not be shown to such users. 2.1.6 Subject The Subject line (formerly ``Title'')î _______ tells what the article is about. It should be suggestive enough of the contents of the article to enable a reader to make a decision whether to read the article based on the subject alone. If the article is submitted in response to another article (e.g., is a ``followup'') the default subject should begin with the four characters ``Re: '' and the References line is required. (The user might wish to edit the subject of the followup, but the default should begin with ``Re: ''.) 2.1.7 Message-ID The Message-ID line gives the article aî __________ unique identifier. The same message ID may not be reused during the lifetime of any article with the same message ID. (It is recommended that no message ID be reused for at least two years.) Message ID's have the syntax "<" "string not containing blank or >" ">" In order to conform to RFC 822, the Message-ID must have the format "<" "unique" "@" "full domain name" ">" where ``full domain name'' is the full name of the host at which the article entered the network, including a domain that host is in, and unique is any string of printing ASCII characters, not including "<", ">", or "@". For example, the "unique" part could be an integer representing a sequence number for articles submitted to the network, or a short string derived from the date and time the article was created. For example, valid message ID for an article submitted from site ucbvax in domain Berkeley.ARPA would be "<4123@ucbvax.Berkeley.ARPA>". Programmers are urged not to make assumptions about the content of message ID fields from other hosts, but to treat them as unknown character strings. It is not safe, for example, to assume that a message ID will be under 14 characters, nor that it is unique in the first 14 characters. The angle brackets are considered part of the message ID. Thus, in references to the message ID, such as the ihave/sendme and cancel control messages, the angle brackets are included. White space characters (e.g., blank and tab) are not allowed in a message ID. All characters between the angle brackets must be printing ASCII characters. - 7 - 2.1.8 Path This line shows the path the article took toî ____ reach the current system. When a system forwards the message, it should add its own name to the list of systems in the Path line. The names may be separated by any punctuation character or characters, thus ``cbosgd!mhuxj!mhuxt'', ``cbosgd, mhuxj, mhuxt'', and ``@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp'' and even ``teklabs, zehntel, sri-unix@cca!decvax'' are valid entries. (The latter path indicates a message that passed through decvax, cca, sri-unix, zehntel, and teklabs, in that order.) Additional names should be added from the left, for example, the most recently added name in the third example was ``teklabs''. Letters, digits, periods and hyphens are considered part of site names; other punctuation, including blanks, are considered separators. Normally, the rightmost name will be the name of the originating system. However, it is also permissible to include an extra entry on the right, which is the name of the sender. This is for upward compatibility with older system. The Path line is not used for replies, and should not be taken as a mailing address. It is intended to show the route the message travelled to reach the local site. There are several uses for this information. One is to monitor USENET routing for performance reasons. Another is to establish a path to reach new sites. Perhaps the most important is to cut down on redundant USENET traffic by failing to forward a message to a site that is known to have already received it. In particular, when site A sends an article to site B, the Path line includes ``A'', so that site B will not immediately send the article back to site A. The site name each site uses to identify itself should be the same as the name by which its neighbors know it, in order to make this optimization possible. A site adds its own name to the front of a path when it receives a message from another site. Thus, if a message with path A!X!Y!Z is passed from site A to site B, B will add its own name to the path when it receives the message from A, e.g., B!A!X!Y!Z. If B then passes the message on to C, the message sent to C will contain the path B!A!X!Y!Z, and when C receives it, C will change it to C!B!A!X!Y!Z. Special upward compatibility note: Since the From, Sender, and Reply-To lines are in internet format, and since many USENET sites do not yet have mailers capable of understanding internet format, it would break the reply - 8 - capability to completely sever the connection between the Path header and the reply function. Thus, sites are required to continue to keep the Path line in a working reply format as much as possible, until January 1, 1984. It is recognized that the path is not always a valid reply string in older implementations, and no requirement to fix this problem is placed on implementations. However, the existing convention of placing the site name and an ``!'' at the front of the path, and of starting the path with the site name, an ``!'', and the user name, should be maintained at least until 1984. 2.2 Optional Headersî Optional Headersî Optional Headersî Optional Headers 2.2.1 Reply-To This line has the same format as From.î ________ If present, mailed replies to the author should be sent to the name given here. Otherwise, replies are mailed to the name on the From line. (This does not prevent additional copies from being sent to recipients named by the replier, or on To or Cc lines.) The full name may be optionally given, in parentheses, as in the From line. 2.2.2 Sender This field is present only if the submitterî ______ manually enters a From line. It is intended to record the entity responsible for submitting the article to the network, and should be verified by the software at the submitting site. For example, if John Smith is visiting CCA and wishes to post an article to the network, using friend Sarah Jones account, the message might read From: smith@ucbvax.uucp (John Smith) Sender: jones@cca.arpa (Sarah Jones) If a gateway program enters a mail message into the network at site sri-unix, the lines might read From: John.Doe@CMU-CS-A.ARPA Sender: network@sri-unix.ARPA The primary purpose of this field is to be able to track down articles to determine how they were entered into the network. The full name may be optionally given, in parentheses, as in the From line. 2.2.3 Followup-To This line has the same format asî ___________ Newsgroups. If present, follow-up articles are to be posted to the newsgroup(s) listed here. If this line is not present, followups are posted to the newsgroup(s) listed in the Newsgroups line, except that followups to - 9 - ``net.general'' should instead go to ``net.followup''. 2.2.4 Date-Received This line (formerly ``Received'') isî _____________ in a legal USENET date format. It records the date and time that the article was first received on the local system. If this line is present in an article being transmitted from one host to another, the receiving host should ignore it and replace it with the current date. Since this field is intended for local use only, no site is required to support it. However, no site should pass this field on to another site unchanged. 2.2.5 Expires This line, if present, is in a legalî _______ USENET date format. It specifies a suggested expiration date for the article. If not present, the local default expiration date is used. This field is intended to be used to clean up articles with a limited usefulness, or to keep important articles around for longer than usual. For example, a message announcing an upcoming seminar could have an expiration date the day after the seminar, since the message is not useful after the seminar is over. Since local sites have local policies for expiration of news (depending on available disk space, for instance), users are discouraged from providing expiration dates for articles unless there is a natural expiration date associated with the topic. System software should almost never provide a default Expires line. Leave it out and allow local policies to be used unless there is a good reason not to. 2.2.6 References This field lists the message ID's ofî __________ any articles prompting the submission of this article. It is required for all follow-up articles, and forbidden when a new subject is raised. Implementations should provide a follow-up command, which allows a user to post a follow-up article. This command should generate a Subject line which is the same as the original article, except that if the original subject does not begin with ``Re: '' or ``re: '', the four characters ``Re: '' are inserted before the subject. If there is no References line on the original header, the References line should contain the message ID of the original article (including the angle brackets). If the original article does have a References line, the followup article should have a References line containing the text of the original References line, a blank, and the message ID of the original article. The purpose of the References header is to allow articles to be grouped into conversations by the user interface program. This allows conversations within a newsgroup to - 10 - be kept together, and potentially users might shut off entire conversations without unsubscribing to a newsgroup. User interfaces may not make use of this header, but all automatically generated followups should generate the References line for the benefit of systems that do use it, and manually generated followups (e.g. typed in well after the original article has been printed by the machine) should be encouraged to include them as well. 2.2.7 Control If an article contains a Control line, theî _______ article is a control message. Control messages are used for communication among USENET host machines, not to be read by users. Control messages are distributed by the same newsgroup mechanism as ordinary messages. The body of the Control header line is the message to the host. For upward compatibility, messages that match the newsgroup pattern ``all.all.ctl'' should also be interpreted as control messages. If no Control: header is present on such messages, the subject is used as the control message. However, messages on newsgroups matching this pattern do not conform to this standard. 2.2.8 Distribution This line is used to alter theî ____________ distribution scope of the message. It has the same format as the Newsgroups line. User subscriptions are still controlled by Newsgroups, but the message is sent to all systems subscribing to the newsgroups on the Distribution line instead of the Newsgroups line. Thus, a car for sale in New Jersey might have headers including Newsgroups: net.auto,net.wanted Distribution: nj.all so that it would only go to persons subscribing to net.auto or net.wanted within New Jersey. The intent of this header is to further restrict the distribution of a newsgroup, not to increase it. A local newsgroup, such as nj.crazy-eddie, will probably not be propagated by sites outside New Jersey that do not show such a newsgroup as valid. Wildcards in newsgroup names in the Distribution line are allowed. Followup articles should default to the same Distribution line as the original article, but the user can change it to a more limited one, or escalate the distribution if it was originally restricted and a more widely distributed reply is appropriate. 2.2.9 Organization The text of this line is a shortî ____________ phrase describing the organization to which the sender belongs, or to which the machine belongs. The intent of this line is to help identify the person posting the - 11 - message, since site names are often cryptic enough to make it hard to recognize the organization by the electronic address. 3. Control Messagesî Control Messagesî Control Messagesî Control Messages This section lists the control messages currently defined. The body of the Control header is the control message. Messages are a sequence of zero or more words, separated by white space (blanks or tabs). The first word is the name of the control message, remaining words are parameters to the message. The remainder of the header and the body of the message are also potential parameters; for example, the From line might suggest an address to which a response is to be mailed. Implementors and administrators may choose to allow control messages to be automatically carried out, or to queue them for manual processing. However, manually processed messages should be dealt with promptly. 3.1 Cancelî Cancelî Cancelî Cancel cancel If an article with the given message ID is present on the local system, the article is cancelled. This mechanism allows a user to cancel an article after the article has been distributed over the network. Only the author of the article or the local super user is allowed to use this message. The verified sender of a message is the Sender line, or if no Sender line is present, the From line. The verified sender of the cancel message must be the same as either the Sender or From field of the original message. A verified sender in the cancel message is allowed to match an unverified From in the original message. 3.2 Ihave/Sendmeî Ihave/Sendmeî Ihave/Sendmeî Ihave/Sendme ihave sendme This message is part of the ``ihave/sendme'' protocol, which allows one site (say ``A'') to tell another site (``B'') that a particular message has been received on A. Suppose that site A receives article ``ucbvax.1234'', and wishes to transmit the article to site B. A sends the control message ``ihave ucbvax.1234 A'' to site B (by - 12 - posting it to newsgroup ``to.B''). B responds with the control message ``sendme ucbvax.1234 B'' (on newsgroup to.A) if it has not already received the article. Upon receiving the Sendme message, A sends the article to B. This protocol can be used to cut down on redundant traffic between sites. It is optional and should be used only if the particular situation makes it worthwhile. Frequently, the outcome is that, since most original messages are short, and since there is a high overhead to start sending a new message with UUCP, it costs as much to send the Ihave as it would cost to send the article itself. One possible solution to this overhead problem is to batch requests. Several message ID's may be announced or requested in one message. If no message ID's are listed in the control message, the body of the message should be scanned for message ID's, one per line. 3.3 Newgroupî Newgroupî Newgroupî Newgroup newgroup This control message creates a new newsgroup with the name given. Since no articles may be posted or forwarded until a newsgroup is created, this message is required before a newsgroup can be used. The body of the message is expected to be a short paragraph describing the intended use of the newsgroup. 3.4 Rmgroupî Rmgroupî Rmgroupî Rmgroup rmgroup This message removes a newsgroup with the given name. Since the newsgroup is removed from every site on the network, this command should be used carefully by a responsible administrator. 3.5 Sendsysî Sendsysî Sendsysî Sendsys sendsys (no arguments) The ``sys'' file, listing all neighbors and which newsgroups are sent to each neighbor, will be mailed to the author of the control message (Reply-to, if present, otherwise From). This information is considered public information, and it is a requirement of membership in USENET that this information be provided on request, either automatically in response to this control message, or manually, by mailing the requested information to the - 13 - author of the message. This information is used to keep the map of USENET up to date, and to determine where netnews is sent. The format of the file mailed back to the author should be the same as that of the ``sys'' file. This format has one line per neighboring site (plus one line for the local site), containing four colon separated fields. The first field has the site name of the neighbor, the second field has a newsgroup pattern describing the newsgroups sent to the neighbor. The third and fourth fields are not defined by this standard. A sample response: From cbosgd!mark Sun Mar 27 20:39:37 1983 Subject: response to your sendsys request To: mark@cbosgd.UUCP Responding-System: cbosgd.UUCP cbosgd:osg,cb,btl,bell,net,fa,to,test ucbvax:net,fa,to.ucbvax:L: cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi 3.6 Senduunameî Senduunameî Senduunameî Senduuname senduuname (no arguments) The ``uuname'' program is run, and the output is mailed to the author of the control message (Reply-to, if present, otherwise From). This program lists all uucp neighbors of the local site. This information is used to make maps of the UUCP network. The sys file is not the same as theî ___ UUCP L.sys file. The L.sys file should never beî _____ transmitted to another party without the consent of the sites whose passwords are listed therein. It is optional for a site to provide this information. Some reply should be made to the author of the control message, so that a transmission error won't be blamed. It is also permissible for a site to run the uuname program (or in some other way determine the uucp neighbors) and edit the output, either automatically or manually, before mailing the reply back to the author. The file should contain one site per line, beginning with the uucp site name. Additional information may be included, separated from the site name by a blank or tab. The phone number or password for the site should NOT be included, as the reply is considered to be in the public domain. (The uuname - 14 - program will send only the site name and not the entire contents of the L.sys file, thus, phone numbers and passwords are not transmitted.) The purpose of this message is to generate and maintain UUCP mail routing maps. Thus, connections over which mail can be sent using the site!user syntax should be included, regardless of whether the link is actually a UUCP link at the physical level. If a mail router should use it, it should be included. Since all information sent in response to this message is optional, sites are free to edit the list, deleting secret or private links they do not wish to publicise. 3.7 Versionî Versionî Versionî Version version (no arguments) The name and version of the software running on the local system is to be mailed back to the author of the article (Reply-to if present, otherwise From). 4. Transmission Methodsî Transmission Methodsî Transmission Methodsî Transmission Methods USENET is not a physical network, but rather a logical network resting on top of several existing physical networks. These networks include, but are not limited to, UUCP, the ARPANET, an Ethernet, the BLICN network, an NSC Hyperchannel, and a Berknet. What is important is that two neighboring systems on USENET have some method to get a new article, in the format listed here, from one system to the other, and once on the receiving system, processed by the netnews software on that system. (On UNIX systems, this usually means the ``rnews'' program being run with the article on the standard input.) It is not a requirement that USENET sites have mail systems capable of understanding the ARPA Internet mail syntax, but it is strongly recommended. Since From, Reply-To, and Sender lines use the Internet syntax, replies will be difficult or impossible without an internet mailer. A site without an internet mailer can attempt to use the Path header line for replies, but this field is not guaranteed to be a working path for replies. In any event, any site generating or forwarding news messages must have an internet address that allows them to receive mail from sites with internet mailers, and they must include their internet address on their From line. - 15 - 4.1 Remote Executionî Remote Executionî Remote Executionî Remote Execution Some networks permit direct remote command execution. On these networks, news may be forwarded by spooling the rnews command with the article on the standard input. For example, if the remote system is called ``remote'', news would be sent over a UUCP link with the command ``uux - remote!rnews'', and on a Berknet, ``net -mremote rnews''. It is important that the article be sent via a reliable mechansim, normally involving the possibility of spooling, rather than direct real-time remote execution. This is because, if the remote system is down, a direct execution command will fail, and the article will never be delivered. If the article is spooled, it will eventually be delivered when both systems are up. 4.2 Transfer by Mailî Transfer by Mailî Transfer by Mailî Transfer by Mail On some systems, direct remote spooled execution is not possible. However, most systems support electronic mail, and a news article can be sent as mail. One approach is to send a mail message which is identical to the news message: the mail headers are the news headers, and the mail body is the news body. By convention, this mail is sent to the user ``newsmail'' on the remote machine. One problem with this method is that it may not be possible to convince the mail system that the From line of the message is valid, since the mail message was generated by a program on a system different from the source of the news article. Another problem is that error messages caused by the mail transmission would be sent to the originator of the news article, who has no control over news transmission between two cooperating hosts and does not know who to contact. Transmission error messages should be directed to a responsible contact person on the sending machine. A solution to this problem is to encapsulate the news article into a mail message, such that the entire article (headers and body) are part of the body of the mail message. The convention here is that such mail is sent to user ``rnews'' on the remote system. A mail message body is generated by prepending the letter ``N'' to each line of the news article, and then attaching whatever mail headers are convenient to generate. The N's are attached to prevent any special lines in the news article from interfering with mail transmission, and to prevent any extra lines inserted by the mailer (headers, blank lines, etc.) from becoming part of the news article. A program on the receiving machine receives mail to ``rnews'', - 16 - extracting the article itself and invoking the ``rnews'' program. An example in this format might look like this: Date: Monday, 3-Jan-83 08:33:47 MST From: news@cbosgd.UUCP Subject: network news article To: rnews@npois.UUCP NRelay-Version: B 2.10 2/13/83 cbosgd.UUCP NPosting-Version: B 2.9 6/21/82 sask.UUCP NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek NFrom: derek@sask.UUCP (Derek Andrew) NNewsgroups: net.test NSubject: necessary test NMessage-ID: <176@sask.UUCP> NDate: Monday, 3-Jan-83 00:59:15 MST N NThis really is a test. If anyone out there more than 6 Nhops away would kindly confirm this note I would Nappreciate it. We suspect that our news postings Nare not getting out into the world. N Using mail solves the spooling problem, since mail must always be spooled if the destination host is down. However, it adds more overhead to the transmission process (to encapsulate and extract the article) and makes it harder for software to give different priorities to news and mail. 4.3 Batchingî Batchingî Batchingî Batching Since news articles are usually short, and since a large number of messages are often sent between two sites in a day, it may make sense to batch news articles. Several articles can be combined into one large article, using conventions agreed upon in advance by the two sites. One such batching scheme is described here; its use is still considered experimental. News articles are combined into a script, separated by a header of the form: ##! rnews 1234 where 1234 is the length, in bytes, of the article. Each such line is followed by an article containing the given number of bytes. (The newline at the end of each line of the article is counted as one byte, for purposes of this count, even if it is stored as CRLF.) For example, a batch - 17 - of articles might look like this: #! rnews 374 Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP Posting-Version: version B 2.10 2/13/83; site eagle.UUCP Path: cbosgd!mhuxj!mhuxt!eagle!jerry From: jerry@eagle.uucp (Jerry Schwarz) Newsgroups: net.general Subject: Usenet Etiquette -- Please Read Message-ID: <642@eagle.UUCP> Date: Friday, 19-Nov-82 16:14:55 EST Here is an important message about USENET Etiquette. #! rnews 378 Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP Posting-Version: version B 2.10 2/13/83; site eagle.UUCP Path: cbosgd!mhuxj!mhuxt!eagle!jerry From: jerry@eagle.uucp (Jerry Schwarz) Newsgroups: net.followup Subject: Notes on Etiquette article Message-ID: <643@eagle.UUCP> Date: Friday, 19-Nov-82 17:24:12 EST There was something I forgot to mention in the last message. Batched news is recognized because the first character in the message is ``#''. The message is then passed to the unbatcher for interpretation. 5. The News Propagation Algorithmî The News Propagation Algorithmî The News Propagation Algorithmî The News Propagation Algorithm This section describes the overall scheme of USENET and the algorithm followed by sites in propagating news to the entire network. Since all sites are affected by incorrectly formatted articles and by propagation errors, it is important for the method to be standardized. USENET is a directed graph. Each node in the graph is a host computer, each arc in the graph is a transmission path from one host to another host. Each arc is labelled with a newsgroup pattern, specifying which newsgroup classes are forwarded along that link. Most arcs are bidirectional, that is, if site A sends a class of newsgroups to site B, then site B usually sends the same class of newsgroups to site A. This bidirectionality is not, however, required. USENET is made up of many subnetworks. Each subnet has a name, such as ``net'' or ``btl''. The special subnet ``net'' is defined to be USENET, although the union of all - 18 - subnets may be a superset of USENET (because of sites that get local newsgroup classes but do not get net.all). Each subnet is a connected graph, that is, a path exists from every node to every other node in the subnet. In addition, the entire graph is (theoretically) connected. (In practice, some political considerations have caused some sites to be unable to post articles reaching the rest of the network.) An article is posted on one machine to a list of newsgroups. That machine accepts it locally, then forwards it to all its neighbors that are interested in at least one of the newsgroups of the message. (Site A deems site B to be ``interested'' in a newsgroup if the newsgroup matches the pattern on the arc from A to B. This pattern is stored in a file on the A machine.) The sites receiving the incoming article examine it to make sure they really want the article, accept it locally, and then in turn forward the article to all their interestedî _____ neighbors. This process continues until the entire network has seen the article. An important part of the algorithm is the prevention of loops. The above process would cause a message to loop along a cycle forever. In particular, when site A sends an article to site B, site B will send it back to site A, which will send it to site B, and so on. One solution to this is the history mechanism. Each site keeps track of all articles it has seen (by their message ID) and whenever an article comes in that it has already seen, the incoming article is discarded immediately. This solution is sufficient to prevent loops, but additional optimizations can be made to avoid sending articles to sites that will simply throw them away. One optimization is that an article should never be sent to a machine listed in the Path line of the header. When a machine name is in the Path line, the message is known to have passed through the machine. Another optimization is that, if the article originated on site A, then site A has already seen the article. (Origination can be determined by the Posting-Version line.) Thus, if an article is posted to newsgroup ``net.misc'', it will match the pattern ``net.all'' (where ``all'' is a metasymbol that matches any string), and will be forwarded to all sites that subscribe to net.all (as determined by what their neighbors send them). These sites make up the ``net'' subnetwork. An article posted to ``btl.general'' will reach all sites receiving ``btl.all'', but will not reach sites that do not get ``btl.all''. In effect, the - 19 - articles reaches the ``btl'' subnetwork. An article posted to newsgroups ``net.micro,btl.general'' will reach all sites subscribing to either of the two classes.  Date: 7 Jun 1983 1028-PDT From: Scott L. McGregor Return-Path: Subject: problems with NBS standard Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT To: msggroup@BRL Cc: header-people@MIT-MC, name-droppers@SRI-NIC Message-Id: <423854936.28783.hplabs@HP-VENUS> Via: HP-Labs; 7 Jun 83 23:26-PDT There has been a flurry of interest in the NBS Specifications for message format for computer based message systems. There have been many messages touting this standard and telling of wide spread acceptance. The purpose of this message is to describe a comparison of the NBS standard with RFC822 that was done here at HP, and reasons are given why RFC822 was found superior. The result of this comparison is that HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed by our facility in Pinewood England) currently support an outbound RFC822 interface, and will in the future support an inbound RFC822 interface. While future interfaces to the NBS standard cannot be ruled out, none is planned at this time. Many MSGGROUP members have made reference to the complexity of the NBS standard. The standard is complex for anyone to implement, particularly if they are interested in supporting the full breadth of the standard. But, as has been pointed out by others, only a small subset is required. The real problem with NBS lies elsewhere. It is purely an implementation problem. The problem is that NBS relies on bit strings (called octets) that allows the message server to recognize fields. RFC822 on the other hand requires no special bit-strings; all heading handling is done in clear text. In an ascii-to-ascii interchange, this is not a problem, but in an ascii-to-ebcdic environment or ascii-to-printed output environment, this is disasterous. Because of the imbedded bit strings, common ascii-to-ebcdic file transfer programs cannot be used; the bit-strings would get translated too. So, the file transfer process must be specialized to deal with the special requirements of NBS mail. This is a hardship on the mail developer, and goes against the spirit of the ISO OSI layered architecture protocol. This is particularly a bad implementation problem because there exist many different ascii-to-ebcdic translation tables that are widely used. The problem also exists in an ascii-to-text environment. When I send mail to someone, I cannot be sure whether they will receive it in hardcopy or soft. They may not have an account on a computer system, but may be served by a printer attached to a remote computer, and their messages may be delivered by interoffice mail. Using RFC822, I can send the message down the line to their printer directly and I don't even have to know if it is a computer, or if it is a printer or some other output device. NBS definately requires another computer at the distant site to decode the bit strings. I suppose that to some, the above may not seem like weighty concerns. Many Ascii worlders would feel little grief in denying contact to the ebcdic world (a world badly in need of additional communcication from this community). Nor would they feel any grief in requiring smarter printers, etc. (or perhaps of requiring anyone interested in internet mail to have a computer account), after all, hardware costs are decreasing. Nor would they concern themselves with the added burden on mail implementers. To those of you with these sentiments, I can only suggest that you lobby harder, because those people who control EDP purse strings in companies are concerned about additional hardware requirements. They are also concerned about mail systems that are biased against certain vendors, particularly if they happen to own some of this hardware already. For this reason, HP Pinewood decided to go with RFC822 over NBS as an initial inter-net standard. About the author: ----------------- Many people seem to want to know additional information about authors of large messages such as this one. If you are not one of these people, no need to read further. Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data center. The data center currently supports an IBM3081K running MVS, an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6 running VM, many HP3000s, and a variety of other computers. He primarily supports the MVS machines although he does some work on the HP3000s and some work on an HP-LABS DEC-20. One of his current projects is implementing a mail system on the MVS machines, including interfaces to the mail system running on the HP3000s, HPMAIL/HPDESKMANAGER. Scott is the author of several papers on a variety of computer topics, including 2 papers presented at ACM SIGDOC conferences and 4 presented at SAS User Group International conferences. Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC. Any similarity between the two is purely coincidental. Postal address: Scott L. McGregor Hewlett-Packard Co. Corporate Data Center 3000 Hanover St. Bldg 20CF Palo Alto, CA 94304 --Scott L. McGregor 07 JUN 83 -------  Date: 8 Jun 1983 0922-EDT From: Larry Campbell To: Scott L. McGregor , msggroup at BRL cc: header-people at MIT-MC, name-droppers at SRI-NIC Subject: Re: problems with NBS standard Message-ID: <"MS11(2347)+GLXLIB1(1056)" 11925863110.12.71.10785 at DEC-MARLBORO> References: Message from Scott L. McGregor of 8-Jun-83 0348-EDT In-reply-to: <423854936.28783.hplabs@HP-VENUS> You seem to imply that the EBCDIC difficulty makes it difficult for a certain class of user to use NBS. Yet using clear text makes it difficult for a much larger class of user: those who don't speak English. I believe that was the primary reason the NBS people chose the structure they did. To indulge in a particularly awkward neologism, the NBS standard is "internationalizable". It's not sufficient to dismiss this problem by saying that most computer users learn English as a second language; many governments are rightly requiring that data processing equipment sold in their countries conform to national language requirements. --------  Date: 8 Jun 1983 1138-EDT Sender: DDEUTSCH@BBNA Subject: Re: problems with NBS standard From: DDEUTSCH@BBNA To: MCGREGOR.HP-HULK@RAND-RELAY Cc: msggroup@BRL, header-people@MIT-MC Cc: name-droppers@SRI-NIC, DDeutsch@BBNA Message-ID: <[BBNA] 8-Jun-83 11:38:16.DDEUTSCH> In-Reply-To: <423854936.28783.hplabs@HP-VENUS> If the purpose of the NBS message format standard were to support messages containing text only, I might agree with you. However, that is not the case. One of the design criteria for the NBS message format standard was that it should be extensible for multimedia messages. In order to do this in a flexible, efficient way, it was necessary to use a binary encoding scheme instead of a character-encoded scheme. Thus, data is interpretted in octets (8-bit bytes) instead of in characters. I am surprised to hear you complain that a specialized data transfer protocol cannot handle general data, and then blame the problem on the the nature of the data. The file transfer protocol that you describe is specialized for the transfer of text. You could not use it to move a file containing an executable program; you could not use it to move a file containing a bitmap image. Are attempts to exchange these kinds of data between different systems violations of the ISO OSI layered architecture? Of course not. Your file transfer protocol implements a small part of the presentation layer, concerned only with character set translation. That is fine, as long as you use that protocol only for character-encoded data. An OSI purist would say that the problem is that you have not implemented a complete presentation layer. I say that the functionality of computer mail is going beyond purely textual messages, and that we must use more general data transfer mechanisms to accomodate the facsimile, voice, bitmaps, etc. that we would like to include with the text in our messages. It is easy to print NBS-style messages. As part of the development of the standard, a program that translates NBS-style messages to RFC 733 messages was built. It could handle everything in the NBS standard. It was fairly simple, and ran very quickly. So having a computer translate an NBS-style message to a textual representation before printing it is quite straightforward. I am left wondering about your final paragraph (before "About the author"). There is nothing to lobby about, because the NBS standard is a standard now. More puzzling is your comment about "mail systems that are biased against certain vendors". Could you explain what you mean by that? What is the bias, and which are the vendors? Debbie Deutsch  Date: Wed 8 Jun 83 12:14:13-PDT From: Mark Crispin Subject: Re: problems with NBS standard To: LCAMPBELL@DEC-MARLBORO.ARPA cc: MCGREGOR.HP-HULK@RAND-RELAY.ARPA, msggroup@BRL.ARPA, header-people@MIT-MC.ARPA, name-droppers@SRI-NIC.ARPA In-Reply-To: Message from "Larry Campbell " of Wed 8 Jun 83 06:22:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Larry - I have heard the language justification for NBS before, and am distinctly unimpressed. Instead of "most computer users learn English as a second language" it is more accurate to state "English is the language of computing." Programming languages which have any language base at all (that is, excepting things like APL) are based upon English. This is the case even in the Soviet Union and China, which due to western trade restrictions are obliged to build a lot of their own computing engines. Another fallacy to the "internationalizable" argument is the fact that with networking there is a lot of foreign computer usage; e.g. a user in Germany accessing a computer in the USA. Still another is that most operating systems with international usage (e.g. TOPS-20) are English-based. I am skeptical that even relatively large software vendors such as DEC have the ability to maintain multiple versions of operating systems, documentation, etc. for the myriad of human languages. I have the sneaky suspicion that this entire argument is to coddle the French and the Quebecois. Recent legislation in Quebec and France has been directed against usage of English or of adding English words to French (e.g. "le garbage"). The best attitude to take is to ignore it, not to argue with or bend over backwards to coddle. If anything, the attempt to prevent any change or language mingling in French will ultimately lead to its becoming a dead language. Latin is an unchanging language, unaffected by English slang. There are also no native speakers of it. -- Mark -- -------  Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:25:31-PDT Received: from BRL by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 01:01:57-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 2:52 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 2:45 EDT Received: From Rand-Relay.ARPA by BRL via smtp; 8 Jun 83 2:34 EDT Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:53 PDT (Wed) Date: 7 Jun 1983 1028-PDT From: Scott L. McGregor Subject: problems with NBS standard Return-Path: To: msggroup@brl Cc: header-people@mit-mc, name-droppers@sri-nic Message-Id: <423854936.28783.hplabs@HP-VENUS> Via: HP-Labs; 7 Jun 83 23:25-PDT There has been a flurry of interest in the NBS Specifications for message format for computer based message systems. There have been many messages touting this standard and telling of wide spread acceptance. The purpose of this message is to describe a comparison of the NBS standard with RFC822 that was done here at HP, and reasons are given why RFC822 was found superior. The result of this comparison is that HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed by our facility in Pinewood England) currently support an outbound RFC822 interface, and will in the future support an inbound RFC822 interface. While future interfaces to the NBS standard cannot be ruled out, none is planned at this time. Many MSGGROUP members have made reference to the complexity of the NBS standard. The standard is complex for anyone to implement, particularly if they are interested in supporting the full breadth of the standard. But, as has been pointed out by others, only a small subset is required. The real problem with NBS lies elsewhere. It is purely an implementation problem. The problem is that NBS relies on bit strings (called octets) that allows the message server to recognize fields. RFC822 on the other hand requires no special bit-strings; all heading handling is done in clear text. In an ascii-to-ascii interchange, this is not a problem, but in an ascii-to-ebcdic environment or ascii-to-printed output environment, this is disasterous. Because of the imbedded bit strings, common ascii-to-ebcdic file transfer programs cannot be used; the bit-strings would get translated too. So, the file transfer process must be specialized to deal with the special requirements of NBS mail. This is a hardship on the mail developer, and goes against the spirit of the ISO OSI layered architecture protocol. This is particularly a bad implementation problem because there exist many different ascii-to-ebcdic translation tables that are widely used. The problem also exists in an ascii-to-text environment. When I send mail to someone, I cannot be sure whether they will receive it in hardcopy or soft. They may not have an account on a computer system, but may be served by a printer attached to a remote computer, and their messages may be delivered by interoffice mail. Using RFC822, I can send the message down the line to their printer directly and I don't even have to know if it is a computer, or if it is a printer or some other output device. NBS definately requires another computer at the distant site to decode the bit strings. I suppose that to some, the above may not seem like weighty concerns. Many Ascii worlders would feel little grief in denying contact to the ebcdic world (a world badly in need of additional communcication from this community). Nor would they feel any grief in requiring smarter printers, etc. (or perhaps of requiring anyone interested in internet mail to have a computer account), after all, hardware costs are decreasing. Nor would they concern themselves with the added burden on mail implementers. To those of you with these sentiments, I can only suggest that you lobby harder, because those people who control EDP purse strings in companies are concerned about additional hardware requirements. They are also concerned about mail systems that are biased against certain vendors, particularly if they happen to own some of this hardware already. For this reason, HP Pinewood decided to go with RFC822 over NBS as an initial inter-net standard. About the author: ----------------- Many people seem to want to know additional information about authors of large messages such as this one. If you are not one of these people, no need to read further. Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data center. The data center currently supports an IBM3081K running MVS, an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6 running VM, many HP3000s, and a variety of other computers. He primarily supports the MVS machines although he does some work on the HP3000s and some work on an HP-LABS DEC-20. One of his current projects is implementing a mail system on the MVS machines, including interfaces to the mail system running on the HP3000s, HPMAIL/HPDESKMANAGER. Scott is the author of several papers on a variety of computer topics, including 2 papers presented at ACM SIGDOC conferences and 4 presented at SAS User Group International conferences. Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC. Any similarity between the two is purely coincidental. Postal address: Scott L. McGregor Hewlett-Packard Co. Corporate Data Center 3000 Hanover St. Bldg 20CF Palo Alto, CA 94304 --Scott L. McGregor 07 JUN 83 -------  Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:28:19-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 06:40:10-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:26:18 PDT (Wed) Date: 8 Jun 1983 0922-EDT From: Larry Campbell Subject: Re: problems with NBS standard To: Scott L. McGregor , msggroup@BRL Cc: header-people@MIT-MC, name-droppers@SRI-NIC Message-Id: <"MS11(2347)+GLXLIB1(1056)" 11925863110.12.71.10785 at DEC-MARLBORO> References: Message from Scott L. McGregor of 8-Jun-83 0348-EDT In-Reply-To: <423854936.28783.hplabs@HP-VENUS> You seem to imply that the EBCDIC difficulty makes it difficult for a certain class of user to use NBS. Yet using clear text makes it difficult for a much larger class of user: those who don't speak English. I believe that was the primary reason the NBS people chose the structure they did. To indulge in a particularly awkward neologism, the NBS standard is "internationalizable". It's not sufficient to dismiss this problem by saying that most computer users learn English as a second language; many governments are rightly requiring that data processing equipment sold in their countries conform to national language requirements. --------  Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:30:41-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 11:33:44-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:27:11 PDT (Wed) Date: 8 Jun 1983 1138-EDT From: DDEUTSCH@BBNA@SU-Score Subject: Re: problems with NBS standard Sender: DDEUTSCH@BBNA To: MCGREGOR.HP-HULK@RAND-RELAY Cc: msggroup@BRL, header-people@MIT-MC Cc: name-droppers@SRI-NIC, DDeutsch@BBNA Message-Id: <[BBNA] 8-Jun-83 11:38:16.DDEUTSCH> In-Reply-To: <423854936.28783.hplabs@HP-VENUS> If the purpose of the NBS message format standard were to support messages containing text only, I might agree with you. However, that is not the case. One of the design criteria for the NBS message format standard was that it should be extensible for multimedia messages. In order to do this in a flexible, efficient way, it was necessary to use a binary encoding scheme instead of a character-encoded scheme. Thus, data is interpretted in octets (8-bit bytes) instead of in characters. I am surprised to hear you complain that a specialized data transfer protocol cannot handle general data, and then blame the problem on the the nature of the data. The file transfer protocol that you describe is specialized for the transfer of text. You could not use it to move a file containing an executable program; you could not use it to move a file containing a bitmap image. Are attempts to exchange these kinds of data between different systems violations of the ISO OSI layered architecture? Of course not. Your file transfer protocol implements a small part of the presentation layer, concerned only with character set translation. That is fine, as long as you use that protocol only for character-encoded data. An OSI purist would say that the problem is that you have not implemented a complete presentation layer. I say that the functionality of computer mail is going beyond purely textual messages, and that we must use more general data transfer mechanisms to accomodate the facsimile, voice, bitmaps, etc. that we would like to include with the text in our messages. It is easy to print NBS-style messages. As part of the development of the standard, a program that translates NBS-style messages to RFC 733 messages was built. It could handle everything in the NBS standard. It was fairly simple, and ran very quickly. So having a computer translate an NBS-style message to a textual representation before printing it is quite straightforward. I am left wondering about your final paragraph (before "About the author"). There is nothing to lobby about, because the NBS standard is a standard now. More puzzling is your comment about "mail systems that are biased against certain vendors". Could you explain what you mean by that? What is the bias, and which are the vendors? Debbie Deutsch  Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:31:48-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 00:07:28-PDT Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:21 PDT (Wed) Date: 7 Jun 1983 1028-PDT From: Scott L. McGregor Subject: problems with NBS standard Return-Path: To: msggroup@BRL Cc: header-people@MIT-MC, name-droppers@SRI-NIC Message-Id: <423854936.28783.hplabs@HP-VENUS> Via: HP-Labs; 7 Jun 83 23:26-PDT There has been a flurry of interest in the NBS Specifications for message format for computer based message systems. There have been many messages touting this standard and telling of wide spread acceptance. The purpose of this message is to describe a comparison of the NBS standard with RFC822 that was done here at HP, and reasons are given why RFC822 was found superior. The result of this comparison is that HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed by our facility in Pinewood England) currently support an outbound RFC822 interface, and will in the future support an inbound RFC822 interface. While future interfaces to the NBS standard cannot be ruled out, none is planned at this time. Many MSGGROUP members have made reference to the complexity of the NBS standard. The standard is complex for anyone to implement, particularly if they are interested in supporting the full breadth of the standard. But, as has been pointed out by others, only a small subset is required. The real problem with NBS lies elsewhere. It is purely an implementation problem. The problem is that NBS relies on bit strings (called octets) that allows the message server to recognize fields. RFC822 on the other hand requires no special bit-strings; all heading handling is done in clear text. In an ascii-to-ascii interchange, this is not a problem, but in an ascii-to-ebcdic environment or ascii-to-printed output environment, this is disasterous. Because of the imbedded bit strings, common ascii-to-ebcdic file transfer programs cannot be used; the bit-strings would get translated too. So, the file transfer process must be specialized to deal with the special requirements of NBS mail. This is a hardship on the mail developer, and goes against the spirit of the ISO OSI layered architecture protocol. This is particularly a bad implementation problem because there exist many different ascii-to-ebcdic translation tables that are widely used. The problem also exists in an ascii-to-text environment. When I send mail to someone, I cannot be sure whether they will receive it in hardcopy or soft. They may not have an account on a computer system, but may be served by a printer attached to a remote computer, and their messages may be delivered by interoffice mail. Using RFC822, I can send the message down the line to their printer directly and I don't even have to know if it is a computer, or if it is a printer or some other output device. NBS definately requires another computer at the distant site to decode the bit strings. I suppose that to some, the above may not seem like weighty concerns. Many Ascii worlders would feel little grief in denying contact to the ebcdic world (a world badly in need of additional communcication from this community). Nor would they feel any grief in requiring smarter printers, etc. (or perhaps of requiring anyone interested in internet mail to have a computer account), after all, hardware costs are decreasing. Nor would they concern themselves with the added burden on mail implementers. To those of you with these sentiments, I can only suggest that you lobby harder, because those people who control EDP purse strings in companies are concerned about additional hardware requirements. They are also concerned about mail systems that are biased against certain vendors, particularly if they happen to own some of this hardware already. For this reason, HP Pinewood decided to go with RFC822 over NBS as an initial inter-net standard. About the author: ----------------- Many people seem to want to know additional information about authors of large messages such as this one. If you are not one of these people, no need to read further. Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data center. The data center currently supports an IBM3081K running MVS, an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6 running VM, many HP3000s, and a variety of other computers. He primarily supports the MVS machines although he does some work on the HP3000s and some work on an HP-LABS DEC-20. One of his current projects is implementing a mail system on the MVS machines, including interfaces to the mail system running on the HP3000s, HPMAIL/HPDESKMANAGER. Scott is the author of several papers on a variety of computer topics, including 2 papers presented at ACM SIGDOC conferences and 4 presented at SAS User Group International conferences. Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC. Any similarity between the two is purely coincidental. Postal address: Scott L. McGregor Hewlett-Packard Co. Corporate Data Center 3000 Hanover St. Bldg 20CF Palo Alto, CA 94304 --Scott L. McGregor 07 JUN 83 -------  Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:08:54-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 13:39:35-PDT Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:25:31-PDT Received: from BRL by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 01:01:57-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 2:52 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 2:45 EDT Received: From Rand-Relay.ARPA by BRL via smtp; 8 Jun 83 2:34 EDT Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:53 PDT (Wed) Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:05:35 PDT (Wed) Date: 7 Jun 1983 1028-PDT From: Scott L. McGregor Subject: problems with NBS standard Return-Path: To: msggroup@brl Cc: header-people@mit-mc, name-droppers@sri-nic Message-Id: <423854936.28783.hplabs@HP-VENUS> Via: HP-Labs; 7 Jun 83 23:25-PDT There has been a flurry of interest in the NBS Specifications for message format for computer based message systems. There have been many messages touting this standard and telling of wide spread acceptance. The purpose of this message is to describe a comparison of the NBS standard with RFC822 that was done here at HP, and reasons are given why RFC822 was found superior. The result of this comparison is that HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed by our facility in Pinewood England) currently support an outbound RFC822 interface, and will in the future support an inbound RFC822 interface. While future interfaces to the NBS standard cannot be ruled out, none is planned at this time. Many MSGGROUP members have made reference to the complexity of the NBS standard. The standard is complex for anyone to implement, particularly if they are interested in supporting the full breadth of the standard. But, as has been pointed out by others, only a small subset is required. The real problem with NBS lies elsewhere. It is purely an implementation problem. The problem is that NBS relies on bit strings (called octets) that allows the message server to recognize fields. RFC822 on the other hand requires no special bit-strings; all heading handling is done in clear text. In an ascii-to-ascii interchange, this is not a problem, but in an ascii-to-ebcdic environment or ascii-to-printed output environment, this is disasterous. Because of the imbedded bit strings, common ascii-to-ebcdic file transfer programs cannot be used; the bit-strings would get translated too. So, the file transfer process must be specialized to deal with the special requirements of NBS mail. This is a hardship on the mail developer, and goes against the spirit of the ISO OSI layered architecture protocol. This is particularly a bad implementation problem because there exist many different ascii-to-ebcdic translation tables that are widely used. The problem also exists in an ascii-to-text environment. When I send mail to someone, I cannot be sure whether they will receive it in hardcopy or soft. They may not have an account on a computer system, but may be served by a printer attached to a remote computer, and their messages may be delivered by interoffice mail. Using RFC822, I can send the message down the line to their printer directly and I don't even have to know if it is a computer, or if it is a printer or some other output device. NBS definately requires another computer at the distant site to decode the bit strings. I suppose that to some, the above may not seem like weighty concerns. Many Ascii worlders would feel little grief in denying contact to the ebcdic world (a world badly in need of additional communcication from this community). Nor would they feel any grief in requiring smarter printers, etc. (or perhaps of requiring anyone interested in internet mail to have a computer account), after all, hardware costs are decreasing. Nor would they concern themselves with the added burden on mail implementers. To those of you with these sentiments, I can only suggest that you lobby harder, because those people who control EDP purse strings in companies are concerned about additional hardware requirements. They are also concerned about mail systems that are biased against certain vendors, particularly if they happen to own some of this hardware already. For this reason, HP Pinewood decided to go with RFC822 over NBS as an initial inter-net standard. About the author: ----------------- Many people seem to want to know additional information about authors of large messages such as this one. If you are not one of these people, no need to read further. Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data center. The data center currently supports an IBM3081K running MVS, an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6 running VM, many HP3000s, and a variety of other computers. He primarily supports the MVS machines although he does some work on the HP3000s and some work on an HP-LABS DEC-20. One of his current projects is implementing a mail system on the MVS machines, including interfaces to the mail system running on the HP3000s, HPMAIL/HPDESKMANAGER. Scott is the author of several papers on a variety of computer topics, including 2 papers presented at ACM SIGDOC conferences and 4 presented at SAS User Group International conferences. Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC. Any similarity between the two is purely coincidental. Postal address: Scott L. McGregor Hewlett-Packard Co. Corporate Data Center 3000 Hanover St. Bldg 20CF Palo Alto, CA 94304 --Scott L. McGregor 07 JUN 83 -------  Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:09:46-PDT Received: from BRL by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 13:59:08-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 9:55 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 9:25 EDT Received: From Dec-Marlboro.ARPA by BRL via smtp; 8 Jun 83 9:24 EDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:08:25 PDT (Wed) Date: 8 Jun 1983 0922-EDT From: Larry Campbell Subject: Re: problems with NBS standard To: Scott L. McGregor , msggroup@brl Cc: header-people@mit-mc, name-droppers@sri-nic Message-Id: <"MS11(2347)+GLXLIB1(1056)" 11925863110.12.71.10785 at DEC-M RefereM References: Message from Scott L. McGregor of 8-Jun-83 0348-EDT In-reply-to: <423854936.28783.hplabs@HP-VENUS> You seem to imply that the EBCDIC difficulty makes it difficult for a certain class of user to use NBS. Yet using clear text makes it difficult for a much larger class of user: those who don't speak English. I believe that was the primary reason the NBS people chose the structure they did. To indulge in a particularly awkward neologism, the NBS standard is "internationalizable". It's not sufficient to dismiss this problem by saying that most computer users learn English as a second language; many governments are rightly requiring that data processing equipment sold in their countries conform to national language requirements. --------  Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:11:36-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 13:10:05-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:04:42 PDT (Wed) Date: Wed 8 Jun 83 12:14:13-PDT From: Mark Crispin Subject: Re: problems with NBS standard To: LCAMPBELL@DEC-MARLBORO.ARPA Cc: MCGREGOR.HP-HULK@RAND-RELAY.ARPA, msggroup@BRL.ARPA, header-people@MIT-MC.ARPA, name-droppers@SRI-NIC.ARPA In-Reply-To: Message from "Larry Campbell " of Wed 8 Jun 83 06:22:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Larry - I have heard the language justification for NBS before, and am distinctly unimpressed. Instead of "most computer users learn English as a second language" it is more accurate to state "English is the language of computing." Programming languages which have any language base at all (that is, excepting things like APL) are based upon English. This is the case even in the Soviet Union and China, which due to western trade restrictions are obliged to build a lot of their own computing engines. Another fallacy to the "internationalizable" argument is the fact that with networking there is a lot of foreign computer usage; e.g. a user in Germany accessing a computer in the USA. Still another is that most operating systems with international usage (e.g. TOPS-20) are English-based. I am skeptical that even relatively large software vendors such as DEC have the ability to maintain multiple versions of operating systems, documentation, etc. for the myriad of human languages. I have the sneaky suspicion that this entire argument is to coddle the French and the Quebecois. Recent legislation in Quebec and France has been directed against usage of English or of adding English words to French (e.g. "le garbage"). The best attitude to take is to ignore it, not to argue with or bend over backwards to coddle. If anything, the attempt to prevent any change or language mingling in French will ultimately lead to its becoming a dead language. Latin is an unchanging language, unaffected by English slang. There are also no native speakers of it. -- Mark -- -------  Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:14:27-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 14:19:43-PDT Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:30:41-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 11:33:44-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:27:11 PDT (Wed) Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:09:31 PDT (Wed) Date: 8 Jun 1983 1138-EDT From: DDEUTSCH@BBNA@SU-Score Subject: Re: problems with NBS standard Sender: DDEUTSCH@BBNA To: MCGREGOR.HP-HULK@RAND-RELAY Cc: msggroup@BRL, header-people@MIT-MC Cc: name-droppers@SRI-NIC, DDeutsch@BBNA Message-Id: <[BBNA] 8-Jun-83 11:38:16.DDEUTSCH> In-Reply-To: <423854936.28783.hplabs@HP-VENUS> If the purpose of the NBS message format standard were to support messages containing text only, I might agree with you. However, that is not the case. One of the design criteria for the NBS message format standard was that it should be extensible for multimedia messages. In order to do this in a flexible, efficient way, it was necessary to use a binary encoding scheme instead of a character-encoded scheme. Thus, data is interpretted in octets (8-bit bytes) instead of in characters. I am surprised to hear you complain that a specialized data transfer protocol cannot handle general data, and then blame the problem on the the nature of the data. The file transfer protocol that you describe is specialized for the transfer of text. You could not use it to move a file containing an executable program; you could not use it to move a file containing a bitmap image. Are attempts to exchange these kinds of data between different systems violations of the ISO OSI layered architecture? Of course not. Your file transfer protocol implements a small part of the presentation layer, concerned only with character set translation. That is fine, as long as you use that protocol only for character-encoded data. An OSI purist would say that the problem is that you have not implemented a complete presentation layer. I say that the functionality of computer mail is going beyond purely textual messages, and that we must use more general data transfer mechanisms to accomodate the facsimile, voice, bitmaps, etc. that we would like to include with the text in our messages. It is easy to print NBS-style messages. As part of the development of the standard, a program that translates NBS-style messages to RFC 733 messages was built. It could handle everything in the NBS standard. It was fairly simple, and ran very quickly. So having a computer translate an NBS-style message to a textual representation before printing it is quite straightforward. I am left wondering about your final paragraph (before "About the author"). There is nothing to lobby about, because the NBS standard is a standard now. More puzzling is your comment about "mail systems that are biased against certain vendors". Could you explain what you mean by that? What is the bias, and which are the vendors? Debbie Deutsch  Date: 8 Jun 1983 1412-PDT Sender: ESTEFFERUD at USC-ECL Subject: Discussion of NBS reports From: DDEUTSCH@BBNA, ESTEFFERUD@USC-ECL Reply-To: MsgGroup-request at BRL To: MsgGroup at BRL Cc: header-people at MIT-MC, Name-Droppers at SRI-NIC Message-ID: <[USC-ECL] 8-Jun-83 14:12:26.ESTEFFERUD> To all MsgGroupers, and others ... in Header-People and Name-Droppers: There has been quite a bit of interest in MsgGroup recently about the NBS program to develop federal information processing standards for computer-based message systems. NBS would like to encourage such discussion, in the belief that the technical concepts it has developed may be of interest to the Internet community, and that feedback from the Internet community will be helpful to NBS. In order to facilitate this process, NBS is willing to make the appropriate NBS reports available as RFCs. The NBS message format standard is already available from the NIC as RFC 841. Two additional NBS reports should be of interest at this time. One deals with naming and addressing, and the other is an analysis of the features of message transfer protocols. Both already have been published for public comment. Contributions are encouraged from all interested parties whether you are a member of MsgGroup or not. In order to capture the entire discussion, it should be conducted in MsgGroup. The MsgGroup transcript of the discussion will be kept in an organized archive for public access and NBS use. Contributions to the discussion should go to MsgGroup@BRL. Extra copies to Header-People and Name-Droppers will not be appreciated by recipients who are also members of MsgGroup. Requests to be added to the MsgGroup mailing list should go to MsgGroup-Request@BRL. Debbie Deutsch and Einar Stefferud  Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:21:18-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 14:47:35-PDT Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:31:48-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 00:07:28-PDT Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:21 PDT (Wed) Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:11:45 PDT (Wed) Date: 7 Jun 1983 1028-PDT From: Scott L. McGregor Subject: problems with NBS standard Return-Path: To: msggroup@BRL Cc: header-people@MIT-MC, name-droppers@SRI-NIC Message-Id: <423854936.28783.hplabs@HP-VENUS> Via: HP-Labs; 7 Jun 83 23:26-PDT There has been a flurry of interest in the NBS Specifications for message format for computer based message systems. There have been many messages touting this standard and telling of wide spread acceptance. The purpose of this message is to describe a comparison of the NBS standard with RFC822 that was done here at HP, and reasons are given why RFC822 was found superior. The result of this comparison is that HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed by our facility in Pinewood England) currently support an outbound RFC822 interface, and will in the future support an inbound RFC822 interface. While future interfaces to the NBS standard cannot be ruled out, none is planned at this time. Many MSGGROUP members have made reference to the complexity of the NBS standard. The standard is complex for anyone to implement, particularly if they are interested in supporting the full breadth of the standard. But, as has been pointed out by others, only a small subset is required. The real problem with NBS lies elsewhere. It is purely an implementation problem. The problem is that NBS relies on bit strings (called octets) that allows the message server to recognize fields. RFC822 on the other hand requires no special bit-strings; all heading handling is done in clear text. In an ascii-to-ascii interchange, this is not a problem, but in an ascii-to-ebcdic environment or ascii-to-printed output environment, this is disasterous. Because of the imbedded bit strings, common ascii-to-ebcdic file transfer programs cannot be used; the bit-strings would get translated too. So, the file transfer process must be specialized to deal with the special requirements of NBS mail. This is a hardship on the mail developer, and goes against the spirit of the ISO OSI layered architecture protocol. This is particularly a bad implementation problem because there exist many different ascii-to-ebcdic translation tables that are widely used. The problem also exists in an ascii-to-text environment. When I send mail to someone, I cannot be sure whether they will receive it in hardcopy or soft. They may not have an account on a computer system, but may be served by a printer attached to a remote computer, and their messages may be delivered by interoffice mail. Using RFC822, I can send the message down the line to their printer directly and I don't even have to know if it is a computer, or if it is a printer or some other output device. NBS definately requires another computer at the distant site to decode the bit strings. I suppose that to some, the above may not seem like weighty concerns. Many Ascii worlders would feel little grief in denying contact to the ebcdic world (a world badly in need of additional communcication from this community). Nor would they feel any grief in requiring smarter printers, etc. (or perhaps of requiring anyone interested in internet mail to have a computer account), after all, hardware costs are decreasing. Nor would they concern themselves with the added burden on mail implementers. To those of you with these sentiments, I can only suggest that you lobby harder, because those people who control EDP purse strings in companies are concerned about additional hardware requirements. They are also concerned about mail systems that are biased against certain vendors, particularly if they happen to own some of this hardware already. For this reason, HP Pinewood decided to go with RFC822 over NBS as an initial inter-net standard. About the author: ----------------- Many people seem to want to know additional information about authors of large messages such as this one. If you are not one of these people, no need to read further. Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data center. The data center currently supports an IBM3081K running MVS, an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6 running VM, many HP3000s, and a variety of other computers. He primarily supports the MVS machines although he does some work on the HP3000s and some work on an HP-LABS DEC-20. One of his current projects is implementing a mail system on the MVS machines, including interfaces to the mail system running on the HP3000s, HPMAIL/HPDESKMANAGER. Scott is the author of several papers on a variety of computer topics, including 2 papers presented at ACM SIGDOC conferences and 4 presented at SAS User Group International conferences. Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC. Any similarity between the two is purely coincidental. Postal address: Scott L. McGregor Hewlett-Packard Co. Corporate Data Center 3000 Hanover St. Bldg 20CF Palo Alto, CA 94304 --Scott L. McGregor 07 JUN 83 -------  Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:23:15-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 14:01:20-PDT Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:28:19-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 06:40:10-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:26:18 PDT (Wed) Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:09:08 PDT (Wed) Date: 8 Jun 1983 0922-EDT From: Larry Campbell Subject: Re: problems with NBS standard To: Scott L. McGregor , msggroup@BRL Cc: header-people@MIT-MC, name-droppers@SRI-NIC Message-Id: <"MS11(2347)+GLXLIB1(1056)" 11925863110.12.71.10785 at DEC-MARLBORO> References: Message from Scott L. McGregor of 8-Jun-83 0348-EDT In-Reply-To: <423854936.28783.hplabs@HP-VENUS> You seem to imply that the EBCDIC difficulty makes it difficult for a certain class of user to use NBS. Yet using clear text makes it difficult for a much larger class of user: those who don't speak English. I believe that was the primary reason the NBS people chose the structure they did. To indulge in a particularly awkward neologism, the NBS standard is "internationalizable". It's not sufficient to dismiss this problem by saying that most computer users learn English as a second language; many governments are rightly requiring that data processing equipment sold in their countries conform to national language requirements. --------  Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:40:57-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 15:34:51-PDT Received: from Diablo by Score with Pup; Wed 8 Jun 83 15:08:54-PDT Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 13:39:35-PDT Received: from Diablo by Score with Pup; Wed 8 Jun 83 12:25:31-PDT Received: from BRL by SU-SCORE.ARPA with TCP; Wed 8 Jun 83 01:01:57-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 8 Jun 83 2:52 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 8 Jun 83 2:45 EDT Received: From Rand-Relay.ARPA by BRL via smtp; 8 Jun 83 2:34 EDT Received: by HP-VENUS via CHAOSNET; 7 Jun 1983 10:28:55-PDT Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 12:22:53 PDT (Wed) Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:05:35 PDT (Wed) Received: from SU-SCORE.ARPA by Diablo with TCP; 8 Jun 83 15:35:22 PDT (Wed) Date: 7 Jun 1983 1028-PDT From: Scott L. McGregor Subject: problems with NBS standard Return-Path: To: msggroup@brl Cc: header-people@mit-mc, name-droppers@sri-nic Message-Id: <423854936.28783.hplabs@HP-VENUS> Via: HP-Labs; 7 Jun 83 23:25-PDT There has been a flurry of interest in the NBS Specifications for message format for computer based message systems. There have been many messages touting this standard and telling of wide spread acceptance. The purpose of this message is to describe a comparison of the NBS standard with RFC822 that was done here at HP, and reasons are given why RFC822 was found superior. The result of this comparison is that HP-MAIL and HP-DESKMANAGER which run on HP3000s (and were developed by our facility in Pinewood England) currently support an outbound RFC822 interface, and will in the future support an inbound RFC822 interface. While future interfaces to the NBS standard cannot be ruled out, none is planned at this time. Many MSGGROUP members have made reference to the complexity of the NBS standard. The standard is complex for anyone to implement, particularly if they are interested in supporting the full breadth of the standard. But, as has been pointed out by others, only a small subset is required. The real problem with NBS lies elsewhere. It is purely an implementation problem. The problem is that NBS relies on bit strings (called octets) that allows the message server to recognize fields. RFC822 on the other hand requires no special bit-strings; all heading handling is done in clear text. In an ascii-to-ascii interchange, this is not a problem, but in an ascii-to-ebcdic environment or ascii-to-printed output environment, this is disasterous. Because of the imbedded bit strings, common ascii-to-ebcdic file transfer programs cannot be used; the bit-strings would get translated too. So, the file transfer process must be specialized to deal with the special requirements of NBS mail. This is a hardship on the mail developer, and goes against the spirit of the ISO OSI layered architecture protocol. This is particularly a bad implementation problem because there exist many different ascii-to-ebcdic translation tables that are widely used. The problem also exists in an ascii-to-text environment. When I send mail to someone, I cannot be sure whether they will receive it in hardcopy or soft. They may not have an account on a computer system, but may be served by a printer attached to a remote computer, and their messages may be delivered by interoffice mail. Using RFC822, I can send the message down the line to their printer directly and I don't even have to know if it is a computer, or if it is a printer or some other output device. NBS definately requires another computer at the distant site to decode the bit strings. I suppose that to some, the above may not seem like weighty concerns. Many Ascii worlders would feel little grief in denying contact to the ebcdic world (a world badly in need of additional communcication from this community). Nor would they feel any grief in requiring smarter printers, etc. (or perhaps of requiring anyone interested in internet mail to have a computer account), after all, hardware costs are decreasing. Nor would they concern themselves with the added burden on mail implementers. To those of you with these sentiments, I can only suggest that you lobby harder, because those people who control EDP purse strings in companies are concerned about additional hardware requirements. They are also concerned about mail systems that are biased against certain vendors, particularly if they happen to own some of this hardware already. For this reason, HP Pinewood decided to go with RFC822 over NBS as an initial inter-net standard. About the author: ----------------- Many people seem to want to know additional information about authors of large messages such as this one. If you are not one of these people, no need to read further. Scott L. McGregor is a systems analyst at Hewlett-Packard's corporate data center. The data center currently supports an IBM3081K running MVS, an AMDAHL 470V8 running MVS, an AMDAHL 470V8 running VM, an AMDAHL 470V6 running VM, many HP3000s, and a variety of other computers. He primarily supports the MVS machines although he does some work on the HP3000s and some work on an HP-LABS DEC-20. One of his current projects is implementing a mail system on the MVS machines, including interfaces to the mail system running on the HP3000s, HPMAIL/HPDESKMANAGER. Scott is the author of several papers on a variety of computer topics, including 2 papers presented at ACM SIGDOC conferences and 4 presented at SAS User Group International conferences. Scott L. McGregor at Hewlett-Packard is NOT Scott A. McGregor at Xerox PARC. Any similarity between the two is purely coincidental. Postal address: Scott L. McGregor Hewlett-Packard Co. Corporate Data Center 3000 Hanover St. Bldg 20CF Palo Alto, CA 94304 --Scott L. McGregor 07 JUN 83 -------  Date: 9 June 1983 15:39 EDT From: Ken Harrenstien Subject: Loop tracing To: HEADER-PEOPLE @ MIT-MC I suspect a forwarding loop exists in Header-People. This is a short message to help track it down, if it exists.  KLH@MIT-MC 06/09/83 19:21:58 To: HEADER-PEOPLE at MIT-MC testing  Date: 9 Jun 1983 1047-PDT From: Scott L. McGregor Return-Path: Subject: Re: problems with NBS standard Received: by HP-VENUS via CHAOSNET; 9 Jun 1983 10:51:46-PDT To: DDEUTSCH@BBNA, MCGREGOR.HP-HULK@RAND-RELAY Cc: msggroup@BRL, header-people@MIT-MC, name-droppers@SRI-NIC, MCGREGOR.HP-HULK@Rand-Relay In-Reply-To: Your message of 8-Jun-83 0838-PDT Message-Id: <424029107.4147.hplabs@HP-VENUS> Via: HP-Labs; 9 Jun 83 19:28-PDT I see that I have not been clear about the kinds of communication that I was addressing. My comments in my previous letter were addressed only to the subset of possible computer communication that is textual. I intended to raise implementations concerns in comparision to RFC822, a textual standard. Debbie is entirely correct that NBS addresses a larger scope, namely multimedia communication. I agree that it probably addresses that scope better than RFC822, which never really was intended to have that scope (according to the RFC822 standard, communications are limited to ascii characters, 8-bit binaries would not be "legitimate" even if accepted by a such a mail system). There is still something to lobby about. Standards have to be implemented. A standard does not enforce conformity any more than laws against drunk driving mean that no more people will die on the roads. People have to follow standards for them to work, just as with traffic laws. To get standards implemented, they have to be made palatable to implementors, and in this case, a general purpose translator is needed. This is especially true for those machines that might want to translate ascii text (if it is contained within the message) to ebcdic, as would occur in transferring text mail from a DEC20 to an IBM370, or vice versa from EBCDIC to ASCII as would happen sending text mail from an IBM370 to a DEC20. In response to the question of mail systems biased against certain vendors, let me say this. If a mail standard is more difficult to implement on one kind of machine than certain others, I consider it "biased" against that vendor. This is not neccessarily bad, it may be the best solution to a bad problem. The fact is, that IBM uses EBCDIC as its character standard on its large mainframes while most of the rest of the world uses ASCII, thus ASCII mail standards are inherently biased against IBM, because extra effort (i.e. translation) is required to get the text readable to the IBM user. What makes an ASCII standard such as RFC822 palatable to an IBM mail system implementor is the existence of vendor supported translation programs. Because such translators cannot be used on NBS text mail, NBS is even more difficult to implement. If IBM were to release a smarter translator that could handle NBS mail containing ASCII text, the NBS would be just as acceptable as RFC822. I think people who are interested in NBS mail to IBM systems should lobby to make this a reality. The existence of an NBS to RFC822 translation program for the printing of text begs the question. RFC822 text can be sent down a tty line to a device and it is unimportant whether it is intelligent or not. It could just be a printer. NBS mail would require an intelligence at the end of the TTY line capable of running the translator, therefore, extra hardware is required here. Of course NBS designers recognized this, it is no suprise; the NBS standard is a standard for communication between computers, and is not intended to be able to go directly to printers. RFC822 just has the nice property that it can go directly to a printer. Some of the comments about my references to ISO OSI, seem to fall out of the confusion of my comparison of the use of NBS (a multimedia standard) with RFC822 (a text standard). Again, I want to clarify my intent, to mention implementation problems concerned with the mailing of text. But there is another issue which I haven't fully digested yet concerning the advantage of a multimedia standard over a text standard. The implication is that because multimedia can include text that the text standard will become unneccessary. My first reaction is that the existence of trucks, which can carry freight or passengers never lead to the abolishment of cars and motorcycles which can only transport people effectively. Still, there are some interesting questions raised here, and I will have to ponder more. Best wishes to all, and thanks for the comments! Scott L. McGregor -------  Date: 10 June 1983 01:35 EDT From: Ken Harrenstien Subject: Explanation of endless NBS messages To: HEADER-PEOPLE @ MIT-MC cc: MsgGroup @ BRL I tried to track down the source of the recent stream of duplicated messages, and it appears that they were falling victim to a bug somewhere at Stanford. What made it difficult was the fact that the original message went to not one but two large mailing lists (it would have been three, but fortunately the incorrect name "name-droppers" was used instead of "namedroppers"!) Enclosed are the two most informative messages which resulted: ---------------------------------- Received: from SCRC-COLLIE by SCRC-TENEX with CHAOS; Thu 9-Jun-83 19:46:08-EDT Date: Thu, 9 Jun 83 19:48 EDT From: Mike McMahon Subject: Loop tracing To: KLH@MIT-MC In-reply-to: The message of 9 Jun 83 15:39-EDT from Ken Harrenstien Message-ID: <830609194825.2.MMcM@SCRC-TENEX> I'd be curious to know what you learn. What I guessed from my mail was that a host named "diablo" was plugged in where su-shasta should be. header-people goes to csl.bkr@score, which goes to reid@shasta. Diablo probably had a broken piece of mail software (like /etc/delivermail without setuid root, wasn't the the explanation last year?) which parses the to: field to find out who to send to, giving it right back to mc. Like I said, this is entirely guesswork, but confirmed a little bit by some troubles Jan Walker was having sending to Brian Reid. ---------------------------------- Date: Thu 9 Jun 83 17:09:39-PDT From: Bill Nowicki Subject: Mailing loop To: klh@MIT-MC.ARPA For a short period of time yesterday afternoon there was such a loop, but it was fixed. Sorry for the inconvenience. -- Bill ------- ---------------------------------- Considering that this is not the first time this has happened (ie it can happen again) and that the size of mailing lists has become rather awesome, perhaps it is time to revive the old ideas for detecting and killing mail forwarding loops. I suggest that any such discussion be confined to Header-People, which is oriented to hairy technical bull sessions. --Ken  Date: 10 June 1983 03:46 EDT From: Ken Harrenstien Subject: Fickle Finger of Fate To: taft @ PARC-MAXC cc: HEADER-PEOPLE @ MIT-MC I got the following message from some PARC mailer. I have two questions: (1) What is the weird ".AG." in my supposed Arpanet address? (2) I thought PARC mailers were clever about mailing error notes for a list to the maintainers of the list; is this not actually true? --Ken ---------------------------- Subject: Undelivered mail From: Gamay.ms@PARC-MAXC.ARPA (a Grapevine mail server) To: KLH@MIT-MC.AG.ARPA Date: 9 Jun 83 22:42:53 PDT The message sent by KLH@MIT-MC.AG at 9-Jun-83 22:38:26 PDT could not be delivered to the following recipients because their names are invalid. Fung.es ---------------- Received: from MIT-MC.ARPA by PARC-MAXC.ARPA; 9 JUN 83 22:38:05 PDT Redistributed: XeroxHeaderPeople^.pa Date: 10 Jun 83 01:35 EDT From: Ken Harrenstien Subject: Explanation of endless NBS messages To: HEADER-PEOPLE@MIT-MC.ARPA cc: MsgGroup@BRL.ARPA I tried to track down the source of the recent stream of duplicated messages, and it appears that they were falling victim to a [KLH: ... I flushed the rest of this text ... ]  Received: from Glacier by Score with Pup; Fri 10 Jun 83 08:18:36-PDT Date: Friday, 10 Jun 1983 08:18-PDT To: Ken Harrenstien Cc: HEADER-PEOPLE at MIT-MC, MsgGroup at BRL Cc: nowicki at Diablo Subject: Re: Explanation of endless NBS messages In-reply-to: Your message of 10 June 1983 01:35 EDT. From: Brian Reid The mail loop this time was caused by a new Berkeley 4.1C program that we had just installed on one of our VAXen (Diablo). It is called "sendmail", and it is supposed to replace the old "delivermail" that was indirectly the cause of last year's loop. The loop path was CSL.Lantz@Score-->lantz@Diablo-->loop. The loop was tracked down and fixed by Bill Nowicki. I don't know anything about the details of this loop, or about the "sendmail" program, but the word that I hear in the halls around here is that sendmail is really complex and incomprehensible (and therefore terrible) and that it is not at all a step forward from the old delivermail. Since it is Berkeley's intention that all Berkeley Unix sites convert to sendmail soon, and since we had this trouble with it, it might be worthwhile getting Bill to explain the loop so that other sites, when installing this new software, do not make the same mistake. Bill seemed to think that part of the cause was a very dangerous feature of the program (that got accidentally invoked), which perhaps Berkeley could be persuaded to remove.  Date: Fri, 10 Jun 83 10:10 PDT From: Taft.PA@PARC-MAXC.ARPA Subject: Re: Fickle Finger of Fate In-reply-to: "KLH@MIT-MC.ARPA's message of 10 Jun 83 03:46 EDT" To: Ken Harrenstien cc: Taft.PA@PARC-MAXC.ARPA, HEADER-PEOPLE@MIT-MC.ARPA 1. The appearance of ".AG" outside the Xerox Internet is a symptom of some bug, which I will look for. It should be stripped off by the mail translation gateway as the message crosses between the Xerox and ARPA worlds. "AG" stands for "ARPA Gateway". It is the name of a Xerox "registry" which logically contains the mailboxes for all ARPA recipients. (You may think of all of Xerox as a subtree of one node in the ARPA Internet, namely the host PARC-MAXC; but we think of the entire ARPA Internet as a subtree of one node in the Xerox Internet, namely the registry AG. We call this "mutual encapsulation of name spaces"; I alluded to it a month or two ago in a message to NameDroppers.) 2. Failure to deliver to a member of a distribution list ordinarily results in the owner of the list being notified. However, there are a few situations in which a delivery failure occurs after the fact that the recipient name came from a list has been forgotten. This usually occurs when a mailbox is destroyed at about the same time as distribution list expansion is being performed. And now a remark of my own: 3. I see no reason to bother all the members of HEADER-PEOPLE with a matter that really concerns only you and me. The amount of junk that pours forth from HEADER-PEOPLE and other groups is a real annoyance; and finding useful information in all this volume of messages is quite time-consuming. Yours for less pollution of the distribution lists, Ed Taft  Date: 10 Jun 1983 1519-EDT Sender: DDEUTSCH@BBNA Subject: Re: problems with NBS standard From: DDEUTSCH@BBNA To: MCGREGOR.HP-HULK@RAND-RELAY Cc: DDEUTSCH@BBNA, msggroup@BRL, header-people@MIT-MC Message-ID: <[BBNA]10-Jun-83 15:19:55.DDEUTSCH> In-Reply-To: <424029107.4147.hplabs@HP-VENUS> Just a few points in response. The NBS message format standard was published for public review twice before it became a standard. Copies were sent out to every vendor of computer based message systems that NBS could identify, every person/organization who requested one, other individuals that hadn't requested copies but NBS thought might be interested, and other national and international standards organizations working in the area. Of all the comments that came back, I can't remember a single one that said the then proposed standard was too difficult to implement, and should be discarded. In fact, the nature of a standard message format (text-based or otherwise) is that some translation between the transfer-syntax and internal form almost always takes place. For example, the system that I am using now stores my draft message as a list of pointers to fields. The pointers are associated with binary numbers that identify the field names; the fields themselves are stored in various formats, according to their types (address, date, text, etc.). So when I tell my system to send the draft message, it must translate from its internal form to RFC822; when I tell it to show me the draft message it must translate from its internal form to a character stream that my terminal can handle. My system does that in order to facilitate the process of composing and editing draft messages. The designers of message systems sometimes find it advantageous to store received messages in a specialized internal format (such as an inverted database). So translators are often used to optimize performance/functionality in various parts of message systems when a internal format can take advantage of local architecture and resources. I am sorry that you must deal with ASCII/EBCDIC translations - the world would be a (slightly) better place if one character encoding scheme could be universally agreed upon. However, any standard issued by NBS must use ASCII. First of all, ASCII is the NBS standard character set. Having the message format standard allow EBCDIC would have been inconsistant. ASCII came to NBS (and the rest of the country) from ANSI. (ANSI has a lot of IBM participation, by the way.) ASCII is also a subset of IA5, the ISO standard for character sets. So, allowing EBCDIC would put NBS in violation of ANSI and ISO standards. Can you imagine the hue and cry from all the folks who are in compliance with ASCII if NBS permitted the use of EBCDIC? By the way, I have never heard an IBM representative argue against the use of ASCII and for the use of EBCDIC at a standards meeting. You can use your favorite vendor-supported translation program on the contents of any NBS ASCII-String data element. The rest of the format would remain the same, no matter which character set was native. There is a flaw in your trucks vs. cars/motorcycles. A manufacturer of motor vehicles would be overjoyed if a given part could be used for both trucks and cars. It usually is cheaper to make one kind of component than two different kinds of components. The same is true in the standards world. It is generally preferable to have a single general-purpose standard than a number of specialized ones. That's the whole idea of having standards in the first place. Debbie  Date: 10 Jun 1983 1216-PDT Sender: BILLW at SRI-KL Subject: Re: Explanation of endless NBS messages From: BILLW at SRI-KL To: KLH at MIT-MC Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[SRI-KL]10-Jun-83 12:16:42.BILLW> In-Reply-To: Your message of 10 June 1983 01:35 EDT I also notice that although the HELO message in SMTP was supposed to prevent the flaw of accidently sending mail to the wrong host, no one seems to use it for such. Comments? Bill W  Date: 10 Jun 1983 1216-PDT Sender: BILLW at SRI-KL Subject: Re: Explanation of endless NBS messages From: BILLW at SRI-KL To: KLH at MIT-MC Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[SRI-KL]10-Jun-83 12:16:42.BILLW> In-Reply-To: Your message of 10 June 1983 01:35 EDT I also notice that although the HELO message in SMTP was supposed to prevent the flaw of accidently sending mail to the wrong host, no one seems to use it for such. Comments? Bill W  Date: 10 Jun 1983 1216-PDT Sender: BILLW at SRI-KL Subject: Re: Explanation of endless NBS messages From: BILLW at SRI-KL To: KLH at MIT-MC Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[SRI-KL]10-Jun-83 12:16:42.BILLW> In-Reply-To: Your message of 10 June 1983 01:35 EDT I also notice that although the HELO message in SMTP was supposed to prevent the flaw of accidently sending mail to the wrong host, no one seems to use it for such. Comments? Bill W  Received: from SCRC-COLLIE by SCRC-SPANIEL with CHAOS; Fri 10-Jun-83 19:23:06-EDT Date: Fri, 10 Jun 83 18:11 EDT From: Mike McMahon Subject: Loop detection To: HEADER-PEOPLE@MIT-MC Message-ID: <830610181125.5.MMcM@SCRC-TENEX> It seems to me the correct way to do this is with the Received: header. Mail servers put in Received, including "for ". (I believe the BNF in 822 doesn't allow for multiple addresses, but it could be fixed.) The mailer detects a loop by the presence of two Received headers, both of which have "by " and "for ". Unfortunately, when mailing lists are expanded at a foreign site, the list of can get very long.  Date: Fri 10 Jun 83 17:36:12-PDT From: Mark Crispin Subject: Re: Loop detection To: MMcM%SCRC-TENEX@MIT-MC.ARPA cc: HEADER-PEOPLE@MIT-MC.ARPA In-Reply-To: Message from "Mike McMahon " of Fri 10 Jun 83 16:36:35-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I don't like the idea of using "for " in the Received: header, as this defeats bcc's. -- Mark -- -------  Date: 10 Jun 1983 2047-EDT From: Mike McMahon Subject: Re: Loop detection To: MRC@SU-SCORE cc: HEADER-PEOPLE@MIT-MC In-Reply-To: The message of Fri 10 Jun 83 17:36:12-PDT from Mark Crispin But shouldn't the mail sending program pass the mailer two different pieces of text, one with a Bcc header for the Bcc recipients and one without for the other recipients? Otherwise the Bcc recipients will be mystified when they get a message with no indication of their name. -------  Received: from Diablo by Score with Pup; Fri 10 Jun 83 18:32:04-PDT Date: Fri, 10 Jun 83 18:31 PDT From: Bill Nowicki Subject: Mail Loop explanation To: DCrocker@UDel-Relay, KLH@MIT-MC, reid@Glacier Cc: HEADER-PEOPLE@MIT-MC, MsgGroup@BRL, mailhax Some people have requested a few more details of our experience with sendmail and the disaster which caused a mail loop on Wednesday June 8. First some background: At Stanford we run 4.1BSD Unix with BBN TCP code, with CMU packet filtering on 3 Mbit Ethernets connecting about a dozen VAXes (and many other machines). We would like to use 4.2 whenever (if ever?) it finally gets done, so we got a 4.1c beta distribution and were trying to phase in some of the user programs on that release, like sendmail. The predecessor of sendmail, delivermail, we had customized slightly by changing a few tables and recompiling. It read the host name by the gethostname() system call, so we could take the program (or an entire disk pack for that matter) from one system to another and it would work. Sendmail contains an SMTP server as well as the other mail switching and aliasing functions of delivermail. Integrating the SMTP server and the aliasing turns out to be a good idea, but all sorts of other "features" were added to sendmail in the mean time. For example, instead of having compile-time tables and modular code, there are enormous configuration files that are read at run-time. You have to specify a "program" to parse your addresses using an incredibly unfathomable production language. The host name is hard-wired into the configuration file, so they are not portable between machines anymore. Part of the confusion came from the distinction between switches entered on the command line, commands in the configuration file, options which can be given on the command line OR in the configuration file (with yet another strange syntax), mailer flags, and configuration file macros. All five of these are represented by single character case sensitive identifiers, with different meanings for the letters in many cases. A vertiable lesson in terrible user interfaces. The specific problem came when we discovered a case in which our TOPS-20 SMTP mailer would open a connection, send part of a message, and then simply give up without sending a RESET packet. The BBN TCP code had no timeouts, so the connection would stay around forever, along with the two sendmail processes and the spool files. I remembered reading about a timeout feature, and glancing at the manual found it was the "t" option. So I ran sendmail with the "t" switch on the command line. There were two mistakes: first, the timeout is an Option, not a Switch, and secondly it is upper case T not lower case t. I was silly enough to think that since it gave me no error message that everything was OK, and went off to our research group meeting. When I came back after the meeting I looked at the log file and noted some suspicious behaviour. What it was doing was sending a copy of each message to the people listed in the "To:" and "Cc:" fields in the header, as well as the person given in the RCPT TO:<> command of SMTP. This resulted in the loop back through our local Ethernet, the Arpanet, the MIT Chaos Net, as well as several nets at BRL and BBN! I killed the server after about an hour, and restarted it with the right options (although the timeout still does not do anything), but the duplicated mail took at least two days to stop bouncing through the net. Morals (some are my personal opinions): 1. Case sensitivity is a bad idea. 2. Single letter identifiers are a bad idea. 3. Multiple notions that are similar are confusing. 4. Large (multi-domain) mailing lists should have a moderator. 5. Timeouts should be in SMTP servers and TCP implementations by default. 6. internet mail systems are fragile things. 7. "Improved" software with more "features" usually isn't. -- Bill  Date: 10 Jun 1983 1837-PDT From: Henry W. Miller Subject: Re: Explanation of endless NBS messages To: BILLW at SRI-KL, KLH at MIT-MC cc: HEADER-PEOPLE at MIT-MC, Miller at SRI-NIC In-Reply-To: Your message of 10-Jun-83 1216-PDT Bill, The way I read the spec, the HELO command merely identifies the sender to the receiver. -HWM -------  Date: Fri, 10 Jun 83 22:08:23 PDT From: Rich Wales To: Header-People@MIT-MC Subject: SMTP and unknown or mismapped host names In-reply-to: BILLW@SRI-KL's message of 10 Jun 1983 1216-PDT BILLW@SRI-KL suggested that Internet hosts examine the info given in the SMTP HELO command and its reply, in order to verify that the right two hosts are connected up. While it is quite possible for two hosts to get misconnected (owing to changed Internet addresses and out-of- date host name tables), I am not sure Bill's suggestion would help. Something that hosts SHOULD do (though a lot of them don't) is check the entire RCPT address, including the domain, and not simply assume that the mail is being directed to the right machine. This is partic- ularly important when the host on a given Internet address has changed. (1) Since not everyone has up-to-date host name tables (in some cases, this is a gross understatement!!), I think we really have to give the other host the benefit of the doubt if it calls itself by a name we aren't familiar with. Perhaps the server can put a mild, non-accusatory warning in its reply to the HELO -- something like 220 PODUNK SMTP Server ready helo ucla-locus 250 PODUNK -- That's odd, I thought your name was UCLA-SECURITY or 220 PODUNK SMTP Server ready helo ucla-locus 250 PODUNK -- By the way, my host name table doesn't list you Flames like the following (I have actually seen this one!) -- 220 PODUNK SMTP Server ready helo ucla-locus 250 PODUNK -- You are a charlatan, UCLA-SECURITY -- not only seem somewhat too harsh (to me, at least), but they may also leave the gurus at the sending site with the lingering suspi- cion that the mail was not really handled properly. (2) A more important concern is what an SMTP server should do if it gets a RCPT command specifying a user on an unknown host -- for example: 220 PODUNK SMTP Server ready helo ucla-locus 250 PODUNK mail from: 250 OK rcpt to: Assuming that SMALLTOWN is not an alias name for the host PODUNK, then PODUNK should clearly either reject the recipient, or accept it and forward the message. A lot of hosts out there, though, are apparently simply ignoring the domain and assuming that the address must be local. In my ex- ample, either the mail would be misdelivered to "fred@PODUNK", or else I would be told that there is no local user "fred"! Comments? -- Rich  Date: 10 Jun 1983 2003-PDT From: Scott L. McGregor Return-Path: Subject: Re: problems with NBS standard Received: by HP-VENUS via CHAOSNET; 10 Jun 1983 20:04:13-PDT To: DDEUTSCH@BBNA, MCGREGOR.HP-HULK@RAND-RELAY Cc: msggroup@BRL, header-people@MIT-MC, MCGREGOR.HP-HULK@Rand-Relay In-Reply-To: Your message of 10-Jun-83 1219-PDT Message-Id: <424148654.14765.hplabs@HP-VENUS> Via: HP-Labs; 11 Jun 83 4:18-PDT I have no problem with NBS as a standard, nor do I propose EBCDIC as a standard. I only point out that it is harder to implement NBS for sending text than RFC822 when you are implementing for an IBM computer using EBCDIC. Some mail systems do more layering separating internal format from presented format. This is nice and gives one more capabilities, but it is more difficult to implement. Such systems take more time to develop and may be prone to more bugs. If one is concerned with expediency of getting a mail transport up, as HP was, then RFC822 was easier and so was chosen. >From some of your comments I can only conclude that NBS is like bad tasting medicine, It tastes bad at first, but it is good for you in the long run. You may be right, but don't be suprised if the natives turn to the local witchdoctors for a while, at least until they see results. I am a bit sorry about that for NBS fans, that seems to be reality of how implementations go. I'm sure in a few years this will all be past history and implementing NBS will be much easier, particularly if vendors provide implementors with smarter interfaces. Please don't paint me as an NBS opponent, I'm just one of the wounded. Scott L. McGregor -------  Date: 11 Jun 83 7:04:35-EDT (Sat) From: Larry Layten Return-Path: Subject: Re: problems with NBS standard To: DDEUTSCH@Bbna Cc: MCGREGOR.HP-HULK@Rand-Relay, DDEUTSCH@Bbna, msggroup@Brl, header-people@Mit-Mc Via: Darcom-HQ; 11 Jun 83 12:40-EDT So now we have two standards. One of them has been adopted by the DOD/DDN/ARPANET community, and is in operation. Can someone indicate what the base of support is for the NBS standard. If that base is not strong enough, maybe changes to the NBS standard wouldn't be too difficult to implement. Larry  Date: 11 Jun 1983 16:09-EDT Sender: DDEUTSCH@BBNA Subject: Re: problems with NBS standard From: DDEUTSCH@BBNA To: llayten@DARCOM-HQ Cc: DDEUTSCH@BBNA, MCGREGOR.HP-HULK@RAND-RELAY Cc: msggroup@BRL, header-people@MIT-MC Message-ID: <[BBNA]11-Jun-83 16:09:21.DDEUTSCH> In-Reply-To: The message of 11 Jun 83 7:04:35-EDT (Sat) from Larry Layten The NBS standard is being used in the commercial sector. When it was published for review, comments were almost unanimously favorable. It just became a standard this January, and will not come up for review for several years. A discussion about what people do and do not like about the standard can be interesting and informative, but it will not lead to any changes in the standard in the near future. The NBS standard was written with full cognizance of RFC 733 (RFC 822 had yet to be written, and isn't fundamentally different). There was a conscious decision to use a binary encoding instead of a text-based encoding, for the reasons I have already given (plus a few others). The main objection that I have heard in this discussion is that people don't like binary encoding. These people much prefer text-based encoding. However, that is not the feeling in the commercial standards arena. The purpose of NBS standards is to govern procurements of the federal government. As Scott has pointed out, a standard isn't worth the paper it is printed on if nobody implements it. However, vendors have indicated that the standard is acceptable to them by their comments made during the review process and by their explicit announcements that they will support it. It is the endorsement of the vendors that is important in approving a FIPS, and NBS has received that endorsement for its message format standard. When the standard comes up for review in a few years, NBS will again consider what to do. At that time, if the vendors say that the standard could not be implemented cost-effectively, or that there was some serious technical flaw, NBS would probably want to reconsider the whole matter. On the other hand, if the vendors are still happy with the standard, NBS would probably only consider refinements to the current document. (Of course, the other important players are the government agencies that buy from the vendors. They were also quite supportive of the standard when it went out for comment.) The important contribution that MsgGroup can make is to come up with ideas that will be helpful during the next review period. So far, people who have actually implemented the standard have reported no problems. If this trend continues, NBS will be interested in ways of extending the standard where additional functionality may be warranted, and refining the standard where a simpler or more powerful mechanism can be substituted for what is already there. Of course, if somebody were to implement the standard and then find a problem with it, NBS would be very interested indeed! Debbie  Date: 11 Jun 1983 1443-PDT Sender: BILLW at SRI-KL Subject: Re: SMTP and unknown or mismapped host names From: BILLW at SRI-KL To: v.wales at UCLA-LOCUS Cc: Header-People at MIT-MC Message-ID: <[SRI-KL]11-Jun-83 14:43:24.BILLW> In-Reply-To: Your message of Fri, 10 Jun 83 22:08:23 PDT Actually, what brought this up was I remember reading last year about the serious security bug introduced by putting your imp into loopback mode, in which case people connecting to you would actually be connecting to themselves (or some such). SOMEBODY said that "SMTP does contain a mechanism for making sure you are talking to the host you think you are talkng to". Wonderful. How coe nobody is using it. BillW  Date: Sat 11 Jun 83 23:36:04-PDT From: Mark Crispin Subject: Re: SMTP and unknown or mismapped host names To: BILLW@SRI-KL.ARPA cc: v.wales@UCLA-LOCUS.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "BILLW at SRI-KL" of Sat 11 Jun 83 14:43:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Bill - Putting your IMP in loopback mode does not cause a problem with TCP the way it did with NCP. TCP is not mirror-reflective the way NCP was, so it is impossible to connect to a host and get yourself unless that host actually does a logical loopback in its software. There is no good reason for a host to do that, and I've only seen it done once in all the years I've been on ARPANET. -- Mark -- -------  Date: 12 June 1983 0405-EDT From: Rudy.Nedved@CMU-CS-A To: BILLW@SRI-KL, Mark Crispin Subject: Re: SMTP and unknown or mismapped host names CC: v.wales@UCLA-LOCUS, Header-People@MIT-MC In-Reply-To: "Mark Crispin's message of 12 Jun 83 01:36-EST" Message-Id: <12Jun83.040519.EN0C@CMU-CS-A> SATNET-ECHO and some other echo sites do a pretty good job of letting you connect to yourself under TCP. At CMU, we discovered a couple of bugs when our "surveys" hit one of these IP echoers. My SMTP survey program ended up checking to make sure that the HELO response was NOT its own name. I would have liked to check the remote name but many sites gave out "You are a charlatan", some nickname, some unofficial name or "Command recieved" instead of the official "that side of the net" host name. Nothing bad has happened lately to get us to put the HELO response checks in yet but I have a feeling we will sometime down the line when some site swaps addresses (like when NBS-VMS and Wharton changed IMP ports). It all depends on how slow NIC does table updates and how often addresses get swapped or re-used. -Rudy  Date: Sun 12 Jun 83 01:26:15-PDT From: Mark Crispin Subject: Re: SMTP and unknown or mismapped host names To: Rudy.Nedved@CMU-CS-A.ARPA cc: BILLW@SRI-KL.ARPA, v.wales@UCLA-LOCUS.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Sun 12 Jun 83 01:05:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The TOPS-20 SMTP server (both ISI's and mine) outputs the host name prior to the "You are a charlatan". In fact, I modeled my response to the HELO command after ISI's, since it was written by the people who designed SMTP. You probably should call the protocol police out on sites which give completely erroneous responses. -- Mark -- -------  Date: 12 Jun 1983 1404-PDT (Sunday) From: eric%UCBARPA@Berkeley Subject: mail loop caused by sendmail (166 lines) Message-Id: <13382.31.424299882@ucbarpa> Received: by UCBARPA.ARPA (3.344/3.32) id AA14066; 12 Jun 83 14:04:45 PDT (Sun) Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.31) id AA07707; 12 Jun 83 13:59:30 PDT (Sun) Phone: (415) 548-3211 To: MsgGroup@BRL, Header-People@MIT-MC Cc: nowicki%Diablo@SU-SCORE Fcc: mail As the author of sendmail, the new mail router out of Berkeley, I feel compelled to respond to the explanation of the mail loop given by Bill Nowicki a few days ago. Part of this will be a defense, and part will be a confession. I hope that this will be an interesting lesson in software engineering, if nothing else. I have had plans to turn this into a paper for some time, but a preview seems appropriate. Let's start with confessions. I agree completely with the criticism that sendmail is just too big and too baroque. This results from several forces. First, I didn't understand the problem when I started. Part of this was because initially I was trying to solve an isolated problem on one machine at Berkeley; I had no idea that it was going to turn into a general problem. Indeed, it was never my "job" to do delivermail or sendmail -- they were "small" (hah!) spare time projects. However, the other side of this was that there was almost nothing published regarding mail routing at that time. I suppose MsgGroup et al existed at that time, but since there does not exist a publicized list of mailing lists, I did not know about them. In summary: the Arpanet community is a difficult community to break into, almost as difficult as the Unix-Wizards community, with no one willing to talk to you until you know the ropes, but no way to learn the ropes unless someone will talk to you. Second, I was entirely too susceptible to criticism. All of us have heard stories of offensive people in the community who are sure that they have all the right answers and will not listen to anyone. I continue to believe that this is a serious problem that has been all too prevalent. But I now understand the other extreme to be equally as bad: the person who puts in anything that anyone suggests ends up with a monster with a voracious appetite. I gained enough confidence to start saying "no", but too late. I have tried to take out features, but it proves harder to take features out than to never put them in in the first place. Third, I underestimated the complexity of the problem. I contend that single-letter identifiers are fine when you have eight or ten identifiers. In my early configuration tables this was indeed the case. When I had to go to split case I should have realized that something was wrong, but it was so easy to go to split case and so hard to go to full words; besides, I had other reasons to stick to single character identifiers (see below). Now for some defense. I will start with the simple rebuttals and then move on to the more sweeping issues. It is not the case that configuration tables are not portable. The host name is available. Sendmail is not intended as a "user interface." My intent was was to be able to read the configuration file doing a fairly trivial amount of parsing -- hence the single letter identifiers, etc. Similarly, the command line arguments are not required to be highly user-friendly, because they are for use by gurus (who presumably have a certain level of intelligence and care) and not by the casual user. About 50% of the configuration table need not be touched until RFC911 comes out (or whatever the next mail protocol is). A large amount of the complexity was put in during the 733 => 822 transition; during that period it was important to be able to handle either protocol. The roughest part of that was route-addr's; production systems seem to be able to handle left-to-right parsing well, and right-to-left parsing adequately, but both at once is a real pain. If the route-addr's had been in the syntax "user@hostc@hostb@hosta" indicating "route to hosta, then hostb, then hostc" it would have been unambiguous, closer to 733, and strictly right-to-left. Sendmail sits in a difficult position. Many of the mail servers on the Arpanet speak only to SMTP-compatible hosts. Sendmail talks to SMTP, UUCP, Purdue Net, Berknet (which uses colons [ugh] in addresses), Phonenet (via MMDF), and can be made to talk to others fairly trivially. This adds an untold amount of complexity. Was this a mistake? Perhaps. My idea was to build a "language" (i.e., the configuration file) that could be programmed to handle the various address formats, etc. I find myself under fire from all sides for this. The world is filled with UNIX-egoists who care only about UUCP. They are exceeded only by the SMTP-egoists who claim to be building an "Internet" based on only one style of communication. Yes, sendmail is complex, because it deals with a complex problem. (By the way, at one time I considered MMDF to be a competitor. At this point I have only the greatest respect for MMDF and it's implementors; if nothing else comes out of this project, I will have developed a contact, respect, and even a degree of friendship with Dave Crocker, Dave Farber, Brendan Reilly, Doug Kingston, and others who have done a magnificent job with a problem so complex that most people cannot even comprehend it.) Strangely enough, one of my recent conclusions is that the obscurity of the configuration file is an advantage! Such heresy deserves explanation. I have discovered (much to my disappointment) that the world is full of people who have no concern whatsoever for protocols. These people are typically called "hackers" and are frequently located far enough off the beaten path that the protocol police cannot find them or cannot touch them. These are people who change Date: lines to be UNIX-style date lines because it is "more standard," people who delete Received: lines because they don't like them and don't understand their importance, people who insist on their "right" to use user@hosta@hostb even though it clearly violates the protocols, etc. This one really falls in the "confession" section, because I now realize that people who are afraid to touch code think nothing of touching a configuration file. The bottom line is that it may be better to leave the configuration somewhat unapproachable than to make it easy for hackers to make gratuitous changes. Finally, no system can protect itself from the person who uses it incorrectly. It seems bizarre to me that sendmail can be criticized for functioning correctly. Today, I would do a number of things differently: Although I remain convinced of the power of the configuration file, I would limit the contents. For example, I would retain the concept of protocol conversion, but only for the most simple cases, such as converting domain-based addresses (as used internally) into Arpanet-based addresses (e.g., I map "user@host.BITNET" into "user%host.BITNET@Berkeley.ARPA"). The configuration file would map external addresses into internal (domain-based) addresses, but after that the parsing would be ad hoc; in particular, the inside-out route-addr's are just too difficult to parse in a production system (which I would probably retain). I would certainly push the absurd cases (e.g., UUCP so-called "addresses" which are really routes) into another module. Given that I seem to have more power and respect now than I once did, I would almost certainly simply outlaw colons in addresses and convert Berknet to use another syntax. I would make the configuration files a very different format, but include a compiler that would generate something that could be read very quickly. The compiler could also do a lot of checking. Morals (some are my personal opinions): 1. Case sensitivity is a bad idea. 2. Single letter identifiers are a bad idea if you have more than about ten of them. 3. Multiple notions that are similar are confusing, but sometimes necessary; there is a difficult balance between exploiting the similarities and accentuating the differences. 4. internet mail systems are fragile things. 5. "Improved" software with more "features" sometimes is and sometimes isn't: the important thing is to realize that every feature has both a cost and a benefit. 6. (Corollary 1) One man's feature is another man's bell or whistle. 7. Both the UNIX and the Arpanet community could afford to learn from the other. 8. Flexibility is a nice thing, but too much flexibility can backfire. 9. Better loop/duplicate detection is needed. Message-Id's should be required in all messages at their origination to make this feasible. Message-Id's should probably be in a well-defined format to simplify their use, e.g., ; this would allow the database to implement timeouts on the message-id's after (say) one week trivially, etc. eric  Date: 12 Jun 1983 1501-PDT From: POSTEL at USC-ISIF Subject: re: SMTP and Unknown Host Names To: header-people at MIT-MC Actually, the notion in the SMTP opening sequence where the host names are exchanged in the HELO command and reply was to check that the connection was between the intended hosts. One early TOPS20 implementation gave a 5xx reply code if it did not believe the host name. This involved quite a bit of work - it checked to see if the name given matched the official name or any of the nicknames for the host on the other end of the connection (determined by looking up the host associated with the Internet Address of the other end of the TCP connection). Early debugging caused this to be changed to a 250 response in all cases (though it still complains in the text of the reply). This was because several sites did their debugging either using a strange host name or using a different internet address. Perhaps, if we went back to giving the 5xx reply, sites would pay more attention to having up to date host tables? --jon. -------  Date: 13 Jun 83 09:52:10 PDT (Monday) From: Curbow.ES@PARC-MAXC.ARPA Subject: Re: problems with NBS standard In-reply-to: llayten's message of 11 Jun 83 7:04:35 EDT (Sat) To: header-people@Mit-Mc.ARPA cc: curbow.es@PARC-MAXC.ARPA "If the base is not strong enough..."? Maybe we can change COBOL into PL/1 if the opposition is not too strong. I have to say that it seems to me that the NBS standard is much like COBOL. It is a reasonable standard, even if it is not perfect. Up to now everyone has their own protocol. (Remember all the vendor supplied languages that were specific to their machines and no way to transport programs to other systems?) I applaud NBS for getting something out that everyone can live with. Give it a chance before you try to change it.  Date: 13 Jun 83 09:52:10 PDT (Monday) From: Curbow.ES@PARC-MAXC.ARPA Subject: Re: problems with NBS standard In-reply-to: llayten's message of 11 Jun 83 7:04:35 EDT (Sat) To: header-people@Mit-Mc.ARPA cc: curbow.es@PARC-MAXC.ARPA "If the base is not strong enough..."? Maybe we can change COBOL into PL/1 if the opposition is not too strong. I have to say that it seems to me that the NBS standard is much like COBOL. It is a reasonable standard, even if it is not perfect. Up to now everyone has their own protocol. (Remember all the vendor supplied languages that were specific to their machines and no way to transport programs to other systems?) I applaud NBS for getting something out that everyone can live with. Give it a chance before you try to change it.  Date: 16 Jun 1983 1258-PDT From: KLH at SRI-NIC Subject: Header-People pollution To: Taft at PARC-MAXC cc: header-people at MIT-MC I agree that it is annoying to paw through the stuff sent by people who don't know whether to address messages to Header-People or MsgGroup and consequently send them to both. The recent mail loop made this worse. However, I think it is perfectly within the domain of Header-People to point out interesting bugs that are uncovered in mailers around the network, especially when header format or transmission protocol errors are involved; this particular instance looked interesting to me (still does). I consider Header-People to consist of mail implementors and hackers who know how things work and have the ability (if not time) to fix them when they don't work. Now that RFC 733 and 822 are under the bridge, one might think of it as a technical gossip ring. I hope that you don't feel unfairly singled out; I suspect every implementor on the list has been in the limelight at some time, since mail mistakes tend to be rather public. Certainly I have seen my share of eggs every time an "ITS-format" header escaped to the network, and that's a minor piffle compared with the bug that made Header-People a black hole for a couple months! --Ken -------  Received: by UCBVAX.ARPA (3.346/3.33) id AA23482; 20 Jun 83 12:46:40 PDT (Mon) Date: 20 Jun 83 15:37:46 EDT (Mon) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Re: loop detection Message-Id: <8306201937.AA00975@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA00975; 20 Jun 83 15:37:46 EDT (Mon) To: header-people@mit-mc It seems to me the correct way to do this is with the Received: header. Mail servers put in Received, including "for ". (I believe the BNF in 822 doesn't allow for multiple addresses, but it could be fixed.) The mailer detects a loop by the presence of two Received headers, both of which have "by " and "for ". Unfortunately, when mailing lists are expanded at a foreign site, the list of can get very long. There are legit ways for a message to go through the same system more than once. For instance, if I send mail to header-people@mit-mc.arpa, it must go through cbosgd (the originating system) ucbvax (the mail gateway between UUCP and ARPA) mit-mc (the mailing list exploder) (at this point, one copy addressed to, say, smb@mhb5b.uucp:) ucbvax (the mail gateway between UUCp and ARPA) cbosgd (as a forwarder) mhb5b (the destination machine) I'm sure you can think of convoluted examples with 3 or 4 passes through the same system. However, the number of passes tends to be small. Usenet detects multiple articles and throws the second copy away. The duplicates are detected primarily by checking the Message-ID, but also by not sending an article to a site that it has already gone through. However, these methods assume (1) a Message-ID is in every message (as it must be on Usenet), (2) each system remembers every Message-ID that has been recently received (it keeps a history file), and (3) it never makes sense to receive the same article on one machine more than once. This third assumption is not valid for mail, as shown by the example above. The pair (Message-ID, recipient) could be used in place of the Message-ID; I suspect this would eliminate loops without causing too many problems. Of course, the problem of a truncated message followed by the full text of the same message still must be addressed.  Received: from SCRC-COLLIE by SCRC-TENEX with CHAOS; Mon 20-Jun-83 19:33:19-EDT Date: Mon, 20 Jun 83 19:29 EDT From: Mike McMahon Subject: Re: loop detection To: cbosgd!mark@UCB-VAX Cc: header-people@MIT-MC In-reply-to: <8306201937.AA00975@cbosgd.UUCP> Message-ID: <830620192941.3.MMcM@SCRC-TENEX> Date: 20 Jun 83 15:37:46 EDT (Mon) From: cbosgd!mark@Berkeley (Mark Horton) It seems to me the correct way to do this is with the Received: header. Mail servers put in Received, including "for ". (I believe the BNF in 822 doesn't allow for multiple addresses, but it could be fixed.) The mailer detects a loop by the presence of two Received headers, both of which have "by " and "for ". Unfortunately, when mailing lists are expanded at a foreign site, the list of can get very long. There are legit ways for a message to go through the same system more than once. For instance, if I send mail to header-people@mit-mc.arpa, it must go through cbosgd (the originating system) ucbvax (the mail gateway between UUCP and ARPA) mit-mc (the mailing list exploder) (at this point, one copy addressed to, say, smb@mhb5b.uucp:) ucbvax (the mail gateway between UUCp and ARPA) cbosgd (as a forwarder) mhb5b (the destination machine) I'm sure you can think of convoluted examples with 3 or 4 passes through the same system. However, the number of passes tends to be small. That's what "for" is for. It is not "legit" for a message to go through the same system more than once -for the same recipient-. In your above example, messages pass through once as "for header-people@mit-mc.arpa" and once again as "for smb@mhb5b.uucp". Usenet detects multiple articles and throws the second copy away. The duplicates are detected primarily by checking the Message-ID, but also by not sending an article to a site that it has already gone through. However, these methods assume (1) a Message-ID is in every message (as it must be on Usenet), (2) each system remembers every Message-ID that has been recently received (it keeps a history file), and (3) it never makes sense to receive the same article on one machine more than once. No, Message-ID does not work in the face of remailing. You would need to look for remailed-message-id first, which is more error prone in the face of systems that don't conform to header standards. For example, those systems that call remailing redistributing. And you need a history file, which is either huge, or its lifetime limited.  Date: 22 June 1983 00:18 EDT From: Earl A. Killian Subject: loop detection To: cbosgd!mark @ UCB-VAX, MMcM @ SCRC-TENEX cc: HEADER-PEOPLE @ MIT-MC In-reply-to: Msg of Mon 20 Jun 83 19:29 EDT from Mike McMahon Also, sites could start using the SMTP EXPAND command to eliminate loops and duplicates both as long you're dealing with directly connected sites.  Date: 22 Jun 1983 0214-PDT From: Henry W. Miller Subject: Re: loop detection To: EAK at MIT-MC, cbosgd!mark at UCB-VAX cc: HEADER-PEOPLE at MIT-MC, Miller at SRI-NIC In-Reply-To: Your message of 22-Jun-83 0018-PDT Alas, many SMTP servers do not have EXPN implemented yet... -HWM -------  Received: by UCBVAX.ARPA (3.346/3.33) id AA16259; 23 Jun 83 12:31:19 PDT (Thu) Date: 23 Jun 83 15:26:25 EDT (Thu) From: cbosgd!mark@Berkeley (Mark Horton) Subject: Re: problems with NBS standard Message-Id: <8306231926.AA07210@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA07210; 23 Jun 83 15:26:25 EDT (Thu) To: OLE@SRI-CSL.ARPA Cc: header-people@mit-mc.ARPA Well, I understand wanting to keep your own culture. However, I'm sure you're aware that there are some incredibly hairy technical problems with trying to get a machine to translate natural languages. If someone with an appropriate incentive wants to tackle these problems, great. But I (being an American who only speaks English and has no particular interest or need to learn other languages, and also having far more to do than time to do it already) can't afford to spend more of my time worrying about foreign languages or funny formats that were invented to make foreign languages easier. Now that we've flamed a bit, let me make a comment aimed a constructive solution to the problem. No, I won't say that everyone should speak English (although that would certainly be convenient, and seems to be true of 99.9% of the world's computing population now), rather, I expect that a gateway translator might be useful. Here are two such translators: (a) Assuming there will be only RFC822 style mail networks: when a message crosses a boundary between a country whose official language is X and another country speaking Y (X != Y), a gateway program does a fixed translation of all the 822 headers from language X into Y, using a fixed, predefined table. No attempt is made to translate the text of the message - that's up to the individuals. (b) Since the NBS standard is a standard, I assume there will soon be NBS mail networks around. There will be gateways to RFC 822 networks. So the gateway translates from one format to the other. Then the rest of the world need only understand their own format. (This takes care of the header names, glibly assuming there is a 1-1 mapping between 822 and NBS, and that NBS is extensible, and that the user address syntax can be reasonably mapped from one to the other format. I suppose I should get the NBS standard and read it, in my copious free time.)  Date: 26 June 1983 16:44 EDT From: Earl A. Killian Subject: loop detection To: Miller @ SRI-NIC cc: HEADER-PEOPLE @ MIT-MC, cbosgd!mark @ UCB-VAX In-reply-to: Msg of 22 Jun 1983 0214-PDT from Henry W. Miller Date: 22 Jun 1983 0214-PDT From: Henry W. Miller Alas, many SMTP servers do not have EXPN implemented yet... Yes, but most mail traffic is between local hosts. E.g. if MIT or Stanford or SRI implemented EXPN in its senders and receivers then they would get 80% of the benefit to be had because most of their mail is from local host to local host. That's why EXPN is interesting even though it doesn't solve the loop problem for hosts that you can't establish a direct connection to. As a side benefit, it puts the mail sending burden on the site that sent the mail, not the site that has the mailing list.  Date: 27 Jun 1983 0211-PDT From: Henry W. Miller Subject: Re: loop detection To: EAK at MIT-MC cc: HEADER-PEOPLE at MIT-MC, cbosgd!mark at UCB-VAX, Miller at SRI-NIC In-Reply-To: Your message of 26-Jun-83 1644-PDT EXPN could help preveent looping, or multiple receipieents. Remember, the NIC talks to EVERYONE!!! Thhanks for your feedback. -HWM -------  Date: 27 Jun 83 10:40:22-EDT (Mon) From: Dave Crocker Return-Path: Subject: NBS / 822 To: Header-People@mit-mc This is to reinforce Debbie Deutsch's comments and to provide you with a little history: RFC733 was primarily intended to codify existing practises, with a "few" improvements. In fact, we seriously considered scrapping the free-text approach and going to some encoded standard, such as Postel's MPM. It was decided, however, that the Arpanet world was not yet ready (read that as "willing") to invest the effort at converting over. RFC822 was, again, intended for the short-term, although this time I think we know that that means several years. It is certainly true that 822 is easier to implement than the NBS standard. For most straight-text mail systems, 822 is probably quite adequate. However, as soon as you want more data structuring or multiple data types, the NBS and MPM approaches are necessary. Someone would do the world a considerable service by specifying the translations between 822 and NBS, formally. As Mark Horton notes, such mail relaying will occur. It is probably better to specify hour the relays should behave, rather than let each one decide on its own. Dave  Received: by UCBVAX.ARPA (3.346/3.33) id AA26200; 29 Jun 83 17:44:51 PDT (Wed) Date: 29 Jun 83 14:53:13 EDT (Wed) From: cbosgd!mark@Berkeley (Mark Horton) Subject: time zones Message-Id: <8306291853.AA20463@cbosgd.UUCP> Received: by cbosgd.UUCP (3.327/3.7) id AA20463; 29 Jun 83 14:53:13 EDT (Wed) To: dcrocker@udel.ARPA, postel@isif.ARPA Cc: header-people@mit-mc.ARPA Minor correction for the successor to RFC 822: I am told that UTC is the favored abbreviation for Universal Time, rather than UT or GMT. I suppose it would be better to accept them all, but to generate UTC. By the way, there are a lot of other time zones whose names seem to have been deleted from 733 to 822. Was this deliberate? I'd be interested to know the reasons, especially since some of those time zones include ARPANET hosts, and certainly the internet will eventually include most of them. I'm thinking not only of the far out North American zones (Atlantic, Newfoundland, Yukon, Alaska/Hawaii), but also of Australian and European zones. I'm enclosing the data for reference in the next table: Letter Zone name UTC+x normal daylight N -1 O -2 P -3 Newfoundland -3.5 ?NST ?NDT Q Atlantic -4 AST ADT R Eastern -5 EST EDT S Central -6 CST CDT T Mountain -7 MST MDT U Pacific -8 PST PDT V Yukon -9 ?YST ?YDT W Alaska-Hawaii -10 ?AHST ?AHDT X Bering -11 ?BST ?BDT Y -12 M +12 L +11 K Australian Eastern +10 AEST AESST (summer time) Australian Central +9.5 ACST ACSST I Japan, Korea +9 ? ? H Australian Western +8 AWST AWSST G +7 F +6 E +5 D +4 C +3 B Eastern European +2 EET EET DST A Middle European +1 MET MET DST Z Western European +0 WET WET DST Coordinated Universal Time +0 UTC (UTC is also known as UT and GMT) I'm sending a copy of this to header-people in the hope that mail system maintainers that have written programs to parse dates will arrange for them to parse these time zones as well as the usual American four. For the most part it shouldn't be hard to add them to existing tables. I'd also like to make people aware that the assumption of a 3 letter time zone abbreviation is NOT always valid. (I have had Australians express frustration at finding code containing this assumption.) Also note that the rules for when and whether to go on daylight saving time vary from country to country. I'm sure many of your are familiar with the various arcane rules in the USA (some states or parts of states don't go at all; the rules were different in 1974 & 1975) - the rest of the world has just as many funny rules. Fortunately, this doesn't normally matter, since you only have to generate dates in your own time zone. You must, however, often understand dates containing other time zones. I had to do considerable digging and asking around to get this information. The friendly atlas and encyclopedia weren't much help - they show a map with hour offsets but no time zone names. Thus, this table is not as complete as I would like. If anyone can fill in any of the blanks, I'd be grateful. I also suspect there are more multiple names for certain time zones, too, at different latitudes. We are rapidly coming into an age where the whole world sends electronic mail to each other, and can no longer afford to be ignorant of foreign time zone conventions. We do have a provision for hour offsets and single zone letters in 822, but we don't use these conventions in America, and we must realize that foreigners don't use them either. Mark Horton  Date: Wed, 29 Jun 83 19:00 PDT From: Taft.PA@PARC-MAXC.ARPA Subject: Re: time zones In-reply-to: Mark Horton <8306291853.AA20463@cbosgd.UUCP> To: header-people@mit-mc.ARPA cc: Taft.PA@PARC-MAXC.ARPA This is a fine example of the sort of trouble you get into when user interface issues are permitted to creep into computer communication protocols. The way in which dates and times are presented to humans is subject to many local conventions and is subject to occasional change. It's totally unreasonable that every program in the world should have to understand the union of all the world's conventions for presenting dates and times to humans. Ideally, RFC 822 should specify ONE form for specifying date and time. I don't care what form it is, so long as its meaning is unambiguous. RFC 822 is better than 733 in this regard, though there are still many ways to express a given value of time. If anything, we should REMOVE variability from the date and time syntax, not add more. If we were starting over, it would be best to pick something completely neutral, not tied to native language, daylight savings time conventions, military vs. civilian conventions, etc., so as to forestall religious discussions. I offer as an example a decimal number which is the number of seconds since some arbitrary starting date. Most computers already use this sort of representation for maintaining their internal calendar clocks. The responsibility of converting this to a human-readable date and time is then shifted to the user interface software where it belongs. Ed Taft  Date: 30 Jun 1983 0223-PDT From: Henry W. Miller Subject: Re: time zones To: Taft.PA at PARC-MAXC, header-people at MIT-MC cc: Miller at SRI-NIC In-Reply-To: Your message of 29-Jun-83 1914-PDT Yep, this drove me batty here, while trying to debug the timeserveer, until, after many blastings from the net, I realzed that the code was using the wrong format... -HWM -------  Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA by Mailnet; 30 Jun 1983 13:02:20 edt Date: Thu, 30 Jun 83 09:31:50 EDT From: Gavin_Eadie@UMich-MTS To: header-people@MIT-MC.ARPA Message-ID: <206472@UMich-MTS> Subject: Time Zones Mark's presentation of time zone names from all over the atlas reminds me of one problem that arose with the 'BST' acronym. In the UK it means 'British Summer Time' -- in the frozen wastes it means 'Bering Standard Time'! ... Gavin (Gavin_Eadie%UMICH-MTS.MAILNET@MIT-MULTICS)  Date: 30 Jun 1983 1016-PDT From: POSTEL at USC-ISIF Subject: re: time zones To: header-people at MIT-MC What about the potential confusion between (1) BST and (2) BST? (1) is obviously British Summer Time, while (2) is obviously Bering Standard Time. By the way -- what should be done about the leap second that gets inserted into time today? --jon. -------  Received: from Shasta by Score with Pup; Thu 30 Jun 83 10:54:30-PDT Received: from decwrl by Shasta with UUCP; Thu, 30 Jun 83 10:56 PDT Date: Thursday, 30 Jun 1983 10:50-PDT To: Shasta!"POSTEL@USC-ISIF" Cc: Shasta!"header-people@MIT-MC" Subject: re: time zones In-reply-to: Your message of 30 Jun 1983 1016-PDT. From: Chris Kent Message-ID: <34.425843432@decwrl> Clearly, we should all reset our clocks. Speaking of which, why isn't there a widely-known WWV clock somewhere on the Internet? Cheers, chris  Date: 30 June 1983 15:13 edt From: Barry Margolin at MIT-MULTICS Subject: Re: time zones To: POSTEL at USC-ISIF cc: header-people at MIT-MC In-Reply-To: Message of 30 June 1983 13:16 edt from POSTEL By the way -- what should be done about the leap second that gets inserted into time today? I think this can be ignored, since the accuracy of the operators who set the time on most computer systems probably averages to about a minute off. barmar  Date: Thu, 30 Jun 83 18:02:02 EDT From: Ron Natalie To: POSTEL@usc-isif cc: header-people@mit-mc Subject: Re: time zones Obviously all mail systems that get letters during the additional second should queue them for transmission the next day to avoid confusion. o o \___/  Date: 30 Jun 1983 1717-PDT From: MILLS at USC-ISID Subject: re: time zones To: POSTEL at USC-ISIF, header-people at MIT-MC cc: MILLS at USC-ISID In response to the message sent 30 Jun 1983 1016-PDT from POSTEL@USC-ISIF Jon, I should know better than to jump into this pot: 1. I like Ed Taft's suggestion best: Standard Time is so many seconds past a historical epoch (IEN-142), expressed as a decimal integer. 2. If (1) is unacceptable, then the only zone understood anywhere is UT (GMT) as per standard time broadcast services in many countries. Local zone conversions are optional, but not specified as part of SMTP (or RFC-822 for that matter). 3. Our Fuzzball hosts are synchronized to NBS time via radio (WWVB) and generally maintain standard time to within a few milliseconds or so. When a leap second is inserted by WWVB the apparent time on these hosts will slew to the correct value at a rate of about one millisecond per second. User interface routines provide the correction factor, so a program can determine the exact time even during the slew, although at somewhat reduced accuracy. The right way to do this is to have advance notice that the leap will happen and zig when it zags. Regards, Dave -------  Received: from Glacier by Score with Pup; Thu 30 Jun 83 17:45:07-PDT Date: Thursday, 30 Jun 1983 17:44-PDT To: Ron Natalie Cc: header-people at Mit-mc Subject: Re: time zones In-reply-to: Your message of Thu, 30 Jun 83 18:02:02 EDT. From: Brian Reid I spent several years in the early 1970's working for various airline companies doing schedule-planning and reservation systems programming. One of the things that I noticed while analyzing Delta airlines' published schedules for that period was that Delta had no planes in the air during the Daylight/Standard switchover hour, to avoid having to solve the problem of a plane that takes off on standard time and lands on daylight savings time, or vice versa. Your idea of requeueing mail for that extra second sounds like the same principle.  Date: 30 Jun 1983 1738-PDT From: MILLS at USC-ISID Subject: NBS time servers To: decwrl!kent%Shasta at SU-SCORE cc: Header-people at MIT-MC Chris, Shame on you for that naughty "to:" field in your message! IEN-142 time servers synchronized to NBS: DCN1 (aka LINKABIT) 128.4.0.1 (synchronized to WWVB) FORD1 (akda FORD) 128.5.0.1 (synchronized to GOES) Regards, Dave -------  Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 1 Jul 83 02:31:59 PDT Via: Rlgk.AC-UK; to UCL-CS.AC-UK (44b) over Sercnet with NIFTP; 1 Jul 83 9:42 BST From: Philip Gladstone (on GEC 4090 at Rutherford) To: Header-People @ Mit-MC.Arpa Date: Fri, 1 Jul 83 09:25 BST Subject: Time zones Message-Id: <01 JUL 1983 09:41:03 NSIN08@RLGK> The long list of time zones produced my Mark Horton does not include the ones I use: +0 GMT BST (British Summer Time) In Germany +1 MEZ MESZ (The Z stands for something in German) In Switzerland +1 CET CEST (C is Central) We have always noted that BST clashes with Bering Standard Time, and so we were pleased when it was taken out of 822 - so that we could re-use it by extending the spec rather than disagreeing with it. The way that the CCITT MHS represents times is as: YYMMDDhhmm[+/-hhmm] where the +/-hhmm indicates the time difference from UTC. This does have the advantage that it is sufficiently unreadable to force any user interface to redisplay it in a more reasonable format. Philip Gladstone  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 22 Jul 83 15:59:54 EDT Date: 22 Jul 83 1540 EDT (Friday) From: Craig.Everhart@CMU-CS-A To: MILLS@USC-ISID, Header-People@MIT-MC Subject: Re: time zones In-Reply-To: "MILLS@USC-ISID's message of 30 Jun 83 19:17-EST" Message-Id: <22Jul83.154019.CE10@CMU-CS-A> When an IEN-142 time server returns a number of seconds since some epoch, does that number account for the leap seconds that have crept into NBS time? There is an obvious disparity between the actual number of seconds since the epoch and the number of seconds that there would have been had the Gregorian calendar been strictly obeyed. It's too bad that applications want both values. Which ones are being returned? Dave Mills' compromise is excellent for applications bursting the universal time into local components, without disturbing precise interval-timing applications by more than 0.1 percent. But is there a better solution? Craig Everhart  Date: 23-Jul-83 05:10:28-UT From: Mills@dcn6 Subject: Time-server leaps and bounds To: Craig.Everhart@CMU-CS-A cc: Header-people@MIT-MC Craig, I have done a little digging on the leap-second problem. The broadcast standards on which our network time-distribution system is based provide time-of-day, day-of-year and certain corrections and offset information. The NBS broadcast formats are described in "NBS Special Publication 432, Time and Frequency Dissemination Services (1979)." Essentially equivalent information is broadcast on LF and HF frequencies and via the GOES satellite. Our receiver uses the LF broadcasts from Boulder, Colorado. The broadcasts provide precise timing information along with time-of-day, day-of-year and certain corrections and offsets. There are two time scales of interest: UTC, commonly called "atomic time" and UT1, commonly called "astronomical time." The broadcast time is UTC; however, UT1 corrections up to a maximum of about one second are encoded in the data stream. When the correction exceeds this a leap-second is inserted or deleted; however, the times when such a correction can be incorporated are known in advance and coordinated throughout the world by the Bureau des Heure. The obvious way to do this would be with a control bit set in advance in the broadcast data, as is done already with leap-year and daylight-saving time control bits. I could find no reference to this in SP 432, although the errata sheet accompanying the publication does mention such a bit in connection with the LF broadcasts. I suspect this may be a typo and in fact the bit does not exist. Now, your question on the civilized IEN-142 time server returning UTC or UT1 is very interesting and provocative. Since UT1, which drives the diddle in the first place, is determined by observation and the precision necessary to determine it to the accuracy required has only recently been achieved, it would seem uninteresting to establish a Network Standard Time based on UT1. I suspect all existing IEN-142 servers, like ours, simply brute-force the calculation assuming no corrections were ever made. This results in our losing about a second a year, on average. I would propose a gentleman's solution to this dilemma: the servers should be expected to return UTC as broadcast by NBS, including the leap-second correction but omitting the UT1 correction. There should be a protocol to ask more detailed questions about the procedure, such as when the next leap-second correction will be made and what the current UT1 offset is. It must then be understood that time intervals measured using UTC samples can be off by numbers of seconds relative to UT1, depending on when the corrections were made. The behavior of our receiver is unknown in the vicinity of a leap-second event, but I suspect it probably hiccups and loses synchronization momentarily. That's why we elected to slew the apparent time at a reasonably sedately clip when a large change is detected. We do in fact have an interesting local operational problem: occasionaly somebody gets the year wrong and all our clocks are off by the exact discrepancy. In retrospect, the NBS format would have been better advised to include the year and advance leap-second indicator, but forget the leap-year indicator. Another problem is the determination of time zone without outside reference. In principle, this can be done from knowledge of longitude, which is readily available from either LORAN-C or OMEGA radio navigation systems. Navigation receivers for these systems are definitely off the scale of our budget, at least. Besides, some countries are positively kinky about time zones, not to mention daylight-saving time. Therefore, we punt the whole issue and use Universal Time (UT, nee GMT) EVERYWHERE in our fuzzballs, which are scattered widely on the globe. By the way, in principle advance notice of a leap second can be determined from the BBC time pips, a series of (usually) five beeps broadcast just before the hour. Either four or six beeps indicate a leap second more or less on the following hour epoch. BBC receivers are probably cheaper than OMEGA receivers. I thought you might like that. Regards, Dave -------  Date: 24 Jul 1983 0303-CDT From: Clive Dawson Subject: Re: Time-server leaps and bounds To: Mills@DCN6 cc: Header-people@MIT-MC In-Reply-To: Your message of 23-Jul-83 0027-CDT Regarding advance notice of leap seconds, you can also tell how close we are to a leap second by listening to the NBS broadcasts (WWV). If you listen for the first ten seconds of each minute, you will note that some of the seconds are marked by a double instead of a single click. I forget the exact details, but basically number of double clicks tells how far away from a leap second we are. Depending on whether the double clicks occur at the beginning or the end of the ten second period, a leap second will be omitted or added. Can anybody elaborate on the scheme? -------  Date: 24-Jul-83 15:55:46-UT From: Mills@dcn6 Subject: Re: Time-server leaps and boundsî To: CliveDawson, Mills@DCN6, Header-people@MIT-MC In-reply-to: Your message of 24 Jul 1983 0303-CDTî Clive, The double-ticks are broadcast by NBS HF services, as well as similar services of many other countries, at the beginning of the minute. The number of doubled ticks on seconds 1-8 indicate a positive offset of that many tenth-seconds, while the number of doubled ticks on seconds 9-16 indicate a negative offset in the same way. Very dumb for computers but good for humans trying to pick the darn things out of sferics and noise. Apparently, by gentleman's agreement the offset is not permitted to exceed eight. This is the same offset broadcast in the digital time code. If the receiver made this information available the clever program could extrapolate when the next correction might be; however, only the BIH officially knows exactly when the correction will be ordered. I will call people at NBS on Monday to see what else I can discover. Regards, Dave -------  Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 25 Jul 83 03:09:28 PDT Via: Rlgk.AC.UK; to UCL-CS.AC.UK (44b) over Sercnet with NIFTP; 25 Jul 83 10:42 BST From: Philip Gladstone (on GEC 4090 at Rutherford) To: Header-People at MIT-MC.ARPA Date: Mon, 25 Jul 83 09:57 BST Subject: Time clocks. Message-Id: <25 JUL 1983 09:57:21 NSIN08@RLGK> The Time service in the UK broadcasts a 'leap second on next hour' bit. We actually ignore this, and just jump the time by 1 second when it happens. The time service also broadcasts the 'national time' and its difference from GMT - this enables us to work out if we are operating summer or winter time. Philip  Received: FROM UCL-CS BY USC-ISID.ARPA WITH TCP ; 25 Jul 83 07:37:28 PDT Via: Rlgk.AC.UK; to UCL-CS.AC.UK (44b) over Sercnet with NIFTP; 25 Jul 83 15:07 BST From: Philip Gladstone (on GEC 4090 at Rutherford) To: Header-people at MIT-MC.ARPA Date: Mon, 25 Jul 83 15:07 BST Subject: Time changes Message-Id: <25 JUL 1983 15:07:31 NSIN08@RLGK> Since leap seconds can only be inserted or removed on 00:00 1st July and 00:00 31 December, it should be easy to anticipate this occurence by some time. An interesting document to read which covers this sort of stuff is Volume VII of Recommendations of the CCIR 1982. ISBN 92-61-01451-8 It goes into great (and gory) detail about time. For example, the time 0.4 sec before 00:00:00 1 July when a leap second has been inserted is 30 June, 23h 59m 60.6s UTC. It also has tables of most time services and their modulation type. Well worth getting out of your technical library. Miscellaneous bit of information: The time taken for Radio waves to reach your receiver from a transmitter is not constant - it can vary noticeably even over short distances (1 microsecond variation, 10Km between transmitter and receiver. Timescale of variation is small (seconds))  Date: 25 Jul 1983 1117-PDT From: MILLS at USC-ISID Subject: Another stitch in time To: Header-people at MIT-MC Philip, Thanks for the information on UK broadcast information. I assume that is on the LF service, not MSF. The NBS broadcast services (except GOES) also have a summertime bit, but not a leap-second bit. And yes, I do know how radio propagation effects affects the precision. Your CCIR reference may clear up some lingering details. I called NBS and found that, indeed, there is no advance notice of a leap second in any code they use. I was also told that leap seconds cannot reliably be forecast from the UT1 offset drift. It looks like any further progress toward really tight time will have to be made in another forum. Meanwhile, I suggest we take further correspondence offline in the interest of good mailmanship. Regards, Dave -------  Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA by Mailnet; 31 Jul 1983 00:14:15 edt Date: Sat, 30 Jul 83 21:38:58 EDT From: Gavin_Eadie@UMich-MTS To: header-people@MIT-MC.ARPA Message-ID: <216715@UMich-MTS.Mailnet> Subject: SMTP response codes Learned Colleagues ... A question: The SMTP document contains an indication that new SMTP response values should not be invented but, rather, that the existing ones be employed as well as possible. My mail system allows a user to leave a 'tag' on their mailbox which carries a short piece of text which is most commonly used to say things like: "I'll be out of town till August 5th". Local users of the system are shown this when they send mail to a 'tagged' mailbox. The display of the 'tag' is the only different action - the 'tag' has no effect on the delivery of the message. Now, when a message arrives over the net aimed at a box with a 'tag' on it, what should I do? I would like to respond to the "RCPT TO:<...>" in some way to indicate to any mailer capable of being clever enough that while the mail was delivered perfectly, there was a little message which the recipient would like the sender to be aware of. In my innocence I invented a '252' response code with the 'tag' text appended. Some words on page 50 of RFC821 would indicate that I did a Bad Thing - they say, "... should not invent new codes for slightly different situations from the ones described ..." oh woe! Well, I could use '250' - but how can I tell that the appended text is significant to those that care? I could use '251' - but that looks like it has a semantic significance which is quite different from what I want. Suggestions? (Tablets of stone accepted!) Gavin_Eadie%UMICH-MTS.MAILNET@MIT-MULTICS  Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.347/3.35) id AA08174; Sat, 30 Jul 83 21:54:34 PDT Received: by UCBARPA.ARPA (3.347/3.37) id AA18125; Sat, 30 Jul 83 21:56:19 PDT From: eric%UCBARPA@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 30 Jul 1983 2156-PDT (Saturday) Message-Id: <18124.31.428475378@ucbarpa> To: Gavin_Eadie@UMich-MTS Cc: header-people@MIT-MC.ARPA Subject: Re: SMTP response codes In-Reply-To: Your message of Sat, 30 Jul 83 21:38:58 EDT. <216715@UMich-MTS.Mailnet> Fcc: mail As 100,000 people will undoubtedly tell you, putting something in the SMTP transcript will not convey the desired information, since it is typically not seen by humans unless something went wrong. The only way you can really handle this is either to return a failure code (which is wrong, since the mail was actually delivered) or to compose a new message back to the sender including the tag (which is correct). eric allman  Date: Saturday, 30 Jul 1983 23:02-PDT To: header-people@MIT-MC Subject: Re: SMTP response codes In-reply-to: Message from eric%UCBARPA@UCB-VAX (Eric Allman) of 30 Jul 1983 2156-PDT (Saturday) <18124.31.428475378@ucbarpa> From: greep@SU-DSN While it is true that the user does not normally see the commands and replies between the mailer and smtp server, there is no reason why a particular mailer could not show users such a message if they happened to be logged in when the mail is sent. It sounds like a good idea to me, and might be worth adding to the SMTP protocol since there is no way to specify such a thing now. (Of course mailers would be free to ignore such a message.) Your suggestion of having the receiving site send back a message has the problem of getting into a loop if both sides do this. A way out of this might be to use the SEND command instead of MAIL, except that some hosts (at least last time I checked) treat SENDs as mail anyway. (Gavin_Eadie: note that UMich-MTS is not in the Arpanet host table.)  Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.347/3.35) id AA13648; Sun, 31 Jul 83 11:32:08 PDT Received: by UCBARPA.ARPA (3.347/3.37) id AA21230; Sun, 31 Jul 83 11:33:51 PDT From: eric%UCBARPA@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 31 Jul 1983 1133-PDT (Sunday) Message-Id: <21229.31.428524428@ucbarpa> To: greep@SU-DSN Cc: header-people@MIT-MC Subject: Re: SMTP response codes In-Reply-To: Your message of Saturday, 30 Jul 1983 23:02-PDT. <8307310614.AA08755@UCBVAX.ARPA> Fcc: mail Although I agree that a sender could behave as you suggest, the fact is that many of them do not at this time -- if he wants to insure that the sender see the "tag" regardless of the sending system then something else need be done. This still doesn't handle the problem of relayed mail anyhow. Your point about mail loops is well taken -- I should have mentioned this problem in my original message. It is probably not wise to rely on SEND -- RFC821 does not require that it be implemented at all; a separate reply code is even supplied (502 Command not implemented) for this purpose. See section 4.5.1. eric  Date: 25 Aug 1983 1507-PDT Sender: ESTEFFERUD at USC-ECL Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO From: ESTEFFERUD at USC-ECL To: wales at UCLA-LOCUS Cc: ROGERS at USC-ISIB, Action at USC-ISI Cc: Bug-MAISER at SU-SCORE, HEDRICK at RUTGERS, MsgGroup at BRL Cc: header-people at MIT-MC Message-ID: <[USC-ECL]25-Aug-83 15:07:07.ESTEFFERUD> In-Reply-To: Your message of Thu, 25 Aug 83 13:29:48 PDT Hi Rich - I appreciate your intent in sending your message to MsgGroup, but I suspect that most of our members are not the right folks to help you. I would expect Header-People to be the better forum for oprational SMPT problems, so I suggest that you shift to that group for future discussion. I will redistribute your message to Header-People, in spite of the large overlap with MsgGroup, with the hope that the discussion will totally shift to the other list. I wish you the best in solving the problems! Stef (MsgGroup Moderator)  Return-path: Date: 25 Aug 1983 1143-PDT From: PLILES Subject: Re: dir access vs connect without pw To: ESTEFFERUD@USC-ECL cc: action@USC-ECL In-Reply-To: Your message of 25-Aug-83 1042-PDT Redistributed-To: header-people at MIT-MC Redistributed-By: ESTEFFERUD at USC-ECL Redistributed-Date: 25 Aug 1983 (John forwarded your message.) What you have said about file protections is perfectly right. Paul Liles -------  Return-path: Received: from BRL by USC-ECL; Thu 25 Aug 83 14:30:39-PDT Received: From Ucla-Locus.ARPA by BRL via smtp; 25 Aug 83 16:37 EDT Date: Thu, 25 Aug 83 13:29:48 PDT From: Rich Wales To: Craig M. Rogers CC: Action@usc-isi, Bug-MAISER@su-score, HEDRICK@rutgers CC: MsgGroup@brl Subject: ISI-VAXA's SMTP sender doesn't say HELO Redistributed-To: header-people at MIT-MC Redistributed-By: ESTEFFERUD at USC-ECL Redistributed-Date: 25 Aug 1983 Craig -- Hi. I am Rich Wales, the UCLA Computer Science Department's mail guru. I may have mentioned the following to you some time ago, but since the problem apparently still exists . . . . There seems to be a bug in the ISI-VAXA SMTP sender program; namely, it doesn't start each transaction with a HELO command. The following is a log of a recent connection between ISI-VAXA and UCLA-LOCUS: 220 UCLA-LOCUS SMTP Server ready; Thu, 25 Aug 83 10:15:05 PDT === mail from: 250 MAIL: OK, even though you forgot to say HELO first === rcpt to: 250 RCPT: OK === data 354 Enter message === [13 lines of message text] === . 250 Message accepted === quit 221 UCLA-LOCUS SMTP Server exiting; Thu, 25 Aug 83 10:15:21 PDT While I admit that RFC821 may not be 100% clear on the issue of whether the HELO is mandatory (and many SMTP servers, including our own, do not require the sender to say HELO), there are quite a few SMTP's around which will reject a MAIL command (with a 503 reply code) unless a HELO comes first. Based on tests I ran this morning, here is a partial list of hosts who appear to insist on being HELO'ed before accepting mail: BBNA BBNG CMU-CS-C DEC-MARLBORO HI-MULTICS MIT-MC MIT-ML OFFICE-3 RADC-TOPS20 RUTGERS SANDIA SRI-AI SU-SCORE SUMEX-AIM SRI-KL SRI-NIC USC-ECL USC-ECLB USC-ECLC UTAH-20 UTEXAS-20 WASHINGTON Note particularly, by the way, that SRI-NIC is on the above list. The "fix" to your SMTP sender program to have it send a HELO and gobble up the "250" reply shouldn't really be too big (if it's more than about 10 lines I would be amazed). My personal opinion, by the way, is that the other hosts ought to fix their SMTP's so as not to demand a HELO -- in keeping with the oft- stated axiom that you should be conservative in what you send out and liberal in what you accept. The pragmatic facts of life, however, are that you can modify your code a lot faster than 22 other people will modify theirs. -- Rich Wales  Return-path: Received: from BRL by USC-ECL; Thu 25 Aug 83 16:17:26-PDT Received: From Su-Score.ARPA by BRL via smtp; 25 Aug 83 18:32 EDT Date: Thu 25 Aug 83 15:27:51-PDT From: Mark Crispin Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO To: wales@UCLA-LOCUS.ARPA cc: ROGERS@USC-ISIB.ARPA, Action@USC-ISI.ARPA, HEDRICK@RUTGERS.ARPA, MsgGroup@BRL.ARPA In-Reply-To: Message from "Rich Wales " of Thu 25 Aug 83 13:36:38-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Redistributed-To: header-people at MIT-MC Redistributed-By: ESTEFFERUD at USC-ECL Redistributed-Date: 25 Aug 1983 Sigh. Another round in the "lets make our protocols simpler to accomodate the quick and dirty implementations" battle. According to section 3.5 of RFC821, "at the time the transmission channel is opened there is an exchange" and "the following...are used in transmission channel opening and closing...HELO...QUIT". That implies to me that HELO is not optional. I'll conceed that 503 isn't listed as a reply code to MAIL, but I would consider that a bogosity in the reply codes list. HELO serves a purpose. That purpose is voided if it isn't used. I would rather mandate a change in a single SMTP user process than force an unknown number of present and future SMTP server processes to be changed. We have a desirable situation now. Despite the ambiguity in RFC821, the de facto situation is that HELO is required. An SMTP user that doesn't send HELO is going to have a lot of hassle getting its mail out. Let's not break a good thing! I cannot believe that a straightforward protocol such as SMTP has gotten corrupted by various short-cut implementations. Isn't it enough that from time to time we are expected to tolerate host-less arguments to MAIL and RCPT, or pre-RFC821 syntax for source routing? In the principle of being "liberal in what you accept", let's make MAIL optional too. It should be the default. While we're at it, why require RCPT? We can just accept DATA and parse the header. Another example of the flaw in the "be conservative/be liberal" argument is in SMTP data flow. For a shocking number of hosts, an SMTP transaction will not work in a message of non-trivial size unless the SMTP user process periodically sets Push in its segments, completely independently of where Push is actually required. A subset of those hosts also fail if you send segments larger than 50 bytes or so. The TOPS-20 SMTP user process used to do all of its TCP transitions in 40 byte Pushed segments. The problem was, that gronked our UK friends at the other end of SATNET. Today, it does normal TCP I/O, and reverts into the Pushed minigram mode if the connection times out (taking more than 2 minutes to output 1000 bytes) or if the connection dies unexpectedly. When it does so it prepends a message (the infamous "Delivery-Notice" message some of you may have seen) suggesting that maybe the receiver's TCP ought to be fixed. Certain mailers across the Internet have discovered that the TOPS-20 mailer has the feature of being able to talk to the broken hosts; Score gets a lot of third-party traffic this way. Also, every so often an innocent host gets sent to in the minigram mode (and gets the obnoxious Delivery-Notice). In a few weeks it will only do normal TCP I/O, when I cut over to the DEC TCP/IP interface. After all, people have had 9 months to get their TCPs working. -- Mark -- -------  Date: 25 Aug 1983 2300-PDT Sender: ESTEFFERUD at USC-ECL Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO From: ESTEFFERUD at USC-ECL To: MRC at SU-SCORE Cc: wales at UCLA-LOCUS, ROGERS at USC-ISIB, Action at USC-ISI Cc: HEDRICK at RUTGERS, header-people at MIT-MC Message-ID: <[USC-ECL]25-Aug-83 23:00:42.ESTEFFERUD> In-Reply-To: Your message of Thu 25 Aug 83 15:27:51-PDT Earlier today I made a dumb error when I redistributed the wrong message to Header-People in my attempt to shift the discussion from MsgGroup to Header-People. I have just redistributed the correct message from Rich Wales, and also a reply from Mark Crispin, so this discussion can now continue in Header-People without copying MsgGroup. Thank you all for your tolerance, and thanks to Mike@brl for pointing out my error. Best - Stef (MsgGroup Moderator)  Return-path: Received: from BRL by USC-ECL; Fri 26 Aug 83 03:20:00-PDT Received: From Sri-Nic.ARPA by BRL via smtp; 26 Aug 83 5:57 EDT Date: Fri 26 Aug 83 02:51:28-PDT From: Henry W. Miller Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO To: MRC@SU-SCORE.ARPA, wales@UCLA-LOCUS.ARPA cc: ROGERS@USC-ISIB.ARPA, Action@USC-ISI.ARPA, HEDRICK@RUTGERS.ARPA, MsgGroup@BRL.ARPA, Miller@SRI-NIC.ARPA In-Reply-To: Message from "Mark Crispin " of Thu 25 Aug 83 23:18:45-PDT Redistributed-To: header-people at MIT-MC, miller at SRI-NIC Redistributed-By: ESTEFFERUD at USC-ECL Redistributed-Date: 27 Aug 1983 Mark, Actually, I think the idea of ttaking RCPT out is a bit extreme... But seriously, I agree. The spec is there; it has been "agreed" on. If they don't want to play ball our way, well, it's our bat and our ball, and... -HWM -------  Return-path: Received: from BRL by USC-ECL; Fri 26 Aug 83 08:20:29-PDT Received: From Hi-Multics.ARPA by BRL via smtp; 26 Aug 83 9:48 EDT Date: 26 August 1983 08:43 cdt From: Stachour.CSCswtec@hi-multics Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO To: Henry W. Miller cc: MRC@su-score, wales@ucla-locus, ROGERS@usc-isib, Action@usc-isi, HEDRICK@rutgers, MsgGroup@brl In-Reply-To: Message of 26 August 1983 07:28 cdt from Henry W. Miller Redistributed-To: header-people at MIT-MC Redistributed-To: Stachour.CSCswtec at HI-MULTICS(Attn: Thanks!) Redistributed-By: ESTEFFERUD at USC-ECL Redistributed-Date: 27 Aug 1983 When I use a mail-system, one of the most common this I do is 'Reply', just as I'm doing now. I expect my mailer to be able to send a response to anyone who can send a msg to me (I hope that's not expecting too much). IF my mailer does not demand a HELO when recieving via SMTP, then it's very easy to get a msg that turns out to be non-replyable automatically, and not even a good "RECEIVED" header for me to try and figure it out manually. Yes, I know that a mailer can 'lie' about who it is, and most SMTP implementations will accept the 'lie'. However, that at least enables me to get a msg back to someone who can disclaim resposibility for the orginal send, something not even possible without a HELO. In short, I think a mailer NOT sending HELO is not only against the RFC, it's not a good way to use a protocol. ...Paul  Return-path: Received: from BRL by USC-ECL; Fri 26 Aug 83 08:39:46-PDT Received: From Hi-Multics.ARPA by BRL via smtp; 26 Aug 83 10:14 EDT Date: 26 August 1983 09:13 est From: DBrown.TSDC@hi-multics Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO To: MsgGroup@brl Redistributed-To: header-people at MIT-MC Redistributed-To: DBrown.TSDC at HI-MULTICS(Attn: THANKS!) Redistributed-By: ESTEFFERUD at USC-ECL Redistributed-Date: 27 Aug 1983 I hope the comment about taking your bat and ball was humor... Seriously, if a program expects a certain protocol and doesn't need it, then there's ane error in defining the protocol. If one *needs* the protocol but is capable of surviving misuse of it in known special cases then the best tack is to send lots of messages (in this case mail) to the person/thing which isn't meeting the spec. Or even to this forum.... --dave  Return-path: Received: from BRL by USC-ECL; Fri 26 Aug 83 10:59:37-PDT Received: From Wisc-Crys.ARPA by BRL via smtp; 26 Aug 83 12:40 EDT Date: 26 Aug 1983 11:14:56-CDT From: Marvin Solomon Reply-to: solomon@uwisc To: MsgGroup@brl Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO Redistributed-To: header-people at MIT-MC Redistributed-To: solomon at UWISC(Attn: THANKS!) Redistributed-By: ESTEFFERUD at USC-ECL Redistributed-Date: 27 Aug 1983 Not requiring the HELO is definitely a violation of spec and should therefore be strongly discouraged, but what is a server SMTP supposed to do with the info? Specifically, what should it do if: The name given isn't in the host tables? The name is in the host tables, but doesn't correspond to the address at the other end of the TCP connection A "MAIL FROM:" command is issued during the course of the session with a return path that does not indicate the named host as the first step? In general, the various Internet specs are good on indicating what correct behavior is, but quite weak on telling you what to do in response to errors. Obviously, not all possible errors can be anticipated, but a few of the more likely ones should be mentioned. P.S. Does this discussion belong in MsgGroup or HeaderPeople? I can never keep straight the difference. I have the feeling there is a large overlap in membership. In fact the lists may be nearly identical. If so, perhaps they should be merged?  Return-path: Received: from BRL by USC-ECL; Sat 27 Aug 83 08:36:38-PDT Received: From Hi-Multics.ARPA by BRL via smtp; 27 Aug 83 11:21 EDT Date: 27 August 1983 10:17 est From: DBrown.TSDC@hi-multics Subject: HELO from who????? To: MsgGroup@brl Redistributed-To: header-people at MIT-MC Redistributed-By: ESTEFFERUD at USC-ECL Redistributed-Date: 27 Aug 1983 I would suggest that the smtp server not try to concern itself too much with validating names/systems, etc. It is very difficult to get a server to test your new host-table entry for site bar if you have to have a correct host-table entry for bar first. Besides, I have a system that can (and probably will) talk smtp and its NOT where i try to have mail sent. My return address is DBrown.TSDC @ HI-MULTICS.ARPA but my system is Daves_micro @ tsd1.toronto.honeywell (an alias for brown at tsd1...). Probably the best criteria is to regard smtp as a mail-transfer mechanism with optional audit trail, and not a mechanism for data-entry with verification. --dave  Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 27 Aug 83 14:08:07 EDT Date: 27 Aug 83 1412 EDT From: Rudy.Nedved@CMU-CS-A To: Header-People@MIT-MC Subject: HELO, problems & restrictions Message-Id: <27Aug83.141212.EN0C@CMU-CS-A> CMU expects mail to be delivered to the correct person or an error message to be generated within a reasonable amount of time. We always generate a HELO and are starting to check the responses from HELOs since we are hitting various problems: 1) If you send mail to Goonhilly-Echo from a TOPS-20 site the mail loops since you effectively are sending mail to yourself. Checking for "250 " handles this problem very effectively. 2) Sometimes two hosts get their addresses swaps during hardware work or when software people are trying to track down bizzarre problems. This has not happen at CMU but it did happen a year ago when WHARTON and NBS-VMS switched IMP ports. I expect to put that check in a few more months. The protocol seems to indicate that HELO is required and a reliable mail system should generate and check the response. A group of people want the "must say HELO first" restriction coded out and same group of people apparently have not hit certain problems which will require the HELO being generated. Instead of one group coding a restriction out and then another group coding something neccessary in that satisfies the restriction later, why doesn't the latter group do the neccessary coding now? -Rudy  Date: 28 Aug 83 19:22:58 EDT From: Charles Hedrick Subject: problem in mailing to RU-GREEN To: EE.GDS%MIT-OZ@MIT-MC.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Message from "Greg Skinner " of 27 Aug 83 08:51:00 EDT The shortest answer to your problem is that your host table is probably out of date. RU-GREEN is listed in the NIC host table, and has been for some time. We are all awaiting the day when there will be name servers and these problems will go away. How about it, John? I agree that in general, the HELO command is helpful in resolving these cases of out of date host tables, as an earlier message from MRC described. In this particular case, it wouldn't have helped, though, because mail from RU-GREEN is relayed by RUTGERS. So your HELO would have been from RUTGERS. If your mailer had been smart enough to figure out the PATH and reverse it, that would have solve the problem, but I don't think anybody really does that. (I won't bother the whole list with a rehash of why analysizing the path is normally no help, as most of us have been through that many times. If you don't know the sorry tale of why paths can't be used to describe relaying, I'll reply to you directly.) However I thought you might find it helpful for me to describe just what is going on with RU-GREEN, since otherwise your investigations may leave you wondering what we are doing. In fact RU-GREEN is not on the Arpanet. It is connected to RUTGERS by a local network. When the edict came down that paths could not be used to describe non-Internet hosts, we decided that we had to come up with an alternate kludge. So what we did is assign RU-GREEN (and its brother, RU-BLUE) an Internet address. It is now in the NIC host table. The addresses are RUTGERS: 10.2.0.58 RU-GREEN: 10.2.1.58 RU-BLUE: 10.2.2.58 Now the interesting thing about these addresses is that they differ only in the third octet. This is the "logical host" field. Packets intended for all of these addresses get delivered to the same place, which is in fact RUTGERS. RUTGERS is set up to accept packets for any address of the form 10.2.xxx.58. Our servers then have to know what is going on. Our mailer looks at the destination address of your packets (the IP-level address, not the host name from the mail address). It initializes itself so it thinks it is that host. So if you open a connection to 10.2.1.58 you will get a mailer that really thinks it is running on RU-GREEN. All the mail receiver does is create a file in the mail directory. This file contains the place where the mail is to be sent. Since that is RU-GREEN, our normal local mail forwarding gets it to the right place. The net result is that as far as the sender is concerned, RU-GREEN might as well be on the Arpanet. We do not play such games in the other direction. Aside from the fact that we don't have any reason to want to, there would be administrative problems. (DCA approves relaying incoming mail freely, but we have to prevent non-Arpanet hosts from sending outgoing mail freely.) So mail from RU-GREEN will probably have a RETURN-PATH that shows <@RUTGERS:foo@RU-GREEN>. (There will not be a RECEIVED line for the transfer from RU-GREEN to RUTGERS, however, as intersystem transfers involve essentially no processing. We just move the mail file from one system to the other by our local equivalent of FTP.) At the moment, only the mail server knows how to do this kind of thing. If you connect to 10.2.1.58 with FTP, you will get a message like "you have reached a non-working Internet address at Rutgers University. Please hang up and dial again." When the next stage of our networking is completed, we may install an FTP relay. We are probably a year away from a real Internet gateway. (One of the problems is that DEC does not support the gateway function in their TCP, and we are going to let other sites pioneer in that area.) Again, an FTP relay would be incoming-only, for administrative reasons. -------  Return-path: Received: from BRL by USC-ECL; Mon 29 Aug 83 05:17:38-PDT Received: From Sri-Nic.ARPA by BRL via smtp; 29 Aug 83 7:26 EDT Date: Mon 29 Aug 83 02:50:58-PDT From: Henry W. Miller Subject: Re: ISI-VAXA's SMTP sender doesn't say HELO To: DBrown.TSDC@HI-MULTICS.ARPA, MsgGroup@BRL.ARPA cc: Miller@SRI-NIC.ARPA In-Reply-To: Message from "DBrown.TSDC@hi-multics" of Fri 26 Aug 83 09:13:00-PDT Redistributed-To: header-people at MIT-MC Redistributed-To: Miller at SRI-NIC(Attn: THANKS!) Redistributed-By: ESTEFFERUD at USC-ECL Redistributed-Date: 29 Aug 1983 Actually, it was intended to be partially humorous, but, equally as serious. The protocol is defined, and is accepted by most rationial beings. Sooner or later, we all shall have to conform to the spec. -HWM -------  Date: 30 August 1983 13:11 edt From: Greenwald.CSR at MIT-MULTICS Subject: Re: problem in mailing to RU-GREEN To: Charles Hedrick cc: EE.GDS%MIT-OZ at MIT-MC, header-people at MIT-MC, Greenwald at MIT-MULTICS In-Reply-To: Message of 28 August 1983 19:28 edt from Charles Hedrick Re: name servers. Return-Path: <@MIT-MULTICS.ARPA,@MIT-MC:HEDRICK@RUTGERS.ARPA> Received: from MIT-MC by MIT-MULTICS.ARPA TCP; 28-Aug-1983 19:27:47-edt Date: 28 Aug 83 19:22:58 EDT From: Charles Hedrick Subject: problem in mailing to RU-GREEN To: EE.GDS%MIT-OZ@MIT-MC.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Message from "Greg Skinner " of 27 Aug 83 08:51:00 EDT The shortest answer to your problem is that your host table is probably out of date. RU-GREEN is listed in the NIC host table, and has been for some time. We are all awaiting the day when there will be name servers and these problems will go away. How about it, John? This seems to come up about once every couple of months. IEN-116 style name servers exist. They have existed for at least three years. They still exist. There is software that has been using them for over three years. Now IEN-116 name servers might not meet your approval - hell, they don't meet mine - but they are useable. Name servers exist on at least the following machines: MIT-XX, MIT-Multics, MIT-Spooler (18.2.0.128), SRI-NIC, BBNA, HI-Multics, RADC-Multics, DCN1 (? Maybe not this one, but at least one of Dave Mills' fuzzballs). ... and more... - Mike Greenwald (For historical reasons some of the Multics name servers might be on port 14 instead of port 42. Most of these are UDP based name servers. I think the one on the NIC is also TCP based.)  Date: 30 Aug 1983 17:19:28 PDT From: MILLS@USC-ISID Subject: Re: problem in mailing to RU-GREEN To: Greenwald.CSR@MIT-MULTICS, HEDRICK@RUTGERS cc: EE.GDS%MIT-OZ@MIT-MC, header-people@MIT-MC, cc: Greenwald@MIT-MULTICS, MILLS@USC-ISID In response to the message sent 30 August 1983 13:11 edt from Greenwald.CSR@MIT-MULTICS Mike, IEN-116 name servers MIT-XX, DCN1, NIC, ISIF, BBNA and BBNG barked when I called just now, along with PURDUE and a Honeybunch or two, but the latter on the "wrong" port. DCN1 does the name server do, as well as a mean IEN-142 clock, but is updated by hand only once every fortnight or so. NIC has been the host of choice and has been very reliable. Dave -------  Date: 30 Aug 1983 2037-EDT From: Greg Skinner Subject: Re: problem in mailing to RU-GREEN To: Greenwald.CSR@MIT-MULTICS cc: HEDRICK@RUTGERS, header-people@MIT-MC In-Reply-To: Your message of 30-Aug-83 1311-EDT ok ... but in my case, the return path was Return-path: not Return-path <@BRL:@rutgers> or even Return-path: <@MIT-MC:@BRL:@rutgers> Now in the case of chaosnet mail transfers, if I send something onto the arpanet it'll look like Return-path: <@MIT-MC:EE.GDS@MIT-OZ> I believe, so there's a chance someone on the arpanet can get something back to me. In the above cases, I couldn't get the message back to RUTGERS even, let alone RU-GREEN. According to what you're saying, as long as I can get the reply back to RUTGERS, RUTGERS mail software can relay it to RU-GREEN. Seems like BRL is actually remailing the message, not forwarding it, thereby msggroup-request@BRL is becoming the recipient of the reply intended for the sender at RUTGERS. I don't know if this is a bug or not, but it's an interesting problem especially with distribution-lists, which are the least likely to be stable in a distributed environment. Maybe there should be an RFC on distribution lists? greg -------  Date: 30 Aug 83 21:15:10 EDT From: Charles Hedrick Subject: Re: problem in mailing to RU-GREEN To: EE.GDS%MIT-OZ@MIT-MC.ARPA cc: Greenwald.CSR@MIT-MULTICS.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Message from "Greg Skinner " of 30 Aug 83 20:37:00 EDT I think it is a matter of taste as to whether the return-path shows the original author or the mailing list. The advantage to pretending that it is a remailing is that error messages (no such user at this site, ...) go back to the list maintainer instead of the original sender, who may not be able to do anything about it. I think that makes a lot of sense. However if this is done, there should probably be something like ORIGINAL-PATH:. -------  Date: Tue, 30 Aug 83 21:17:04 EDT From: Ron Natalie To: Greg Skinner cc: Greenwald.CSR@mit-multics, HEDRICK@rutgers, header-people@mit-mc Subject: Re: problem in mailing to RU-GREEN Our mailing list processor on the BRL uses something like MAIL FROM:<@BRL:LIST-REQUEST@BRL> in the SMTP dialog. The "MAIL" command is documented in RFC821 as being the route to send non-delivery notices. It goes on to say that "in some types of error reporting messages (for example, undeliverable mail notifications) the reverse path may be null." This means that the whole purpose of MAIL FROM is disposition of error messages relating to non-delivery. Our list processor changes this to the LIST-REQUEST address so that the list maintainer gets the failed mail notices right away (used to be that we had to wait until someone else called a failure to our attention or we actually mailed a letter out on the list and had it fail) and the a submitter to the list not get the typical 3 or 4 mail failures that happen even on a good day when he submits an item. -Ron INFO-MICRO-REQUEST, INFO-CPM-REQUEST, INFO-MUSIC-REQUEST  Date: 30 Aug 1983 2059-EDT From: Greg Skinner Subject: Local-area forwarding To: hedrick@RUTGERS, greenwald@MIT-MULTICS, header-people@MIT-MC (That's what I'm going to call it now.) Just tried it again, replying to a msg from ron@brl-vgr, and again, it refused brl-vgr as a known host. OZ is using the 7/28 host tables and they do, indeed, contain brl-vgr. (They probably contain RU-GREEN also, since I believe the same file is on XX.) Anyway, the curious fact in this case is that the return path was Comments? greg -------  Date: Tue, 30 Aug 83 22:30:38 EDT From: Doug Kingston To: Greg Skinner cc: Greenwald.CSR@mit-multics, HEDRICK@rutgers, header-people@mit-mc Subject: Re: problem in mailing to RU-GREEN I can shed some light on the RU-GREEN reply situation as it relates to the forwarding through BRL. Msggroup is a large mailinglist maintained on the BRL host. In order to efficiently process the Msggroup mail, the list is processed by our "list-processor" channel of MMDF. This channel handles the address-list verification in the background, but it also changes the return address given to us via the "MAIL FROM:" SMTP command. The return address is changed to contain the Msggroup-Request address in order to route all the automatic return messages to go to the list maintainer instead of the list contributers who can do nothing about mailing list problems. The new return address is only used to change the "MAIL FROM:" command when we pass the message on to others. The text of the message and the header are NOT changed to reflect this new return address. This prevents hundreds of annoying messages from being sent to list contributors and routes most of them to someone in a position to handle them properly (the -requests mailboxes). Cheers, -Doug-  Date: 2 September 1983 01:14 edt From: Greenwald.CSR at MIT-MULTICS Subject: Help! To: header-people at MIT-MC I'm not certain why I am being CC'd on every message to header people these days (Most of these messages don't seem to be in response to the neutral little note I sent - which only gently reminded people that name servers do exist). My mailbox is being inundated with mail. I can usually deal with multiple copies of things, but I am about to take off for a couple of days and multics is fairly strict about quota. If my mailbox overflows with duplicates, I lose all my legitimate mail. Please, please, clean me out of your messages before I am swamped. Sorry to bother everyone about this. - Mike Greenwald  Date: 4 September 1983 19:52 est From: DBrown.TSDC at HI-MULTICS Subject: Forwarding or remailing? To: Header-People at MIT-MC It strikes me that MsgGroup@BRL.ARPA is really remailing messages, to ensure that the inevitable error messages come to the list maintainer and not the poor fellow who mailed the message in the first place. This raises two questions: (1) is that a good thing to do, and (2) are we really handling errors properly in smtp. At the moment I think accepting a message at the home of a mailing list (thereby accepting responsability for it) and remailing it with a different return address is probaly a *good thing*. I suspect that the smtp definition really only concerned itself with what happened when the sender's host failed to transfer the message to the recipient's host, and not what happends when a host several hops away (either in another net or after list expansion/remailing) fails. Not unreasonable, considering that there weren't all that many nets at the time, but probably undesirable now. Any suggestions on what one "should" do in the way of returning an error letter to the sender? (I'll air my prejudices after a few people have had a chance to reply). --dave DBrown.TSDC @ HI-MULTICS.ARPA drbrown @ watbun.UUCP (decvax!watmath!watbun!drbrown)  Date: Sun, 4 Sep 83 21:17:13 EDT From: Farber Return-Path: Subject: IEEE Computer Society Mail service Received: from udel-ee by udel-relay.ARPA ; 4 Sep 83 21:19:45 EDT (Sun) To: header-people%mit-mc.arpa@udel-ee The following will appear in the September Computer Magazine of the IEEE Computer Society. ____________________________________________________________________ COMPMAIL+ Computer communications for today's computer professional Offered by the IEEE Computer Society. Using COMPMAIL+ you can: 1. Communicate via electronic mail with your col- leagues - one-on-one, or in electronic mail confer- ences. Either way, there's no more postal system delays, no more "telephone tag." 2. Access Computer Society listings of upcoming con- ferences, publications and technical activities. 3. Scan the complete, up-to-the-minute list of Com- puter Society Press publications. 4. Speed up your Computer Society publications orders and conference registrations by ordering on-line and charging to your credit card. On-line book orders are shipped in 48 hours; conference registrations are processed in 24 hours. 5. Locate your colleagues in the system by accessing a complete on-line directory of all COMPMAIL+ users. 6. Post your own messages to - and scan - a soci- ety-wide electronic bulletin board. 7. Set up your own executive calendar system: sched- ule meetings, display your own open time slots, and scan colleagues schedules for open time slots. 8. Access state, national, and international newswires. Scan the headlines, or do keyword inquiries. 9. Obtain current stock, bond, and commodity quotes. 10. Use the on-line Official Airline Guide to obtain current flight schedules and fares. 11. Utilize a wide range of programs in the system library (over 200), ranging from finance and statisti- cal routines to games. 12. Create your own programs and data files using compilers and the database management system resident on COMPMAIL+. And remember: this is just a partial list of the tools and facilities available through COMPMAIL+ right now. Even more will be available in the future. Easy to use To assure maximum access for all society members, COMPMAIL+ is available via Telenet, Tymnet, or Uninet. All you need is a telephone, a modem, and a terminal or microcomputer capable of communicating via ASCII protocols over telephone lines. When you log on you'll see a complete menu of available services, together with extensive on-line help commands and functions. There's even a special HELP mailbox in case you run into a problem, and a SUGGESTION mailbox in case you think of enchancements that will make the system even more useful to Computer Society Members. Low Cost For most COMPMAIL+ services, the basic rate is an hourly connect charge that varies by time of day. In addi- tion, there is a communications charge that varies by time of day and by the particular network you select (Telenet, Tymnet or Uninet). The following sample rates cover basic electronic mail and communications assuming you access COMPMAIL+ via Telenet: Prime Time (8:00 a.m.* to 6:00 p.m., $16/hour Monday through Friday) Off-Prime (6:01 p.m. to 9:00 p.m., $7/hour Monday through Friday; and 8:00 a.m. to 9:00 p.m., Saturdays, Sundays, and holidays) Nighttime (9:01 p.m. to 7:59 a.m. daily) $6/hour * Times are based on Eastern Time. If you use the filing capability of the system there is a small storage charge (40 cents per 2048-byte storage unit per month). There are surchages for use of some of the special services such as the OAG and news or stock quotation systems. Finally, if you use the system for programming or database applications, there are CPU-time-and-storage charges. A complete schedule of rates for all services will be sent to all new subscribers, so you'll know exactly what each service costs before you use the system. Best of All ... * There's no start-up or enrollment charge. * As a special introductory offer, you'll receive a $30 credit toward your use of the basic COMPMAIL+ services (items 1 through 7 above).  Date: Mon 5 Sep 83 13:06:58-PDT From: David Roode Subject: Re: Forwarding or remailing? To: DBrown.TSDC@HI-MULTICS, Header-People@MIT-MC In-Reply-To: Message from "DBrown.TSDC at HI-MULTICS" of Sun 4 Sep 83 19:52:00-PDT Location: EJ286 Phone: (415) 859-2774 Postel had a proposal some time back to add an "Errors" header to messages which could direct errors as desired. Here at the NIC, we habitually send messages to hundreds of people at a time, and it would be a really useful feature to direct the errors from each mailing to a special place. I earnestly urge the establishment of this "errors" header right away. -------  Date: Mon, 5 Sep 83 13:40 PDT From: Taft.PA@PARC-MAXC.ARPA Subject: Re: Forwarding or remailing? In-reply-to: "ROODE@SRI-NIC.ARPA's message of Mon, 5 Sep 83 13:06:58 PDT" To: Header-People@MIT-MC.ARPA I think we've beaten this issue to death already. But let me try to reiterate. I also suggest that people re-read carefully the relevant sections of RFCs 821 (4.1.1: MAIL command) and 822 (4.4: originator fields). These protocols already have the needed mechanisms, and there is no need to invent any more. Of particular interest is the "sender", identified in the MAIL FROM field on the envelope (RFC 821) and by the SENDER field in the contents (RFC 822). This is the agent responsible for actually causing the message to be sent (as opposed to the originator of the message), and to whom transport and delivery failure notifications should be sent. If a message is redistributed to some list of recipients and it is deemed desirable for failure notifications to be sent to the maintainer of the list, that maintainer should be identified as the "sender" when the message is resubmitted for transport and delivery to the new recipients. That is what the "sender" is for; it serves no other purpose. The problem with the proposal to add an ERRORS-TO field, aside from its redundancy, is that it would appear only in the contents (RFC 822 header) and not on the envelope (RFC 821). It is totally unreasonable (and a violation of protocol layering) for transport and delivery mechanisms to have to look at the contents of a message in order to determine where to send it when a failure occurs. Ed Taft  Date: Mon 5 Sep 83 16:06:11-PDT From: Mark Crispin Subject: Re: Forwarding or remailing? To: Taft.PA@PARC-MAXC.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "Taft.PA@PARC-MAXC.ARPA" of Mon 5 Sep 83 13:53:43-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I am in total and complete agreement with Ed Taft. Even if somebody in a moment of foolishness were to define an Errors header I seriously doubt I would ever implement it in the TOPS-20 mailsystem. It is bad enough that operational considerations still dictate that one has to parse the RFC 822 (header) information at the RFC 821 (transport) level, but one can see the gradual obsolescence of that technique. For your enjoyment, the TOPS-20 mailer tries to use whatever information is available from the transport level. Failing that, it parses the header in the order: ReSent-From Remailed-From (pre-822 version of ReSent) Redistributed-From (ditto) Sender From Reply-To Mail-From A purist may argue that ReSent-Sender should be in the list too as highest priority. But, increasingly the header parse code is never being called for 821 mailing, only on other networks where the tranport doesn't specify the sender. -------  Date: Mon 5 Sep 83 17:07:02-PDT From: David Roode Subject: senders, originators and relays To: Header-People@MIT-MC Location: EJ286 Phone: (415) 859-2774 Consider: 1. When the BRL mailer alters the RETURN-PATH to point to the intermediary, it does not add a SENDER: header to the message. 2. Crispin points out that he does not consult any existing headers when delivering errors for mail which has the MAIL FROM:<> command filled in. Won't this lead to mismatch between supposedly equivalent things? 3. In the TOPS-20 mailsystem, when you cause a "SENDER:" header to be generated by specifying the contents of the "FROM:" header, automatically, a "REPLY-TO:" header is generated to match the "SENDER:" header. There needs to be a convenient way to leave this off if the functionality of separating error reports from replies is to be achieved. Also, there is no way to set the SENDER to say "HEADER-PEOPLE-REQUEST@MIT-MC" because it is forced to be the user logged in sending the message. 4. With BRL's current scheme, there is no way for me to say "I want to see the error reports." 5. With the TOPS-20 mailer's current scheme, there is no way to say "I do not wish to see the error reports." My purpose is not to criticize any mailing system, but rather to illustrate there are implementation-dependent differences that ought perhaps to be consistent across implementations. -------  Date: 5 Sep 83 21:27:28 EDT From: Charles Hedrick Subject: RFC's XXX, YYY, and ZZZ To: header-people@MIT-MC.ARPA I trust the moderator will tell me if this is not the right place to be discussing this topic. There seem to be at least three almost indistinguishable mailing lists. I have read RFC's XXX, YYY, and ZZZ. In general I am quite impressed with the amount of work that has gone into them, and the number of problems they will handle. I had a few minor editorial comments, which I have sent directly to Postel. However I do think there is one fairly serious issue. The formats for requests and responses to domain servers are essentially binary. This will be the first time an Arpanet protocol has been defined that way. Indeed a number of us consider that the fact that RFC821/822 define all commands and headers as text is a significant advantage over the NBS proposal. I would like to hear why the designers of RFCZZZ have gone to binary. I think previous discussions of mail have made the advantages of text clear: - it is easier to handle them in many high level languages - it is easier to add new options and arguments, since the command structure is free-field rather than fixed. (NBS has at least tried to answer this by allowing for user-defined options at every level, but if different vendors have to talk to each other, then there will be conflicts among their uses of the user-defined codes. This is far less likely when we are dealing with keywords, as the address space of English verbs is larger than an octet.) - it is easier to debug commands that are given as text, since a human can read them. You can also put them into log files with minimal processing, to allow for later diagnosis. - you can pass text through ASCII/EBCDIC converters if necessary. I can understand that both Arpa and other developers are concerned about allowing for graphics and digitized voice. Thus I can understand that protocols will tend to evolve towards having certain fields be able to handle arbitrary contents. I am not convinced that the domain server is the best place to start this. (Probably we would like to have digitized voice in the body of the message before we allow it for host names. I don't think our domain servers are likely to be able to parse voice for some time.) But even if it were, I think it would be sufficient for the formats to allow for arbitrary strings of octets, probably with a short header to indicate what it is. I don't know how this would apply to the domain server (as I still think host and user names should continue to be text), but it wouldn't be hard to dream up a header that goes at the beginning of a field and says "the following field is 25 octets of digitized voice": RFC822: from: hedrick@rutgers to: postel@isif subject: ~D,25:!"#$%678^Ajkl789^CUIOXlkjkjkljlk This assumes that ~D is a special marker indicating a digitized voice field, in this case 25 octets. I am sure further thought will elicit less kludegy ways of doing this, without requiring us to go to NBS or RFCZZZ. -------  Date: 5 Sep 83 21:41:24 EDT From: Charles Hedrick Subject: PS about digitized voice To: header-people@MIT-MC.ARPA I did not mean to imply that I had any very good ideas about digitized voice. In fact I do not. My real view is that I would like to see it tried our experimentally before we start modifying our productionn protocols to take it into account. I was just trying to point out that it seems just as plausible to believe that we can extend a protocol like RFC822 to handle voice as one like NBS. Actually, I suspect people may find voice and video somewhat less useful than they expect. Consumers have rejected the use of voice in home appliances. Every review I have seen of hi-tech automobiles has considered its use in automobiles an annoyance. It is not clear to me that I want my terminal talking to me, except in somewhat specialized circumstances. Graphics inside messages does seem useful. However there we are far more likely to want it in the middle of a piece of text than to want a whole field of that type (which is what NBS assumes). -------  Date: Mon 5 Sep 83 18:19:24-PDT From: Mark Crispin Subject: Re: senders, originators and relays To: ROODE@SRI-NIC.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "David Roode " of Mon 5 Sep 83 17:22:57-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) From: David Roode 1. When the BRL mailer alters the RETURN-PATH to point to the intermediary, it does not add a SENDER: header to the message. [I don't see anything wrong with that. BRL is performing the service of altering the address where errors go to, by deliberate and desirable intent. There is nothing in the standard that requires that Sender equal Return-Path.] 2. Crispin points out that he does not consult any existing headers when delivering errors for mail which has the MAIL FROM:<> command filled in. Won't this lead to mismatch between supposedly equivalent things? [The correct behavior would be NEVER to consult existing headers. If the Return-Path is null, errors should go into a black hole. The only reasons the TOPS-20 mailsystem consults headers at all are that certain (bogus) SMTP implementations always transmit a null return path and that certain non-Internet networks have no way of specifying Return-Path in their transmission protocol. I hope to see an end to those reasons (and of parsing headers at the transport level) in the very near future.] 3. In the TOPS-20 mailsystem, when you cause a "SENDER:" header to be generated by specifying the contents of the "FROM:" header, automatically, a "REPLY-TO:" header is generated to match the "SENDER:" header. There needs to be a convenient way to leave this off if the functionality of separating error reports from replies is to be achieved. [I don't see why this is germaine to the topic under discussion or to Header-People in general, but I'll answer it anyway. MM's function of specifying an arbitrary From line is a power tool that performs no validity checking. It was designed in RFC 733 days when the From line was not required to contain a mailbox. As MM had no way of knowing whether or not the user's From was replyable, it generated a Reply-To by default. In 733 days this guaranteed a valid message header, unless the user also used the power tool to set an arbitrary Reply-To as well. 822 removed that protection; I'm not sure 822 was an improvement in that regard. But the power tools are still valuable enough (especially for experimental electronic mail applications) that they remain as they presently are. However, that isn't relevant to the issue of generating a Return-Path, which is always derived from the physical sender of the message (not the Sender which can be forged). If you're trying to suggest to me that I implement a functionality to generate alternate Return-Path's, sending to Header-People is not a good way of doing it.] Also, there is no way to set the SENDER to say "HEADER-PEOPLE-REQUEST@MIT-MC" because it is forced to be the user logged in sending the message. [The Sender should be the physical sender. It can be forged because it is added at message composition level. That is why the mail transport level has its own idea of Sender. But those two ideas are different from Return-Path. Therefore it is wrong to change the Sender.] 4. With BRL's current scheme, there is no way for me to say "I want to see the error reports." [You don't have to mail via BRL. You can get a copy of the mailing list and have your system undertake to deliver the messages itself.] 5. With the TOPS-20 mailer's current scheme, there is no way to say "I do not wish to see the error reports." [Once again, Header-People is not the forum to suggest a new functionality in the TOPS-20 mailsystem.] -------