Acknowledge-To: "Benson I. Margulies" Date: Sun, 18 Mar 84 17:25 EST From: "Benson I. Margulies" Subject: Rochester SMTP server complaint To: Postmaster@ROCHESTER.ARPA, Liason@ROCHESTER.ARPA cc: header-people@MIT-MC.ARPA Message-ID: <840318222540.999839@MIT-MULTICS.ARPA> VRFY appears to eat ANYTHING, valid, deliverable, or not. So does EXPN.  Date: Tue, 20 Mar 84 11:06:09 GMT From: Steve Kille To: postel@usc-isif.arpa cc: header-people@mit-mc.arpa Subject: dhosts.txt I note that the new format nhosts.txt contains only the official name with .ARPA appended (e.g. it has USC-ISID.ARPA but not ISID.ARPA). It would be more helpful (to our system at least), if the set of entries were orthogonal. Steve  Date: Tue, 20 Mar 84 16:28 EST From: Network_Server.Daemon@MIT-MULTICS.ARPA (mmdf@Ucl-Cs.ARPA@Ucl-Cs) Message-ID: <840320212813.970083@MIT-MULTICS.ARPA> Resent-Date: 20 Mar 84 17:55 EST Resent-From: "Benson I. Margulies" Resent-To: header-people@MIT-MC.ARPA Resent-Comment: Anybody know what provoked THIS? Resent-Message-ID: <840320225523.986628@MIT-MULTICS.ARPA> Return-Path: <@MIT-MULTICS.ARPA,@Ucl-Cs:mmdf@Ucl-Cs.ARPA> Received: from Ucl-Cs by MIT-MULTICS.ARPA TCP; 20-Mar-1984 16:28:07-est Received: from rlgk.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 20 Mar 84 19:48 GMT To: "Benson I. Margulies" , ZUXA.UCL-CS.FTP@ucl-cs.arpa MMDF-Warning: Parse error in preceding line at 44d.Ucl-Cs.AC.UK Date: Tue, 20 Mar 84 12:50 GMT References: <840318222540.999839@MIT-MULTICS.ARPA> Message-Id: <20 MAR 1984 12:50:32 NSAU01@RLGK> Subject: Message acknowledgement Authentic-sender: NSAU01@RLGK Your message dated Sun, 18 Mar 84 17:25 EST Subject "Rochester SMTP server complaint", has been accepted by user Neil Davies (on GEC 4090 at Rutherford) using Mail Vn 3  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA04113; Tue, 20 Mar 84 15:22:57 pst Received: by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.14.4) id AA06664; Tue, 20 Mar 84 15:23:02 pst Message-Id: <8403202323.AA06664@ucbjade.CC.Berkeley.ARPA> Date: Tue, 20-MAR-1984 18:10 EST From: Ronald A. Jarrell To: Margulies@Mit-Multics.ARPA Cc: Header-People@mit-mc.ARPA Reply-To: TSDTEST%VPIVAX3.BITNET@BERKELEY.ARPA Subject: ack's.. Moral of the story: Don't try to get an Ack across the network. You never know what might turn up... Ron Jarrell  Date: Wed, 21 Mar 84 09:59 EST From: "Benson I. Margulies" Subject: re: that amazing ack To: header-people@MIT-MC.ARPA Message-ID: <840321145911.850332@CISL-SERVICE-MULTICS.ARPA> 1) Once again, the distinction between a mailing list and a redistributor rears it head. I think header-people should ack mail, not the individuals. 2) Something is wrong with that header (MMDF seems to agree) such that our mail server rejected it, so I did not immediately see the subject and detect that it was an ack.  Date: Wed, 21 Mar 84 12:12 EST From: "Benson I. Margulies" Subject: That ferocious ack To: header-people@MIT-MC.ARPA Message-ID: <840321171211.369245@CISL-SERVICE-MULTICS.ARPA> The local SMTP maintainer points out that that so-called ack has neigher a From nor a Sender field, and is therefore invalid. Would the responsable implementation (COM?) stand up?  Date: Wed, 21 Mar 84 18:09:07 GMT From: Steve Kille To: "Benson I. Margulies" cc: header-people@mit-mc.arpa Subject: Re: That ferocious ack For its sins, "Acknowledge-To:" is specified by the JNT Mail protocol as generating an end to end acknowlegement. There are dire warnings about its use with distribution lists. The element is intended for human rather than machine processing (i.e. to give confidence as to a messages arrival). Many UK sites would send an ack if such a field is in the original message. UCL will send one ONLY if the message arrives by the JNT Mail Protocol. Steve  From: Christopher A Kent Message-Id: <8404041704.AA07376@merlin.ARPA> Received: by merlin.ARPA; Wed, 4 Apr 84 12:04:05 est Date: 4 Apr 1984 1204-EST (Wednesday) To: cowan@udel-relay.ARPA, postmaster@udel-relay.ARPA Subject: losing header munging at udel relay Cc: header-people@mc.ARPA, cic@csnet-cic.ARPA (Background -- purdue-merlin is acting as a mail relay on behalf of decwrl until their X.25/IP connection is fully straightened out.) I recently saw a message in my outbound mail queue with a recipient of <@Purdue-Merlin.ARPA:hobday@algol.dec-marlboro.ARPA>. This looked rather bogus, so I thought I'd dig into it a bit farther. I looked at the header file (not the data, of course), and found that the message had the following lines: From: Ken Cowan To: Ken Hobday ZKO2-3/K23 881-2214 Hmm. How did that get turned into the recipient above? Decwrl is acting as a mail relay for the DEC Engineering network, and uses the .DEC domain internally to indicate this. (Several internet sites currently understand that the .DEC domain is handled by decwrl, by the way.) However, "dec" is also a nickname for "dec-marlboro" in the NIC host table. So it looks like udel-relay, which runs MMDF, is peeking at the left hand side of headers not destined for itself and munging them (for shame!). I know that it used to use the . specifier as an indicator that this should be relayed (this from the old phonenet software), and MMDF has this wonderful habit of expanding nicknames (and capitalizing host names!) in headers that it munges.... So that's what I think happened. Udel-relay peeked at the header and munged it as if it were relaying the note, but it doesn't really end up being relayed after all. The letter didn't make it through. Would the postmaster at Udel-Relay please fix this bogosity? Would other folks running the same mail software (you presumably know who you are) check to make sure that you're not doing the same thing? Cheers, chris ----------  Date: 6 Apr 1984 08:34:14 PST From: POSTEL@USC-ISIF Subject: name@XEROX To: header-people@MIT-MC Date: 6 Apr 84 08:11:21 PST (Friday) From: owen.PA@Xerox.ARPA Subject: name@XEROX Hi, Arpanet address name change. "...New Gateway (Xerox.ARPA) For many years, MAXC has been our connection to the Arpanet. Although it has served us well, we are planning to retire it. The new Arpanet mail gateway code now runs on a Dorado computer in the Cedar environment. Telnet and FTP are still available through MAXC but will be supported by other facilities in the near future. Please replace "Name@PARC-MAXC" or "Name@PARC" with "Name@Xerox" in future Arpanet correspondence. Persons in charge of distribution lists should update their lists accordingly. ..." meg -------  Delivery-Date: 9 Apr 84 09:18 EST Delivery-By: Network_Server.Daemon@MIT-MULTICS.ARPA (msggroup-request@BRL-MIS.ARPA@BR) Date: Fri, 6 Apr 84 15:03 EST From: Liudvikas Bukys Subject: looking for etiquette documents To: MsgGroup@BRL.ARPA Message-ID: <8404062003.10794@SEN.ROCHESTER> Resent-Date: 9 Apr 84 09:46 EST Resent-From: Steven Schwartz Resent-To: header-people@MIT-MC.ARPA Resent-Message-ID: <840409144641.104484@MIT-MULTICS.ARPA> Can anyone direct me to a "network mail etiquette" document suitable for instruction of new users? I'm looking for something more fleshed-out than "no commercial use, no vulgarity, no chain letters". I already have a copy of "Emily Post for Usenet". I'm looking for something with an Arpanet orientation. Liudvikas Bukys bukys@rochester.arpa  Date: Wed 11 Apr 84 04:46:56-EST From: Greg Skinner Subject: Re: losing header munging at udel relay To: header-people@MIT-MC.ARPA In-Reply-To: Message from "Christopher A Kent " of Wed 4 Apr 84 12:04:00-EST I have noticed a similar obscurity: when a mail message passes between decwrl and rhea (as in a UUCP <--> DEC ENET mail message with a pathname ...!decwrl!rhea!...), the headers are munged(?) to look like: Received: from DECWRL.ARPA by RHEA.ARPA with where as I understand it, Rhea should be Rhea.DEC. When attempting to send mail through RICE-RHEA (that's what RHEA.ARPA) is, I got undeliverable mail messages stating that the host was down or not accepting mail. Curiouser and curiouser ... -------  Date: Wed 11 Apr 84 07:24:34-EST From: covert%castor.DEC@Purdue-Merlin.ARPA Subject: Re: losing header munging at udel relay Sender: RSX-DEV@DEC-MARLBORO.ARPA To: Gds@MIT-XX.ARPA cc: header-people@MIT-MC.ARPA Reply-To: covert%castor.DEC@Purdue-Merlin.ARPA In-Reply-To: Message from "Greg Skinner " of Wed 11 Apr 84 04:48:59-EST UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" The addition of the spurious ".ARPA" seems to be a "feature" of all 4.2 BSD Unix mailers, added to be sure that the now required ".ARPA" is there. There was some discussion a while back (either here on on USENET; I've forgotten where) about how this was hard-coded into the 4.2 BSD mailer. -------  Date: Wed, 11 Apr 84 08:18 EST From: Dennis Rockwell Subject: Re: losing header munging at udel relay To: Greg Skinner , header-people@MIT-MC.ARPA Cc: postmaster@decwrl Yes, RHEA.ARPA is RICE-RHEA, and is a completely different host from decwrl!rhea. The reason mail doesn't get through to RICE-RHEA is that they are on a net that is unknown to the core gateways at this point. Of course, when domains are real, this name collision will go away, right, folks? Right?  Date: Wed 11 Apr 84 23:12:40-PST From: David Roode Subject: observation To: Header-people@MIT-MC.ARPA Location: EJ286 Phone: (415) 859-2774 The headers on the following message display a nightmarish combination of domain-style host names and routing-style recipient addresses. I cannot help making this observation. A previous message referred to confusion between RHEA.DEC and RHEA.ARPA (RICE-RHEA). What gives the domain "DEC" legitimacy? Return-Path: <@MIT-MC:RSX-DEV@DEC-MARLBORO.ARPA> Received: from MIT-MC by SRI-NIC.ARPA with TCP; Wed 11 Apr 84 04:40:06-PST Date: Wed 11 Apr 84 07:24:34-EST From: covert%castor.DEC@Purdue-Merlin.ARPA Subject: Re: losing header munging at udel relay Sender: RSX-DEV@DEC-MARLBORO.ARPA To: Gds@MIT-XX.ARPA cc: header-people@MIT-MC.ARPA Reply-To: covert%castor.DEC@Purdue-Merlin.ARPA In-Reply-To: Message from "Greg Skinner " of Wed 11 Apr 84 04:48:59-EST UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" -------  From: Christopher A Kent Message-Id: <8404121537.AA15118@merlin.ARPA> Received: by merlin.ARPA; Thu, 12 Apr 84 10:37:30 est Date: 12 Apr 1984 1037-EST (Thursday) To: David Roode Cc: Header-people@MIT-MC.ARPA Subject: Re: observation In-Reply-To: Your message of Wed 11 Apr 84 23:12:40-PST. <8404120713.AA17639> Note that the DEC domain appears only on the left hand side of the @, so it's a local convention. I haven't seen any letters come out that have just "user@host.DEC" as the return address, and I don't expect to until (if) .DEC becomes a top-level domain. It's really unfortunate that a) DECNET uses :: as the user/host separator, and b) rfc822 is so written that this can't be properly parsed. Return-Path: <@MIT-MC:RSX-DEV@DEC-MARLBORO.ARPA> Received: from MIT-MC by SRI-NIC.ARPA with TCP; Wed 11 Apr 84 04:40:06-PST Date: Wed 11 Apr 84 07:24:34-EST From: covert%castor.DEC@Purdue-Merlin.ARPA Subject: Re: losing header munging at udel relay Sender: RSX-DEV@DEC-MARLBORO.ARPA To: Gds@MIT-XX.ARPA cc: header-people@MIT-MC.ARPA Reply-To: covert%castor.DEC@Purdue-Merlin.ARPA In-Reply-To: Message from "Greg Skinner " of Wed 11 Apr 84 04:48:59-EST UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" ----------  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA10440; Thu, 12 Apr 84 12:17:58 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.16) id AA16572; Thu, 12 Apr 84 12:18:51 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.16) id AA28059; Thu, 12 Apr 84 12:03:26 pst Date: Thu, 12 Apr 84 12:03:26 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8404122003.AA28059@ucbopal.CC.Berkeley.ARPA> To: Header-people@MIT-MC.ARPA Subject: Re: observation In reply to: Date: Wed 11 Apr 84 23:12:40-PST From: David Roode Subject: observation To: Header-people@MIT-MC.ARPA Location: EJ286 Phone: (415) 859-2774 The headers on the following message display a nightmarish combination of domain-style host names and routing-style recipient addresses. I cannot help making this observation. A previous message referred to confusion between RHEA.DEC and RHEA.ARPA (RICE-RHEA). What gives the domain "DEC" legitimacy? Return-Path: <@MIT-MC:RSX-DEV@DEC-MARLBORO.ARPA> Received: from MIT-MC by SRI-NIC.ARPA with TCP; Wed 11 Apr 84 04:40:06-PST Date: Wed 11 Apr 84 07:24:34-EST From: covert%castor.DEC@Purdue-Merlin.ARPA Subject: Re: losing header munging at udel relay Sender: RSX-DEV@DEC-MARLBORO.ARPA To: Gds@MIT-XX.ARPA cc: header-people@MIT-MC.ARPA Reply-To: covert%castor.DEC@Purdue-Merlin.ARPA In-Reply-To: Message from "Greg Skinner " of Wed 11 Apr 84 04:48:59-EST UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" ------- I don't see any problem with the above header. The "DEC" is part of the local address (not the domain). The UUCP-address and ENET-address fields are user comments since they are not defined in RFC-822. What the problem? Assuming the gateway from DEC to ARPA mail domain puts the DEC address in the Internet local address and adds a valid Internet domain name to the right of the "@" there is no problem for the Internet mail world. Bill Wells wcwells@Berkeley.ARPA  Received: from RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.15) id AA12194; Thu, 12 Apr 84 12:49:48 pst Message-Id: <8404122049.AA12194@decwrl.ARPA> Date: 12-Apr-1984 1548 From: covert%castor.DEC@decwrl.ARPA (John Covert) To: header-people@mit-mc.ARPA Subject: What DEC domain? In the address "covert%castor.DEC@Purdue-Merlin.ARPA" I don't see a DEC domain. The ".DEC" appears in the local part, and is therefore perfectly legit. /john  Date: Thu 12 Apr 84 20:02:49-PST From: David Roode Subject: Re: What DEC domain? To: covert%castor.DEC@DECWRL.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Message from "covert%castor.DEC@decwrl.ARPA (John Covert)" of Thu 12 Apr 84 15:48:00-PST Location: EJ286 Phone: (415) 859-2774 OK, OK, the ".DEC" is "legit." The address is nevertheless complicated. There are 5 parseable tokens separated by 3 different delimiters. I just hope this is the darkness before the dawn, and we don't soon see 8 tokens and 6 different delimiters in the address. -------  Date: 14 Apr 1984 03:17:32-EST From: allegra!hou3c!burl!we13!ihnp4!cbosgd!mark at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA21423; Sat, 14 Apr 84 01:17:18 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP From: allegra!cbosgd!mark (Mark Horton) Subject: Re: observation Message-Id: <1260@cbosgd.UUCP> Date: Thu, 12-Apr-84 17:32:01 EST Received: by hou3c.UUCP; Fri, 13-Apr-84 01:34:14 EST References: <459@hou3c.UUCP> In-Reply-To: <459@hou3c.UUCP> Organization: AT&T Bell Laboratories, Columbus What gives the domain "DEC" legitimacy? DEC is as legitimate a domain as any of the others (UUCP, CSNET) that are currently being used. ARPA is not recognizing any domains other than ARPA right now, although they have published dates by which they are willing to consider them. However, these domains exist and are being used, whether or not ARPA recognizes them. That particular message header you showed had the DEC domain entirely hidden on the LHS, e.g. From: covert%castor.DEC@Purdue-Merlin.ARPA This is entirely within 822 guidelines even if DEC is not known on ARPA, as long as Purdue-Merlin knows how to gateway it. From all appearances, the gateway is doing fine. Mark Horton  Return-Path: Received: from csnet-relay by WASHINGTON.ARPA with TCP; Sat 14 Apr 84 04:06:24-PST Received: by csnet-relay via xucsc; 14 Apr 84 6:09 EST Date: 13 Apr 84 21:27:25-PST (Fri) From: MEMO SERVICE (MMDF) Subject: Waiting mail To: FURUTA@washington.arpa ReSent-date: Sat 14 Apr 84 11:46:25-PST ReSent-from: Richard Furuta ReSent-to: header-people@MIT-MC.ARPA After -112 days, your message has not yet been fully delivered. Mail is not returned until it is in the queue for at least 11 days. Delivery attempts are still pending for the following address(es): laser This usually is due to service interruptions at the receiving machine. Less often, there are problems with the communications system. Your message begins as follows: Received: From washington.arpa.arpa by csnet-relay via smtp; 12 Apr 84 18:16 EST Return-Path: Received: from wisc-rsch.arpa by WASHINGTON.ARPA with TCP; Thu 12 Apr 84 14:19:31-PST Date: Thu, 12 Apr 84 16:21:25 cst From: Dave Cohrs Message-Id: <8404122221.AA11640@wisc-rsch.arpa> Received: by wisc-rsch.arpa (4.22/3.7) id AA11640; Thu, 12 Apr 84 16:21:25 cst To: laser-lovers%washington.arpa@csnet-relay.csnet Subject: ln01 fonts and programs available ReSent-date: Thu 12 Apr 84 15:04:27-PST ReSent-from: Richard Furuta ReSent-to: "Laser Lovers": ; Via: rand-relay; 5 Aug 84 15:44-PDT ditroff filter, versatec ==> ln01 font conversion (and support programs) available from University of Wisconsin Computer Science Dept. ...  Date: Sat 14 Apr 84 11:50:48-PST From: Richard Furuta Subject: Friday the 13th To: header-people@MIT-MC.ARPA cc: Furuta@WASHINGTON.ARPA Let me submit the following as an example of "Friday the 13th behavior." Note how long mmdf thinks the message has been in the queue. Another instance of this kind of behavior showed up here yesterday. We have a hung job on one of our systems that we cannot log out. It was started on Friday the 13th, is job number 13, and is on terminal line number 13. Unfortunately, I also provided another example of "Friday the 13th" behavior in formulating this message by accidentally forwarding a copy of the enclosed without any commentary. Sorry. --Rick ---------- Return-Path: Received: from csnet-relay by WASHINGTON.ARPA with TCP; Sat 14 Apr 84 04:06:24-PST Received: by csnet-relay via xucsc; 14 Apr 84 6:09 EST Date: 13 Apr 84 21:27:25-PST (Fri) From: MEMO SERVICE (MMDF) Subject: Waiting mail To: FURUTA@washington.arpa After -112 days, your message has not yet been fully delivered. Mail is not returned until it is in the queue for at least 11 days. Delivery attempts are still pending for the following address(es): laser This usually is due to service interruptions at the receiving machine. Less often, there are problems with the communications system. Your message begins as follows: Received: From washington.arpa.arpa by csnet-relay via smtp; 12 Apr 84 18:16 EST Return-Path: Received: from wisc-rsch.arpa by WASHINGTON.ARPA with TCP; Thu 12 Apr 84 14:19:31-PST Date: Thu, 12 Apr 84 16:21:25 cst From: Dave Cohrs Message-Id: <8404122221.AA11640@wisc-rsch.arpa> Received: by wisc-rsch.arpa (4.22/3.7) id AA11640; Thu, 12 Apr 84 16:21:25 cst To: laser-lovers%washington.arpa@csnet-relay.csnet Subject: ln01 fonts and programs available ReSent-date: Thu 12 Apr 84 15:04:27-PST ReSent-from: Richard Furuta ReSent-to: "Laser Lovers": ; Via: rand-relay; 5 Aug 84 15:44-PDT ditroff filter, versatec ==> ln01 font conversion (and support programs) available from University of Wisconsin Computer Science Dept. ... -------  Date: Sat, 14 Apr 84 15:15:25 EST From: Daniel Long Subject: Re: Friday the 13th In-Reply-To: Your message of Sat 14 Apr 84 11:50:48-PST To: Richard Furuta Cc: header-people@MIT-MC, cic@BBN-UNIX This one is fairly straightforward. MMDF returns mail after it has been queued for some amount of time. Things get interesting when someone sets the system date far ahead of the present. Note the date on the Via: line. Received: From washington.arpa.arpa by csnet-relay via smtp; 12 Apr 84 18:16 EST Return-Path: Received: from wisc-rsch.arpa by WASHINGTON.ARPA with TCP; Thu 12 Apr 84 14:19:31-PST Date: Thu, 12 Apr 84 16:21:25 cst From: Dave Cohrs Message-Id: <8404122221.AA11640@wisc-rsch.arpa> Received: by wisc-rsch.arpa (4.22/3.7) id AA11640; Thu, 12 Apr 84 16:21:25 cst To: laser-lovers%washington.arpa@csnet-relay.csnet Subject: ln01 fonts and programs available ReSent-date: Thu 12 Apr 84 15:04:27-PST ReSent-from: Richard Furuta ReSent-to: "Laser Lovers": ; Via: rand-relay; 5 Aug 84 15:44-PDT Here's March's entry in the contest: Date: Tue, 13 Mar 84 6:58:04 EST From: CSNET-RELAY Memo Service (MMDF) Subject: Waiting mail To: chris%umcp-cs@Csnet-Relay.ARPA Via: CSNet-Relay; 13 Mar 84 22:51-EDT After 9 days (194 hours), your message has not yet been fully delivered. Attempts to deliver the message will continue for 178956969 more days. No further action is required by you. Delivery attempts are still pending for the following address(es): eggert @ Ucsb (queue: ucsb) Problems usually are due to service interruptions at the receiving machine. Less often, they are caused by the communication system. -- Dan  Date: 15 Apr 1984 01:45:31-EST From: allegra!hou3c!burl!ulysses!harpo!seismo!uwvax!dave at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA03837; Sat, 14 Apr 84 21:56:32 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site uwvax.ARPA From: allegra!dave@uwvax.ARPA Subject: Re: What DEC domain? Message-Id: <201@uwvax.ARPA> Date: Sat, 14-Apr-84 03:02:48 EST Received: by hou3c.UUCP; Sat, 14-Apr-84 11:24:25 EST References: <467@hou3c.UUCP> In-Reply-To: <467@hou3c.UUCP> Organization: U of Wisconsin CS Dept > OK, OK, the ".DEC" is "legit." The address is nevertheless > complicated. There are 5 parseable tokens separated by 3 different > delimiters. I just hope this is the darkness before > the dawn, and we don't soon see 8 tokens and 6 different delimiters > in the address. If its number of tokens and delimiters you're worried about, I have bad news for you. The new ARPAnet standard has domains and subdomains, etc, etc. The number of tokens is bound to increase for a while. -- Dave Cohrs @ wisconsin ...!{allegra,eagle,heurikon,ihnp4,seismo,ucbvax,uwm-evax}!uwvax!dave dave@wisc-rsch.arpa  Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.17) id AA01284; Mon, 16 Apr 84 13:00:05 pst Message-Id: <8404162100.AA01284@decwrl.ARPA> Date: Monday, 16 Apr 1984 11:47:08-PST From: lipman%rhea.DEC@decwrl.ARPA To: header-people@mit-mc.ARPA Subject: More on RHEA.DEC In my previous submission to header-people, I noted that I had eliminated identifying RHEA.DEC as RHEA.ARPA in the "Received: " headers. I had chosen to identify RHEA.DEC as DEC-RHEA.ARPA at least partially due to the way 4.2 BSD sendmail generates that Received header message. A second reason for changing the host name and not just the domain was the argument that user@rhea, user@rhea.ARPA, and user@rice-rhea.ARPA should all be equivalent. I based this feeling on the argument that I and my user community wanted user@Shasta, user@Shasta.ARPA, and user@SU-Shasta.ARPA to all be equivalent. Consistency might even make some of this obscure junk understandable. But Brian Reid points out in the note enclosed below that neither user@rhea, nor user@rhea.ARPA should be arriving at decwrl from the outside world. Nicknames are not supposed to leave the local machine on which they are used, they are supposed to be converted into the real host name. Note that I believe 4.2 BSD Sendmail violates this rule. If this is indeed the case, then it is only my local user community I should be concerned about and for them, user@rhea should mean dec-rhea. I'll bet there is a mailbag worth of opinions out there! Peter Lipman DEC Western Research Laboratory 4410 El Camino Real Los Altos, California 94022 (415) 949-0776 uucp: {decvax, ucbvax, ihnp4, allegra} decwrl!lipman ARPA net: lipman@decwrl.ARPA DEC-Enet: RHEA::LIPMAN --------------- Note from Brian Reid ------------------------ From: RHEA::DECWRL::"reid@Glacier.ARPA" "Brian Reid" 15-APR-1984 16:21 To: Peter Lipman Subj: rhea and domains Received: from DECWRL by DEC-RHEA with SMTP; Sun, 15 Apr 84 16:21-PST Received: from Glacier (su-glacier.arpa.ARPA) by decwrl.ARPA (4.22.01/4.7.16) id AA24254; Sun, 15 Apr 84 16:18:03 pst Date: Sun, 15 Apr 84 16:16:11 pst Cc: Forest Baskett Message-Id: <8404160018.AA24254@decwrl.ARPA> Peter, I saw a message on acetes that there is a naming conflict between rice-rhea and DEC's rhea. I don't think there should be a need to panic. One of the main purposes for having domains in symbolic addressing is to provide a way of circumventing this problem. The main use, so far, of domain addressing in the internet has been to assist subnet routing of mail. Perhaps this has obscured the more important use of domains for name qualification. Thus, the name RHEA.DEC is a different name from RHEA.ARPA. As it turns out, if you read the fine print in RFC822, it is illegal to put domain qualifications on nicknames, e.g. RHEA.ARPA is not a legal name, but RICE-RHEA.ARPA is a legal name. Furthermore, the standard requires that all exported text contain only fully-qualified names. This means that once a message leaves the .ARPA domain, it cannot contain the name "RHEA" anywhere in it, or even "RHEA.ARPA". This important restriction provides the basis for making your system do what you want. When you are on, say, Acetes, and you reference a name "RHEA", you are allowed to assume that you are in some domain besides the .ARPA domain. Specifically, you are in the .DEC domain. You can think of the task of name resolution as being like looking down a search path of domains: first you check your own home domain, then you check neighboring domains, and so forth. If you did it this way, then the name "rhea" would always resolve to RHEA.DEC and not RICE-RHEA.ARPA when it was used in an unqualified context on any machine in the DEC domain. The moral: you don't have to change the name of your machine unless you want to. Brian  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA00430; Tue, 17 Apr 84 13:13:25 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.16) id AA23442; Tue, 17 Apr 84 12:01:44 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.16) id AA18530; Tue, 17 Apr 84 12:01:05 pst Date: Tue, 17 Apr 84 12:01:05 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8404172001.AA18530@ucbopal.CC.Berkeley.ARPA> To: header-people@mit-mc.ARPA Subject: Re: More on RHEA.DEC In reply to: Message-Id: <8404162100.AA01284@decwrl.ARPA> Date: Monday, 16 Apr 1984 11:47:08-PST From: lipman%rhea.DEC@decwrl.ARPA To: header-people@mit-mc.ARPA Subject: More on RHEA.DEC ..... Nicknames are not supposed to leave the local machine on which they are used, they are supposed to be converted into the real host name. Note that I believe 4.2 BSD Sendmail violates this rule. ..... Peter Lipman DEC Western Research Laboratory 4410 El Camino Real Los Altos, California 94022 (415) 949-0776 Let's stop blaming the Unix sendmail program and work toward getting local sendmail configuration files fixed so gatewaying is handled properly. At Berkeley we permit users to use different nicknames and top-domain names with sendmail. Our mail system also transforms non-Internet addresses into Internet addresses of before transmitting the message to an Internet mail site. Bill Wells wcwells@Berkeley.ARPA  Date: Tue 17 Apr 84 13:30:29-PST From: Mark Crispin Subject: "blaming Unix SendMail" 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) I will probably regret this, but I couldn't help myself. It seems that any program which requires configuration files of such complexity that just about every site gets them wrong is sadly lacking in the most basic principles of good software design. Unix SendMail seems to be such a program. Tell me, why does SendMail need such complex configuration files? Wouldn't a preferable scheme be to look at ones environment at runtime and do the right thing by default? I guess I'm wedged. After all, I program on dinosaurs using the obsolete thinking that software should do the right thing in its default unmodified state without requiring such elaborate configuration procedures. -------  Date: 18 Apr 1984 22:26:39-EST From: allegra!hou3c!burl!ulysses!allegra!princeton!down!honey at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA18518; Wed, 18 Apr 84 22:20:42 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site down.UUCP From: allegra!down!honey (code 101) Subject: Re: "blaming Unix SendMail" Message-Id: <140@down.UUCP> Date: Tue, 17-Apr-84 20:20:30 EST Received: by hou3c.UUCP; Tue, 17-Apr-84 23:19:11 EST References: <474@hou3c.UUCP> In-Reply-To: <474@hou3c.UUCP> Organization: Princeton Univ. EECS why does sendmail require such complex configuration tables, you ask? read the documentation (sendmail/doc/op.me): There is one point that should be made clear immediately: the syntax of the configuration file is designed to be reasonably easy to parse, since this is done every time sendmail starts up, rather than easy for a human to read or write. let's just ignore the fact that parsing was made trivial by geniuses of decades past, and go blithely along, prematurely optimizing. progress? who needs it? feh. peter honeyman  Date: 18 Apr 1984 22:26:46-EST From: allegra!hou3c!burl!ulysses!harpo!seismo!rlgvax!guy at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA18539; Wed, 18 Apr 84 22:22:25 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP From: allegra!rlgvax!guy (Guy Harris) Subject: Re: "blaming Unix SendMail" Message-Id: <1871@rlgvax.UUCP> Date: Wed, 18-Apr-84 00:03:37 EST Received: by hou3c.UUCP; Wed, 18-Apr-84 03:16:59 EST References: <474@hou3c.UUCP> <140@down.UUCP> In-Reply-To: <140@down.UUCP> Organization: CCI Office Systems Group, Reston, VA >why does sendmail require such complex configuration tables, you ask? >read the documentation (sendmail/doc/op.me): > There is one point that should be made clear immediately: the > syntax of the configuration file is designed to be reasonably > easy to parse, since this is done every time sendmail starts > up, rather than easy for a human to read or write. >let's just ignore the fact that parsing was made trivial by geniuses of >decades past, and go blithely along, prematurely optimizing. progress? >who needs it? feh. Not entirely fair; the comment in the documentation refers to the *syntax* of a configuration file (which is, admittedly, baroque) but the person who complained about "sendmail" was complaining about the baroque *semantics* of the configuration file. Unfortunately, if you want a program which is all things to all people (like "sendmail" is) you aren't going to get something which is straightforward. Frankly, I bless "sendmail"s ability to be made to do lots of mail handling tasks without having to dive into the source code (which is a poor idea because 1) it's complicated and you may break it, 2) it means you've got private versions of "sendmail" running around all over the place - Allman's paper on "sendmail" points out that the "sendmail" configuration file was intended to make it possible to run the same binary everywhere, and 3) lots of people out there don't have source anyway). I wish it were more straightforward, but I don't know whether that's possible. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy  Date: Wed 18 Apr 84 21:16:33-PST From: Mark Crispin Subject: Re: "blaming Unix SendMail" To: Header-People@MIT-MC.ARPA In-Reply-To: Message from "allegra!hou3c!burl!ulysses!harpo!seismo!rlgvax!guy at mit-vax" of Wed 18 Apr 84 19:26:46-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Perfectly fair. It doesn't matter whether one refers to syntax or semantics of the configuration files. The fact is that it is very hard to respect a mailsystem which engages in idiotic behavior because the case of one of single-letter options in the configuration file was lower case instead of upper. This has happened repeatedly in systems across the ARPANET, and in-house at Stanford a number of times. The developers and users of Unix and its software loudly proclaim how advanced their software is and how it is the "clean non-kludgy" way into the future (compared with systems such as DEC-20's which are presumably "unclean and kludgy"). It seems quite fair to call SendMail on this sort of thing. If Unix wants to be more than a toy system it has got to recognize that ergonomics is part of software engineering. -------  From: Christopher A Kent Message-Id: <8404190535.AA11042@merlin.ARPA> Received: by merlin.ARPA; Thu, 19 Apr 84 00:35:39 est Date: 19 Apr 1984 0035-EST (Thursday) To: Mark Crispin Cc: Header-People@MIT-MC.ARPA Subject: Re: "blaming Unix SendMail" In-Reply-To: Your message of Wed 18 Apr 84 21:16:33-PST. <8404190521.AA12910> Header-People seems hardly to be the place to launch into TOPS-20 vs. Unix flamage. Please desist. Cheers, chris ----------  Message-Id: <8404191218.AA26607@harvard.UUCP> From: lhasa!stew@harv-10 Date: 19-apr-1984 07:12 To: harvard!header-people@mit-mc Subj: Malformed headers I have recently been involved in setting up a mailsystem connecting HARVARD, a 4.2BSD Unix 780 on the internet, to other machines here at Harvard. All this guff about sendmail config files is starting to hit me; This is a problem we're faced with here. Here is an example of a recent incoming message that illustrates some of the problems. Perhaps someone out there can make some suggestions as to who is to blame for the following headers, and what can be done. The first message is in the exact form that harvard transmitted it. To harvard, our machine appears as a "fake" uucp address; LHASA is a VAX/VMS machine running software which I wrote to pick the necessary files out of Harvard's uucp spool directories and deliver them on the VMS machine. --------------- Begin forwarded message #1 ----------------- From @MIT-MC.ARPA:@SRI-KL.ARPA:engvax!KVC@cit-vax Thu Apr 19 02:26:57 1984 remote from harvard Received: from cit-vax.ARPA by SRI-KL.ARPA with TCP; Wed 18 Apr 84 22:36:18-PST Received: by cit-vax.ARPA id AA03064 at Wed, 18 Apr 84 16:09:33 pst Date: Wed, 18 Apr 84 16:09:33 pst From: harvard!engvax!KVC@cit-vax.ARPA Message-Id: <8404190009.AA03064@cit-vax.ARPA> To: ."cit-vax!info-vax@sri-kl.arpa"@ENGVAX.ARPA Subject: Re: lost batch jobs... /Kevin Carosso engvax!kvc @ CIT-VAX Hughes Aircraft Co. --------------- End forwarded message #1 ----------------- For those who are interested, this is the form the message takes when it appears in my VMS mail file. --------------- Begin forwarded message #2 ----------------- From: HARVARD!@MIT-MC.ARPA:@SRI-KL.ARPA:engvax!KVC@cit-vax 19-Apr-1984 02:26 To: ."cit-vax!info-vax@sri-kl.arpa"@ENGVAX.ARPA Subj: Re: lost batch jobs... Received: by lhasa via VAXNET; Thu Apr 19 02:44:15 1984 Received: from cit-vax.ARPA by SRI-KL.ARPA with TCP; Wed 18 Apr 84 22:36:18-PST Received: by cit-vax.ARPA id AA03064 at Wed, 18 Apr 84 16:09:33 pst Date: Wed, 18 Apr 84 16:09:33 pst From: harvard!engvax!KVC@cit-vax.ARPA Message-Id: <8404190009.AA03064@cit-vax.ARPA> /Kevin Carosso engvax!kvc @ CIT-VAX Hughes Aircraft Co. --------------- End forwarded message #2 ----------------- Now. The problems should be obvious. I want to respond to an address something like harvard!"engvax!kvc"@cit-vax, I think. And if I want to CC the list, it does NOT want to go to "cit-vax!info-vax@sri-kl.arpa"@ENGVAX.ARPA ENGVAX isn't even on ARPA!!! Someone has to translate these to things like: <@HARVARD: engvax!kvc@CIT-VAX.ARPA> and <@CIT-VAX: INFO-VAX@SRI-KL.ARPA>. Are my interpretations of RFC822 correct? I assume that the problems on both ends could be corrected by changes to the sendmail config files... I should of course say that I am not blaming anyone at CIT; the same sort of malformed header will be visible on the message that you receive from me. Stew Rubenstein ARPA: lhasa!stew@harvard.arpa UUCP: {allegra!ima,decvax!genrad!wjh12}!harvard!lhasa!stew MAIL: Harvard University Chemical Labs 12 Oxford St. Box 100 Cambridge, MA 02138  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA12770; Thu, 19 Apr 84 11:04:25 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.16) id AA14654; Thu, 19 Apr 84 11:06:07 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.16) id AA15115; Thu, 19 Apr 84 11:05:27 pst Date: Thu, 19 Apr 84 11:05:27 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8404191905.AA15115@ucbopal.CC.Berkeley.ARPA> To: Header-People@MIT-MC.ARPA Subject: Re: "blaming Unix SendMail" I think we can agree that "machine readable" files are not necessarily "human readable". Yes, the sendmail configuration file is susceptible to human error because it is complex, terse, and has to be manually edited for installation. I think the BSD Unix development group could make installation easier by supplying more examples of sendmail configuration files (eg. one for a site in one mail domain, one for a site in a subdomain, one for a site in a gateway domain [multiple local domains], etc.). A program that asks the installer appropriate questions and generates a configuration file for the more common types of installations might reduce the number of errors being made. Bill Wells wcwells@Berkeley.ARPA ucbvax!wcwells  Received: ID ; Thu 19 Apr 84 15:56:56-EST Date: Thu 19 Apr 84 15:56:53-EST From: Vince Fuller Subject: Re: "blaming Unix SendMail" To: MRC@SU-SCORE.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "Mark Crispin " of Thu 19 Apr 84 07:39:20-EST One of the things that has continually amazed me about Unix is the steadfast refusal to implement anything as something other than a text file. This whole argument is silly. Why does sendmail (or the termcap library, or anything else in Unixland for that matter) have to parse a rarely-changing text file every time it is started? Why not have the file preparsed into a binary file that imposes structure on the options for ease of access? This kind of simple optimization (which is the way the TOPS-20 mailsystem handles address lists) satisfies both requirements: the text file "source" can be easy for humans to read - it doesn't have to be parsed often - so what it parsing takes a little while longer, and the binary can be optimized for speed (probably would do a lot better than the current approach). I'm sorry, but I won't buy the "it has to be parsed quickly" argument. --Vince P.S. My apology to those offending by the flaming tone of the message. I am just tired of seeing so much braindamage like this in Unix - it really isn't that hard to sit down and THINK about how to implement something before you go out and do it. -------  Date: Fri, 20 Apr 84 10:01:01 cst From: solomon@wisc-crys.arpa (Marvin Solomon) Message-Id: <8404201601.AA05840@wisc-crys.arpa> Received: by wisc-crys.arpa (4.22/3.7) id AA05840; Fri, 20 Apr 84 10:01:01 cst To: lhasa!stew@harv-10 Subject: Re: Malformed headers Cc: header-people@mit-mc Sender: forwarder@wisc-crys.arpa This has all been said before, so I'll try to be brief, but it keeps coming up, so I think it's worth repeating. The problem is conflicting and ambiguous syntax for addresses between RFC 822 and UUCP. The UUCP syntax is host!localpart, while the 822 syntax is localpart@host. When you try to put an address into "localpart" to simulate source routing, you get ambiguity. Does "a!b@c" mean "a!(b@c)" (use UUCP to send to host a, which hopefully is on Arpanet and can send to b@c), or does it mean "(a!b)@c" (send over Arpanet to host c, which will forward using uucp). The ad hoc solution seems to be context-sensitive parsing, using info like whether I'm on Arpanet, whether Arpanet contains a host named "c", etc. Usually some sort of local kludge can be worked out. But when a message crosses back and forth between worlds more than once (as the message in question seems to have done), I have very little hope that anything will work. Some UUCP sites are trying to move to the 822 syntax with hacks like munging host!user to user@host.UUCP. Sometimes that helps, and sometimes it makes things worse. My own personal opinion is that source-routing is a necessary evil that will be with us for some time. The best syntax I've seen is the RFC821 syntax: <@host1,@host2,...,@hostN-1:user@hostN>. I've seen some evidence that more software packages are supporting it, not only in the SMTP envelope, but in headers and in user agents. When putting together independantly planned (or unplanned) systems and trying to make a consistent whole, we must strike a delicate balence: We must be understanding and sympathetic with sites running obsolete software, while continuing to urge them and help them to change. In this case, we can help by moving quickly towards putting the domain system in place and setting up some sort of "official" UUCP domain.  Date: Fri, 20 Apr 84 10:31:40 cst From: solomon@wisc-crys.arpa (Marvin Solomon) Message-Id: <8404201631.AA06136@wisc-crys.arpa> Received: by wisc-crys.arpa (4.22/3.7) id AA06136; Fri, 20 Apr 84 10:31:40 cst To: VAF@CMU-CS-C.ARPA Subject: Re: "blaming Unix SendMail" Cc: Header-People@MIT-MC.ARPA Sender: forwarder@wisc-crys.arpa The change you suggested is already in sendmail (the version distributed with 4.2 UNIX). I believe I was the one who suggested the particular "trick" now used. I thought of it years ago while trying to make Adventure start up more quickly. Take ANY program that has a complicated and time-consuming startup and add two options: When the program is called with the first option, it goes through the initialization, then dumps everything willy-nilly into a file. (In C, that can usually be done by simply dumping bss: everything from _edata to _end; in FORTRAN it can be done by dumping COMMON). When called with the second option, the program skips the initialization and simply loads the file. Now the bad news: The syntax for sendmail configuration files was designed before the "freeze-file" idea was incorporated, but even though the justification is now gone, nobody is very anxious to change it. I think the best course is simply to improve the instructions for creating configuration files, but that's much more boring that creating more software :-) Sendmail was designed and implemented by Eric Allman. If you disagree with some aspect of its design, argue with him. I believe he's already stated publicly that he's sorry he made the configuration file so cryptic, and if he had it to do over, he'd do it differently. Comments like "I'm just tired of seeing so much braindamage like this in Unix" are really off the mark. I'm tired of seeing so much sectarian strife.  Date: 20 Apr 1984 12:42:08-EST From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!intelca!t4test!lew at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA11289; Fri, 20 Apr 84 10:56:01 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 5/3/83; site t4test.UUCP From: allegra!t4test!lew (Lew Mullen) Subject: Re: "blaming Unix SendMail" Message-Id: <518@t4test.UUCP> Date: Thu, 19-Apr-84 12:40:24 EST Received: by hou3c.UUCP; Fri, 20-Apr-84 09:21:51 EST References: <474@hou3c.UUCP> In-Reply-To: <474@hou3c.UUCP> Organization: Intel, Santa Clara, Ca. So that's why it doesn't work ... what configuration files ? t4test!lew lew mullen  Date: 20 Apr 1984 12:42:20-EST From: allegra!hou3c!burl!ulysses!harpo!seismo!ut-sally!smoot at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA11346; Fri, 20 Apr 84 10:58:42 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site ut-sally.UUCP From: allegra!ut-sally!smoot (Smoot Carl-Mitchell) Reply-To: smoot@ut-sally.ARPA (Smoot Carl-Mitchell) Subject: Re: "blaming Unix SendMail" Message-Id: <2003@ut-sally.UUCP> Date: Thu, 19-Apr-84 13:30:56 EST Received: by hou3c.UUCP; Thu, 19-Apr-84 20:34:58 EST References: <474@hou3c.UUCP> In-Reply-To: <474@hou3c.UUCP> Organization: U. Texas CS Dept., Austin, Texas As the local "sendmail hacker" here at UT, I do find the configuration file syntax to be difficult to understand at times. Fortunately, Eric Allman did provide some pretty good template files to get users started and I greatly appreciated that. Most of the configuration files I have modified are based upon one or more of Eric's files. Without those files I would have spent a great deal more time writing the configuration files we need. In defense of sendmail it was designed to operate in a heterogenous network mail environment and serve as a bridge between user communities using different mail address syntax. As a first stab at trying to address the problem, I think Eric did a fine job. It can be improved. A more "user friendly" syntax would certainly be useful and while not an easy job it is not impossible. -- Smoot Carl-Mitchell, CS Dept. University of Texas at Austin {seismo, ctvax, ihnp4}!ut-sally!smoot, smoot@ut-sally.{ARPA, UUCP}  Date: 20 Apr 1984 12:42:26-EST From: allegra!hou3c!burl!ulysses!harpo!ihnp4!cbosgd!mark at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA13227; Fri, 20 Apr 84 12:35:22 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP From: allegra!cbosgd!mark (Mark Horton) Subject: Re: "blaming Unix SendMail" Message-Id: <1291@cbosgd.UUCP> Date: Thu, 26-Apr-84 00:41:20 EST Received: by hou3c.UUCP; Fri, 20-Apr-84 07:15:36 EST References: <487@hou3c.UUCP> In-Reply-To: <487@hou3c.UUCP> Organization: AT&T Bell Laboratories, Columbus Why does sendmail (or the termcap library, or anything else in Unixland for that matter) have to parse a rarely-changing text file every time it is started? Check out the following /usr/lib/sendmail -bz This creates a binary file for quick startup. Termcap is being replaced by terminfo, which also uses binary files. So of course it doesn't have to. But it's great for prototyping when the first stab is in a text format. Mark  From: Mark Shoemaker Message-Id: <8404202031.AA26150@mordred.ARPA> Received: by mordred.ARPA; Fri, 20 Apr 84 15:31:48 est Date: 20 Apr 1984 1531-EST (Friday) To: header-people@mit-mc.ARPA Subject: arcane sendmail configuration tables Why doesn't someone (with lots of spare time) design a more reasonable syntax for describing a sendmail configuration and then implement a translator from it to the current syntax? While they're at it, they could write a translator (disassmbler?) from the old syntax to the new to aid in incorporating updates. I'd do it if I had the time (really!), Mark Shoemaker mas@purdue  Date: Fri 20 Apr 84 13:31:17-PST From: Mark Crispin Subject: Re: "blaming Unix SendMail" To: smoot@UT-SALLY.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "allegra!hou3c!burl!ulysses!harpo!seismo!ut-sally!smoot at mit-vax" of Fri 20 Apr 84 09:42:20-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) To answer smoot@UT-SALLY's defense of Sendmail, I should point out that the TOPS-20 mailsystem (in particular, its MMailr module) also operates in a heterogenous network mail environment. MMailr doesn't require gothic configuration files to do the right thing. I will confess that MMailr doesn't try to bridge between different mail syntaxes. user@host is a perfectly reasonable syntax to standardize on, and I see no particular reason to encourage relative addressing unless it is absolutely necessary. What does foo!bar!rag!zowie mean when host bar knows of TWO DIFFERENT machines called rag? Can't happen, you say? Nonsense; it is a real problem between Internet and several University LAN's right now. In other words, relative addressing is only safe to use in the cases where it is unnecessary! -------  Date: Fri, 20 Apr 84 15:06:05 pst From: Joseph I. Pallas Subject: Re: "blaming Unix SendMail" To: MRC@SU-Score, smoot@UT-SALLY.ARPA Cc: Header-People@MIT-MC.ARPA Sorry, MRC, but relative addressing is still necessary even when it is safe to use. In your example, foo!bar!rag!zowie it's still possible that foo doesn't know how to talk to ANY machine named rag, let alone two of them. That's why SMTP supports source routing. Of course, domains will change all that Real Soon Now. joe  Date: Fri 20 Apr 84 16:20:01-PST From: Mark Crispin Subject: Re: "blaming Unix SendMail" To: pallas@PESCADERO.ARPA cc: smoot@UT-SALLY.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "Joseph I. Pallas " of Fri 20 Apr 84 15:06:26-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) SMTP source routing is completely useless, due to restrictions on what may be in the SMTP source route. It might as well not exist. My point was that relative addressing is not at all a desirable thing. It should only be looked at as a last resort. Within a single naming registry, it should be possible to use absolute addressing. Between naming registries, it should be possible to give "an absolute address within an absolute registry" -- this was the original concept behind domains although now domains refer to administrative rather than technical entities (naming registries traditionally have followed the latter rather than the former). -------  Date: 21 Apr 1984 16:39:07 PST From: POSTEL@USC-ISIF Subject: RFC 821 Documentation Bug To: header-people@MIT-MC Date: Wed, 18 Apr 84 21:36:07 pst From: spgggm%ucbopal.CC@Berkeley (Greg Minshall) To: postel@isif.ARPA Subject: rfc821 question... Hi, Is it true that 'postel@f.isi.arpa' is illegal by rfc821, since ::= is at least three characters long? Or, should it be like ::= | | ? Thanks, Greg Minshall Subject: RFC821 Question From: Postel@isif To: spggm%ucbopal.cc@BERKELEY Greg: That is a documentation bug. What is needed is a nested set of option brackets. ::= [[] ]. --jon. -------  Date: Sat, 21 Apr 84 22:03:47 cst From: smoot@ut-sally.ARPA (Smoot Carl-Mitchell) Posted-Date: Sat, 21 Apr 84 22:03:47 cst Message-Id: <8404220403.AA23099@ut-sally.ARPA> Received: by ut-sally.ARPA (4.22/4.22) id AA23099; Sat, 21 Apr 84 22:03:47 cst To: MRC@SU-SCORE.ARPA Subject: Re: "blaming Unix SendMail" Cc: Header-People@MIT-MC.ARPA Certainly life will be simpler when the ARPA domain addressing is adopted as a standard. I do know that UUCP addressing was a consideration in sendmail's design. Also it was designed to operate in a heterogenous mail syntax environment. I'll be happy when the ARPA domain addressing with nameservers becomes the standard because then the software becomes a lot simpler. I agree that relative addressing is a drag and I'll be happy when UUCP adopts absolute addressing. I might point out that I have used sendmail to implement a local mail domain here at the University of Texas connecting 4 Vaxen, one 11/70, four SUNs and a DEC-20 (the DEC-20 did not use sendmail). Our network situation is very ad-hoc. We have three machines on the internet and currently have two discontiguous ethernets. The two ethernets are linked via a UUCP link. Yet with this situation I was able to quickly build sendmail configuration files for all the systems which allows absolute addressing between all these machines, no matter what the underlining routing which could include routing over a dialup line, through our IMP, or via an ethernet. I would certainly like to know if other mail delivery systems have that flexibility.  Date: 24 Apr 1984 02:22:53-EST From: allegra!hou3c!ka at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA04407; Mon, 23 Apr 84 15:46:26 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP From: allegra!hou3c!ka (Kenneth Almquist) Subject: Re: Malformed headers Message-Id: <479@hou3c.UUCP> Date: Fri, 20-Apr-84 18:24:10 EST In-Reply-To: <8404201601.AA05840@wisc-crys.arpa> Organization: Bell Labs, Holmdel, NJ UUCP mail does not conform to RFC 822. (Actually, no written standard for UUCP mail exists, which is one reason for trying to phase it out.) Context-sensitive parsing is not an "ad hoc" solution; it is a recog- nition of this situation. It should be possible to write mail gateway software that will leave all the exclamation points on the UUCP side. E. g. this mail could be given a from line reading "From: ka@hou3c.UUCP" and a return path reading "Return-Path: <@mit-vax.ARPA,@allegra.UUCP:ka@hou3c.UUCP>". Alternatively, the full return path could be included in the from line as well as the return path line. Are either of these approaches reason- able? How many existing mailers will be able to reply to such letters? Kenneth Almquist  Date: 24 Apr 1984 02:22:59-EST From: allegra!hou3c!burl!ulysses!harpo!seismo!uwvax!dave at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA04538; Mon, 23 Apr 84 15:51:19 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site uwvax.ARPA From: allegra!dave@uwvax.ARPA Subject: Re: Malformed headers Message-Id: <217@uwvax.ARPA> Date: Sat, 21-Apr-84 08:36:01 EST Received: by hou3c.UUCP; Mon, 23-Apr-84 15:24:35 EST References: <479@hou3c.UUCP> In-Reply-To: <479@hou3c.UUCP> Organization: U of Wisconsin CS Dept You probably shouldn't change the 'From:' line if the mailers *all* understand the 'Return-Path' (remember, not everyone conforms to standards). 4.2BSD sendmail sites should all be able to understand that syntax. A site just running uucp..... I don't know. I doubt it (our 11/70 w/2.8bsd couldn't understand that without some serious work on my part). What's this about phasing out uucp addresses? I vaguely remember seeing, a month or so ago, a message stating that uucp was going to be released for *micros* in the very near future. Once this is released, uucp addresses will be permanant, more permanant than even ARPAnet addresses. If any phasing out is going to happen, it had better happen fast! -- Dave Cohrs @ wisconsin ...!{allegra,eagle,heurikon,ihnp4,seismo,ucbvax,uwm-evax}!uwvax!dave dave@wisc-rsch.arpa  Date: 24 Apr 1984 02:23:06-EST From: allegra!hou3c!burl!we13!ihnp4!harpo!seismo!hao!hplabs!nsc!chuqui at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA08780; Mon, 23 Apr 84 18:37:37 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1.chuqui 4/7/84; site nsc.UUCP From: allegra!nsc!chuqui (Chuq Von Rospach) Subject: Re: "blaming Unix SendMail" Message-Id: <866@nsc.UUCP> Date: Sat, 21-Apr-84 12:50:38 EST Received: by hou3c.UUCP; Mon, 23-Apr-84 18:30:56 EST References: <8404201631.AA06136@wisc-crys.arpa> In-Reply-To: <8404201631.AA06136@wisc-crys.arpa> Organization: National Semiconductor, Sunnyvale What I've wondered is why someone hasn't simply written a front end that creates sendmail files. Isn't that what computers are for? (Hmm, with the complexity of sendmail files, we are probably talking about one whale of a parser/compiler.... Hmmm... ) -- >From under the bar at Callahan's: Chuq Von Rospach {amd70,fortune,hplabs,menlo70}!nsc!chuqui (408) 733-2600 x242 Never give your heart to a stranger, unless you are sure that you are dead.  Date: 24 Apr 1984 02:23:12-EST From: allegra!hou3c!burl!we13!ihnp4!harpo!seismo!ut-sally!jsq at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA08990; Mon, 23 Apr 84 18:43:02 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site ut-sally.UUCP From: allegra!ut-sally!jsq (John Quarterman) Subject: Re: "blaming Unix SendMail" Message-Id: <2048@ut-sally.UUCP> Date: Sat, 21-Apr-84 23:55:26 EST Received: by hou3c.UUCP; Mon, 23-Apr-84 18:31:22 EST References: <491@hou3c.UUCP> In-Reply-To: <491@hou3c.UUCP> Organization: U. Texas CS Dept., Austin, Texas There is no advantage in UUCP style a!b!c relative addressing: it exists for historical reasons and those of us who deal with the UUCP network as it stands are forced to deal with it because many (most?) UUCP sites do not have any way of dealing with Internet-style addresses. One hopes the UUCP domain project will allow the phasing out of the old-style relative addressing, but until then hosts that deal with both UUCP and the Internet (and CSNET and several local networks in ut-sally's case) must be able to map between addressing syntaxes. We at ut-sally encourage users to enter addresses in Internet domain syntax and let sendmail call a program to look up a UUCP route and convert to relative form. We do not encourage the use of the relative form; we tolerate it because we still have to. The problem of bang!decwrl!rhea!bang!user having bang in there twice was quite common for a while. DEC's ENET was hooked up to UUCP in a fashion that pretended all DEC's machines were actually UUCP sites. Yet there were at least 20 name duplications: vortex, for instance, existed on both sides of the gateway. The DEC domain has lately taken on some solidity and addresses now tend to appear more like bang!decwrl!user%bang.DEC, which removes the problem. Until the UUCP domain exists, there will always be the possibility of duplicate sites within the UUCP network proper (seems like there used to be two machines named "turtlevax"). Religious arguments about "TOPS-20 does it better" are beside the point: I've never run across anybody who likes sendmail's configuration syntax, and I wish somebody *would* write a compiler to convert from some more reasonable language, but sendmail does get the job done. (At least when there's somebody as patient as Smoot to make it do it.) Part of the job *is* converting among diverse addressing syntaxes. -- John Quarterman, CS Dept., University of Texas, Austin, Texas 78712 USA jsq@ut-sally.ARPA, jsq@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsq moskvax!kgbvax!mcc!ut-sally!jsq  Date: 24 Apr 1984 02:23:19-EST From: allegra!hou3c!burl!we13!ihnp4!harpo!seismo!rlgvax!cvl!umcp-cs!chris at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA08950; Mon, 23 Apr 84 18:41:47 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP From: allegra!umcp-cs!chris Subject: Re: "blaming Unix SendMail" Message-Id: <6689@umcp-cs.UUCP> Date: Sat, 21-Apr-84 19:01:25 EST Received: by hou3c.UUCP; Mon, 23-Apr-84 18:32:56 EST References: <491@hou3c.UUCP> In-Reply-To: <491@hou3c.UUCP> Organization: Univ. of Maryland, Computer Science Dept. Time to toss in another couple of pennies' worth of thought here: MMDF (the Multi-Channel Memo Distribution Facility) has in interesting way of "dealing with" UUCP syntax. The basic idea behind MMDF is actually quite similar to the ideas now in use in networking, compiler design, computer design, microprocessor architecture, ... (i.e., a lot of stuff). That is: do things modularly. MMDF has a central input program (called submit). This is not (repeat NOT) a good user interface; all it's good for (and it's pretty good for it) is taking a mail message (with a sender and a list of addressees) and putting it into a queue. It also has a central delivery program (called deliver). This is not an SMTP mailer, nor a UUCP mailer, nor anything else, all it's good for is looking at queued messages and asking another program to deliver them (or to tell it why it can't deliver them). It then has a bunch of (mostly tiny) programs to do delivery for various "channel"s. There is one for local mail (delivery to user's mailboxes). There is another for CSNet PhoneNet mail [which seems to be by far the buggiest, by the way]. I suppose that by now there is one for X.25net mail. And of course, there is one for UUCP mail. It takes a message and a list of addressees, breaks up the message (one for each address as required by some older versions of /bin/rmail), and hands it to the "uux" program, after editing message headers to match UUCP requirements. On the input side, the "/bin/rmail" program is completely rewritten. It takes in a UUCP mail message and figures out the sender's name, and the destination address. It hands to submit a suitably edited message for delivery to the destination. ----------------- The interesting point about this whole system is that UUCP-style addresses are meaningless to the MMDF system and never appear inside it. This really has quite a bit of flexibility, because with small changes to the UUCP-in and UUCP-out programs, you can change the way the UUCP-world sees you. You never have to touch the queueing system. It also means that one can get rid of UUCP syntax in small, relatively painless bits at a time. ----------------- This is not to say that MMDF is the best system there is. There were a few bugs in the original distribution, some serious, some minor, and the code is incredibly inefficient in some respects. To mail to a mere hundred people takes it many CPU-minutes, inspecting your five hundred line alias file a hundred times. A hundred and fifty messages in the queue, and it takes ten minutes for deliver to even start delivering. And to look up a host name alone in the four or five alias tables can take seconds. If you put this together on a Vax 11/780 whose afternoon load average is over 35, you can have lots of fun trying to send mail. But on the other hand, there's a new version that uses better database schemes, multiple queues, etc., which gets around most of that. (And I've done some work myself; things are much better now here.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690 UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relay  Received: from Semillon.ms by ArpaGateway.ms ; 24 APR 84 01:03:41 PST Date: 24 Apr 84 01:03:28 PST From: Murray.pa@XEROX.ARPA Subject: Re: How many existing mailers will be able to reply to such letters? In-reply-to: <479@hou3c.UUCP> To: allegra!hou3c!ka@mit-vax.ARPA Cc: Header-People@MIT-MC.ARPA I don't know, but I have a data point that might shed some light on the scene. There is code in our header munger that translates "at" to "@". It's there because lots of mail software still generates that form of header. Your suggestion raises an interesting question. I don't know of any mail software around here that inspects the Return-Path line. Our mail gateway adds it, but it also munges the headers well enough so that the info in the Return-Path line isn't normally needed. Is this the normal approach? Do any programs out there actually use the info in the Return-Path line?  Date: 24 Apr 1984 21:00:19-EST From: allegra!hou3c!burl!we13!ihnp4!drutx!houxe!hogpc!houti!ariel!vax135!floyd!clyde!lda at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA04315; Tue, 24 Apr 84 20:56:13 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site clyde.UUCP From: allegra!clyde!lda Subject: Re: arcane sendmail configuration tables Message-Id: <412@clyde.UUCP> Date: Sun, 22-Apr-84 16:56:28 EST Received: by hou3c.UUCP; Mon, 23-Apr-84 21:39:15 EST References: <8404202031.AA26150@mordred.ARPA> In-Reply-To: <8404202031.AA26150@mordred.ARPA> Organization: AT&T Bell Laboratories Whippany NJ Why doesn't someone (with lots of spare time) design a more reasonable syntax for describing a sendmail configuration and then implement a translator from it to the current syntax? While they're at it, they could write a translator (disassmbler?) from the old syntax to the new to aid in incorporating updates. I'd do it if I had the time (really!), Mark Shoemaker mas@purdue As one of my roomates used to say to me when *I* made a statment like that: "And if I had a rocket ship, I'd fly to the moon!" -- Larry D. Auton AT&T Technologies WH 2C-122 (201)386-4272 ihnp4!clyde!lda  Date: 25 Apr 1984 16:57:40-EST From: allegra!hou3c!burl!rcj at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA18194; Wed, 25 Apr 84 12:46:16 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site burl.UUCP From: allegra!burl!rcj (R. Curtis Jackson) Subject: network fans check this out... Message-Id: <447@burl.UUCP> Date: Tue, 24-Apr-84 12:06:35 EST Received: by hou3c.UUCP; Tue, 24-Apr-84 13:45:31 EST Organization: AT&T Technologies; Burlington, NC The guy who sent me this is on a broadband cable network with a wide variety of terminals, micros, minis, and dialups. Note the double 'ihnss': >>> From ihnp4!ihnss!ihnss!stevenso Tue Apr 24 09:57:34 1984 >>> Date: 24 Apr 84 09:57:34 CST (Tue) >>> From: ihnp4!ihnss!ihnss!stevenso >>> Message-Id: <8404241557.AA14981@ihnp4.ATT.UUCP> >>> Received: by ihnp4.ATT.UUCP; id AA14981; 24 Apr 84 09:57:34 CST (Tue) >>> To: ihnss!ihnp4!we13!burl!rcj >>> Re: micro networks Hmmm, I wonder what the address would have been from the far side of a ring network..... -- The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd clyde ]!burl!rcj  Received: from Semillon.ms by ArpaGateway.ms ; 28 APR 84 19:47:49 PST Date: 28 Apr 84 19:47:40 PST From: Murray.pa@XEROX.ARPA Subject: RFC821/822 updates/extensions To: Header-People@MIT-MC.ARPA Cc: Murray.pa@XEROX.ARPA Does anybody have a collection of updates and/or extensions to RFC821/822 that are needed by a real world mail system? I already know about SMTP reply code of 050, MAIL FROM <>, full words for days and months, BST for a time zone, "."s in the phrase part of a route-addr, and name "at" host. How many more krocks/tweaks are there in common use that I don't (yet) know about?  Date: 29 Apr 1984 01:06:02-EST From: allegra!hou3c!burl!ulysses!harpo!decvax!ittvax!dcdwest!sdcsvax!bmcg!cepu!scw at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA23439; Wed, 25 Apr 84 18:06:02 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 5/3/83; site cepu.UUCP From: allegra!cepu!scw Subject: Re: Malformed headers Message-Id: <233@cepu.UUCP> Date: Tue, 24-Apr-84 15:51:14 EST Received: by hou3c.UUCP; Wed, 25-Apr-84 13:13:55 EST References: <488@hou3c.UUCP> In-Reply-To: <488@hou3c.UUCP> Organization: VA Wadsworth Med. Center, LA CA There is another way: Mail that goes to ARPA net sites should just be forwarded to (or torwards a ARPA site), putting your site name in the return path, and without modifying the destination path. Once the message reaches an ARPA site the @site.ARPA is removed and the ARPA site turns the return path into an arpa address by putting @orig.ARPA at the end of the path, this MUST inhibit the uucp forwarder(s) (once back in uucp land) from further munging the path. The message is then forwarded to the appropiate ARPA (from the To: field) site, from there it is treated as a normal uucp message. synopsis: a message from litvax!sender to dartvax!user via arpa land step 0 (original message): to: decvax!dartvax!user@ucbvax.ARPA from: sender -------the litvax mailer forwards mail to a cooperating system (cepu) step 1 (as recieved by cepu): to: decvax!datrvax!user@ucbvax.ARPA from: litvax!sender -------cepu forwards to a known ARPA site (ucla-locus) step 2 (as recieved by ucla-locus): to: decvax!dartvax!user@ucbvax.ARPA from: cepu!litvax!sender -------message goes via ARPA (unspecified path) to ucb-vax step 3 (As recieved by ucbvax): to: decvax!dartvax!user from cepu!litvax!sender@ucla-locus.ARPA -------ucbvax forwards to next site (decvax) step 4 (as recieved by decvax): to: dartvax!user from: cepu!litvax!sender@ucla-locus.ARPA -------decvax forwards to dartvax step 5 (as recieved by dartvax): to: user from: cepu!litvax!sender@ucla-locus.ARPA The nice thing about this is that systems only need to know 2 things about the ARPA net. (1) it exsists, and (2) the name of a site closer to the ARPA net than they are. Smart sites could rerout ARPA bound mail to a host known to be up, dumb sites would just try to send to to a fixed host. mail headers of course must conform to RFC822 (or which ever) but it doesn't require a WHOLE lot of hacking to postman/deliver_mail/what_ever to add the ability to reconize a ARPA style address and to not mung forward path, forward with back path or mung address, not touch back path. Note that mail systems on the ARPA net seem to handle mail like this already (I have succesfully send mail to decvax from cepu) in addition litvax and ucla-cime both forward mail to/from ARPA land through my site. -- Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology) uucp: { {ihnp4, uiucdcs}!bradley, hao, trwrb, sdcsvax!bmcg}!cepu!scw ARPA: cepu!scw@ucla-locus location: N 34 06'37" W 118 25'43"  Date: 29 Apr 1984 01:06:09-EST From: allegra!hou3c!burl!ulysses!harpo!decvax!mcvax!enea!erix!robert at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA09340; Fri, 27 Apr 84 19:59:52 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83 (MC840302); site erix.UUCP From: allegra!erix!robert (Robert Virding) Subject: Re: "blaming Unix SendMail" Message-Id: <343@erix.UUCP> Date: Wed, 25-Apr-84 13:52:00 EST Received: by hou3c.UUCP; Thu, 26-Apr-84 20:17:19 EST References: <487@hou3c.UUCP> In-Reply-To: <487@hou3c.UUCP> Organization: L M Ericsson, Stockholm, Sweden Of course the best method is to have a human readable form which is then parsed into a binary file which sendmail can read. The advantages are obvious. Is there any valid reason why this hasn't been done? "We don't do things int that way on UNIX" is not a valid reason! Robert Virding  Date: 29 Apr 1984 01:06:15-EST From: allegra!hou3c!burl!ulysses!harpo!seismo!ut-sally!smoot at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA09349; Fri, 27 Apr 84 20:00:02 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site ut-sally.UUCP From: allegra!ut-sally!smoot (Smoot Carl-Mitchell) Subject: Re: "blaming Unix SendMail" Message-Id: <2137@ut-sally.UUCP> Date: Fri, 27-Apr-84 09:44:57 EST Received: by hou3c.UUCP; Fri, 27-Apr-84 13:49:07 EST References: <487@hou3c.UUCP> <343@erix.UUCP> In-Reply-To: <343@erix.UUCP> Organization: U. Texas CS Dept., Austin, Texas > Of course the best method is to have a human readable form which is then > parsed into a binary file which sendmail can read. The advantages are > obvious. > > Is there any valid reason why this hasn't been done? "We don't do things > int that way on UNIX" is not a valid reason! > > Robert Virding I think this is a good idea in general. I have some thoughts on such an endeavor, but do not have the time to devote to it. I also want to see how domain based addressing evolves before tackling such a task. I think it is comparatively easy to at least make the syntax of a configuration file human readable. I too get tired of all the "$*$-$+" stuff. -- Smoot Carl-Mitchell, CS Dept. University of Texas at Austin {seismo, ctvax, ihnp4}!ut-sally!smoot, smoot@ut-sally.{ARPA, UUCP}  Date: Mon, 30 Apr 84 9:52:22 EDT From: Ron Natalie To: Header-People@Mit-Mc.ARPA Subject: Re: Malformed headers This is fine except that in STEP 3, you've saddled UCB-VAX with an illegal "TO" line as far as the 822 spec goes (although I'm pretty sure UCB vax can handle it). -Ron  Date: Tue, 1 May 84 03:33 EDT From: Barry Margolin Subject: Re: Malformed headers To: ron@BRL-TGR.ARPA cc: header-people@MIT-MC.ARPA Message-ID: <840501073320.124744@MIT-MULTICS.ARPA> Ron, there is nothing wrong with the TO line in step 3. There is nothing in RFC822 that prohibits a local-part of the form "string1!string2!string3", and UCB-VAX is free to interpret it any way it wishes, and it wishes to interpret it as a Usenet address. barmar  Date: Tue, 1 May 84 03:39 EDT From: Barry Margolin Subject: Re: Malformed headers To: header-people@MIT-MC.ARPA Message-ID: <840501073922.688491@MIT-MULTICS.ARPA> Of course, the real problem with Stephen Woods' suggestion is that it assumes that a Usenet site can figure out how to get the mail to the UUCP-Arpa gateway without requiring the user to specify the route explicitly. If they had this capability then it would only be a small step to not requiring explicit paths for anything, and they could then use domain addressing, and there would be no problem of ambiguous syntax to solve. barmar  Date: Tue, 1 May 84 16:10:25 EDT From: Ron Natalie To: Barry Margolin cc: ron@brl-tgr.arpa, header-people@mit-mc.arpa Subject: Re: Malformed headers But an address must have soething to the right of the "@" and must contain the "@" as well! -Ron  Date: Tue, 1 May 84 16:44 EDT From: Barry Margolin Subject: Re: Malformed headers To: Ron Natalie cc: header-people@MIT-MC.ARPA In-Reply-To: Message of 1 May 84 16:10 EDT from "Ron Natalie" Message-ID: <840501204450.711421@MIT-MULTICS.ARPA> Date: 1 May 1984 16:10 edt From: Ron Natalie Subject: Re: Malformed headers But an address must have soething to the right of the "@" and must contain the "@" as well! -Ron Once a messagessed to foo@bar is received by bar it may convert the address into any internal form it pleases, which generally begins by removing the "@bar". After UCLA-LOCUS forwards the message to UCB-VAX it is no longer in an SMTP environment, so @'s are no longer needed. Perhaps the wording of the steps was misleading, and I was inferring something different from you. It says that the header in step 3 was the way the message was received by UCB-VAX. I interpreted that to mean that this was what the header looked like after UCB-VAX received and munged it. Anyway, we are arguing minor semantics. The point of the message is obvious: UUCP hosts are all expected to know a route to an Arpa gateway, so the explicit route (with !'s) only has to be specified for the part of the route after traversing the Arpanet. As I said in a previous message, this is not realistic. What is to stop hosta from thinking hostb is closer to the Arpanet and vice-versa, causing all Arpa mail from or thru either host to loop forever? barmar  Received: by sri-tsc.arpa at Thu, 3 May 84 01:14:10 pdt Message-Id: <8405030814.AA04439@sri-tsc.arpa> Date: 3 May 1984 0114-PDT (Thursday) From: Greg Satz To: header-people@mc Cc: Subject: bogus headers Why are illegal mail headers being sent out by MIT-VAX? Particularily, the dual from line is rather annoying. ------- Forwarded Message Return-Path: <@MIT-MC:allegra!hou3c!ka@MIT-VAX> Received: from MIT-MC (mit-mc.arpa) by sri-tsc.arpa at Tue, 24 Apr 84 00:03:44 pst Date: 24 Apr 1984 02:22:53-EST From: allegra!hou3c!ka@mit-vax Received: by allegra.UUCP (4.12/4.7) id AA04407; Mon, 23 Apr 84 15:46:26 est To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP From: allegra!hou3c!ka (Kenneth Almquist) Subject: Re: Malformed headers Message-Id: <479@hou3c.UUCP> Date: Fri, 20-Apr-84 18:24:10 EST In-Reply-To: <8404201601.AA05840@wisc-crys.arpa> Organization: Bell Labs, Holmdel, NJ UUCP mail does not conform to RFC 822. (Actually, no written standard for UUCP mail exists, which is one reason for trying to phase it out.) Context-sensitive parsing is not an "ad hoc" solution; it is a recog- nition of this situation. It should be possible to write mail gateway software that will leave all the exclamation points on the UUCP side. E. g. this mail could be given a from line reading "From: ka@hou3c.UUCP" and a return path reading "Return-Path: <@mit-vax.ARPA,@allegra.UUCP:ka@hou3c.UUCP>". Alternatively, the full return path could be included in the from line as well as the return path line. Are either of these approaches reason- able? How many existing mailers will be able to reply to such letters? Kenneth Almquist ------- End of Forwarded Message  Date: 3 May 1984 05:23:01-EDT From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!drutx!houxe!hogpc!pegasus!hocsd!jis at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA21566; Wed, 2 May 84 23:55:22 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.PCS 1/10/84; site hocsd.UUCP From: allegra!hocsd!jis Subject: Re: Malformed headers Message-Id: <229@hocsd.UUCP> Date: Wed, 2-May-84 13:10:28 EDT Received: by hou3c.UUCP; Wed, 2-May-84 22:11:01 EDT Organization: AT&T Information Systems Labs, Holmdel NJ SENT-BY: j.mukerji CC: Margolin@MIT-MULTICS.ARPA --------------------------------------------------------------------------- Of course, the real problem with Stephen Woods' suggestion is that it assumes that a Usenet site can figure out how to get the mail to the UUCP-Arpa gateway without requiring the user to specify the route explicitly. If they had this capability then it would only be a small step to not requiring explicit paths for anything, and they could then use domain addressing, and there would be no problem of ambiguous syntax to solve. --------------------------------------------------------------------------- Some mailers in the UUCP world already do that, like the one that is being used for mailing this message does. This one is driven by a set of network configuration tables, which are updated periodically. Jishnu Mukerji AT&T ISLab Holmdel NJ jis@hocsd.UUCP  Received: by harvard.UUCP (4.12/4.27) id AA13807; Sun, 6 May 84 14:36:15 edt Date: Sun, 6 May 84 14:36:15 edt From: morris@harvard (Free Advice) Message-Id: <8405061836.AA13807@harvard.UUCP> To: header-people@mit-mc What are the prospects on official words about top-level domains other than ARPA? Seems to me there is a conflict here. In order to make addresses absolute, all hosts have to know about all top-level domains. If more domains, eg BITNET, UUCP, etc., are officially added, then official recognition, if not permission, between the Arpanet and non-DDN nets is implied. If no domains at the level of ARPA are added, then the domain naming scheme is almost worthless. People on the arpanet don't need domains, since .ARPA is default and each host knows about every other one (not strictly true, but mosher%ucbarpa@Berkeley is absolute without being domain based). Addresses bound from the arpanet to nets which aren't subsets of the arpanet will either be absolute without being domain based (uucphost!user@Berkeley), or will be domain based but not absolute (user@host.BITNET works from here, but not from most arpanet hosts). Any ideas on how this may be resolved? Robert Morris, morris@harv-10.  Date: 7 May 1984 11:12:36 PDT From: POSTEL@USC-ISIF Subject: re: Domains To: morris@HARVARD cc: header-people@MIT-MC Robert Morris: Have your read the RFCs on domains (881, 882, 883, 879)? Other top level domains will be added. There are several requirements that have to be met for something to be a domain. First, since domains are administrative entities they have to have a responsible management - there has to be an individual in charge of the domain. Second, there have to be lookup servers for the domain data provided - this has to be very robust. Third, the domain must have some minimum size - at the top level probably 100s of hosts. Fourth, the top level domains have to be registered with the NIC. Another RFC on "domain requirements" is in the works. --jon. -------  Received: by harvard.UUCP (4.12/4.27) id AA04840; Mon, 7 May 84 20:55:02 edt Date: Mon, 7 May 84 20:55:02 edt From: morris@harvard (Robert Morris) Message-Id: <8405080055.AA04840@harvard.UUCP> To: postel@isif Subject: Domains. Cc: header-people@mc Thank you, Jon, for your letter and information. I read rfc883 and admit to being confused. How much of 883 deals with looking up host numbers (possibly to send mail), and how much deals strictly with mail? For instance, does one really need a name server for a domain which is not on the internet, and thus only accessible through a mail (only) gateway. In particular, I would like to register a top level domain with a couple of hundred hosts. There are a few people here who already have big databases describing it, and are trying to keep them up to date. We can control the format and so forth of messages going onto the arpanet. What I need is clarification of what the name servers are for; I'm not sure what in rfc883 applies to domains with a single gateway and no internet host tables. Thank you, Robert Morris (morris@harv-10)  Date: 7 May 1984 19:47:40 PDT From: POSTEL@USC-ISIF Subject: re: domains To: morris@HARVARD cc: header-people@MIT-MC Robert: Enclosed is a note i recently sent to the Namedroppers list that addresses the point you raise. (To join Namedroppers send a request to "Namedroppers-Request@SRI-NIC.ARPA".) In general, what ever information you want hosts in the ARPA-Internet to be able to resolve has to be available in lookup name servers accessible via ARPA-Internet protocols. If it is sufficient that the only thing that can be done is find the Internet Address of the relay host into your domain then the database is simply the entry mapping "*.DOMAIN" into "Relay-Host-Address". If you want ARPA-Internet hosts to be able to determine before sending mail that the destination host actually exists, then a full database to the host level is needed. If you want ARPA-Internet hosts to be able to check if the recipient mailbox is valid and to determine if there is a forwarding address etc, then a database to that level of detail must be available. --jon. Date: 3 May 1984 20:07:38 PDT From: POSTEL@USC-ISIF Subject: Inter-Enviromnent Name Service Hi: There are two parts to the domain name system. The first is the introduction of domain style names. The second is the introduction of domain name lookup service. In both cases, the design is intended to be widely applicable in a variety of communication environments, not just the ARPA-Internet. We have a reasonable expectation that the domain style names will be used in a variety of environments. We have (so far) little reason to expect that the domain name lookup service will be implemented in any environment other than the ARPA-Internet. However, for a host in the ARPA-Internet to make use of a domain style name (from any environment) that host must be able to lookup that name using the domain name service via ARPA-Internet protocols. This means that every domain style name from any environment that is to be meaningfull to ARPA-Internet hosts must be listed in some domain name lookup server in the ARPA-Internet. Suppose there were some domain (let us call it XYZ) in some environment (let us call it PQR) not even sharing any common element with the ARPA-Internet or any of the domains overlapping the ARPA-Internet, yet communication between hosts in XYZ and hosts in the ARPA-Internet is possible via some third parties. For this communication to be possible, some domain name lookup servers in the ARPA-Internet would have to be able to answer queries about host names in the XYZ domain. At first blush, this would seem to require that a complete detailed and up-to-date copy of the database of hosts from the XYZ domain would have to be maintained in a domain name lookup server in the ARPA-Internet, at locations possibly far removed from any part of the XYZ domain. But, what is the necessary information in this database? If, as is likely, all the communication between ARPA-Internet hosts and hosts in the XYZ domain is routed via a particular relay host, then all the entries in the database will point to that relay host. If it is desired to verify that a particular host name in the XYZ domain is valid, then the full database is required. If it is sufficient to find the address of the relay to the XYZ domain, then the database can be a single entry for the name "*.XYZ" with the address of the relay host. That is, any query with a domain style name ending in ".XYZ" will match the entry, and will receive a reply indicating the relay host. Please notice that the situation is symmetric. If the XYZ domain hosts used a procedure similar to that of the ARPA-Internet hosts in resolving host names then the domains overlapping the ARPA-Internet would have to provide databases describing their domains in a form suitable to the name servers of the PQR environment. --jon. -------  Date: 7 May 1984 23:00:56-EDT From: allegra!hou3c!burl!clyde!akgua!sdcsvax!bmcg!cepu!scw at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA03641; Sun, 6 May 84 13:10:57 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site cepu.UUCP From: allegra!cepu!scw Subject: Re: routing *TO* ARPA.NET (changed title) Message-Id: <249@cepu.UUCP> Date: Fri, 11-May-84 01:09:08 EDT Received: by hou3c.UUCP; Sat, 5-May-84 22:23:08 EDT References: <229@hocsd.UUCP> In-Reply-To: <229@hocsd.UUCP> Organization: VA Wadsworth Med. Center; LA CA Two reasonable points have already been raised about my proposal. 1) What is to keep site a from thinking that site b is a vector to the ARPA-net and vice-versa, causing a loop. Well, I can think of several (1) cooperating systems with hardwired paths (not elegant but it works reasonably well, this is what is currently in use around ucla). (2) Looking at the path (don't send it back to someone that just (or somewhere) had it) this is reasonable, and perhaps should be a part of any system (3) Routing tables, updated regulary/periodicly. I would suspect that (3) is the best way to go. Especially if we can implement some reasonable mechanisim for detecting undelivered messages, picking them up and forwarding/rerouting them, and perhaps a method of automagicly reconfigureing the routing tables. 2) This implies that any site need to know how to get to any site on the ARPA-NET. The implication is that this is most of the intra-uucp routing problem. The nice part of this delivery system is that there is NO one ARPA-NET routing center, by definition *ANY* ARPA host has a complete routing table. This is possiable for several reasons. (1) A limited (semi-fixed) number of sites, unlike uucp.anarchy where systems come and go almost at will, it takes: (2) A central control point that assigns site numbers (and approves names??), and limits access to (membership on) the net. (3) Each site has a FIXED name (number actually) and there is hardware (IMPs?/TIPs?) that does the actual routing of packets (this is all hearsay, from quite a while ago, and third hand at that). NOTE: This is not attempting to address the problem of intra-uucp domain addressing, it is only a suggestion for the problem of inter-domain communications (messages that cross the ARPA-NET/uucp.anarchy) boundry with some specific path information. -- Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology) uucp: { {ihnp4, uiucdcs}!bradley, hao, trwrb, sdcsvax!bmcg}!cepu!scw ARPA: cepu!scw@ucla-locus location: N 34 06'37" W 118 25'43"  Date: 7 May 1984 23:01:00-EDT From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!stolaf!sys at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA03655; Sun, 6 May 84 13:11:07 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site stolaf.UUCP From: allegra!stolaf!sys (System Management) Subject: UUCP style From lines Message-Id: <1687@stolaf.UUCP> Date: Sat, 5-May-84 14:46:30 EDT Received: by hou3c.UUCP; Sun, 6-May-84 07:00:53 EDT Organization: St. Olaf College, Northfield MN I am trying to bring sendmail up at stolaf and am having problems with the UUCP from lines. I can't seem to get sendmail to either (a) keep the old From lines or (b) build a From line with what is on the From: line. I am using 4.2 Mail as rmail. Can any one out there give me some help? Thanks in advance, -Paul R Borman St. Olaf College ...{ihnp4,decvax}!stolaf!agnes!paul  Date: 10 May 1984 16:56:01 PDT From: POSTEL@USC-ISIF Subject: BATCH SMTP ? To: header-people@MIT-MC I remember talking to some people about a "batch mode" for smtp. I can't find my notes about it any more. Does anyone remember it? Can you give me a pointer to the people who were working on it? --jon. -------  Date: Fri, 11 May 84 16:11:42 PDT From: sventek@lbl-ws.arpa Message-Id: <840511161118.001@lbl-ws.arpa> Subject: Re: Batch SMTP? To: postel@usc-isif.arpa cc: header-people@mit-mc.arpa, mo@lbl-csam.arpa Jon, The original proposal for batch mode SMTP was made by Mike O'Dell while he was here at LBL. He can be reached at mo@lbl-csam.arpa. It turns out that his ideas were adopted for use in BITNET. Maybe someone else on the list can point you to the document describing their batch mode variant. Joe Sventek  Date: Fri, 11 May 84 19:48:44 EDT From: Ron Natalie To: POSTEL@usc-isif.arpa cc: header-people@mit-mc.arpa Subject: Re: BATCH SMTP ? What I recall is that the BITNET mailer uses something called BSMTP. Since all they have is file transfer, they transfer a file with the SMTP commands and then get one back with the replies. Solomon from UWISC mentioned it at the gateway meeting. It comes to mind that it was Alan Crosswell from Columbia (EACUS@CUVMB on bitnet) who wrote it. -Ron  Date: Mon, 14 May 84 16:35:20 PDT From: sventek@lbl-ws.arpa Message-Id: <840514163434.005@lbl-ws.arpa> Subject: RFC822 clarification To: header-people@mit-mc.arpa While using a compiler-compiler to replace my ad hoc address parser with a complete one, I came across an aspect of the RFC822 address specification which puzzles me. The offending lines follow mailbox = addr-spec | phrase route-addr route-addr = "<" [route] addr-spec ">" phrase = 1*word word = atom | quoted-string This indicates that if an user wishes to use a "route-addr" form of address, at lease one "word" must precede it. This seems rather silly, since the "phrase" preceeding the "route-addr" has no semantic value what-so-ever. What have others done in this case? In my current ad hoc parser, I do not require it, in apparent violation of the specification. I suppose I can force this restriction upon my users, or automatically generate the atom Useless Atoms preceeding each "route-addr". Joe Sventek  Date: Mon, 14 May 84 22:04:00 EDT From: Doug Kingston To: sventek@lbl-ws.arpa cc: header-people@mit-mc.arpa Subject: Re: RFC822 clarification The MMDF parser does indeed enforce the restriction that there be at least one atom before a route-addre specification. If you don't require this, you are asking for trouble when the mail leaves your host. It may be silly, but its in the spec, Sigh. Cheers, -Doug- PS. When you get your parser done, I'd love to see it....  Date: 14 May 1984 21:09:31 PDT From: POSTEL@USC-ISIF Subject: Batch SMTP To: header-people@MIT-MC Thanks to all those who sent me information or references for Batch SMTP. It is indeed a batch style use of SMTP to deliver a bunch of messages in one direction and sometime later receive a bunch of responses. It was created and evolved by Mike O'Dell, Greg Minshall, and Alan Crosswell. It is used in some parts of BITNET, particularly at Berkeley. A six page description of it was prepared by Alan Crosswell. --jon. -------  Date: Tue, 15 May 84 11:08:38 EDT From: Ron Natalie To: sventek@lbl-ws.arpa cc: header-people@mit-mc.arpa Subject: Re: RFC822 clarification Your understanding is correct. I've run into machines that gag when you give the address inside "< >" and don't have the phrase in front. -Ron  Date: Tue, 15 May 84 16:00:39 cdt From: smoot@ut-sally.ARPA (Smoot Carl-Mitchell) Posted-Date: Tue, 15 May 84 16:00:39 cdt Message-Id: <8405152100.AA23211@ut-sally.ARPA> Received: by ut-sally.ARPA (4.22/4.22) id AA23211; Tue, 15 May 84 16:00:39 cdt To: header-people@mit-mc.ARPA Subject: add to mailing list Please add me to the mailing list.  Date: Tue, 15 May 84 19:24:28 PDT From: Rich Wales To: Joe Sventek CC: Header-People@MIT-MC.ARPA Subject: Re: RFC822 clarification (token before "route-addr") In-reply-to: Joe Sventek's message of Mon, 14 May 84 16:35:20 PDT Joe -- I agree with you that requiring a "phrase" token before a "route-addr" makes no sense. This was almost certainly an oversight in the specifi- cation. However, the fact remains that this is the way the standard was written, and some mail systems (such as MMDF, apparently) do demand that this part of the standard be obeyed strictly. At this stage of the game, I'm afraid that no amount of protest is going to result in any changes to RFC822, however trivial they may seem (I know -- I've tried). Given this reality, I would suggest the following course of action: (1) When analyzing the headers in incoming mail, if you see an address consisting of a "route-addr" without a preceding "phrase", go ahead and accept it. Some people, I know, may protest that the only way to enforce compliance with the standard is to adamantly complain about any and all violations; I choose not to take such a stand. (2) When processing outgoing mail, if you see an address consisting of a "route-addr" without a preceding "phrase": (a) If the address is not a "source route" of the form <@A:B@C>, simply strip off the angle brackets; they are unnecessary. (b) If the address is a "source route", then you really should add something in front of the address; for lack of anything better, I would suggest copying the "local-part" of the address. That is, an address like <@UCLA-LOCUS.ARPA:wales@UCLA-CS.ARPA> would become wales <@UCLA-LOCUS.ARPA:wales@UCLA-CS.ARPA> While you're at it, by the way, I would suggest a similar approach to the question of "phrase"s with periods in them. That is, an address like Richard B. Wales violates the standard because of the period after the initial. This restriction has a little bit more to say in its favor (it seems that allowing the period would complicate the parser and/or the lexer), but enough hosts still generate such constructions -- whether out of lazi- ness, rebellion, or lack of time, I will not venture a guess -- that it is reasonable to recognize and accept them on incoming mail if possible. (The appropriate action in the case of outgoing mail is to put double quotes around the "phrase".) -- Rich  Date: Wed, 16 May 84 08:36:46 cdt Message-Id: <8405161336.AA10157@wisc-crys.arpa> Received: by wisc-crys.arpa (4.22/3.7) id AA10157; Wed, 16 May 84 08:36:46 cdt To: header-people@mit-mc.arpa Subject: what to do with (as yet) illegal domains Cc: ibm-project@wisc-crys.arpa Sender: forwarder@wisc-crys.arpa From: solomon@wisc-crys.arpa We are in the process of setting up a BITNET/CSNET mail forwarder and are trying to figure out the best way to munge addresses of mail from BITNET to ARPANET. When we get the mail, we expect it to have an 822 header (actually 733, but that's another story) with something like USER@BNETHOST in the From: field. We intend to munge it to something like EITHER (1) <@WISCVM.ARPA:USER@BNETHOST.BITNET> (yes, I guess with some noise before the "<"), OR (2) USER%BNETHOST.BITNET@WISCVM.ARPA (Of course, we expect to accept either form.) Alternative (1) adheres better to the spirit of current Arpanet standards, while (2) adheres to de facto current practice, as well as the current letter of the law, since the "illegal" domain ".BITNET" appears only as part of the local part of the address. Ultimately, of course, we'd like to set up a BITNET domain (I don't care if it's a top-level or lower-level domain) complete with a full Domain Name Server, and allow Internet users simply to type USER@BNETHOST.BITNET.EDU (or whatever). Does anybody have any opinions about this? Would anybody mind if a source-route has an unknown domain in other than the first position?  Received: from EDUCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2631046869802761@MIT-MULTICS.ARPA>; 16 May 1984 18:21:09 edt Date: 15-MAY-1984 12:45 EST From: OBERST%EDUCOM.MAILNET@MIT-MULTICS To: HEADER-PEOPLE@MIT-MC.ARPA Subject: REF: SVENTEK@LBL-WS.ARPA "RFC822 clarification" there was a heated exchange a while back on header-people on the point you raised. It got started off with complaints about having to quote names which used middle initials (and a period) as the phrase. You're right, if you want to used a rout-addr, you should put a 'phrase' in front. Thus if you want to construct a path for a reply from header information, you would be forced to insert 'phrase'. Normally this is a person's first&last name, but I suppose one could put in something like The following is a route address ******  Date: Wed, 16 May 84 13:45:02 EDT From: G B Reilly To: solomon@wisc-crys.arpa cc: header-people@mit-mc.arpa, ibm-project@wisc-crys.arpa Subject: Re: what to do with (as yet) illegal domains We've been set up to accept both BITNET and MAILNET addresses for some time now. The position we take is that addresses destined for the Internet should be of the form: name%BTHOST.BITNET@UDEL-RELAY.ARPA But, in inbound mail we accept this form, and the "name@BTHOST.BITNET" as destined for the mailnet site (remember that all that is left of the ":" is informational only.) Brendan  Date: 17 May 1984 23:35:37-EDT From: allegra!hou3c!burl!clyde!akgua!psuvax!jdi at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA00340; Thu, 17 May 84 17:34:45 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.08 10/3/83; site psuvax.UUCP From: allegra!psuvax!jdi (John D. Irwin) Subject: Re: Batch SMTP Message-Id: <1061@psuvax.UUCP> Date: Wed, 16-May-84 13:39:09 EDT Received: by hou3c.UUCP; Thu, 17-May-84 07:30:29 EDT References: <573@hou3c.UUCP> In-Reply-To: <573@hou3c.UUCP> Organization: Pennsylvania State Univ. I really must mention here that one of the developers of BSMTP (Batch Simple) is Dr. Robert Owens here at PSU. He wrote it mainly to handle mail through the BITNET, since he also wrote the Unix BITNET software. Unfortunately, it doesn't handle non-smart uucp sites very well so we still run delivermail (or sendmail). -- Spoken: John D. Irwin AT&T: 814-237-5068 Bitnet: jdi@psuvax1.BITNET Csnet: jdi@penn-state.CSNET Uucp: {akgua, allegra, cornell, princeton, ihnp4, burdvax}!psuvax!jdi  Date: 19 May 1984 18:46:52-EDT From: allegra!hou3c!burl!mgnetp!ihnp4!fortune!rpw3 at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA08992; Sat, 19 May 84 14:13:47 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP From: allegra!fortune!rpw3 Subject: Re: what to do with (as yet) illegal dom - (nf) Message-Id: <3358@fortune.UUCP> Date: Sat, 19-May-84 04:04:47 EDT Received: by hou3c.UUCP; Sat, 19-May-84 12:49:55 EDT Sender: allegra!fortune!notes Organization: Fortune Systems, Redwood City, CA #R:wisc-cry:1297456416:fortune:28400003:000:716 fortune!rpw3 May 18 21:17:00 1984 +--------------- | ...We intend to munge it to something like EITHER | | (1) <@WISCVM.ARPA:USER@BNETHOST.BITNET> | (yes, I guess with some noise before the "<"), OR | (2) USER%BNETHOST.BITNET@WISCVM.ARPA | | ...Does anybody have any opinions about this? Would anybody mind if | a source-route has an unknown domain in other than the first position? +--------------- Having just composed a long ramble in "net.mail" on quoting, I wonder why the following would not be both legal and preferred: (3) "USER@BNETHOST.BITNET"@WISCVM.ARPA Rob Warnock UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065  Date: Sun, 20 May 84 07:51:53 cdt Message-Id: <8405201251.AA29512@wisc-crys.arpa> Received: by wisc-crys.arpa (4.22/3.7) id AA29512; Sun, 20 May 84 07:51:53 cdt To: header-people@mit-mc.arpa Subject: Internet->USENET gatewaying Cc: dave@wisc-crys.arpa Sender: forwarder@wisc-crys.arpa From: solomon@wisc-crys.arpa I submitted an item to this group (header-people@mit-mc.arpa) and got an echo back through the net.mail.headers USENET group. (For anyone who doesn't know, USENET is a sort of distributed bulletin-board system largely (but not entirely) supported by UNIX hosts and the UUCP mail network). From the USENET header (cf. RFC850), it appears that the message was relayed into the USENET system by UUCP host hou3c: Path: crystal!uwvax!seismo!harpo!ihnp4!mhuxl!ulysses!burl!hou3c!solomon@wisc-crys.arpa (the entire header is reproduced below). My question is this whether anyone in UUCP-land can reply to me by mail based on the information in the header. Assuming you could somehow get mail to hou3c with my ARPANET address in the header and/or envelope, would hou3c be able to send it to me through the Internet? More specifically, if someone at (say) ihnp4 sent mail to mhuxl!ulysses!burl!hou3c!solomon@wisc-crys.arpa what would happen? I can't run the experiment here because of the well-known problem with the ambiguity of a!b@c: If I send to the path mentioned above, my local mail system would parse it as "host: wisc-crys.arpa; local-part: crystal! ... !burl!hou3c!solomon". Since I don't have an account at hou3c, that's surely not right. If you want to reply to me, try: Internet or CSNET: solomon@uwisc UUCP: ... !{allegra,seismo,ihnp4,ucbvax}!uwvax!solomon From uwvax!seismo!harpo!ihnp4!mhuxl!ulysses!burl!hou3c!solomon@wisc-crys.arpa Wed May 16 08:36:46 1984 Relay-Version: version B 2.10.1 6/24/83; site crystal.ARPA Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP Path: crystal!uwvax!seismo!harpo!ihnp4!mhuxl!ulysses!burl!hou3c!solomon@wisc-crys.arpa From: solomon@wisc-crys.arpa Newsgroups: net.mail.headers Subject: what to do with (as yet) illegal domains Message-ID: <8405161336.AA10157@wisc-crys.arpa> Date: Wed, 16-May-84 08:36:46 CDT Date-Received: Wed, 16-May-84 19:55:54 CDT Sender: ka@hou3c.UUCP (Kenneth Almquist) Lines: 22 To: header-people@mit-mc.arpa Cc: ibm-project@wisc-crys.arpa < body deleted >  Date: 22 May 1984 23:25:17-EDT From: allegra!hou3c!burl!ulysses!allegra!princeton!tilt!smw at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA16772; Mon, 21 May 84 15:17:06 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site tilt.UUCP From: allegra!tilt!smw (Stewart Wiener) Subject: new BITNET site Message-Id: <122@tilt.UUCP> Date: Sun, 20-May-84 15:34:56 EDT Received: by hou3c.UUCP; Mon, 21-May-84 14:56:53 EDT Organization: Princeton Univ. EECS Just a friendly reminder to the BITNET gateways out there -- especially Penn State and Berkeley! -- do you have the new BITNET site PUCCUTS in your site tables? It's a satellite of PUCC, running Amdahl UTS. -- Stewart Wiener / Princeton Univ. EECS / UUCP: princeton!tilt!smw ARPA: princeton!tilt!smw@seismo BITNET: q2933@puccuts  Received: from NJIT-EIES by MIT-MULTICS.ARPA with Mailnet id <2631638850747017@MIT-MULTICS.ARPA>; 23 May 1984 14:47:30 edt Date: Wed, 23 May 84 8:42:45 EDT From: "Thomas A. Moulton" <995@NJIT-EIES> To: @MIT-MULTICS:Header-People@MIT-MC.ARPA Subject: BBS/CBMS Confiscation Message-ID: This is totally off the subject, but i just wanted to get a copy of this out into arpa, etc and is FYI (this also may show that the US laws need work...) C685 CC944 JACK POWERS (JACKP,218) 5/22/84 8:06 PM L:30 KEYS:/1984 IS HERE/EIES COULD BE A VICTIM TOO!/ -------------------- begin forwarded message -------------------- Subject: BBS Confiscation I think the following message retrieved from Compuserve deserves widespread circulation; no further explanation needed: --- #: 91655 Sec. 0 - Communications Sb: Important warning! 20-May-84 00:48:44 Fm: - tom tcimpidis 70250,323 To: all On May 16 I was served with a search warrant and my system seized because of a message that allegedly had been left, unknown to me, on one of the public boards. This was done by the L.A.P.D. under direction of a complaint by Pacific telephone. All Sysop's should be warned that under present law (or at least the present interpetation) they are now responsible for ALL information that is left or exchanged on their system and that ANY illegal or even questionable activities, messages or even public outpourings are their direct legal responsibility and that they will be held directly accountable regardless of wether or not they knew of it, used it, and regardless of any other circumstances! Yes, it is unjust. Yes, it is legally questionable. But it, for the moment, seems to be enforcable and is being "actively pursued" as a felony. Tom Tcimpidis - Sysop of The MOG-UR's HBBS (366-1238). Mailing: P.O. Box 5236, Mission Hills, CA 91345. I would appreciate it if this message was spread to as many systems as possible so that the word may be spread to the greatest number of Sysops. 1984 may, indeed, be here... ----  Received: from NJIT-EIES by MIT-MULTICS.ARPA with Mailnet id <2631686117243561@MIT-MULTICS.ARPA>; 24 May 1984 03:55:17 edt Date: Wed, 23 May 84 15:46:06 EDT From: "Thomas A. Moulton" <995@NJIT-EIES> To: @MIT-MULTICS:Header-People@MIT-MC.ARPA Subject: Addressing people across networks Message-ID: I like @HOSTA:USER@HOSTB best of the choices...  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA16681; Tue, 29 May 84 14:35:56 pdt Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.3/4.16) id AA11252; Tue, 29 May 84 14:36:36 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.16) id AA09099; Tue, 29 May 84 14:36:02 pdt Date: Tue, 29 May 84 14:36:02 pdt From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8405292136.AA09099@ucbopal.CC.Berkeley.ARPA> To: Header-People@mit-mc.ARPA Subject: SMTP for IBM VM It looks like there may finally be a SMTP for the IBM VM world. Bill Wells wcwells@Berkeley.ARPA ucbvax!wcwells ------------------------------------------------------------------------------ Message-Id: <8405290304.AA21094@wisc-rsch.arpa> Date: Mon, 28 May 84 22:04:16 cdt From: lhl @ wisc-rsch.arpa Sender: forwarder@wisc-rsch.arpa To: TCP-IP @ SRI-NIC Subject: Networking Software Available for IBM VM Computers Text: The University of Wisconsin has implemented the DOD Internet protocols (FTP/SMTP/Telnet/TCP/IP) for IBM VM systems under con- tract to IBM. This software package, called WISCNET, is owned by IBM. IBM has licensed Wisconsin to distribute WISCNET to univer- sities and colleges. Source code will be included with the dis- tribution, which will begin in mid-June. To receive WISCNET, a university or college must sign a license agreement with the University of Wisconsin and pay a one-time distribution fee of $500. Licenses may be obtained from and should be returned to: Lawrence H. Landweber Computer Science Department University of Wisconsin - Madison 1210 W. Dayton St. Madison, WI 53706 ARPANET, CSNET: landweber@wisc-rsch.ARPA UUCP: ...!{seismo,allegra,ihnp4}!uwvax!landweber Documents describing WISCNET will be sent with licenses. BRIEF OVERVIEW OF WISCNET WISCNET includes: (1) An implementation of the standard DOD protocols TCP and IP under VM/SP Release 2 or 3. (2) Implementations of the higher-level DOD protocols FTP, SMTP, and Telnet. (3) An interface between SENDFILE and SMTP. (4) Interfaces from IP to the Ethernet and Pronet local area networks (using a DACU as described below). (5) An interace from IP to the Telenet public data network (using a Series/1 as described below). TCP/IP runs in a separate disconnected virtual machine on the VM host. Similarly, each of SMTP, server FTP, and server Telnet occupies a dedicated virtual machine. User FTP and user Telnet run within a user's virtual machine under CMS. Virtual machines communicate with one another using the Virtual Machine Communication Facility (VMCF). The VM software is written almost entirely in Pascal, with a small amount of assembler-language support. Standard IBM-released software is used throughout (i.e., no modified or unreleased sys- tem software has been employed). Local area network interfaces are available for Pronet (Pro- teon Corp. - 10 Megabit/sec token ring) and Ethernet (Interlan - 10 Megabit/sec). The IBM host is connected to these local area networks via a Device Access Control Unit (DACU), which is a UNIBUS-to-channel adapter sold by IBM. There is also an inter- face to the Telenet public data network, using an X.25 implemen- tation running on a channel-attached Series/1 front end running the RPS operating system. The latter interface allows CSNET IBM VM hosts to connect to the DARPA Internet via Telenet. -------------END OF FORWARDED MESSAGE(S)-------------  Received: by mit-eddie.Mit-chaos.Arpa id AA10839; Sat, 2 Jun 84 03:17:19 edt Date: Sat, 2 Jun 84 03:17:19 edt From: Greg Skinner To: header-people@mc Subject: Date: field in UUCP mail I don't know if this has been discussed before, but has anyone noticed that mail sent between certain UUCP sites (I think the ones that run the 4.12/4.7 version) do not leave the original Date: filed of the sender but replace it with the Date: field of the relaying site? using arpanet mail because (sigh) our news link is converting to 4.2 ... --gregbo  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2632700137010041@MIT-MULTICS.ARPA>; 04 Jun 1984 21:35:37 edt Date: 01 Jun 84 16:18 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people@MIT-MC.ARPA Subject: Multiple SENDER-s? Message-ID: <57547@QZCOM> How strict is the RFC822 rule that a message can only have one SENDER. Example: User A forwards a message to RA, and user B forwards the same message to RB. To save transfer costs across the Atlantic, only one copy of the message is transferred, with both RA and RB as SMTP-receivers, and included in TO, CC or BCC fields. How would you advise me to handle this case? (At present I never generate any SENDER fields, just because I do not understand how to handle multiple sender-s.)  Date: 5 Jun 1984 11:29:06 PDT From: POSTEL@USC-ISIF Subject: multiple senders ? To: header-people@MIT-MC In the RFC 822 world a message has one sender. The "from" is the author or authors of the message. The "sender" is the clerk that pushed the final button that sent the message. When a message is forwarded it is really a new message and should have (at least) additional header fields added to indicate who did the forwarding and when (resent-sender, resent-from, resent-date). If two different people (say, Fred and Sam) get copies of a message and both forward it to a third person (say, Joe), then the third person (Joe) will get two copies -- but, he (Joe) will be able to see when and by whom each copy was forwarded. --jon. -------  Date: Thu, 7 Jun 84 16:42:04 EDT From: Ron Natalie To: header-people@mit-mc.ARPA cc: postmaster@rutgers.ARPA, postmaster@purdue.ARPA, postmaster@usc-eclb.ARPA, postmaster@dec-marlboro.ARPA, postmaster@bnl.ARPA, sun!l5!gnu@ucb-vax.ARPA Subject: Date format survey. Well, I thought I had a program for parsing RFC822 dates that worked pretty well incorporating some of the common illegal formats that are being used such as out of order days of week (I through it away), years greater than 100, spelled out month names, misplaced commas, etc... but I ran it on my current mail and the following hosts got caught: sun!l5@ucb-vax RUTGERS, PURDUE, USC-ECLB, DEC-MARLBORO, BNL The errors in these cases were either the lack of separation between the hours and minutes of the time (the colons are obligatory) or using hyphens to separate the day of month and year from the month name. -Ron  Received: by YALE-BULLDOG via CHAOS; Wed, 13 Jun 84 21:48:22 EDT Received: from YALE-RING by YALE-RES via CHAOS; Wed, 13 Jun 84 21:36:47 EDT Subject: SMTP "MAIL FROM:" Date: Wed, 13 Jun 84 21:36:53 EDT From: Nathaniel Mishkin To: header-people@MIT-MC.ARPA The SU-SHASTA.ARPA SMTP mailer likes to send out SMTP MAIL commands that look like: MAIL FROM: It turns out that for obscure reasons (that probably indicate a deficiency in my own mail system), the fact that it says "shasta" and not "su-shasta.arpa" screws me up. But is it not reasonable to expect that all addresses presented in the SMTP transaction are the official names, not nicknames? -- Nat  Date: Thursday, 14 Jun 1984 00:32-PDT To: Nathaniel Mishkin Cc: header-people at MIT-MC.ARPA , mann at Pescadero Subject: Re: SMTP "MAIL FROM:" In-Reply-To: Your message of Wed, 13 Jun 84 21:36:53 EDT. From: Steve Hartwell >> The SU-SHASTA.ARPA SMTP mailer likes to send out SMTP MAIL commands >> that look like: >> >> MAIL FROM: Not anymore. It now uses official names only. Yours ever vigilante, Steve Hartwell, Stanford (Hartwell@SU-SHASTA.ARPA, formerly Shasta)  Date: 6 Jul 1984 02:35:27-EDT From: allegra!hou3c!burl!we13!ihnp4!cbosgd!mark at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA06253; Fri, 6 Jul 84 01:11:47 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP From: allegra!cbosgd!mark (Mark Horton) Subject: Re: "blaming Unix SendMail" Message-Id: <1279@cbosgd.UUCP> Date: Tue, 17-Apr-84 20:23:25 EDT Received: by hou3c.UUCP; Thu, 5-Jul-84 23:37:45 EDT References: <474@hou3c.UUCP> In-Reply-To: <474@hou3c.UUCP> Organization: AT&T Bell Laboratories, Columbus Tell me, why does SendMail need such complex configuration files? Wouldn't a preferable scheme be to look at ones environment at runtime and do the right thing by default? This is a little like claiming your computer should "do the right thing by default" when presented with a null program. "The right thing" is highly subjective, and probably depends on reading someones mind. For example, how should "a!b@c" be interpreted? "(a!b)@c" as required by the ARPANET? "a!(b@c)" as required by existing UUCP software? Someone has to make a decision, and this decision must be implemented in the sendmail config file. In fact, "looking in ones environment" is done on UNIX largely by reading a file. Wouldn't such a file be called a config file? Sure, sendmail configuration files are complex. So is machine language. It doesn't mean that you shouldn't have any machine language on your machine. It means you write a compiler from a high level language. Sendmail's config files are very complex because they do so much. What should be done is for someone to write a simple compiler or interactive front end that asks a few questions and generates the appropriate file.  Date: 7 Jul 1984 22:06:36-EDT From: allegra!hou3c!burl!mgnetp!ihnp4!stolaf!sys at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA01318; Sat, 7 Jul 84 21:57:30 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site stolaf.UUCP From: allegra!stolaf!sys (System Management) Subject: double home address in From: line Message-Id: <1755@stolaf.UUCP> Date: Sat, 30-Jun-84 08:17:15 EDT Received: by hou3c.UUCP; Fri, 6-Jul-84 14:51:52 EDT Organization: St. Olaf College, Northfield MN In bringing up sendmail on a v7 machine, I did not define DAEMON, the result is that whenever I activate the "From:" line in the headers and send out mail, I get something like "From: stolaf!stolaf!bob (Bob)" instead of the appropriate "From: stolaf!bob (Bob)". (Also, on v7, doing "H?F?From: $q" and putting 'F' in the flags line for the mailer does not seem to work, I have to nuke the From: line by using "HFrom: $q". Has anyone else out there had these problems? (And preferable, if someone has, how do I fix them?) -Paul R Borman St. Olaf College {decvax,ihnp4}!stolaf!agnes!paul  Date: Mon, 9 Jul 84 7:15:26 EDT From: Dave Crocker To: Header-People@mit-mc.ARPA Subject: RFC 822 history Over the past few months, there were some items about the history of some decisions that were made in 822. While you all have not doubt moved on to more weighty matters, I just read the messages and thought a bit of clarification might be useful. In a feeble attempt to head off some of the likely comments, let me add the caveat that what follows is reporting, only. The hindsight of experience may well lead you to (continue to) wish for different choices. The naming of 'Resent-X' was the result of a small effort at political sensitivity. 'Remail-xx' and 'Redistribute-xx' were already in use and the choice of either one could have led the other to have felt slighted. In retrospect, I rather like the source of humor that seems to have resulted. Requiring a phrase, before a route-address was a more personal (and obscure) choice. My feeling was that addresses which have as much text as an address with full routing information would be essentially unreadable. It therefore would be considerate to the recipient(s) to separate the address information from the reference to the 'name' of the person owning the cited mailbox. One note on this issue indicated that the prefatory phrase had no semantics; that is not strictly true. It is supposed to be a string that names (as opposed to addressing) a person/process/role. While this has no semantics for mail-handling software, people tend to find it useful. The hack of filling in the local-part, in the absence of a sender-provided string, into the phrase, sounds like an excellent idea. Well, this ended up as more than reporting. Still, if anyone responds to this, note that I am tending to read my mail about once a month, if that. Dave  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA21189; Mon, 9 Jul 84 19:24:02 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.20) id AA11373; Mon, 9 Jul 84 19:23:34 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.20) id AA18079; Mon, 9 Jul 84 19:23:29 pdt Date: Mon, 9 Jul 84 19:23:29 pdt From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8407100223.AA18079@ucbopal.CC.Berkeley.ARPA> To: Header-People@MIT-MC.ARPA Subject: Re: "blaming Unix SendMail" Cc: postmaster@Berkeley I would like to add to Mark Horton's reply: ... For example, how should "a!b@c" be interpreted? "(a!b)@c" as required by the ARPANET? "a!(b@c)" as required by existing UUCP software? UUCP and Internet (ARPANET) mail address formats are not compatible. Note that the "@" has is the primary delimiter in the Internet mail world and that "!" is the primary delimiter in the UUCP mail world. UUCP Mail/Internet Mail gateways should be doing the address conversion as follows: UUCP to LOCAL, then LOCAL to DOD Internet; and DOD Internet to LOCAL, then LOCAL to DOD Internet (where LOCAL is a gateway domain addressing scheme that provides for identification of different external mail addresses). If you are using sendmail, I suggest that you adopt the Internet mail address format as your LOCAL format. Then in the local mail domain you can use to identify UUCP addresses locally. Here are some basic rules that a sendmail mail transport agent acting as a gateway can follow to handle different address formats. In the following examples "ucbvax" (@Berkeley) is a UUCP/Internet mail gateway. And "b@c" is a valid Internet mail address. Note that mail addresses are modified both at entering the local (gateway) mail domain and when leaving the local mail domain. Incoming from In the LOCAL Outgoing to UUCP mail gateway domain DOD Internet mail From: x!y!z From: y!z@x.UUCP From: x!y!z@Berkeley.ARPA To: ucbvax!b@c To: b@c To: b@c Incoming from In the LOCAL Outgoing to DOD Internet mail gateway domain UUCP mail From: b@c From: b@c From: ucbvax!b@c To: x!y!z@Berkeley.ARPA To: y!z@x.UUCP To: x!y!z Note that there are two steps in the address conversion. First the local mail agent information "ucbvax!" (from UUCP) or "@Berkeley.ARPA" (from Internet) is stripped off, then the local address remaining is interpreted. For mail moving across the gateway, "@c" must be a full Internet mail domain name. That is a UUCP/Internet gateway should be strict about only accepting complete addresses from non-local mail transport agents. If "@c" is not a full domain name, then the gateway can only assume that "@c" is in the local domain of the mail gateway. Bill Wells wcwells@Berkeley.ARPA WCWELLS@UCBJADE.BITNET ucbvax!wcwells  Date: 11-Jul-84 18:13:09-UT From: gross@dcn7 Subject: internetwork addressing questions To: header-people@mit-mc I have a question or two for the mail wizards out there. Some of my concerns are probably old hat and I suspect you old-timers may be tired of answering them for us relative newcomers to net-hopping. Some of these questions, however, may actually be interesting. If there is a document (or 2 or 3, like the 'emily post' series), please feel free to point me that direction. Otherwise, I volunteer to collect and summarize all responses to produce such a document. All my questions evolved from the following situation: I occassionally send mail from our ARPANET host to PSUVAX1, which is a USENET and BITNET host but not an ARPANET host. I've used BERKELEY as my point of departure from Arpaland to Usenet, with an address like , which uses the familiar USENET source route as the 'local part' of the RFC822 'addr-spec'. Recently, PSUVAX1 made some changes and I began using an address like , which uses the '%' convention and BITNET neither of which I am familiar with. Now I would like to send mail to BURDVAX, which I know that I can reach through PSUVAX1 via USENET. The smart money addressing choice was , however, I couldn't resist trying , or . I was pretty sure the second would fail because the '%' is nowhere to be found in RFC822, which means there's no formal operator precedence between '!', '%', and '@', which means all bets are off. Sure enough, BERKELEY took the first choice but flung the second back into my face. The second addressing choice (or some legal variant) is my favorite because if BITNET is the path of choice to get to PSUVAX1 from here (perhaps because it's not restricted to source routing like USENET), then I shouldn't be forced to use USENET for the whole trip simply due to addressing hassles. I also like it because it uses 3 dissimilar, non-traditional-arpa-internet nets (Anyone know a better route involving CSNET?). My smorgasbord of resulting questions are below. Again, I will summarize the results and produce a document that we can point guys like me toward in the future (unless, of course, one already exists). To avoid cluttering mailboxes with possibly old issues, replies should come directly to me (gross@dcn7), unless of general interest to the group. 1) I'm familiar with USENET (although a clarification between UUCP and USENET would be useful), but not with BITNET. Are there articles descibing it (like the 10/83 CACM or Sigcomm '83 Proceeeding articles on CSNET) or can someone give me a paragraph or two. 2) Since '%' (percent) it isn't part of the RFC822 grammer, what does it mean and what is the convention for parsing it? 3) Is the "usenetroute@arpahost" convention a Berkeley kludge or is it a recognized de facto standard of some sort? 4) Is there a permissable way to do the ARPA-to-BIT-to-USEnet addressing implied in the second choice above? In other words, is there an accepted way to parse a mixture of '!', '%' and '@' together. If so, how widely would it be accepted? 5) Who develops these conventions for non-Arpa-Internet inter- networking and how are they documented? 6) How do people determine efficient UUCP/USENET source routes? 7) Are Arpanauts guilty of a narrow worldview or should non-arpanoids accept the one true way? (I've asbestos lined my mailbox for this one, just in case.) This is another way of asking whether there may ever be an ecumenical 'son of 822' to codify some of this stuff? Awaiting Enlightenment, Phill Gross -------  Date: 11 July 1984 21:59-EDT From: Pandora B. Berman Subject: faulty address change To: TSDTEST%VPIVAX3.BITNET @ UCB-VAX cc: HEADER-PEOPLE @ MIT-MC Date: 11 July 1984 21:16-EDT From: MAILER-DAEMON%ucbjade.CC@Berkeley (Mail Delivery Subsystem) Subject: Returned mail: User unknown To: ----- Transcript of session follows ----- >>> RCPT To: <<< 550 Illegal userid for RSCS network. 550 ... User unknown ----- Unsent message follows ----- Received: from ucblapis.CC.Berkeley.ARPA (ucblapis.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.20) id AA24504; Wed, 11 Jul 84 18:16:58 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucblapis.CC.Berkeley.ARPA (4.14/4.20) id AA16005; Wed, 11 Jul 84 18:16:32 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA26166; Wed, 11 Jul 84 18:16:33 pdt Message-Id: <8407120116.AA26166@UCB-VAX.ARPA> Date: 11 July 1984 21:16-EDT From: Pandora B. Berman Subject: address change To: JARRELLRA@VPIVAX3.BITNET Cc: HEADER-PEOPLE-REQUEST@MIT-MC Date: Mon, 9-JUL-1984 08:14 EDT From: Ronald A. Jarrell To: Header-People-Request@mit-mc.ARPA Subject: address change. Please change TSDTEST%VPIVAX3.BITNET@berkeley to JARRELLRA%VPIVAX3.BITNET at Berkeley. done.. well, i did, and tried sending to you at that address, but it didn't work (UNIX fucked with the header, too). when it does work, please let us know and we'll try again.  Date: Thu, 19 Jul 84 14:17 PDT From: Postmaster@LLL-MFE.ARPA Subject: embedded spaces in mail addresses To: header-people@mit-mc.arpa i'm so sick of mailers complaining about quoted addresses with embedded blanks i could scream. is it possible to get unix fixed so that it understands addresses of the form '"provan don"@lll-mfe.arpa', or should we just flush this syntax? as long as my syntax is legal, i find it real hard to justify going to the lengths i'd have to go to make it some address without any blanks in it. i've been waiting since i first brought up SMTP in march '83 for unix to be fixed, but i think it's time to give up waiting. i used to send notes to postmasters telling them we were having problems, but i always got the response that it was purchased software so they couldn't fix it. it wasn't so bad when it was just a couple of cases a month. i could tell someone to use a user number instead of a name or change a name to not have a blank in a few cases. but now there's been a great surge of interest in the arpanet mail system so something has to be done. should i give up? should i consider that syntax obsolete and unsupported? should i just not let my users communicate with unix sites? well, to start with, i guess i'll get mad....  Date: 19 Jul 84 1749 EDT (Thursday) From: don.provan@CMU-CS-A.ARPA To: header-people@MIT-MC.ARPA Subject: Re: embedded spaces in mail addresses In-Reply-To: "Postmaster@LLL-MFE.ARPA's message of 19 Jul 84 16:17-EST" Message-Id: <19Jul84.174950.DP0N@CMU-CS-A.ARPA> i forgot i was in an anonymous account when i send the message titled "embedded spaces in mail addresses." i hereby accept responsibility for that message.  Return-Path:<@MIT-MULTICS.ARPA:WILLUT@EDUCOM.MAILNET> Received: from MIT-MULTICS.ARPA by CMU-CS-A.ARPA; 20 Jul 84 19:09:31 EDT Received: from EDUCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2636665689992730@MIT-MULTICS.ARPA>; 20 Jul 1984 19:08:09 edt Date: 20-JUL-1984 13:39 EDT From: WILLUT%EDUCOM.MAILNET@MIT-MULTICS To: DON.PROVAN@CMU-CS-A.ARPA Subject: Quotes and spaces in usernames Resent-To: header-people@MIT-MC.ARPA Resent-From: don.provan@CMU-CS-A.ARPA Resent-Date: 20 Jul 84 1932 EDT (Friday) Some of our MAILNET sites have had a great deal of trouble with quoted usernames, too. Thought you might enjoy Alan Hunter's assessment of the problem (they have now, by the way, changed their system to send out usernames in the firstname_lastname format) --Candy Willut ---------------------------------------- From: MAILNET 18-MAY-1984 13:11 To: WILLUT Subj: From:<@MIT-MULTICS.ARPA:"Alan Hunter"@Newcastle.Mailnet> Received: from Newcastle.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2631138437336308@MIT-MULTICS.ARPA>; 17 May 1984 19:47:17 edt Date: Thu, 17 May 84 16:02:38 BST From: "Alan Hunter"@Newcastle.Mailnet To: Steve_Rothwell@UMICH-MTS.MAILNET, Gavin_Eadie@UMICH-MTS.MAILNET, WILLUT@EDUCOM.MAILNET, RUSHBY@SRI-CSL.ARPA Message-ID: <79269@Newcastle.Mailnet> Subject: MTS network mail addresses Steve, Gav: cc: Candy, John Rushby I spend a lot of time explaining this sort of thing (see following message) to users. I think perhaps the MTS NETMAIL program ought to throw in the sponge and sign outgoing messages in the First_Last@Site form rather than the equally correct "First Last"@Site. A lot of our mail is to ARPA and CSNET, and UNIX, TOPS and RSX systems in use on those nets don't seem to like quotes, even now. I doubt they ever will. I have actually had complaints from SRI-CSL (a Foonly TOPS system) saying we send them illegally formatted messages! So much for the success of the #822 revision! - Alan ---(Forwarded from: "Alan Hunter"@Newcastle, Dated: Thu, 17 May 84 15:37:28 BST Brian: cc: sundry others Once upon a time there was a mail system called ARPA. It had network mail gurus who designed a protocol for the presentation of network mail messages. They called this RFC #733 so that everyone would instantly know what it was, and respect it as The Truth. In the course of time, the gurus found that a number of groups among the ARPA proletariat had actually ignored the words of wisdom, and implemented what they thought it ought to be rather than what it was supposed to be. Most of these illiterate programmers ran a young upstart operating system (the name escapes me) and knew, of course, that personal names were things like 'brian' and 'lindsay' and never had spaces in them. So a message to: brian randell@newcastle clearly had two recipients; some local guy called 'brian' and somebody over the net called 'randell'. Obvious isn't it? (Actually they were supposed to use commas as separators for this case but these people never did that at home and didn't see why users of lesser systems should need to.) Eventually things got so bad that the gurus got together five years later and rewrote RFC #733, fixing all the problems and calling it RFC #822 which is a much better title. They said that if a local part (that's what gurus have instead of names) had certain characters in it, it had to be surrounded by quotes ("). Spaces are one of these specials; underbars are not. So your messages from MTS go out signed correctly as: "Brian Randell"@Newcastle.Mailnet Meanwhile the mail types who used that operating system had heard from a friend of a friend that 822 wasn't much different to 733, so they changed the comment at the head of their mail program to say '822' instead of '733'. All their friends used the same system (other people didn't seem to want to talk to them) and anyway they had much more fun things to do, because they'd discovered RPCs. The gurus got very annoyed with this and have spent the last two years issuing RFC's with ever more impressive numbers on them giving ever receding dates by which they must comply. Since the mail implementors think they are complying they don't read these either. They have even been known to complain when more up to date sites send them correctly formatted messages! The MTS mail people, being kind, are prepared to accept recipient's names with underbars representing the spaces. Nor do they care if people shout at you and call you BRIAN RANDELL at the top of their voice. Both quoted and underbarred forms are equally valid. Few non-MAILNET-or-BITNET sites can generate our (correct) quoted signatures as return addresses. So I always tell people to quote the underbarred form in the message text when establishing a connection. You are: Brian_Randell@NEWCASTLE.MAILNET but these people don't know where that is, so tell them you are: Brian_Randell%NEWCASTLE@MIT-MULTICS.ARPA They'll think you are being pedantic putting the ".ARPA" on the end because they don't believe there is anybody else out there. They'll also think you have a funny name and must live in or near Cambridge, Mass., BUT THEIR MESSAGES WILL GET THROUGH. I suppose MTS will be reduced to signing messages with underbars one day. Sigh.... - Alan  Date: Mon, 23 Jul 84 10:12 PDT From: Postmaster@LLL-MFE.ARPA Subject: where do error reports go now? To: header-people@mit-mc.arpa it has been pointed out to me that RFC822 (4.4.4) says that reports for undeliverable mail should be sent to the Sender: field (or the From: field if there's no sender field). RFC821 (4.1.1, Mail command) says that non-delivery notices should be sent to the return path passed in the SMTP Mail command, which, of course, ends up as the Return-Path: header in the mail. i'm sure this has been argued about before. i don't remember the argument. anyway, i'm not feeling very argumentative, so i just want to know which field i should use in my implementation. presumably they both point back to the same mailbox, but if they don't, which should i choose? don provan provan@cmu-cs-a postmaster@lll-mfe  Date: Mon, 23 Jul 84 21:08:56 EDT From: Doug Kingston To: Postmaster@LLL-MFE.ARPA cc: header-people@MIT-MC.ARPA Subject: Re: where do error reports go now? The address given in the SMTP MAIL FROM: command is the prefered return address for errors. -Doug-  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2637018731564431@MIT-MULTICS.ARPA>; 24 Jul 1984 21:12:11 edt Date: 24 Jul 84 15:47 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people , Postmaster@LLL-MFE.ARPA Subject: embedded spaces in mail addresses Message-ID: <63316@QZCOM> In-Reply-To: <63030@QZCOM> In the QZCOM mail network interface, I translate internal COM names of the format "Jacob Palme QZ" into the external mail format Jacob_Palme_QZ so as to avoid quotes and spaces which some mail systems cannot handle. I have never in my life come across a "standard" which in actual implementation is to blatantly disregarded as RFC822.  Date: 25 Jul 84 1151 EDT (Wednesday) From: don.provan@CMU-CS-A.ARPA To: header-people@MIT-MC.ARPA Subject: re: embedded spaces in mail addresses Message-Id: <25Jul84.115112.DP0N@CMU-CS-A.ARPA> I went into the lll-mfe mail server to put in a underbar-equals-space hack and found i'd already given up on UNIX and put a hash-equals-space hack (hash because it's the standard around my network) in. i wonder how many other sites have done the same thing just to relieve UNIX of the need to fix it. CMU uses a dot-equals-space hack, as i'm sure many other sites do from the rfc722 days, but that's because it's been in so long no one would think of taking it out. (it's become a standard all the way to user level.) everytime i bitch to a UNIX site, they say, "gee, you're the first site we've dealt with that had spaces in their user names." i suspect i'm just the first to complain about it. the thing that pisses me off most is that i need to add hashes on the return addresses of out-going mail even for sites that can handle spaces. i think we should all boycott UNIX until the mail system's fixed.  Date: 25 Jul 84 1954 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: header-people@MIT-MC.ARPA Subject: Re: embedded spaces in mail addresses In-Reply-To: <25Jul84.115112.DP0N@CMU-CS-A.ARPA> Message-Id: <25Jul84.195452.EN0C@CMU-CS-A.ARPA> For the record: CMU supports the dot-equals-space hack and actually uses it as "the way to go" for non-CMU sites because of the belief that most sites do not have lexically powerful mail systems and can only handle simple single lexical token @ mail addresses. We advocate internal CMU mail to use quoted names and that mail user interfaces/composers are expected to work very hard to resolve a "name" or "nickname" into an electronic mail address (i.e. 'Mr. E. R. Nedved' turns into '"Rudy Nedved"@CMU-CS-A.CMU.ARPA'). CMU's 4.1BSD Unix mail system (the majority around here) supports spaces in names and quoted names. When we upgrade to 4.2BSD or whatever, the mail system will support quoted names also. What you want to do is boycott simple mail delivery software that tries to use a hacked up version of the COPY or CAT program to move mail around. Given the growing importance of eletronic mail systems it is amazing that managers have not allocated more software developement resources into this area.....it still seems to be under the "general software maintainence" for most sites. Rudy Nedved CMU CS/RI Facilities Staff  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2637130622486575@MIT-MULTICS.ARPA>; 26 Jul 1984 04:17:02 edt Date: 25 Jul 84 16:29 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people , Postmaster@LLL-MFE.ARPA Subject: where do error reports go now? Message-ID: <63545@QZCOM> In-Reply-To: <63431@QZCOM> I would strongly urge you to send reports for undeliverable mail to the SMTP sender, not to the FROM or the SENDER in the RFC822 header. When a mailing list resends a message, it usually will not munge the RFC822 header, but most mailing list implementations will put the list maintainer as the SMTP SENDER, and it is the list maintainer, not the original author, who should get these kind of messages. At the same time, I would warn you against doing what some mail systems do: They send a message saying that "the next message is a returned undeliverable mail" and then they send the undeliverable mail as a separate message. This causes problems at least in my mail system (QZCOM) because when I get the second message, I immediately note that I already have that message in my data base, and since there are no new recipients on it, I will just disregard it. Thus, people will get a message saying "the next message is an undeliverable mail", and then they will not get any next message at all. The principle of sending undeliverable mail as two separate messages, one with the error message and one with the returned message, would be a good idea, but only if the first of these two messages, the error message, contained some identification of the returned message, the message-id of it and the author and date fields for example.  Date: Thu, 26 Jul 84 07:53:46 cdt Message-Id: <8407261253.AA21469@wisc-crys.arpa> Received: by wisc-crys.arpa; Thu, 26 Jul 84 07:53:46 cdt To: header-people@mit-mc.arpa Subject: returned mail under separate cover Cc: implementors@csnet-sh Sender: forwarder@wisc-crys.arpa From: solomon@wisc-crys.arpa Jacob Palme points out one problem with returning undeliverable mail in a separate message from the error report (what I'll call "two-message error reports" or TMER). I would go further than he did and assert that TMER is an extremely bad idea. Another facility interfered with by TMER is automated handling of errors. Error recovery is difficult enough in the current chaotic mail world; TMER makes it almost impossible. The latest version of the CSNET nameserver software provides an example. The software intercepts outgoing mail and tries to give the sender additional assistance in getting it to its destination. It puts "forwarder" in the "sender" field (and in the SMTP envelope) so that error reports are returned to a program rather than the original author (see the header of this message for an example). This program queries a central database to see if the failure was due to stale information (for example, because the recipient has moved). Only if such attempts fail does it return the message to the author. The information necessary to query the database, and indeed the identity of the original author is only in the original message. At the very least, TMER introduces a headache: One error message must be queued until the other arrives (note that there is no guarantee on order of delivery, so the returned mail may precede the error message!) In the absence of any standards on how the two messages identify each other, it is impossible to deal with TMER in any reasonable way. By the way, another bogosity at some sites pointed up by the new nameserver software is sites that send replies (mail generated by humans using a "reply" command in their mail-reading software) to the address in the "sender" field or the SMTP envelope in clear violation of RFC 822. From time to time we get mail addressed to "forwarder" with contents like "You're right Jim, but I disagree with the third paragraph." In some cases it is impossible to figure out who the sender was trying to reach and we are reduced to returning the mail (by hand) to the sender, along with a nasty note to the postmaster at the sending site. Luckily, postmasters seem to be reasonably willing to clean up their acts when they have the problem pointed out. We haven't had too many try to tell us they're right and we're wrong.  Received: From hp-labs.csnet by csnet-relay; 27 Jul 84 14:48 EDT Received: by HP-VENUS id AA02239; Fri, 27 Jul 84 09:44:48 pdt Date: Fri, 27 Jul 84 09:44:42 pdt From: Mark Laubach Received: by HP-MARS id AA01099; Fri, 27 Jul 84 09:44:42 pdt Message-Id: <8407271644.AA01099@HP-MARS> To: header-people%mit-mc.arpa@csnet-relay.arpa Subject: embedded blanks in multi-part local names Source-Info: From (or Sender) name not authenticated. While 4.XXBSD might be able to handle quoted strings properly, we've found some problems dealing with them in the Bell System III and V OS's. For that reason, the general consensous among the "mail experts" within HP, is that we will use the underscore to delimit _ name pairs and do away with the quote problem altogether. We have a significantly large problem within HP as we support two completely different mailing domains, the HPDeskManager world, where everyone has a first and last name, and the HP-UX/Unix world, which we all know and love. I'm in the process of completing a gateway between the two and have come up against this problem. The underscore solution seems to be the best alternative. Mark Laubach HP Labs Corporate Engineering  Date: 27 Jul 84 1902 EDT (Friday) From: don.provan@CMU-CS-A.ARPA To: header-people@MIT-MC.ARPA Subject: embedded blanks, round two Message-Id: <27Jul84.190259.DP0N@CMU-CS-A.ARPA> didn't UNIX SMTP servers used to reject the Mail command if it had a from field it couldn't send back to? i just added code to try a non-quoted from field (with blanks replaced) if the mail command was rejected with a quoted blanky from field, but now i can find any mailers that will reject such a mail command. is this reasonable behavior?  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2637271950399124@MIT-MULTICS.ARPA>; 27 Jul 1984 19:32:30 edt Date: 27 Jul 84 17:40 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people , don.provan@CMU-CS-A.ARPA Subject: re: embedded spaces in mail addresses Message-ID: <63810@QZCOM> In-Reply-To: <25Jul84.115112.DP0N@CMU-CS-A.ARPA> If you want to know if spaces in names are to be recommended, the right person to ask would be the English language department at your university. I am quite sure what they would reply!  Date: Fri 27 Jul 84 23:18:04-PDT From: Charles Hedrick Subject: Rutgers is temporarily off the net To: tops-20@SU-SCORE.ARPA, header-people@MIT-MC.ARPA, paetzold@DEC-MARLBORO.ARPA Rutgers is in the process of moving from NYU (a DDN node) to Columbia (an Arpnaet node). Unfortunately, only half of the necessary workorders were issued, so our phone line has now been moved, but not the equipment necessary for us to connect to the IMP. We hope to be back on the net sometime this week. You can contact us via UUCP through allegra: ... allegra!ru-blue!user@color where color is one of Red, Blue, or Green. (the Arpanet node is Red.) You can also send mail to HEDRICK@SUMEX. I will log in here at least once a day, and will forward message to others at Rutgers. However I will forward them by writing them down and resending them, so please only use this for critical cases. -------  Date: Sun, 29 Jul 84 15:45:01 PDT From: sventek@lbl-ws.arpa Message-Id: <840729154437.002@lbl-ws.arpa> Subject: Group addresses To: header-people@mit-mc.arpa How do others handle the construct in their parsers? Since the body of the group can be 0 or more s separated by commas, 822 requires that the parser be able to handle an unlimited amount of input before determining that there is an error. If one is trying to do a parser for use in non-virtual memory systems, one cannot count on being able to buffer all input until the trailing ';' is seen. By the way, for our own system, we do not use the group:; construct for distribution lists. We maintain a set of system alias definitions which are referred to in the same way as user mailboxes. Please address replies to me, and I will summarize for the list, if there is interest. Joe Sventek  Date: 1 Aug 1984 08:57:24-EDT From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!zehntel!dual!amd!decwrl!decvax!harpo!whuxle!akgua!psuvax1 at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA12765; Wed, 1 Aug 84 08:47:19 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.08 10/3/83; site psuvax1.UUCP From: allegra!psuvax1!jdi (John D. Irwin) Subject: Re: internetwork addressing questions Message-Id: <1102@psuvax1.UUCP> Date: Thu, 19-Jul-84 10:06:03 EDT Received: by hou3c.UUCP; Tue, 31-Jul-84 23:31:21 EDT References: <694@hou3c.UUCP> In-Reply-To: <694@hou3c.UUCP> Organization: Pennsylvania State Univ. Speaking as psuvax1, first I'd like to clear up a couple of mis- conceptions. First of all, our switch to 4.2 OBVIATED the need for a '%', not required it. Currently if you can get mail to us through whatever net that is 822 we will send it on (except for a teeny uucp problem we're working on) Thus djb@burdvax.UUCP.BITNET sent to us would work. However, you have a problem in specifying HOW to get it from Berkeley to us. Mark, any answers? -- Spoken: John D. Irwin AT&T: 814-237-5068 Nets: jdi@psuvax1.{BITNET,CSNET} Uucp: {akgua, allegra, cornell, pitt, purdue, ihnp4, burdvax}!psuvax1!jdi  Date: 1 Aug 1984 at 2334-PDT From: Andrew Knutsen To: allegra!psuvax1!jdi at BERKELEY (John D. Irwin) Cc: Header-People at MIT-MC.ARPA Subject: Re: internetwork addressing questions In-reply-to: Your message of 1 Aug 1984 08:57:24-EDT Thu, 19-Jul-84 10:06:03 EDT. <1102@psuvax1.UUCP> Sender: knutsen at Sri-Unix The basic problem is that ARPA (the US gov't) hasnt declared any "official" domains other than ARPA. An official domain implys the existence of a well-maintained nameserver service, and this does not exist for uucp, or bitnet for all I know. Thus on the arpanet, ARPA must be top level, and subdomains must be in the "local part". Kind of a silly situation, but the good side is that it encourges the formation of the nameservers. Apparently things are coming along on the uucp and csnet fronts. AK  Date: 2 Aug 1984 16:40:29-EDT From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!cbosgd!mark at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA18393; Thu, 2 Aug 84 09:22:53 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP From: allegra!cbosgd!mark (Mark Horton) Subject: Re: internetwork addressing questions Message-Id: <160@cbosgd.UUCP> Date: Thu, 26-Jul-84 23:16:14 EDT Received: by hou3c.UUCP; Wed, 1-Aug-84 09:30:56 EDT References: <694@hou3c.UUCP>, <1102@psuvax1.UUCP> In-Reply-To: <1102@psuvax1.UUCP> Organization: AT&T Bell Laboratories, Columbus There must be lots of machines that talk to both ucbvax and psuvax1 - cbosgd for example. But I confess I can't understand why djb@burdvax.UUCP.BITNET would be a useful address. If your system understands BITNET but not UUCP, then djb%burdvax.UUCP@psuvax1.BITNET or the more intended @psuvax1.BITNET:djb@burdvax.UUCP ought to work. >From the ARPANET I think Berkeley will gateway to BITNET, from CSNET there's probably a gateway somewhere too. >From UUCP it depends on what software you have and where you want to send the mail.  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2637963057983948@MIT-MULTICS.ARPA>; 04 Aug 1984 19:30:57 edt Date: 04 Aug 84 18:27 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, "(John D. Irwin)" , "Andrew Knutsen" cc: header-people Subject: Re: internetwork addressing questions Message-ID: <64745@QZCOM> In-Reply-To: <64572@QZCOM> Why does an official domain imply the existence of a well-maintained nameserver service. I can understand that they may require that an official domain implies the existence of a well-maintained nameserver service for host names (and in the case of relative nets like UUCP also pathes to them), but a name server for user names within a host does not seem to be necessary.  Date: 6 Aug 1984 13:09:00-EDT From: allegra!hou3c!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!hao!seismo!uwvax!dave at mit-vax Received: by allegra.UUCP (4.12/4.7) id AA03652; Mon, 6 Aug 84 09:47:11 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site uwvax.ARPA From: allegra!dave@uwvax.ARPA Subject: Re: embedded spaces in mail addresses Message-Id: <361@uwvax.ARPA> Date: Wed, 1-Aug-84 10:02:38 EDT Received: by hou3c.UUCP; Fri, 3-Aug-84 18:18:58 EDT References: <703@hou3c.UUCP> In-Reply-To: <703@hou3c.UUCP> Organization: U of Wisconsin CS Dept > is it possible to get unix fixed so that it > understands addresses of the form '"provan don"@lll-mfe.arpa', or > should we just flush this syntax? as long as my syntax is legal, i find > it real hard to justify going to the lengths i'd have to go to make it > some address without any blanks in it. First of all, UNIX* doesn't know what mail is. UNIX is an operating system, not a mailer. On 4.2BSD, the standard mailer is sendmail. This mailer understands spaces in names (you must quote the name, of course, like your example shows). Another mailer which runs on 4.2, MMDF, also understands spaces in names. If there are any sites out there running out-of-date and incorrect software, mail them. They should want to know their mailer doesn't conform to the RFC 822/823 standards. You say some sites buy their software (Unix sites without source? Who *are* these people?), have they notified the manufacturer of the problem? Maybe a solution here is to post the name of the manufacturer to the net, after giving them a chance to remedy the problem. This should cause prompt attention to the problem. *UNIX is a trademark of AT&T Bell Laboratories -- Dave Cohrs @ wisconsin ...!{allegra,heurikon,ihnp4,seismo,ucbvax,uwm-evax}!uwvax!dave dave@wisc-rsch.arpa  Date: 7 Aug 84 9:32-PDT From: mclure @ Sri-Unix.arpa To: header-people @ Mit-Mc.arpa Subject: RFC822 parser I am looking for C routines to parse an RFC822 address. Does anyone out there have one? I'm looking for a comprehensive implementation that works well. Replies to mclure@sri-unix. Stuart  Received: by YALE-BULLDOG.YALE.ARPA; 8 Aug 84 22:40:13 EDT (Wed) Date: 8 Aug 84 22:40:13 EDT (Wed) From: Dan Glasser To: Header-People@MIT-MC.ARPA Subject: Sendmail problem: UUCP headers I'm having a problem getting sendmail to properly rewrite headers on messages going out to UUCP. Let's say that I compose a message with the following header fields: From: dglasser To: decvax!foo, apollo!bar Cc: decvax!harpo!blah The copy of the message spooled for decvax!foo and decvax!harpo!blah should have the headers rewritten as follows: From: yale!dglasser To: foo, yale!apollo!bar Cc: harpo!blah The copy of the message spooled for apollo!bar should have the headers rewritten as follows: From: yale!dglasser To: yale!decvax!foo, bar Cc: yale!decvax!harpo!blah In other words, what we want to do is the following: 1) Prepend "yale!" to the sender address. 2) For recipient address a!b!c: a) For copies of the message going to a, strip "a!" b) For copies of the message NOT going to a, prepend "yale!". Now, I have two important questions: 1) Is my description of how the headers should be rewritten correct? (I think it is, but I'd be interested to hear disagreements) 2) Has anyone successfully implemented this sort of rewriting in sendmail? (I tried doing it by using the $h macro in the UUCP recipient rewriting ruleset, but it didn't work) Danny Glasser decvax!yale!dglasser (formerly yale-comix!dglasser) Glasser-Daniel@YALE.ARPA  Received: From hp-labs.csnet by csnet-relay; 10 Aug 84 19:58 EDT Date: Wed, 8 Aug 84 15:34:36 pdt From: Stan Isaacs Received: by HP-VENUS id AA07360; Wed, 8 Aug 84 15:34:36 pdt Message-Id: <8408082234.AA07360@HP-VENUS> To: header-people%mit-mc.arpa@csnet-relay.arpa, mclure%sri-unix.arpa@csnet-relay.arpa Subject: Re: RFC822 parser Cc: isaacs@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. Hi, Stuart: I am currently trying to write a lex/yacc parser for 822. I'll send it to you when I get it done and checked. If you get any responses from someone who has already done that, please let me know. Also, we are looking for a C compiler for a large IBM (running MVS or VM). Do you know of any? How are you doing? Are you back at SRI? Last I heard, you were graduate- studenting at Stanford. Are you still? Where are you living? I've been meaning to write since I found you had come back to this area, but have just bought a new house and am busy moving in. I saw Ole a few weeks ago (that's how I found you were back). I'm now over at HP, and enjoying myself. I'm working on UNIX, IBM, HP3000, and other systems. Very confusing, but a lot of fun. See you one of these days -- Stan Isaacs  Received: by mit-vax.Mit-chaos.Arpa (4.12/4.8) id AA11542; Wed, 15 Aug 84 15:19:56 edt Received: by allegra.UUCP (4.12/4.7) id AA12088; Mon, 13 Aug 84 11:09:48 edt To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 3/23/84; site cbosgd.UUCP From: allegra!cbosgd!mark@mit-vax (Mark Horton) Subject: Re: Sendmail problem: UUCP headers Message-Id: <232@cbosgd.UUCP> Date: Fri, 10-Aug-84 18:40:59 EDT Received: by hou3c.UUCP; Sat, 11-Aug-84 02:18:22 EDT References: <745@hou3c.UUCP> In-Reply-To: <745@hou3c.UUCP> Organization: AT&T Bell Laboratories, Columbus No, that's not "the right thing" to do. Of course, I should mention that RFC822 requires that all such addresses in mail headers (From, To, Cc, etc) should be in the user@domain form, so that nobody has to go around rewriting them. So to conform to 822, you should be sending out @ addresses. (This is the direction being taken by the UUCP project. Having to change headers at every machine the mail passes through is an ugly proposition which is best avoided.) According to "de-facto" convention, there really aren't any rules. Any given machine does pretty much whatever it wants. So by this rule, I suppose you're fine too. However, some software takes the position that addresses without @'s in them are as typed on the sending host, and must be interpreted relative to that host. Thus if you send mail to decvax!foo and it arrives on decvax reading To: foo there will be software that will assume this means "foo on host yale". (Assuming yale sent it.) Mark  Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA25697; Thu, 16 Aug 84 14:58:52 edt Received: by ihnp4.ATT.UUCP; id AA22746; 16 Aug 84 14:03:57 CDT (Thu) To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 5/3/83; site hou2e.UUCP From: ihnp4!hou2e!gregbo@mit-eddie (Greg Skinner) Subject: user-editable mail headers Message-Id: <243@hou2e.UUCP> Date: Thu, 16-Aug-84 11:45:25 EDT Received: by hou3c.UUCP; Thu, 16-Aug-84 14:49:03 EDT Organization: Bell Labs, Holmdel NJ Is there any interest in Unix Mailers which support user-editable headers like tops20 MM supports them? The new exptools version of Mail doesn't seem to support them and I don't know of any other Unix Mailers offhand that do. Note that I am not talking about editing just the to, from, cc, bcc and subject fields ... I am talking about putting anything in your header which RFC822 will parse. -- Hug me till you drug me, honey! Greg Skinner (gregbo) {allegra,cbosgd,ihnp4}!hou2e!gregbo  Received: by YALE-BULLDOG.YALE.ARPA; 17 Aug 84 17:12:17 EDT (Fri) Message-Id: <8408172112.AA16150@YALE-BULLDOG.YALE.ARPA> Received: by YALE-COMIX.YALE.ARPA; 17 Aug 84 17:04:05 EDT (Fri) Received: by MULTIFLOW.UUCP; 17 Aug 84 16:45:37 EDT (Fri) Date: 17 Aug 84 16:45:37 EDT (Fri) From: Ben Cutler Subject: Re: user-editable mail headers To: ihnp4!hou2e!gregbo@MIT-EDDIE.ARPA Cc: Header-People@MIT-MC.ARPA In-Reply-To: ihnp4!hou2e!gregbo@MIT-EDDIE.ARPA (?Invalid domain (host)), Thu, 16-Aug-84 11:45:25 EDT Is there any interest in Unix Mailers which support user-editable headers like tops20 MM supports them? The new exptools version of Mail doesn't seem to support them and I don't know of any other Unix Mailers offhand that do. Note that I am not talking about editing just the to, from, cc, bcc and subject fields ... I am talking about putting anything in your header which RFC822 will parse. I have written a portable mailer called AZ. It's very similar to Tops-20 OZ written by John Ellis. AZ runs on Apollos, and Unix and VMS Vaxen at Yale and at several other sites. You can edit the basic header fields (To, Cc, Bcc, Subject) directly using simple commands or using a full screen editor (if you have one). AZ doesn't support user-editing of the wide variety of possible header fields, but this capability would be very easy to add. Ben Cutler Cutler@YALE.ARPA decvax!yale!multiflow!cutler -------  Date: Sat, 18 Aug 84 15:43 EDT From: Paul Schauble Subject: List address change To: Header-People@MIT-MC.ARPA, Header-People-Request@MIT-MC.ARPA Message-ID: <840818194344.843492@MIT-MULTICS.ARPA> I apologize for bothering the entire list with this, but... I have requested this address change several times before, both to the -request address and to the list. So far, nothing has happened. It seems like communications with the list maintainer have broken down somehow. So, could anyone who is able please make this change: DELETE Schauble at MIT-Multics, ADD Header-People-disty at MIT-Multics Thanks you, Paul  Date: Sat, 18 Aug 84 21:57:27 EDT From: Stephen Wolff To: header-people@mit-mc.ARPA Subject: Re: user-editable mail headers Can anyone explicate an honest reason for editing the From: line of a message? It is certainly not possible in our mailer without exercising privilege, and I had blithely assumed that to be universally the case. I should hate to have to regard every message as a potential forgery.  Date: 18 Aug 1984 20:24-PDT Sender: GEOFF@SRI-CSL Subject: Re: user-editable mail headers From: the tty of Geoffrey S. Goodfellow To: steve@BRL-BMD Cc: header-people@MIT-MC Message-ID: <[SRI-CSL]18-Aug-84 20:24:46.GEOFF> In-Reply-To: The message of Sat, 18 Aug 84 21:57:27 EDT from Stephen Wolff Oh please, let's not rehash THIS issue again! If you're interested in past discussions in this area I suggest you retrieve and peruse the archives for this list as well as MsgGroup. It's not possible, using the current in place methods for delivering netmail to prevent any such unauthenticated and/or unauthorized mangling of message headers. I would even go so far as to say that if I had an an account on your system (without the ability to exercise privilege) I could still edit the From: line of a message. You should always regard every message as a potential forgery, since the ability to perpetrate a forgery is no great act of chicanery. g  Date: Sun 19 Aug 84 10:46:52-PDT From: Mark Crispin Subject: Re: user-editable mail headers To: steve@BRL-BMD.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "Stephen Wolff " of Sat 18 Aug 84 19:18:24-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The TOPS-20 MM mailsystem allows editing the From: line of a message. This is to support some of the hairier aspects of office automation; e.g. models where some other person (e.g. a secretary) sends mail for another. MM also has the capability to be run in a mode where you can "become" another user for reading/sending mail, but this needs access to that user's directory (MM will ask for the user's password if necessary to obtain that access). The security problems with forged mail are there to be sure, BUT... unlike TOPS-10 or Unix, programs on TOPS-20 NEVER run with "temporary" privileges. It is therefore impossible to enforce any security at the level of a program run by users, because any security enforcement done by such a program can be evaded simply by building one's private copy of the program without the check. Even leaving aside the issue of a patched copy of the program, you must also consider the possibility of other message composition programs being developed to run concurrantly on the same system; whether to evade the security check or simply to experiment with alternative interfaces. That leaves security enforcement to a privileged agent, that is, the mailer. The problem here is that at the present time the TOPS-20 mailer doesn't have the slightest idea what RFC 822 is. It doesn't deal at that level; it deals with SMTP. When RFC 1234 comes out that completely changes the standards, not only would the message composition program require changing but also the mailer. Ugh. Personally, I believe that security against forged mail is a fantasy. The best you can do is validate that a message clearly came from such- and-such a host, or for locally-originated mail, that a message was composed by a certain user (provided your operating system supports a "file author" word that unprivileged users can't modify). In TOPS-20, this is done via Received: and Mail-From: lines. -------  Received: by YALE-BULLDOG.YALE.ARPA; 19 Aug 84 14:51:57 EDT (Sun) Message-Id: <8408191851.AA10995@YALE-BULLDOG.YALE.ARPA> Date: Sun, 19 Aug 84 14:37:02 EDT From: John R Ellis Subject: Re: user-editable mail headers To: Mark Crispin Cc: steve@BRL-BMD.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Mark Crispin , Sun 19 Aug 84 10:46:52-PDT Personally, I believe that security against forged mail is a fantasy. The best you can do is validate that a message clearly came from such- and-such a host, or for locally-originated mail, that a message was composed by a certain user. It's quite easy to do much better than this for local networks, using standard operating systems like TOPS-20 and Unix. At Yale, our Chaosnet implementation provides a server with the user id and host of the program at the other end of the connection. The operating systems provide this information; user-state programs cannot forge it. (It isn't hard to modify TOPS-20 and Unix implementations of Chaosnet to provide this capability.) Thus our mail system knows reliably who sent local-network mail. Of course, if someone broke into the operating systems, they could forge the mail. So what? Computer people often talk about "security" as if it were an all-or-nothing proposition. But as in the physical world, there are varying degrees of computer security, depending on how much the security is worth to you. Show me a particular computer security method, and I'll show you a (possibly very expensive) way to circumvent it (including non-electronic methods). Just as most of us prefer moderately secure locks on the doors of our homes in preference to no locks at all, most computer users would prefer protection against easy forgery rather than no protection at all. I was once told the government's sensible definition of security: Make it more expensive for the spies to break security of your particular system than it would cost them to achieve their goals by some other means. -------  Received: by sri-prism.ARPA (4.12/4.16) id AA05721; Mon, 20 Aug 84 22:39:32 pdt Message-Id: <8408210539.AA05721@sri-prism.ARPA> Date: Mon Aug 20 22:37:55 1984 From: mclure@sri-prism To: header-people@mit-mc Subject: RFC822 parser needed This is a repeat of an earlier message. I need an RFC822 parser in C for Unix. I could steal code from various public routines, but I'm looking for a separate piece of code so I don't have to disentangle code from some mammoth program. If you have such a parser (a good one) and are willing to release it, please contact me. (mclure@sri-prism) Stuart  Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA17488; Tue, 21 Aug 84 06:49:26 edt Received: by ihnp4.ATT.UUCP; id AA01693; 20 Aug 84 16:09:36 CDT (Mon) To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 exptools 1/6/84; site ihuxl.UUCP From: ihnp4!ihuxl!bamford@mit-eddie (bamford) Subject: Re: user-editable mail headers Message-Id: <1293@ihuxl.UUCP> Date: Thu, 16-Aug-84 15:54:39 EDT Received: by hou3c.UUCP; Thu, 16-Aug-84 22:46:27 EDT References: <243@hou2e.UUCP> In-Reply-To: <243@hou2e.UUCP> Organization: AT&T Bell Labs, Naperville, IL Y E S ! ! ! I am very interested in a well supported mailer program that allows editing of the headers. I very much liked what the TOPS20 machine at Stanford had.  Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA17500; Tue, 21 Aug 84 06:49:39 edt Received: by ihnp4.ATT.UUCP; id AA01715; 20 Aug 84 16:09:52 CDT (Mon) To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site ulysses.UUCP From: ihnp4!ulysses!smb@mit-eddie (Steven Bellovin) Subject: Re: user-editable mail headers Message-Id: <969@ulysses.UUCP> Date: Thu, 16-Aug-84 22:42:47 EDT Received: by hou3c.UUCP; Fri, 17-Aug-84 11:24:23 EDT References: <1293@ihuxl.UUCP> In-Reply-To: <1293@ihuxl.UUCP> Organization: AT&T Bell Laboratories, Murray Hill Please note that the Rand MH system -- distributed with 4.2bsd -- has had that ability for years. When you want to send a letter, it pops you into the editor of your choice; when you're done, it parses the header to see who it's addressed to.  Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA17511; Tue, 21 Aug 84 06:49:51 edt Received: by ihnp4.ATT.UUCP; id AA02254; 20 Aug 84 16:17:50 CDT (Mon) To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP From: ihnp4!dual!fair@mit-eddie (Erik E. Fair) Subject: Re: user-editable mail headers Message-Id: <772@dual.UUCP> Date: Sat, 18-Aug-84 17:42:27 EDT Received: by hou3c.UUCP; Sat, 18-Aug-84 22:46:52 EDT References: <1293@ihuxl.UUCP> <969@ulysses.UUCP> In-Reply-To: <969@ulysses.UUCP> Organization: Dual Systems, Berkeley, CA The recmail program from the netnews distribution does similar things. Standard procedure is to make a prototype header for the user, fire up an editor, and when it exits, hand the text to recmail. It picks out the To: and Cc: fields and mails off the letter with /bin/mail, which will accept *anything* as input. Voila! Editable headers. Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA dual!fair@BERKELEY.ARPA {ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair Dual Systems Corporation, Berkeley, California  Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA17528; Tue, 21 Aug 84 06:50:04 edt Received: by ihnp4.ATT.UUCP; id AA03069; 20 Aug 84 16:33:32 CDT (Mon) To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ihnp4!utzoo!henry@mit-eddie (Henry Spencer) Subject: Re: user-editable mail headers Message-Id: <4231@utzoo.UUCP> Date: Sat, 18-Aug-84 18:10:02 EDT Received: by hou3c.UUCP; Sun, 19-Aug-84 19:00:22 EDT References: <1293@ihuxl.UUCP>, <969@ulysses.UUCP> In-Reply-To: <969@ulysses.UUCP> Organization: U of Toronto Zoology > Please note that the Rand MH system -- distributed with 4.2bsd -- has had > that ability for years. When you want to send a letter, it pops you into > the editor of your choice; when you're done, it parses the header to see > who it's addressed to. I have no direct experience with MH, but this is *clearly* the right way to do letter composition. A mail system is a mail system: it should not try to be a text editor as well. Partly because it complicates the mail system unnecessarily, partly because it means the poor user has to learn two different editors, but mostly because mail-system editors are lousy editors! Text editing is a complex task; writing a good text editor is not easy. Mail-system authors should leave this job to specialists. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry  Date: Tue 21 Aug 84 08:27:06-PDT From: Mark Crispin Subject: user-editable headers Sender: CRISPIN@SU-SCORE.ARPA To: Header-People@MIT-MC.ARPA Reply-To: MRC@SU-SCORE.ARPA Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107 Phone: (415) 442-1500 x31 The main objection I have to the idea of popping you into an editor to compose the message and then parsing the header to see where the message goes to is that there is not necessarily a correspondence between the header of a message and its envelope! Just about every mail system (including TOPS-20's MM) I am aware of which has this capability has this fundamental flaw. The problem is what you do about things which do not conform to the definition of 822 but are still valid under it. The best example I can think of is the tradition of using group names to hide a recipient list (this is the original usage of group names from long long ago and, I imagine, still its primary usage). bcc's present another problem; there are several theories on the correct bcc behavior which can only be determined at mailer instead of editor level. -------  Date: Tue, 21 Aug 84 11:49 EDT From: "Benson I. Margulies" Subject: parsing headers To: Header-People@MIT-MC.ARPA Message-ID: <840821154949.966446@CISL-SERVICE-MULTICS.ARPA> I disagree with Mr.Crispin's comments. There is a distinction between text and envelope. However, a mail header is a sensible printed representation of the envelope of a new, outgoing message. It is also a sensible representation to edit. Multics allows users to "edit" the header, parses it, and then carefully prevents the user from forging those fields that are (a) part of the envelope and (b) a communication from agent to agent rather than from user to user.  Date: Tue 21 Aug 84 10:17:18-PDT From: Mark R. Crispin Subject: Re: parsing headers To: Margulies@CISL-SERVICE-MULTICS.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from ""Benson I. Margulies" " of Tue 21 Aug 84 09:06:09-PDT Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107 Phone: (415) 442-1500 x31 The difference between my position and Benson's seems to be philsophical. I mostly agree with him on his points that: . a text/envelope distinction exists . a header is a sensible printed representation of the envelope of a freshly-composed message . a header is a sensible representation to edit Where I disagree is that I do not see the necessity to require that the post-editing header remain a respresentation of the envelope. This introduces the problem which I referred to: if an "edit headers" functionality exists, which parts of that functionality affect the envelope and which don't? MM's approach to the problem is less than satisfactory. It has an "edit headers" functionality which is parsed by the reply processor with the added twist that unknown header items are treated as user- defined headers (neither good nor very robust). It then has various power tool commands to alter the headers from MM context, which know what should alter the envelope and what shouldn't. -------  Date: Tue, 21 Aug 84 19:08 EDT From: "Benson I. Margulies" Subject: Re: Editing Headers To: header-people@MIT-MC.ARPA Message-ID: <840821230804.729547@CISL-SERVICE-MULTICS.ARPA> I, and Multics, DO NOT require/guarantee that the header in the text retain the identical form that the user edits it into. In fact, if the user tries to add certain fields that we reserve as envelope reflections, we rename the fields. (We add X- to the front). Thus it seems that Mr. C. and I agree, but that I accidently implied that I agreed with an feature that I don't.  Date: Tue 21 Aug 84 19:59:48-EDT From: Gregbo Subject: Re: user-editable mail headers Sender: GDS@MIT-XX.ARPA To: header-people@MIT-MC.ARPA Reply-To: Gds@MIT-XX.ARPA In-Reply-To: Message from "Stephen Wolff " of Sat 18 Aug 84 22:12:45-EDT From: Stephen Wolff Can anyone explicate an honest reason for editing the From: line of a message? It is certainly not possible in our mailer without exercising privilege, and I had blithely assumed that to be universally the case. I should hate to have to regard every message as a potential forgery. I often use my nickname (gregbo) in the From: field and use my real name in the Sender: field. It's not to be fraudulent, just to have a little fun. --gregbo -------  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA20435; Wed, 22 Aug 84 10:33:31 pdt Received: from SJRLVM4.BITNET by ucbjade.CC.Berkeley.ARPA (4.14/4.23.5) id AA23132; Wed, 22 Aug 84 10:32:52 pdt Message-Id: <8408221732.AA23132@ucbjade.CC.Berkeley.ARPA> Date: Wed, 22 Aug 84 10:30:45 PDT From: David Alpern To: MRC@SU-SCORE.ARPA Cc: Header-People@MIT-MC.ARPA Subject: Re: user-editable headers In-Reply-To: Message of Tue 21 Aug 84 08:27:06-PDT from Mark Crispin Both the problem of BCCs and of recipient lists can be dealt with reasonably by having the "header template" creator include all of the addressees (all members of the group, all BCC entries) in the header as seen within the editor, and then "hiding" the appropriate entries as the header is parsed to create the envelope. The only difficulty is how to separate those groups whose members the user wants seen from those whose recipient list is to be hidden. Our choice was to hide all group recipient lists, since people did not seem to be using any group names in situations where the recipient list was wanted. Another possibility would be a syntactic distinction (e.g. a * instead of a : after the group name) between the two uses. The only problem this seems to leave is that the user might edit a group recipient list which gets hidden, yielding misleading information about who the recipients were. Since group names really have no semantic meaning from a recipient's viewpoint anyhow, this seems mute. Is there a side to this problem I've missed? - Dave David Alpern IBM San Jose Research Laboratory, K65/282 5600 Cottle Road, San Jose, CA 95193 Phone: (408) 284-6521 Internet: Alpern%IBM-SJ@CSnet-Relay.ARPA Alpern@SJRLVM4.BITNET  Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA01745; Thu, 23 Aug 84 19:24:53 edt Received: by ihnp4.ATT.UUCP; id AA10992; 23 Aug 84 10:39:00 CDT (Thu) To: GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP From: ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist) Subject: Re: user-editable mail headers Message-Id: <775@hou3c.UUCP> Date: Thu, 23-Aug-84 11:30:43 EDT Received: by hou3c.UUCP; Thu, 23-Aug-84 11:30:43 EDT References: <773@hou3c.UUCP> In-Reply-To: <773@hou3c.UUCP> Organization: Bell Labs, Holmdel, NJ I often use my nickname (gregbo) in the From: field and use my real name in the Sender: field. It's not to be fraudulent, just to have a little fun. What you may not realize is that you are having fun in a way that violates RFC 822. (I sometimes wonder whether anyone in Arpaland has ever read that document.) RFC 822 requires that all addresses contain at signs, as your mail program should know but apparently doesn't. Therefore, when your letter arrived here, I had to manually edit the header to replace From: Grebo with From: GDS@MIT-XX.ARPA So nobody on the USENET side of the gateway got to see your little joke. Kenneth Almquist  Date: Thu, 23 Aug 84 20:57 EDT From: "Jon A. Rochlis" Subject: editing the from field To: steve@BRL-BMD.ARPA cc: header-people@MIT-MC.ARPA, gds@MIT-XX.ARPA Message-ID: <840824005720.556900@MIT-MULTICS.ARPA> A better reason for editing the from field, is that the message may be "from" more than one person. For example, a friend and I write a neat hack and we send out a piece of mail describing it and make it from both of us. (It is true though, that only one process is the "sender" and an explicit sender: field seems appropriate when the from field has been hacked by the user.) -- Jon  Date: 23 Aug 1984 19:26 MDT (Thu) Message-ID: From: "Frank J. Wancho" To: ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist) Cc: GDS@MIT-XX, Header-People@MIT-MC Subject: user-editable mail headers In-reply-to: Msg of 23 Aug 1984 09:30-MDT from ihnp4!hou3c!ka at mit-eddie (Kenneth Almquist) Kenneth, RFC822 says many things in different places. One of them says that the Sender: field MUST appear if the From: field is not "correct". Another says that the Reply-to: supercedes the From: field. So, in spite of the "illegality" of the From: field, both the Sender: and the Reply-to: fields were legal. Your complaint should have been made to the maintainer of your mail handler. --Frank  Date: Thu, 23 Aug 84 21:53:53 PDT From: sventek@lbl-ws.arpa Message-Id: <840823215307.007@lbl-ws.arpa> Subject: Re: edited header fields To: header-people@mit-mc.arpa I hate to enter the fray, but it seems that the appropriate chapter and verse need to be quoted concerning the precise syntax required of the From: field in RFC822. The first quote comes from page 18 of RFC822: originator = authentic ; authenticated addr [ "Reply-To" ":" 1#address] ) authentic = "From" ":" mailbox ; Single author / ( "Sender" ":" mailbox ; Actual submittor "From" ":" 1#mailbox) ; Multiple authors ; or not sender As you can see from these two productions, the From field is required to have a single token of type "mailbox" if the sender is the same person that the message is from. If the sender is different, or there are multiple authors, then the sender must contain a single token of type "mailbox" indicating the sender, and the From field must contain one (or more) token of type "mailbox". The next quote provides the productions for "mailbox", and is extracted from page 27 of RFC822: mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec route-addr = "<" [route] addr-spec ">" route = 1#("@" domain) ":" ; path-relative addr-spec = local-part "@" domain ; global address These productions indicate that the mailbox token is always of the form local-part@domain or phrase <[route]local-part@domain> The moral of the story (as I see it) is that if you let your users edit their own headers, then the composition utility must then check all of the headers which have precisely defined syntax requirements (such as From) for compliance with the spec. If there is an illegal header field, then two courses of action can be followed: the composer can try to set things right, or the message can be tossed back at the user. I think most systems opt for the first possibility. Regardless of the method used, the message must be made RFC822 compliant before the message leaves the composer's machine. Joe Sventek  Date: Fri, 24 Aug 84 9:33:45 EDT From: Ron Natalie To: "Frank J. Wancho" cc: header-people@mit-mc.ARPA Subject: Re: user-editable mail headers However, there is a difference between not being correct (having the wrong or non-existant user name) than having the wrong syntax. People who have illegally formatted header lines should be shot. -Ron  Date: Fri 24 Aug 84 08:15:01-PDT From: Mark Crispin Subject: Re: user-editable mail headers To: ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA cc: GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist)" of Thu 23 Aug 84 16:43:40-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The command which GDS uses to generate "From: Gregbo" is a power tool in MM and not a result of any failure in it. There are other commands which can be used to "become" some other user which do ensure valid RFC 822 header lines. A "power tool" is something which lets the user go beyond the program's (narrow) interpretation of whatever standard...either to use some unimplemented or new feature...or in this case to violate it. Just like somebody can hurt themselves with a chain saw, one can abuse a mailsystem power tool. But blame the user, not the tool. -------  Date: Fri 24 Aug 84 08:24:17-PDT From: Mark Crispin Subject: illegality 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) I sure wish that people would use "invalid" instead of "illegal" when referring to syntax validity checking or other forms of user-error checking on computers. "Illegal" should be reserved for things which are against the law; e.g. theft of services, vandalism, fraudulent usage, etc. I still remember the day a few years ago when I found a newly-hired secretary at Stanford CSD crying. You see, it was her first day on the computer, and shortly after being left alone with a zillion things to enter in she made some trivial error which rewarded her with an "Illegal syntax" error message. She was terrified that the FBI was going to come and arrest her! [The fact that "syntax" itself is a horrible word to use in an error message in any program a novice might use is beside the point] I firmly believe that computers should be made more accessible to the general public, not less, and we should start by not misusing the term "illegal." I start feeling ill every time I see some message saying so-and-so's "header is ILLEGAL"! -------  Date: Fri, 24 Aug 84 09:04:50 pdt From: Joseph I. Pallas Subject: Re: user-editable mail headers To: MRC@SU-Score, ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA Cc: GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA "MM doesn't shoot RFC822, people shoot RFC822." Sorry, by no stretch of the imagination can your "power tool" argument justify sending illegal (I mean, invalid) headers out into world. MM can do whatever it wants, but your SMTP mailer is responsible for supplying the safety glasses if MM doesn't. joe  Date: Fri, 24 Aug 84 12:06:40 EDT From: Ron Natalie To: Mark Crispin cc: Header-People@MIT-MC.ARPA Subject: Re: illegality Of course, if you use illegal headers the Protocol Police will come and arrest you. -Ron  Date: 24 Aug 84 1313 EDT (Friday) From: don.provan@CMU-CS-A.ARPA To: Mark Crispin Subject: Re: illegality CC: Header-People@MIT-MC.ARPA, In-Reply-To: "Mark Crispin's message of 24 Aug 84 10:24-EST" Message-Id: <24Aug84.131355.DP0N@CMU-CS-A.ARPA> gee, does that mean we have to stop threatening to call out the protocol police, too?  Received: by YALE-BULLDOG.YALE.ARPA; 24 Aug 84 13:53:55 EDT (Fri) Message-Id: <8408241753.AA06954@YALE-BULLDOG.YALE.ARPA> Date: Fri, 24 Aug 84 13:47:01 EDT From: John R Ellis Subject: Re: illegality To: Mark Crispin Cc: Header-People@MIT-MC.ARPA In-Reply-To: Mark Crispin , Fri 24 Aug 84 08:24:17-PDT I sure wish that people would use "invalid" instead of "illegal" when referring to syntax validity checking or other forms of user-error checking on computers. "Illegal" should be reserved for things which are against the law; e.g. theft of services, vandalism, fraudulent usage, etc. "Illegal" more accurately describes a message with bad syntax than "invalid". From my Random House College Dictionary (a mediocre dictionary): illegal: 1. not legal; contrary to existing statutes, regulations, etc.; unauthorized. invalid: 1. not valid; without force or foundation; indefensible. 2. deficient in substance or cogency; weak. 3. void or without legal force, as a contract. valid: 1. sound; just; well-founded: "a valid objection." 2. producing the desired result; effective: "a valid remedy." 3. having force, weight, or cogency; authoritative. 4. Logic. (of an argument) so constructed that if the premises are jointly asserted the conclusion cannot be denied without contradition. "Illegal" merely implies some non-conformance with a regulation or statute or rule. There is no necessary requirement that there be the force of government behind the rule. For example, it is common usage to say that a move in a game is illegal, i.e. doesn't conform to the rules. "Invalid" on the other hand is mainly used to refer to arguments and methods, especially those involving logic (thinking). For example, you might describe a possible compiler source transformation as invalid. So "illegal" accurrately describes a header that does not conform to the rules of RFC822, rules laid down by a supposedly authoritative agency, DARPA. "Invalid" wouldn't be nearly as good an adjective, since a message header is not an argument or method. It's pretty much mom and apple pie these days that error messages such as "Illegal syntax" or "Invalid header format" are pretty useless to a novice (as Mark points out in with his anecdote). On the other hand, there need be little relation between what our programs say to users and the terminology we used to describe the implementation of the program. -------  Date: Fri 24 Aug 84 12:49:24-PDT From: David Roode Subject: Re: illegality To: MRC@SU-SCORE.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "Mark Crispin " of Fri 24 Aug 84 08:50:20-PDT Location: EJ286 Phone: (415) 859-2774 Mark's explication of illegality reminds me of a solution one computer facility had. The also had a lot of novice users. One of their programs would print: UNASSIGNED JFN AT 321222, FATAL ERROR (That's not so bad.) -------  Received: by mit-eddie.Mit-chaos.Arpa (4.12/4.8) id AA11501; Fri, 24 Aug 84 17:01:26 edt From: ihnp4!hou3c!ka@mit-eddie Date: 24 Aug 84 15:59:34 CDT (Fri) Message-Id: <8408242059.AA08504@ihnp4.ATT.UUCP> Received: by ihnp4.ATT.UUCP; id AA08504; 24 Aug 84 15:59:34 CDT (Fri) To: WANCHO@SIMTEL20.ARPA Cc: GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA Subject: user-editable mail headers In-Reply-To: Frank, I disagree with the way you interpret standards. If you write a program with a syntactically incorrect statement in it, would you try to tell the compiler writer that the compiler should accept the program anyway as long as the statement was not executed? It is true that the message in question had a Sender: field which indicated the real sender of the message and a Reply-to: field which indicated where replies were to be sent to. The fact that the From: field was not used for these purposes does not mean that it is OK for the From: field to be syntactically incorrect. I do not check the syntax of every entry in a mail header. However, RFC 822 requires gateways to parse From: fields. In section 6.2.2 it says: This standard permits abbreviated domain specification.... When a message crosses a domain boundary, all addresses must be specified in the full format, ending with the top-level name-domain in the right-most field. It is the responsibility of mail forwarding services to ensure that addresses conform with this requirement. In the case of abbreviated addresses, the relaying service must make the necessary expansions. Presumably RFC 822 is intended to specify the format of ARPANET mail. It follows that any mailer which sends out nonconforming messages is broken. I should not be told to fix *my* software to deal with such messages. I gather that the mailer on MIT-XX doesn't bother to check the syntax of user specified From: lines on the grounds that users are not supposed to make mistakes. That is not the mark of a quality piece of software. Kenneth Almquist  Date: Fri 24 Aug 84 16:54:05-PDT From: Mark Crispin Subject: Re: user-editable mail headers To: ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA cc: WANCHO@SIMTEL20.ARPA, GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "ihnp4!hou3c!ka@mit-eddie" of Fri 24 Aug 84 15:59:34-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Whether or not software is "quality" or no depends upon whether or not it does what it is intended to do. It is pretty silly to expect Visicalc to execute PL/I programs. The TOPS-20 mailer agrees to act as a mail bridge only, not as a "mail gateway". It is the responsibility of the originating entity to generate a message to the destination in correct format. Similar, all entities should use the same standard for message headers. The mailer (MMailr) knows nothing about RFC 822; its expertise is with RFC 821 and other transport-level protocols. It is completely separate from any message composition agent. Any user agent which does not wish to take the responsibility of composing a valid message for the destination agent should simply not use a mail bridge. Most of the TOPS-20 mail bridges would be happy to have less traffic; they provide it only as a courtesy and not as a guaranteed service. -------  Date: Fri, 24 Aug 84 20:27:17 EDT From: Ron Natalie To: Mark Crispin cc: ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA, WANCHO@SIMTEL20.ARPA, GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA Subject: Re: user-editable mail headers Then you are saying that TOPS-20 users should either get smarter user agents or not use MMailr. Sounds good, when is it likely to happen? -Ron  Date: Sat 25 Aug 84 06:43:53-EDT From: Greg Skinner Subject: Re: user-editable mail headers To: header-people@MIT-MC.ARPA In-Reply-To: Message from "Mark Crispin " of Fri 24 Aug 84 11:28:27-EDT From: Mark Crispin The command which GDS uses to generate "From: Gregbo" is a power tool in MM and not a result of any failure in it. There are other commands which can be used to "become" some other user which do ensure valid RFC 822 header lines. A "power tool" is something which lets the user go beyond the program's (narrow) interpretation of whatever standard...either to use some unimplemented or new feature...or in this case to violate it. Now hold on! Just because I like to modify my headers, it doesn't mean that I am violating the mailsystem! I've seen some really ridiculous headers in my day, and mine is quite reasonable compared to those! Greg Skinner Gds@MIT-XX.ARPA ihnp4!houxm!gregbo (UUCP) -------  Date: Sat 25 Aug 84 07:04:02-EDT From: Greg Skinner Subject: Re: user-editable mail headers To: header-people@MIT-MC.ARPA In-Reply-To: Message from "ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist)" of Thu 23 Aug 84 19:33:05-EDT From: ihnp4!hou3c!ka@mit-eddie (Kenneth Almquist) I often use my nickname (gregbo) in the From: field and use my real name in the Sender: field. It's not to be fraudulent, just to have a little fun. What you may not realize is that you are having fun in a way that violates RFC 822. (I sometimes wonder whether anyone in Arpaland has ever read that document.) RFC 822 requires that all addresses contain at signs, as your mail program should know but apparently doesn't. Therefore, when your letter arrived here, I had to manually edit the header to replace From: Grebo with From: GDS@MIT-XX.ARPA So nobody on the USENET side of the gateway got to see your little joke. Kenneth Almquist People on the more civilized side of ucbvax do read RFC 822. I have read it also. All you had to do was delete the From: line and take what was in the Sender: line and manually replace it. Since there is an authenticated Sender: field generated whenever a From: field is munged, the message still stays within legality of RFC822. The only problem is readnews' and its brothers' inabilities to read Arpanet mail. Simple fix to readnews -- just have the Sender: field examined if the From: field is unparseable. One more thing, in case you didn't know, I work at Bell Labs also, so I have the experience of both ARPA and Usenet message composition. Don't blame the user, blame the standards' (RFC850 and RFC822) different interpretation of From: Greg Skinner (I do read RFCs!) Gds@MIT-XX.ARPA ihnp4!houxm!gregbo (UUCP) p.s. perhaps mit-vax is at fault also! -------  Date: Sat 25 Aug 84 09:12:21-PDT From: Mark Crispin Subject: Re: user-editable mail headers To: ron@BRL-TGR.ARPA cc: ihnp4!hou3c!ka%MIT-EDDIE@MIT-MC.ARPA, WANCHO@SIMTEL20.ARPA, GDS@MIT-XX.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "Ron Natalie " of Fri 24 Aug 84 17:29:28-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Well, in fact, I have started the specification for a smarter user agent than MM. MM has reached the end of its useful lifetime. There are other user agents of varying strengths and weaknesses for TOPS-20 that interact with MMailr: Babyl and Hermes come immediately to mind. Many of the messages that people have complained about did not, in fact, originate at a TOPS-20 system. Many of them did, in fact, originate on a Unix system! You see, while there are very good mailers on Unix there are very poor ones. Some of the latter think it is alright to send a letter out on the Internet simply by bouncing it to a TOPS-20 system after having appended "@host" (where host is the name of the TOPS-20 system) to the From: line. I feel it violates all concepts of modularity to have the mail delivery agent know about whatever is inside the message. Part of the problem is that the Internet mail protocols still insist upon having syntax-checking of this thing called a "message header" inside the message, instead of having all that stuff be external and/or obtained from the envelope at the transport level where it belongs. -------  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA03190; Sat, 25 Aug 84 10:42:55 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.23.5) id AA00422; Sat, 25 Aug 84 10:44:34 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.5) id AA10519; Sat, 25 Aug 84 10:44:18 pdt Date: Sat, 25 Aug 84 10:44:18 pdt From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8408251744.AA10519@ucbopal.CC.Berkeley.ARPA> To: MRC@SU-SCORE.ARPA Subject: Re: user-editable mail headers Cc: header-people@mit-mc.ARPA In reply to: Date: Sat 25 Aug 84 09:12:21-PDT From: Mark Crispin Subject: Re: user-editable mail headers .... I feel it violates all concepts of modularity to have the mail delivery agent know about whatever is inside the message. Part of the problem is that the Internet mail protocols still insist upon having syntax-checking of this thing called a "message header" inside the message, instead of having all that stuff be external and/or obtained from the envelope at the transport level where it belongs. ------- Lets be clear about whether you are talking about mail user agent or mail transport agent functions. A message composed by a user should have its headers validated before it is passed to a mail transport agent to be transmitted. That is, the header should be full and complete before it is passed to the envelope builder. I concur that the envelope should contain the information it needs to the job. For example, Precedence and Classification should be part of the SMTP envelope. But since those fields are user defined (in the DOD community), they first have to be in the "contents" header. Within the same mail system, it should not be necessary for intermediate mail agent program to check or modify the "contents" message header (with the exception of adding the "Received" audit trail). However, when the message is gatewayed into another mail system, format and address conversion may need to be preformed. I think some of the problems we have been having are a result of the unofficial policy of making mail programs liberal in what they are willing to receive and (hopefully) strict about what they transmit. I would like to suggest that gateway mail agents enforce the rules. If you are a gateway into the Internet mail community, you should have a syntax and address checker between the Internet mail agent program and the non-Internet mail system. Of course, if you want to be kind to your non-Internet neighbor, you can put a conversion program between the non-Internet mail system and the check program. Bill Wells wcwells@Berkeley.ARPA ucbvax!wcwells WCWELLS@UCBJADE.BITNET  Date: Sun 26 Aug 84 12:36:29-PDT From: Mark Crispin Subject: Re: user-editable mail headers To: wcwells%ucbopal.CC@UCB-VAX.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "wcwells%ucbopal.CC@Berkeley (William C. Wells)" of Sat 25 Aug 84 10:53:22-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Let's get some other things straight. What is the point of a power tool to create arbitrary headers if some process (be it composition or transport) decides to "correct" them? It means that you cannot experiment with new header syntaxes without writing code to do so. I am greatly prejudiced against having mail transport agents (or even mail bridges -- which some call "mail gateways") know about RFC 822. Time and time again I have seen perfectly valid headers munged into unrecognizability by such overly-"helpful" bridges. Personally, I consider mail bridges in general to be a crock. If it weren't for every trivial entity which strings up a network thinking they have God's gift for designing the perfect network protocols, we wouldn't have this plethoria of different network protocols that require mail bridges. -------  Date: 27 August 1984 00:13-EDT From: header-people-request @ MIT-MC Sender: CENT @ MIT-MC Subject: this is a test To: HEADER-PEOPLE @ MIT-MC cc: HEADER-PEOPLE-REQUEST @ MIT-MC of the early warning mailing list error msg system. do not respond unless you do not receive this msg.  Date: 28 August 1984 01:51-EDT From: Pandora B. Berman Subject: Re: test To: ihnp4!garfield!tag @ UCB-VAX cc: HEADER-PEOPLE @ MIT-MC Date: Tue, 28 Aug 84 00:31:38-0330 From: ihnp4!garfield!tag@Berkeley (Terry Greening) To: CENT@MIT-MC.ARPA Subject: Re: test Date: 27 August 1984 00:45-EDT From: Pandora B. Berman Subject: test To: ihnpa!garfield!tag@BERKELEY, ihnp4!garfield!tag@BERKELEY this is a test. we have some problems with your address on the HEADER-PEOPLE list. if you get this msg please respond indicating your correct address. thank you.. As you can see I did receive your test message. The correct path is through site "ihnp4". I would like you to send mail to a group called "header-people" on our system. The correct address should be: ihnp4!garfield!header-people@BERKELEY Once again, thank-you. aha. somehow i had originally entered you as at ihnpA!..., which caused a host-unknown msg from berkeley when i sent a recent test msg. you are fixed now, and i have added the local redistribution list you requested. are you going to read from that (should i remove you from the list here), or do you want to continue to get header-people mail directly from MC?  Received: From hp-labs.csnet by csnet-relay; 29 Aug 84 17:16 EDT Received: by HP-VENUS id AA24117; Wed, 29 Aug 84 12:32:20 pdt Message-Id: <8408291932.AA24117@HP-VENUS> Date: Wed 29 Aug 84 12:32:03-PDT From: Scott L. McGregor Subject: [Scott L. McGregor : Re: illegality] To: header-people@mit-mc.arpa Source-Info: From (or Sender) name not authenticated. Mail-From: MCGREGOR created at 29-Aug-84 12:28:10 Date: Wed 29 Aug 84 12:28:09-PDT From: Scott L. McGregor Subject: Re: illegality To: ron%brl-tgr.arpa@csnet-relay cc: MCGREGOR@HP-HULK In-Reply-To: Message from "Ron Natalie " of Fri 24 Aug 84 14:19:49-PDT I will just make a few observations on "illegality","protocol police", and "shooting mail system administrators who allow illegal headers to leave their mailsystems", and then I will step out of the fray. It is ironic that a document called RFC (request for comment) is regarded as a law that some would have treated as a capital offence and to be policed by protocol police. While I don't regard the violations of the guidelines proposed in RFC822 as quite as serious as some do, I do recognize that there is much a human problem here as a machine or program problem. Here's my analysis: Many people see great benefits in reaching the Internet community by mail. This makes it desirable for them to get up a mail bridge to get into the system as quick as possible, and as is equally human, with the least amount of effort required. There are two strategies in building such a mail connection that are particularly of interest: 1) saving on building a input checking routine (assuming everyone follows the standard) and 2) saving on building an output checking routine (assuming that no one will hand you bad stuff to send out). Some sites seem to have adopted one strategy or the other. Some have even adopted both. Whenever someone who doesn't do output checking sends some garbage to someone who doesn't do input checking, the fur starts to fly in header-people. RFC733 and 822 have something to recommend about this, and there has long been a policy recommended by header-people and others that goes something like this (in various variants): 'It is good courtesy (and smart practice) to make your mail interface to the net as strict as possible about what it transmits (outbound) and as flexible as possible about what it will receive (inbound).' This is of course entirely contrary to the two strategies described above (don't input check and don't output check). For a real problem to exist there have to be two systems at fault, the one who sent the garbage and the one who received it and belched. Both sides have failed to meet the courtesy standard, and so argue about who is more at fault, and who should have to do something about it in the future. I don't find this kind of discussion very helpful. Both systems need to change. Given human organizations, the one who doesn't change is just asking for another problem in the future. Both systems should be made more error tolerant in my opinion. Of course, any changes that need to happen, won't happen overnight. Thats just how organizations and people work. But there are things that can be done to speed up these changes, and I find discussing these much more productive. In particular, there seems to be precious little discussion on how to do better error checking on output and how to do correction on input. What we mainly hear is that we should all just do a better job of it. I must admit that in my mail interface programs I have made many mistakes in the past and that these have been pointed out to me by angry mail administrators. I have tried to address them as quickly as possible, but I'll let you all in on a hint to quicker fixes. I have always responded faster to complaints that suggested how the actual repair could be accomplished (in code or pseudo code) than I have to those that just said that it needed to be fixed and that I should do it now. In the interest of more robust systems everywhere, I would like to see much more code sharing. recklessly yours, Scott McGregor ------- -------  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2640159562548570@MIT-MULTICS.ARPA>; 30 Aug 1984 05:39:22 edt Date: 29 Aug 84 23:47 +0200 From: Tommy_Ericson_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Tommy_Ericson_QZ_%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: header-people , Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Re: user-editable mail headers Message-ID: <68007@QZCOM> In-Reply-To: <66788@QZCOM> (Text 66788) 84-08-22 11.39 GDS @ MIT-XX.ARPA %Original date: Tue 21 Aug 84 19:59:48-EDT. %FROM: Gregbo %In-reply-to: Message from "Stephen Wolff " of Sat 18 Aug 84 22:12:45-EDT %SMTP sender: @MIT-MULTICS.ARPA,@MIT-MC:GDS@MIT-XX.ARPA I often use my nickname (gregbo) in the From: field and use my real name in the Sender: field. It's not to be fraudulent, just to have a little fun. In our COM computer conferencing system we want to retain as much security and stringency as possible. Therefore we select the sender name from the SMTP-sender field but adds a different From field right into the text just for user information. I.E. with reliable (in some measure) mail agents consistency is retained as far as possible. Nicknames: we don't have'm. But we allow sort of fuzzy matching: "t er q", "ericson qz" and "zeke" (just for fun) are valid local parts. To MRC: Yes, TOPS-20 does not allow user programs to get "temporary" privs. But it is rather easy to install a monitor call that will allow a certain program to access a certain file safe, we have done this to ensure that only THE (execute-only) program may access the message data base.  Date: Thu, 30 Aug 84 09:04 EDT From: "Benson I. Margulies" Subject: Sender versus the envelope To: header-people@MIT-MC.ARPA Message-ID: <840830130411.326570@CISL-SERVICE-MULTICS.ARPA> Proposition: To the extent that a mailsystem is secure, that security is asssured by careful maintenance of envelope information by servers. If this statement is correct, then it follows: The presence of a Sender field prepared by the sending agent in the text is a convienience to aid in replies, but is not any good for security. Thus, a mail reading program should by default show the From field, which is the sender's advertised name, and the Envelope Sender in formation, which is the trustworthy name. The Sender field should only be used to send replies, or if the user explicitly asks after it. Is this consistent with other people's interpretations? --benson  Date: Mon, 3 Sep 84 14:55:54 PDT From: Rich Wales To: Header-People@MIT-MC.ARPA Subject: "bare CR" and "bare LF" in RFC822 headers RFC822 says you can have "bare" CR's and LF's in header text. For example, the definition of the lexical token "text" (Section 3.3, page 10) reads as follows: text = atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized. Also, the discussion on quoting (Section 3.4.1, page 11) mentions that a CR must be quoted (i.e., preceded by a backslash) if it occurs within a quoted string, domain literal, or comment. This is, I suppose, implicit evidence that someone thinks CR's or CRLF's could appear in addresses. What I want to know is -- does ANYONE, ANYWHERE, use (or intend to use) "bare" CR's or LF's in addresses, or indeed anywhere else in a header? (I am, of course, not talking about the CRLF end-of-line delimiter.) Rich Wales UCLA Computer Science Department 3531 Boelter Hall // Los Angeles, CA 90024 // (213) 825-5683 ARPA: wales@UCLA-LOCUS.ARPA UUCP: ...!{cepu,ihnp4,trwspp,ucbvax}!ucla-cs!wales  Date: 3 Sep 84 1926 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: Rich Wales Subject: Re: "bare CR" and "bare LF" in RFC822 headers CC: Header-People@MIT-MC.ARPA In-Reply-To: "Rich Wales's message of 3 Sep 84 16:55-EST" Message-Id: <03Sep84.192613.EN0C@CMU-CS-A.ARPA> Rich, CMU does not use the bare cr or bar lf BUT it handles cr, lf and crlf all the same...they are treated as end-of-line and are converted to whatever the local end-of-line convention is. "...be conservative in what you send and liberal in what you receive..." -Rudy  Received: from Gamay.ms by ArpaGateway.ms ; 03 SEP 84 22:17:27 PDT From: DonWinter.pasa@XEROX.ARPA Date: 3 Sep 84 22:17:09 PDT Subject: Re: [Scott L. McGregor : Re: illegality] In-reply-to: MCGREGOR%hp-labs.csnet@CSNET-RELAY.ARPA's message of Wed, 29 Aug 84 12:32:03 PDT, <8408291932.AA24117@HP-VENUS> To: Scott L. McGregor cc: header-people@MIT-MC.ARPA Scott, I'm pleased to see a little sanity injected into this political discussion. Of course, I expect it to have as much impact as sanity injected into any other political discussion. Sigh. Don  Date: 4 Sep 84 1154 EDT (Tuesday) From: Craig.Everhart@CMU-CS-A.ARPA To: Header-People@MIT-MC.ARPA Subject: Re: "bare CR" and "bare LF" in RFC822 headers In-Reply-To: "Rich Wales's message of 3 Sep 84 16:55-EST" Message-Id: <04Sep84.115407.RD00@CMU-CS-A.ARPA> Even if your poll shows that nobody polled intended to use bare CRs or LFs in their addresses, would you feel justified in not providing support for them in your mail handling software? After all, if you fail to support that part of the standard, you can't claim that you follow it. Who knows what somebody will try to use as an address some day? For whatever reason? It sure sounds like interpreting quoted CRs and LFs as other than text (e.g., as a line break) is a bad idea, also.  Received: from [mrxa] by 44d.Ucl-Cs.AC.UK via Janet with NIFTP; 10 Sep 84 12:46 BST Received: from Maths.Nott.AC.UK by Hcig.Nott.AC.UK via Phonenet; 10 Sep 84 12:45 BST Date: 10 Sep 84 12:35:44 BST (Mon) To: header-people-request@mit-mc.arpa CC: HEADER-PEOPLE@mit-mc.arpa, tdl%maths.hcig.nott.ac.uk@ucl-cs.arpa Subject: Re: this is a test In-reply-to: Your message of 27 August 1984 00:13-EDT. From: Tdl%maths.hcig.nott.ac.uk@ucl-cs.arpa Sender: Tdl%maths.hcig.nott.ac.uk@ucl-cs.arpa test  Date: Sat, 15 Sep 84 14:39:52 PDT From: Rich Wales To: Header-People@MIT-MC.ARPA Subject: What are SMTP commands "EXPN" and "VRFY" good for? I would like to hear some other people's opinions on the SMTP "EXPN" and "VRFY" commands. I seriously wonder what, if anything, these commands are good for. As everyone probably knows, they are not required in the "minimum" SMTP server implementation, and I can think of very few situ- ations in which a mailer program would ever need (or want) to use them. First, my gripes with EXPN. The problem with using EXPN to expand a remote mailing list is that this spoils any attempt by the receiving host to direct "undeliverable mail" messages to someone who can fix the problem. I think everyone by now agrees that problems relating to an invalid address on a mailing list should be reported to whoever is responsible for maintaining the mailing list -- NOT to the person who sent a message to the list. But there is no provision in the EXPN command for the server to pass this information back to the requesting host. Hence, any host which used EXPN in order to send directly to everyone on a remote mailing list would defeat any attempt by the remote host to direct error messages to the right place (by substituting a new "return path" as the list was expanded). Admittedly, mailing lists could be flagged in some way so that an EXPN on the name would return only one line (namely, the address of the list) -- but if you do this, what's the point in having EXPN at all? Now, the problems with VRFY. I have seen only one ARPANET host whose mailer routinely uses VRFY (namely, MIT-MULTICS). Even MIT-MULTICS appears to use VRFY only when relaying mail originating on MAILNET. The scenario seems to be as fol- lows (based on an examination of the various system logs kept by our SMTP server): (1) MIT-MULTICS connects to our SMTP server and issue a VRFY -- which is rejected with a 502 ("command not implemented") reply code. (2) MIT-MULTICS, upon having its VRFY command rebuffed in this manner, does a QUIT and closes the connection. (3) Almost immediately thereafter, MIT-MULTICS connects to our SMTP server again and, without trying another VRFY, sends mail to the user named in the previous session's unsuccessful VRFY. I sent a message to Postmaster@MIT-MULTICS a little while ago asking about this strange behavior, but never received a reply. I also re- cently added code to our SMTP server to implement VRFY (for local user names and mailing lists only), and I'm waiting to see what happens if MIT-MULTICS says VRFY to us and gets a real answer back -- but, so far, there have been no takers. The idea of doing a VRFY on a user name before trying to send mail to that name disturbs me. RFC821's description of VRFY is vague enough to make it unreliable as a means for validating an address before mailing to it. This is particularly true when non-local user names are involved (if someone wants to send to "podunk!fred@UCLA-LOCUS.ARPA", there is no way we can validate a command like "VRFY podunk!fred"). In any case, I thought that validation of a recipient address -- if done by the SMTP server at all -- belonged in the processing of the RCPT command. The only scenario I can currently think of where a mailer program might want to use VRFY is if a RCPT command is rejected and the mailer wants to get as much info as possible to send back to the user. For example, assume I call up the PODUNK.ARPA SMTP server and try to send mail to "fred@PODUNK.ARPA": 220 PODUNK.ARPA SMTP server ready helo UCLA-LOCUS.ARPA 250 PODUNK.ARPA (hi there, UCLA-LOCUS.ARPA) mail from: 250 OK rcpt to: 550 Sorry, no one named here At this point, I could do a VRFY and see if I get anything interesting: vrfy fred 553-Ambiguous user name; try one of: 553-Fred Jones 553 Fred Smith quit 221 PODUNK.ARPA SMTP server says bye-bye Now, when I send the obligatory "rejection notice" back to the message sender, I can include the reply to the VRFY in the message -- perhaps like this: Date: Sat, 15 Sep 84 14:20:10 PDT From: UCLA-LOCUS Mail System To: John Jones Subject: Undeliverable mail to ===== transcript of mailer session follows ===== rcpt to: 550 Sorry, no one named here vrfy fred 553-Ambiguous user name; try one of: 553-Fred Jones 553 Fred Smith ===== unsent message follows ===== . . . Other than this, I really can't think of a good use for VRFY. -- Rich  Received: by UCB-VAX.ARPA (4.24/4.31) id AA22333; Sat, 15 Sep 84 19:10:25 pdt Received: by ulysses.UUCP; Sat, 15 Sep 84 22:06:02 edt Received: by kalypso.UUCP; Sat, 15 Sep 84 22:05:49 edt Date: Sat, 15 Sep 84 22:05:49 edt From: ulysses!smb@Berkeley (Steven Bellovin) Message-Id: <8409160205.AA15551@kalypso.UUCP> To: header-people@mit-mc.ARPA, wales@ucla-locus.ARPA Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for? Except for the problem of failed mail in a list expansion -- on which matter I agree with Rich Wales -- EXPN struck me as a good idea for handling mail to multiple lists, or to a person and a list. As is, Rich is going to receive two copies of this letter -- one direct, and one via the list expansion. A sufficiently smart mailer could use EXPN to discover that Rich is on the list, and not send him a separate copy. (We'll ignore the fact that this particular note is going via uucp to an SMTP host; it wouldn't really change anything if it weren't.) --Steve Bellovin AT&T Bell Laboratories ulysses!smb@berkeley.arpa smb.ulysses.btl@csnet-relay (should work, but probably doesn't) smb.research.btl@csnet-relay (works more often)  Date: 16 Sep 84 18:27:56 EDT From: jpm@BNL To: Header-People@MIT-MC Subject: Distribution lists I'm very new at this so please forgive me if this is obvious to the rest of you, it sure isnt to me. I want to implement a way for users to send to a mailing list stored in a file. I dont want to update the system alias table every time somebody creates a mailing list, and I dont want to implement private alias tables for each user. I have seen messages with a format something like To: My-Dist-List: :INCLUDE: "DISK:MYLIST.DST"@MYHOST.ARPA ; This seems to be what I want, but I cant find that format in RFC822. Is this a hack by a particular host to do file includes or is it the standard way of doing it? John McNamee jpm@Bnl.Arpa  Date: Mon, 17 Sep 84 08:18:48 pdt From: Steven Tepper Subject: VRFY To: wales@ucla-locus Cc: greep@su-russell, header-people@mit-mc One potential use of VRFY is to check that all addresses are valid before trying to deliver to any of them, for example in case the sender might have mistyped one of them and doesn't want address errors to be propogated in replies to the original message. But this doesn't work unless all the hosts at which you want to verify an address implement VRFY and are up when you try doing the VRFY (unless you want to wait for them all to be up before sending to any of them). Even if they all implement VRFY, they may not be able to do it in real time for addresses which are not local, as you point out with the case of uucp.  Date: Mon, 17 Sep 84 11:35 EDT From: Barry Margolin Subject: Re: Distribution lists To: jpm@BNL.ARPA cc: header-people@MIT-MC.ARPA Message-ID: <840917153533.394324@MIT-MULTICS.ARPA> The :INCLUDE: syntax is an obsolete syntax that may have been in RFC733, but is not in RFC822. It is still in use, however, by some of the older mailers. There is no standardized syntax for mailing lists. On Multics we have a number of address types for which there is no standard syntax, and we handle them by using a special syntax in the local-part of addresses. In particular, we use the syntax To: "{list PATHNAME}"@MYHOST.ARPA for mailing lists. Since the string is quoted it is treated as an ordinary local-part by properly functioning software on other hosts. barmar  From: Larry Peterson Message-Id: <8409171559.AA20944@merlin.ARPA> Received: by merlin.ARPA; Mon, 17 Sep 84 10:59:07 est Date: 17 Sep 1984 1059-EST (Monday) To: Barry Margolin Cc: header-people@MIT-MC.ARPA, jpm@BNL.ARPA Subject: Re: Distribution lists In-Reply-To: Your message of Mon, 17 Sep 84 11:35 EDT. <840917153533.394324@MIT-MULTICS.ARPA> Sendmail gives you an easy mechanism for implementing mailing lists defined outside of /usr/lib/aliases. You just tag the list's alias to indirectly point to a file, where the file contains the members of the group. Larry  Date: 17 Sep 84 1208 EDT (Monday) From: Craig Everhart@CMU-CS-A.ARPA To: Header-People@MIT-MC.ARPA Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for? Sender: Craig.Everhart@CMU-CS-A.ARPA Reply-To: Craig.Everhart@CMU-CS-A.ARPA In-Reply-To: "Rich Wales's message of 15 Sep 84 16:39-EST" Message-Id: <17Sep84.120838.RD00@CMU-CS-A.ARPA> I can think of several uses for EXPN and VRFY. As Rich notices, it's too bad that EXPN doesn't have more options to handle mailing-list exploders and the destinations for error replies. Surely EXPN was conceived without taking such issues real seriously. EXPN can be used, as has already been noted, to suppress sending private copies of messages that are also destined for mailing list delivery. Of course, the client of a mailer that does such suppression must accept that he will not necessarily be notified on late or failed delivery. Then again, even though it goes against our images of what all mailing lists ``should'' be like, there can easily be (small) lists that have no particular maintainer; they act as simple address exploders rather than as redistributors that take responsibility for the redistribution. With such lists (which seem to be the sort of list for which EXPN in its present form was designed), EXPN has obvious use both in eliminating duplicate delivery and in reducing the number of forwarding hops necessary. I can see several uses for VRFY, also. Let's suppose that a user agent for electronic mail wanted its client (a user) to know about misspellings of names that he typed in, and that it wanted him to know about them right away. It could connect to the proposed destination host and try to VRFY the addresses that the user gave. Then, once the mail was to be delivered, the user agent might just let a daemon process do that. (Rationale? Not easy, until you think that maybe the user doesn't really care if the mail goes out immediately or in several minutes; maybe the user wants to do something else right now.) Another use of VRFY could be as follows. Suppose a program maintains distribution lists for people. Suppose that it has a command to validate the addressees named in the list; perhaps this is to update the list to account for new forwarding links or new host names that have been established since the list entry was made. What better tool is there than VRFY, which checks addressees on foreign hosts without actually sending mail? When a feature is being used, it's a good bet that it's a usable and useful feature. However, just because a feature isn't much used yet doesn't mean that it's not both usable and useful. Give it time! Craig Everhart  Date: 17 Sep 84 1337 EDT (Monday) From: don.provan@CMU-CS-A.ARPA To: Rich Wales Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for? CC: Header-People@MIT-MC.ARPA, In-Reply-To: "Rich Wales's message of 15 Sep 84 16:39-EST" Message-Id: <17Sep84.133744.DP0N@CMU-CS-A.ARPA> i've always assumed that VRFY would be used only in reaction to a user's request. in other words, a user would say "verify jones@cmu-10a" and the program would run out and check on the existence of such a user. there are any number of reasons a person may want to check an address in such a way. for me, it's usually because i can't remember whether jones has his mailbox on cmu-10a or cmu-10b. VRFY allows me to check this without actually sending mail. i assume EXPN is for similar purposes. it's not intended to be used to deliver mail to the list. it allows a user to find out who's on the list. i didn't have anything to do with designing this protocol, so i'm guessing when i say "intended", but it certainly seems like the more obvious use of optional commands. i'd also like to point out that i talk big, but none of my software uses or supports these two commands in any way.  Received: from SCRC-PEACE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 92095; Mon 17-Sep-84 12:21:19-EDT Date: Mon, 17 Sep 84 12:20 EDT From: Charles Hornig Subject: What are SMTP commands "EXPN" and "VRFY" good for? To: Rich Wales , Header-People@MIT-MC.ARPA In-Reply-To: The message of 15 Sep 84 17:39-EDT from Rich Wales Message-ID: <840917122038.0.HORNIG@PEACE.SCRC.Symbolics> Date: Sat, 15 Sep 84 14:39:52 PDT From: Rich Wales I would like to hear some other people's opinions on the SMTP "EXPN" and "VRFY" commands. I seriously wonder what, if anything, these commands are good for. As everyone probably knows, they are not required in the "minimum" SMTP server implementation, and I can think of very few situ- ations in which a mailer program would ever need (or want) to use them. First, my gripes with EXPN. We (Symbolics) use EXPN solely to support our user-level "Show Mailing List" command. The actual sending of mail does not use it. Now, the problems with VRFY. I have seen only one ARPANET host whose mailer routinely uses VRFY (namely, MIT-MULTICS). Even MIT-MULTICS appears to use VRFY only when relaying mail originating on MAILNET. The scenario seems to be as fol- lows (based on an examination of the various system logs kept by our SMTP server): (1) MIT-MULTICS connects to our SMTP server and issue a VRFY -- which is rejected with a 502 ("command not implemented") reply code. (2) MIT-MULTICS, upon having its VRFY command rebuffed in this manner, does a QUIT and closes the connection. (3) Almost immediately thereafter, MIT-MULTICS connects to our SMTP server again and, without trying another VRFY, sends mail to the user named in the previous session's unsuccessful VRFY. I sent a message to Postmaster@MIT-MULTICS a little while ago asking about this strange behavior, but never received a reply. I also re- cently added code to our SMTP server to implement VRFY (for local user names and mailing lists only), and I'm waiting to see what happens if MIT-MULTICS says VRFY to us and gets a real answer back -- but, so far, there have been no takers. Multics systems send a VRFY when they are acting as a mail relay and receive a RCPT for a non-local recipient. The idea is to make a best effort to get the appropriate error back to the sender syncronously. If the VRFY command is not completed successfully (as was the case above) the mail is accepted anyway for forwarding.  Date: 17 Sep 84 16:30:11 EDT From: jpm@BNL To: Header-People@MIT-MC Subject: Thanks for distribution list info Thank you to the people who sent me information on including files of mailboxes. I've decided to implement it using ":INCLUDE: file"@Host. This should keep it from blowing the mind of of some other mailer. John McNamee  Date: Mon, 17 Sep 84 17:46 EDT From: Barry Margolin Subject: Re: Distribution lists To: Larry Peterson cc: header-people@MIT-MC.ARPA, jpm@BNL.ARPA In-Reply-To: Message of 17 Sep 84 11:59 EDT from "Larry Peterson" Message-ID: <840917214620.110302@MIT-MULTICS.ARPA> Larry Peterson's response is not apropos to the question. jpm specifically asked for a mechanism that did not require updating the central alias file when a user creates a personal mailing list. It sounds like your sendmail mechanism doesn't fit the bill. The only advantage that indirection provides is that the user doesn't have to modify the alias file to modify the mailing list. However, that isn't what he asked for. barmar  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2641807270918172@MIT-MULTICS.ARPA>; 18 Sep 1984 07:21:10 edt Date: 15 Sep 84 15:46 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Re: illegality Message-ID: <69859@QZCOM> In-Reply-To: <67429@QZCOM> How many books do you want? FIVE %XYZ123 ILLEGAL NUMERIC ITEM A more suitable error message text would be Sorry, the computer does not understand this!  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2641807392228511@MIT-MULTICS.ARPA>; 18 Sep 1984 07:23:12 edt Date: 16 Sep 84 05:04 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: header-people bcc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Name data base or Name and Host data base Message-ID: <69941@QZCOM> I have an important design question for a future interface to RFC mail, where I would like the advice of other people in the header-people group. I would like to automatically build up a data base of people, with whom our users often communicate, from the names and adresses of people in the header fields of incoming messages. This data base can be organized in two ways: (1) A data base of names of people. For each name, the full return path to that person is stored. (2) A data base of hosts and names. For each name, only the host name is stored. The return path to that host is then stored on the host. Note that there are in-between alternatives. For a name like AAA!BBB!CCC%DDD@EEE this could be stored as (a) the name "AAA!BBB!CCC%DDD" at the host "EEE", or as (b) the name "AAA!BBB"CCC" at the host "DDD" or as (c) the name "CCC" at the host "BBB". Of those three alternatives, I would much prefer alternative (c) with the real name and the real host. But my main problem is selection between alternatives (1) and (2) above. Some arguments: Arguments for (1): This solution will not cause any problem if two hosts have the same name (except if two people have both the same name and the same host, but this has VERY low probability). Also, faulty path information for one person will only affect the return path to that person, not to anyone else. It will thus be easier to create the data base automatically from pathes in incoming messages. With solution (2), a new return path for a host in a new incoming message cannot immediately be stored on that host, since the faulty path will then cause all messages to that host to go wrong. Thus, solution (2) will require more manual checking. Arguments for (2): The correct and proved path to a certain host need only be stored once in the data base, and will then be available for all messages to be sent to anyone at that host in the future. Less information is duplicated in the data base with this solution. Note: We presently are using solution (1) and it works rather well. But since we plan to re-write everything, we can decide on solution (2) when design the next version of the program. What is your opinions? Please help me!  Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2641807439242285@MIT-MULTICS.ARPA>; 18 Sep 1984 07:23:59 edt Date: 16 Sep 84 11:53 +0200 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people Subject: Illegality in from fields Message-ID: <69950@QZCOM> In-Reply-To: <8408291932.AA24117@HP-VENUS> Original date: Wed 29 Aug 84 12:32:03-PDT. FROM: Scott L. McGregor For a real problem to exist there have to be two systems at fault, the one who sent the garbage and the one who received it and belched. Both sides have failed to meet the courtesy standard, and so argue about who is more at fault, and who should have to do something about it in the future. I do not agree. Our interface is certainly written according to the principle: Accept much in input, follow standards strict on output. (With some small exceptions, we are misusing the BCC field on output.) But in our system, we have a special command to make it easy to send a message to the author of a previous message. If the RFC822 header does not contain the necessary information to implement such a command, then the system which created this header is to be blamed. Also, I would certainly prefer not to have to have two different algorithms in order to find out where to send a reply to the author, one for headers from some systems and one for headers from another system. No field except the FROM field gives information about where to send a reply to the author of a message except possibly the REPLY-TO field. Also, we have another command in our system to send a reply to everyone who received a certain previous message. For that command to work, we need correct machine addresses in the TO, CC and BCC fields. Some systems include unexpanded local macro calls in these fields, and only expand these macros to correct machine addresses in the SMTP-RECEIVER fields. We do not like this. And that is not because we are unliberal or narrowminded, but only because we want to provide a good service to our users with these two replying commands which we have.  Date: Tue 18 Sep 84 08:31:39-MDT From: William G. Martin Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for? To: header-people@MIT-MC.ARPA cc: wmartin@ALMSA-1.ARPA In-Reply-To: Message from "Charles Hornig " of Mon 17 Sep 84 14:08:00-MDT The recent discussion of the EXPN and VRFY commands included a couple mentions of using EXPN to implement a command that would let a user discover who is on a remote mailing list. I had never heard of such a command before, but, now that I know it is possible, I want it! As a contact point at my Activity for message-system problems and advice, I have often been asked by various users who send mail to a remote mailing list how to find out the actual recipients of such mail. For lists with regular maintainers and "list-Request" addresses, it is often possible to either write the request address or locate and read the actual file of addresses via FTPing to the distribution host. (This was easy on MIT-based distributions, but not possible on BRL-based distributions, where anonymous FTP login is not allowed.) For other lists, where the maintainer is not known, it is difficult. So, if a simple, user-executable command exists that I can tell a secretary to use to find out who is on the "DMIS-Chiefs@BRL" list, I need to know it! I need such a command for our 4.2 BSD UNIX main host (ALMSA-1), which runs mmdf mail. I'd also like to find it on this TOPS-20 host from which I am sending this message. Is it there, already existing, and I just don't know what the command is? Or do I have to get the command implementation from somewhere and have our operating systems people install it? Or is this only implemented by a couple people out there and it isn't really available at all? And does this discussion, in which most people say that their host ignores the "EXPN" command anyhow, mean that, even if I located and installed the user-command to perform this function, it wouldn't work in most cases anyway? (Caught up to the heights of joy, and then cruelly dashed on the rocks of despair...) Will Martin USArmy AMC ALMSA, St. Louis, MO -------  Date: Tue 18 Sep 84 08:45:21-PDT From: Mark Crispin Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for? To: WMartin@SIMTEL20.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from "William G. Martin " of Tue 18 Sep 84 07:47:08-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The distributed version of the TOPS-20 SMTP server (MAISER) supports both the VRFY and the EXPN commands. For local mailing list expansion lookups, you can run the MMailbox program (or XMailbox for very old systems). It would not be too difficult to write a network "remote mailing list query" program for TOPS-20 or for that manner any operating system. I'd be surprised if it took a junior programmer more than 15 minutes to do it. I've always been lazy and TELNET'd to the SMTP server. -------  Date: Tue, 18 Sep 84 12:50:49 EDT From: G B Reilly To: Header-People@mit-mc.ARPA Subject: MCI Mail Recently I was on a business trip to complete a contract with a three-letter government agency. Since I had no stationery with me at the time, I decided to use MCI Mail to send in the invoice. Well, a month passed, and I called down to the Finance office, who told me 'We never received it.' This didn't sound right - I had never had MCI lose mail before. A few days later, the Finance people called, telling me they had found the invoice. After some questions, I found that the bright orange invoice had been placed, UNOPENED, on the desk with ADVERTISEMENTS. By coincidence, I had called just before someone got around to opening the "ad" - my invoice. So much for casting "leading technology" onto those who know nothing about it.  Date: Wed, 19 Sep 84 02:43 EDT From: Barry Margolin Subject: Re: Name data base or Name and Host data base To: Jacob_Palme_QZ@QZCOM.MAILNET cc: header-people@MIT-MC.ARPA Message-ID: <840919064304.199768@MIT-MULTICS.ARPA> A problem with your proposals (2) and (3) is that they violate the sanctity of the local-part. Your software that might try to recognize AAA!BBB!CCC%DDD@EEE as meaning the user CCC on Usenet host BBB would be making possibly incorrect assumptions about how EEE parses its local parts. On a suitably unusual computer "AAA!BBB!CCC%DDD" could be a local user name; there is no way for your site to know how what those special characters mean to EEE. If, perhaps, you know that EEE treats % in the local part as synonymous with @, then you have the next level of assumption, about how DDD parses ITS local-part, and then AAA. barmar  From: Christopher A Kent Message-Id: <8409202127.AA13887@merlin.ARPA> Received: by merlin.ARPA; Thu, 20 Sep 84 16:27:29 est Date: 20 Sep 1984 1627-EST (Thursday) To: William G. Martin Cc: wmartin@ALMSA-1.ARPA, header-people@MIT-MC.ARPA Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for? In-Reply-To: Your message of Tue 18 Sep 84 08:31:39-MDT. <8409181438.AA07422> From: William G. Martin Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for? The recent discussion of the EXPN and VRFY commands included a couple mentions of using EXPN to implement a command that would let a user discover who is on a remote mailing list. I had never heard of such a command before, but, now that I know it is possible, I want it! My implementation of the finger protocol for Unix has this feature; if you finger a mailing list on a remote site, the server will expand it and finger all the individual members (recursively following lists, of course). As a separate issure, I'd like to see this kind of behaviour more formally described with a new finger protocol spec (there are a number of problems with the current one). Anyone interested in collaborating? chris ----------  Date: 18-Oct-84 19:33:35-UT From: little@dcn5 Subject: Virtual Terminal Protocol To: header-people@mit-mc.arpa, msggroup@brl, tcp-ip@sri-nic.arpa I am attempting to create a virtual terminal protocol (VTP) with emphasis on solving problems created by forms mode type terminals (eg-3270). I currently view the problem with the following breakdown - Graphical (Character) Representation code for information exchange (agreement) Control Domain and Exercising modal operation transfer requests function keys out-of-band signals Display cursor addressing end-of-line/screen condition presentation attributes Does anyone have any interesting thoughts or know of problems they are having in this area?? (or are header/TCPIP/msg people the right people for this sort of thing?) Specifically - what problems do you have with TELNET?? Are there deficiencies you would like to overcome with TELNET or RFC 731? Also, does anyone have access to the new VTP spec put out recently by the Terminal Repertoire Committee of ANSI (chaired by Henry Lowe -DEC)? Mike Little - LINKABIT@DCN5 -------  Date: Thu, 18 Oct 84 20:10:05 EDT From: Ron Natalie To: little@DCN5.ARPA cc: header-people@MIT-MC.ARPA, msggroup@BRL.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Virtual Terminal Protocol Actually, the WISCNET software that allows you to use TCP/IP to IBM-370 series machines running VM/CMS does this. They have an option negotiation that says "do 3270 style stuff" and from then on send 3270 control messages. I have been meaning to try to simulate the user end on UNIX with a termcap driven user telnet, but haven't gotten around to it. -Ron  Date: 19 Oct 1984 01:11-PDT Sender: ESTEFFERUD@USC-ECL Subject: Re: Virtual Terminal Protocol From: ESTEFFERUD@USC-ECL To: little@DCN5 Cc: header-people@MIT-MC, msggroup@BRL, tcp-ip@SRI-NIC Message-ID: <[USC-ECL]19-Oct-84 01:11:57.ESTEFFERUD> In-Reply-To: The message of 18-Oct-84 19:33:35-UT from little@dcn5.ARPA Msggroup and header-people are both the wrong lists for this topic. Please, everyone (and especially those of you who we all know know better), refrain from dumbly copying these two lists on replies, just because the originator did not know better. I can understand innocent new netmail users making such an error, but I cannot understand why knowlegeable people blindly continue? Thanks for your forebearance, and your consideration. Stef  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA07932; Tue, 23 Oct 84 21:20:24 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.17/4.26) id AA19997; Tue, 23 Oct 84 21:28:08 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.26) id AA03712; Tue, 23 Oct 84 21:28:04 pdt Date: Tue, 23 Oct 84 21:28:04 pdt From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8410240428.AA03712@ucbopal.CC.Berkeley.ARPA> To: Header-People@mit-mc.ARPA Subject: UUCP/Internet - Handing Local Domain Addresses Forwarded from USENET "net.mail" news group: ----------- From gnu@sun.uucp Wed Oct 17 00:00:13 1984 Newsgroups: net.mail Subject: uucp!user%localnet, etc, with a Free Surprise Present! Article-ID: net.mail/529 sdcsvax!brian suggests: > when I send mail from one of our campus machines ('wizard', for > example), the address will appear as follows: > sdcsvax!brian%wizard > since 'sdcsvax' is our portal to the world. A better choice is to output your local addresses as sdcsvax!wizard!brian since there is a firmly defined parsing order for that, while there is no firmly defined precedence between ! and %. > UCSD is our local domain. (We have a ucsd net registered with the NIC). > > When we get full sub-subdomains installed (there are about 50 machines > on campus that can send/receive mail), split along administrative or > departmental lines, each sub-subdomain(ssd) will have a name, and a mail > server that can route mail within that ssd. So, for example, the > machines in the computer center will generate addresses of the sort > brian%sdcc9.cc.ucsd > as a return address. Mail entering our portal at sdcsvax can be > addressed using this address, eg > sdcsvax!brian%sdcc9.cc.ucsd I would think that for internal use you'd have brian@sdcc9.cc.ucsd . When accepting mail from outside to get to such a place, it looks like the uucp mail project has settled on this syntax: sdcsvax!sdcc9.cc.ucsd!brian because we know of no Unix mailers that will munge an address like this unless the dotted "hostname" is the first hostname in the list. Also note that this is the same convention used for "brian@wizard" above. > If/when we get on the Internet, the above composite address > (user%machine or user%ssd) will simply be the mailbox part of a > standard RFC822 address, such as brian%wizard.cglab@UCSD, or more > simply, brian%cglab@UCSD. The standard Internet address should have the subdomains and hosts on the RIGHT side of the @ -- that's what it's there for, to separate the username from the host&domain. Thus you'd be: brian@wizard.cglab.ucsd or brian@cglab.ucsd There's an outstanding question in my mind whether "ucsd" should be a top level domain (Sun has a network registered at the NIC too, but that doesn't make us one of a few dozen names that every site in the world should know how to route to). There should be no problem tucking it under the uucp, csnet, or arpa domains though. Or whatever strange world domain naming scheme the ISI folks have dreamed up this season. ------------------ The Free Surprise! What follows below is excerpts from our local sendmail.cf file which implement rewriting of local addresses into uucp-like addresses as described above. As an added feature, the stuff at the bottom (rule 8) hacks mail relayed from our Arpanet relay (ucbvax) to make the relay transparent (i.e. to make the return address "foo@bar.arpa" rather than "ucbvax!foo@bar.arpa"). You'll have to merge these into your sendmail.cf file. The best way I've found is to print both on fanfold paper and spread them out on a table. Diffs don't usually work very well because of the cryptic and very context-sensitive nature of the file. One more thing. I've used rewriting rule numbers greater than 30 for convenience (mine, not yours). The standard sendmail only allows 30 rules. You'll have to either recompile your sendmail with this silly limit raised, or change rules 30, 38, etc. to have smaller (otherwise unused) numbers. Search for all the "30"s in the file and fix them all, don't just change the number in the "S" line and expect it to work. If you don't do either, your sendmail will point out the rewriting rule numbers it can't deal with, when you first test the merged config file. I'll answer questions, but remember -- NO WARRANTEES! ############################################################ ### local info ############################################################ # my official hostname # You have two choices here. If you want the gateway machine to identify # itself as the DOMAIN, use this line: Dj$D.$U # If you want the gateway machine to appear to be INSIDE the domain, use: #Dj$w.$D.$U # major relay mailer DMuucp # major relay host DR ucbvax CR ucbvax # local domain names DDsun CDsun # domain-spec for local domain within universe (eg, what domains are above?) DUuucp # known SMTP/ethernet hosts (this domain only) FS/etc/hosts.equiv FS/usr/lib/mailhosts # my name DnMAILER-DAEMON ################################# # Final Output Post-rewriting # ################################# S4 R$+<@$+.uucp> $2!$1 u@h.uucp => h!u R$+ $: $>9 $1 Clean up addr R$*<$+>$* $1$2$3 defocus ################################################ # Clean up an address for passing to a mailer # # (but leave it focused) # ################################################ S9 # externalize internal forms which don't meet external specs R@ $@$n handle <> error addr R$*<$*LOCAL>$* $1<$2$D.$U>$3 change local info R<@$+>$*:$+:$+ <@$1>$2,$3:$4 canonical ########################### # Name Canonicalization # ########################### # Internal format of addresses within the rewriting rules is: # anything<@host.domain.domain...>anything # We try to get every kind of address into this format, except for local # addresses, which have no host part. The reason for the "<>" stuff is # that the relevant host name could be on the front of the address (for # source routing), or on the back (normal form). We enclose the one that # we want to route on in the <>'s to make it easy to find. # S3 # handle "from:<>" special case R<> $@@ turn into magic token # basic textual canonicalization R$*<$+>$* $2 basic RFC821/822 parsing R$+ at $+ $1@$2 "at" -> "@" for RFC 822 # make sure <@a,@b,@c:user@d> syntax is easy to parse -- undone later R@$+,$+:$+ @$1:$2:$3 change all "," to ":" R@$+:$+ $@$>6<@$1>:$2 src route is canonical # more miscellaneous cleanup R$+ $:$>8$1 host dependent cleanup R$+:$*;@$+ $@$1:$2;@$3 list syntax R$+@$+ $:$1<@$2> focus on domain R$+<$+@$+> $1$2<@$3> move gaze right R$+<@$+> $@$>6$1<@$2> already canonical # convert old-style addresses to domain-based addresses # All old-style addresses parse from left to right, without precedence. # Note that the left side of '%' is a username; it is matched with $+ so # that complex names like "john.gilmore%l5" will be caught and translated. # The rest can only have an atom as the host name (left of the symbol). R$-:$+ $@$>3$2@$1 host:user R$-^$+ $1!$2 convert ^ to ! R$-!$+ $@$>6$2<@$1.uucp> uucphost!user R$-=$+ $@$>6$2<@$1.bitnet> bitnethost=user R$-.$+!$+ $@$>6$3<@$1.$2> host.domain!user R$+%$+ $@$>3$1@$2 user%host ####################### # Rewriting rules # ####################### ##### special local conversions S6 R$*<@$*$=D>$* $1<@$2LOCAL>$4 convert local domain R$*<@$*$=D.$U>$* $1<@$2LOCAL>$4 or full domain name ############################################################ ############################################################ ##### ##### UUCP Mailer specification ##### ##### @(#)uucpm.m4 1.3 84/03/23 SMI; from UCB 3.6 3/26/83 ##### ############################################################ ############################################################ ############################################################ ############################################################ ##### ##### Provide Backward Compatibility ##### ##### @(#)compat.m4 1.3 84/03/23 SMI; from UCB 3.3 2/24/83 ##### ############################################################ ############################################################ ########################################################## # General code to convert back to old style UUCP names # ########################################################## S5 R$+<@LOCAL> $@ $D!$1 name@LOCAL => sun!name R$+<@$-.LOCAL> $@ $2!$1 u@h.LOCAL => h!u R$+<@$+.uucp> $@ $2!$1 u@h.uucp => h!u R$+<@$=S> $@ $2!$1 u@etherh => etherh!u R$+<@$+> $@ $1%$2 u@any => u%any # Route-addrs do not work here. Punt til uucp-mail comes up with something. R<@$+>$* $@ @$1$2 just defocus and punt R$*<$*>$* $@ $1$2$3 Defocus strange stuff Muucp, P=/usr/bin/uux, F=sDFMhuU, S=13, R=23, A=uux - -r $h!rmail ($u) # Convert uucp sender (From) field S13 R$+ $:$>5$1 convert to old style R$=w!$+ $2 strip local name R$+ $:$w!$1 stick on real host name # Convert uucp recipient (To, Cc) fields S23 R$+ $:$>5$1 convert to old style ############################################################ ############################################################ ##### ##### RULESET ZERO ##### ##### domain.cf has a totally custom Ruleset Zero. ##### ############################################################ ############################################################ # Ruleset 30 just calls rulesets 3 then 0. S30 R$* $: $>3 $1 First canonicalize R$* $@ $>0 $1 Then rerun ruleset 0 S0 # On entry, the address has been canonicalized and focused by ruleset 3. # Handle special cases..... R@ $#local $:$n handle <> form # For numeric spec, you can't pass spec on to receiver, since rcvr's # are not smart enough to know that [x.y.z.a] is their own name. R<@[$+]>:$* $:$>9 <@[$1]>:$2 Clean it up, then... R<@[$+]>:$* $#ether $@[$1] $:$2 numeric internet spec R<@[$+]>,$* $#ether $@[$1] $:$2 numeric internet spec R$*<@[$+]> $#ether $@[$2] $:$1 numeric internet spec # resolve the local hostname to "LOCAL". R$*<$*$=w.LOCAL>$* $1<$2LOCAL>$4 thishost.LOCAL R$*<$*$=w.uucp>$* $1<$2LOCAL>$4 thishost.uucp R$*<$*$=w>$* $1<$2LOCAL>$4 thishost # Mail addressed explicitly to the domain gateway (us) R$*<@LOCAL> $@$>30$1 strip our name, retry R<@LOCAL>:$+ $@$>30$1 retry after route strip # deliver to known ethernet hosts explicitly specified in our domain R$*<@$*$=S.LOCAL>$* $#ether $@$3 $:$1@$2$3.$D.$U$4 user@etherhost.sun.uucp # etherhost.uucp is treated as etherhost.$D.$U for now. # This allows them to be addressed from uucpnet as foo!sun!etherhost!user. R$*<@$*$=S.uucp>$* $#ether $@$3 $:$1@$2$3.$D.$U$4 user@etherhost.uucp # Explicitly specified names in our domain -- that we've never heard of R$*<@$*.LOCAL>$* $#error $:Never heard of host $2 in domain $D.$U # Clean up addresses for external use -- kills LOCAL, route-addr ,=>: and etc. R$* $:$>9 $1 Then continue... # resolve UUCP domain R<@$-.uucp>:$+ $#uucp $@$1 $:$2 @host.uucp:... R$+<@$-.uucp> $#uucp $@$2 $:$1 user@host.uucp # Pass Arpanet and Bitnet names up the ladder to our forwarder R$*<@$*$-.arpa>$* $#$M $@$R $:$1@$2$3.arpa$4 user@anything.arpa R$*<@$*$-.bitnet>$* $#$M $@$R $:$1@$2$3.bitnet$4 user@anything.bitnet # All addresses in the rules ABOVE are absolute (fully qualified domains). # (Note that all patterns end in a word, not a multi-matcher). # Addresses BELOW can be partially qualified. # deliver to known ethernet hosts R$*<@$*$=S>$* $#ether $@$3 $:$1@$2$3$4 user@etherhost # other non-local names have nowhere to go; return them to sender. R$*<@$+.$->$* $#error $:Unknown domain $3 R$*<@$+>$* $#error $:Never heard of $2; maybe you mean $2.arpa ? R$*@$* $#error $:I don't understand $1@$2 # Local names with % are really not local! R$+%$+ $@$>30$1@$2 turn % => @, retry # everything else is a local name R$+ $#local $:$1 local names # # Host-dependent address cleanup: strip Berkeley! relay off Arpanet mail # S8 # # Handle from addresses that arrive over uucp from our Arpanet relay # site. They are passed to us in the -f argument from rmail, when uucp # hands us the message. Since many Arpa hosts are not qualifying their # domains yet, we have to tack on ".arpa" if no domain is specified. # # If there's no atsign in the name, just let it on thru -- it's being # relayed from a uucp site. # # THIS IS A KLUDGE OF THE EMERGENCY BROADCAST SYSTEM. THIS IS ONLY A KLUDGE. # It will have to stay around until our relay site passes us real # domain-based addresses, at which point all we have to do is strip off # the uucp garbage on the front. # R$=R!$* $@ $>38 $2 Run thru 38 if came from relay! # Otherwise, the address is OK as it stands. # This address is from our Arpa relay site. Fix it for slow Arpanauts. S38 R$* $: $>3 $1 Canonicalize, focus rest of it R$*<@$-.uucp> $@ $2!$1@$R.uucp If uucp addr, leave relay on. R$*<@$*LOCAL>$* $@ @$R.uucp:$1@$2$D.$U$3 If LOCAL, deloc&relay R$*<@$+.$*>$* $@ $1@$2.$3$4 If domain known, defocus&return R$*<@$+>$* $@ $1@$2.arpa$3 If not, "arpa", defocus&return R$*<$*>$* $@ $R!$1$2$3 Restore unknown strangenesses R$* $@ $R!$1 Restore unknown strangenesses # Kludge to deal with non-UGLYUUCP mail from our relay site. # Adds host "somewhere" to the class containing our relay site. It will # be translated to the real name, or removed, by the S8 code. CRsomewhere  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA08063; Tue, 23 Oct 84 21:26:36 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.17/4.26) id AA20225; Tue, 23 Oct 84 21:34:21 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.26) id AA03783; Tue, 23 Oct 84 21:34:18 pdt Date: Tue, 23 Oct 84 21:34:18 pdt From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8410240434.AA03783@ucbopal.CC.Berkeley.ARPA> To: Header-People@mit-mc.ARPA Subject: UUCP mail addresses Forwarded from USENET "net.mail" news group: ------ From hokey@plus5.UUCP Tue Oct 16 20:47:42 1984 Newsgroups: net.mail Subject: Re: parsing host1!user@host2 - a new idea Article-ID: net.mail/533 I was hoping I could stay out of this. Where do you want to use these headers? In the transport address (the stuff sent to rmail)? what about the addresses used in the From: and To: lines? The uucp-mail project has addresses these issues in gory detail. I will tell you the decisions that have been reached. I hope I don't get a lot of mail on this issue because I need to get the new mail software out in a hurry. I believe the issues should be aired ASAP. Many of the others on the project would rather wait until the software is ready before mouths are opened. I am not always wasy to work with. Many are concerned that rehashing these issues will unnecessarily delay the project. I hope I am not the only one from the project addressing these issues, because I have code to write. First, all addresses sent *from* the new software across uucp will be in strictly bang format. Mail to user@dom.ain will be converted to dom.ain!user. This works for almost all of the cases (the exception being explicitly routed RFC822 addresses across gateways, near as I can tell). Mail sent *to* the new software will accept non-hybrid addresses only, because of the parsing ambiguity. This means mail to a!b@c.d will be rejected by the new rmail. This is necessary because the mail must go through, and If, Someday, we all end up with RFC mailers, the parsing of addresses will change and then we are all in trouble again. Sendmail sites should leave the From: and To: lines *alone*. There is a difference between an address and a route. Non-RFC mailers won't look at these lines for replies, and they certainly won't update them when the mail passes through their site! These addresses should be in RFC822 format *if you are using an RFC mailer*. If a non-RFC mail message passes through an RFC mailer, it *might* add a From: line and an Apparently-to: line. The >addresses< on these lines should probably take the form "a!b!c"@thissite and thissite should be qualified (site.UUCP) if the site is registered with the Uucp Site Registry (lauren@vortex.UUCP). This implies that the mailers invoked by sendmail should be able to handle routing to non-neighbors, by using things like pathalias. Note that routing information is added, the addresses are not changed. Rob Warnock wrote a very clear discussion on the issue of route optimization which clearly states the conditions under which paths may be rerouted. Sites like ihnp4 optimize paths because many people do not have access to RFC mailers or routing software, so when people reply to news articles the mail goes along a path which is usually absurd. My solution to the problem of Path: replies to mail is for (at least) the first "smart" registered site in the path to use its fully-qualified name. This means it is safe for any other "smart" mailer to optimize directly to the last fully-rooted machine on the path. This may be enough to prevent the "optimization" of explicitly specified paths. Chuqui can still send out his looping paths to check path validity and the speed with which the message travels, without worrying that the path will be "fixed" for him. This also means that these smartmailers will handle mail to other domains as well as recognizing subdomains. Just think, no more problems with the duplicate named machines gang, vortex{.DEC,.UUCP}, rigel{.sun.UUCP, .oddjob.UUCP}, regina{.DEC,.UUCP}, and a host (no pun...) of others! Leaves you kind of breathless, huh? This also means that you could send mail to, say, ucbvax!site.CSNET!user and not have to worry about the hilarious contortions with csnet-relay. Specifically, you would only have to address the mail to *any* convenient smarthost!do.ma.in!user and it will get there (assuming the addressee exists!). I have left out a lot of points in my discussion. These ideas have been gone over quite thoroughly by many people, and I have done a mediocre job of covering the issue. Many of the problems must be solved in specific places. The use of parentheses in an address will mess up most sendmail sites in the universe. We can leave most of the routing software alone if we have user-interface mailers which do the job they are supposed to do, specifically, produce an *appropriately* formatted mail message with the help of the user. This stuff must be easy to use, and should not get in our way. We are getting there. -- Hokey ..ihnp4!plus5!hokey 314-725-9492  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA07823; Tue, 23 Oct 84 21:15:01 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.17/4.26) id AA19925; Tue, 23 Oct 84 21:22:48 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.26) id AA03686; Tue, 23 Oct 84 21:22:49 pdt Date: Tue, 23 Oct 84 21:22:49 pdt From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8410240422.AA03686@ucbopal.CC.Berkeley.ARPA> To: Header-People@mit-mc.ARPA Subject: mail address parsing Forwarded from Usenet "net.mail" news group: --------- From gnu@sun.uucp Tue Oct 16 23:14:12 1984 Newsgroups: net.mail Subject: Re: parsing host1!user@host2 -- the real fix Article-ID: net.mail/528 Several people have recently suggested that ( and ) be used in addresses to define precedence. While this would be a great idea if it had been standardized, instead most of the left- and right- matching characters have been standardized in the Arpanet formats to mean various other things: address (comments) comments
We could perhaps use [ ] or { } to accomplish this, but this will not work unless every host we go through uses the same conventions. The only precedence conventions defined in the Arpanet RFC's do it by quoting; if you want to nest quoted things you have to double all the internal quotes. Needless to say this makes for very messy looking addresses which are easy to type wrong. This is one of the failings of the Arpanet RFC's and one I hope they'll address in the future. Most people have come around to agreeing that if we all standardized on one naming convention, rather than mixing two or more conventions using ! @ : ^ . % etc, we could all talk to each other. Furthermore, that the Arpanet domain naming convention is reasonable enough to use. The rest of the question as far as UUCP mail is concerned revolves around two implementation questions: * How do we take an address like mark@cbosgd.att.uucp and deliver the mail to the right place (routing) * How do we implement the above without breaking all the existing uucp sites? (eg, avoid routing mail which should not get rerouted; avoid generating return addresses old sites can't handle) There's a task force (cbosgd!uucp-mail) working on these issues now and software is being readied for eventual release in net.sources. Stay tuned.  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA07788; Tue, 23 Oct 84 21:12:14 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.17/4.26) id AA19889; Tue, 23 Oct 84 21:19:55 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.26) id AA03666; Tue, 23 Oct 84 21:19:52 pdt Date: Tue, 23 Oct 84 21:19:52 pdt From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8410240419.AA03666@ucbopal.CC.Berkeley.ARPA> To: Header-People@mit-mc.ARPA Subject: mail address parsing Forwarded from USENET news group "net.mail". (Note "From" line is not a full UUCP mail address, so don't try to reply to ...@nsc.uucp unless you have a UUCP path expansion server.) ------------ From chongo@nsc.UUCP Tue Oct 16 02:11:14 1984 Newsgroups: net.mail Subject: Re: parsing host1!user@host2 - a new idea Article-ID: net.mail/526 Chuqui has some good points in his article. To remove confusion, why not allow '('s? You could say: (host1!user)@host2 -or- host1!(user@host2) The '(' is your friend. (and so is ')') Always keep in the message, where the message has gone. If a message hits a dead/wrong end, DONT opt. the path of the return message. On another point, I think each site should not just blindly adjust the path of a message. Here are some reasons why: 1) I don't want site foo to receive my letter because the uucp manager just learned how to monitor letters and kills messages which he/she does not like. (this actually happened in a local S.F. site) The normal path might be: a!bletch!foo!bar!mojo but I want: a!bletch!curds!and!whey!bar!mojo. 2) There are too sites named foo. I send a letter to: a!bletch!c!d!e!foo!mojo but bletch changes the path to: a!bletch!foo!mojo where e!foo is not the same site as bletch!foo. I can see a site adjusting a domain directed message path if it is a gateway, or sending it on to a gateway site if it is not. The cases where you want a forced path are few. Most of the time, mailer path opt. does help. But there ARE reasons who you might want to force a given path. I have a suggestion and another use for the '(' in a path. Let the '(' guide you on which paths NOT to touch. For example: a!b!c!(x!y!z)!d!e!foo!mojo where (x!y!z) is a path expression. We will talk about this path below, so keep it in mind. Here is some ideas on how to treat this path expression: - Deal with the path c!(expression)!d as a glued in path and NOT subject to change. That is, c MUST receive the message and pass it along to the leftmost site inside the expression. The rightmost site MUST send the message to site d. In other words, c!x and z!d are 'glued' in. - Disallow a site to change the path to the right of any expression. That is, site b can not change the d!e!foo!mojo path because it is to the right of the path expression. - Allow any site within an expression to ONLY change the path inside that expression. That is, x can send it along to z and bypass site y if it wants to, but dont allow x to send it to d or e. - Pull the left '('s along until you reach a right ')'. The life of the path could go like: a!b!c!(x!y!z)!d!e!foo!mojo - as sent by the user b!c!(x!y!z)!d!e!foo!mojo - the users site talks directly to the site b, so a is bypassed. The users site also talks to e, but sending directly to e would bypass the expression. c!(x!y!z)!d!e!foo!mojo - b sent it to c. (x!y!z)!d!e!foo!mojo - c is FORCED to send it to x. (y!z)!d!e!foo!mojo - x sends it to y. (z)!d!e!foo!mojo - y sends it to z. d!e!foo!mojo - z is FORCED to send it to d. The '('s meet and they go away. foo!mojo - d can send directly to foo, and does. here mojo gets the message. Some additional notes, expressions can be nested. Such as: a!(b!c!(x!y!z))!d!e!(foo)!g!mojo a MUST send to b; c MUST send to x; z MUST send to d; e MUST send to foo; foo MUST send to g. chongo /\(--)/\ -- ~ Imagine UN*X source, being in the public domain... ~ J. Alton 84'  Date: Thu, 25 Oct 84 7:57:02 EDT From: Ron Natalie To: header-people@mit-mc.ARPA cc: gurus@BRL-TGR.ARPA Subject: Domain Specification  Date: Thu, 25 Oct 84 11:20:25 EDT From: Ron Natalie To: header-people@mit-mc.ARPA cc: gurus@BRL-TGR.ARPA Subject: Domain Specification Well, I was trying to mail to princeton!down!north@seismo.ARPA But what he received was Date: Wed, 24 Oct 84 10:11:51 EDT From: Ron Natalie To: princeton!down!north@seismo.domain Subject: Re: windham hill Obviously some aspect of "domain" specification that I overlooked while reading the RFC. -Ron  Date: 31 October 1984 21:06-EST From: Ken Harrenstien Subject: Interesting bug To: HEADER-PEOPLE @ MIT-MC There are really two bugs here, but it's the sendmail one that seems to need publicizing so all the sites using it can fix their programs. --Ken Received: by rand-unix.ARPA; Mon, 29 Oct 84 11:14:15 pst From: Terry West Message-Id: <8410291914.AA15962@rand-unix.ARPA> Date: 29 Oct 84 11:14:11 PST (Mon) To: postmaster@mit-mc Cc: guyton@rand-unix, terry@rand-unix Subject: Mail Problem Hi, Last night we had a problem with a msg from your site that caused our SMTP server (sendmail) to loop. The problem appears to be a bogus MAIL FROM line "@MIT-MC>". This morning I changed the config file to prevent the loop, and successfully received the problem msg. If this msg is being sent to any other sites running sendmail, I'd suspect they're also having problems. Here's an extract from our log file. P347 T467924367 DdfAA15710 S@MIT-MC> Rwescourt@isi H?P?return-path: Hreceived: from mit-mc.arpa by rand-unix.ARPA; Mon, 29 Oct 84 10:59:27 pst H?x?full-name: H?M?message-id: <8410291859.AA15710@rand-unix.ARPA> Hdate: 28 October 1984 04:12-EDT HFrom: Eliot Moore HSender: ELMO @ MIT-MC Hsubject: Special K's HTo: HEATH-PEOPLE @ MIT-MC Hreply-to: Elmo@USC-ISIB Thanks, Terry West