Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 6 Oct 88 02:23:51 EDT Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 5 Oct 88 02:23:56-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 5 Oct 88 02:18:04 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 5 Oct 88 04:16:00 GMT From: amdcad!rpw3@bloom-beacon.mit.edu (Rob Warnock) Organization: [Consultant] San Mateo, CA Subject: Re: Documentation on Internet/UUCP/??? possible types of mail addresses? Message-Id: <23128@amdcad.AMD.COM> References: <194@chip.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <194@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: +--------------- | Unfortunately, from what I can determine RFC822 does not address the mixed | UUCP/DECNET/Internet/?? formats that can exist that we all commonly use now. +--------------- See RFC976, "UUCP Mail Interchange Format Standard". It includes recommendations about what to do when you see mixed-mode addresses. Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 OCT 88 03:51:30 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Sat, 8 Oct 88 03:50:10 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 8 Oct 88 03:26:34 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 6 Oct 88 07:00:45 GMT From: mcvax!hp4nl!philapd!ssp15!jos@uunet.uu.net (Jos Vos) Organization: Philips Telecommunication and Data Systems, The Netherlands Subject: Contents of RFC822 field "Encrypted" Message-Id: <578@ssp15.idca.tds.philips.nl> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Does anyone know the (registered) official contents of the Encrypted field in a RFC822 mail header? -- -- ###### Jos Vos ###### Internet jos@idca.tds.philips.nl ###### -- ###### ###### UUCP ...!mcvax!philapd!jos ######  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Oct 88 12:54:44 EDT Received: from relay2.cs.net by RELAY.CS.NET id ad00695; 12 Oct 88 12:17 EDT Received: from sdr.slb.com by RELAY.CS.NET id af12597; 12 Oct 88 11:18 EDT Date: Wed, 12 Oct 88 10:23 EDT From: "PSI%PRSRTR::PRSRTR::MRGATE::\"MRGATE::PSI%SINET.000000360400::RILEY\"%sdr.slb.com"@RELAY.CS.NET Subject: RFC #822 Received: id field To: header-people@MC.LCS.MIT.EDU X-VMS-To: MRGATE::M_SDR::IN%"header-people@mc.lcs.mit.edu" It has been suggested that I send the following to HEADER-PEOPLE@MC.LCS.EDU so ... ----------------------- Would anyone out there like to explain the following problem/conflict with RFC #822 (the "Standard for ARPA Internet Text Messages" used in many mail systems) :- Problem: The received message "id" in a "Received:" field is not in the specified format for all mail I have seen (and a friend confirms this also). The definition for the "Received:" field is the following ... received = "Received" ":" ["from" domain] ["by" domain] ["via" atom] *("with" atom) ["id" msg-id] ["for" addr-spec] ";" date-time The definition for "msg-id" is the following ... msg-id = "<" addr-spec ">" Now observe an example "Received:" field ... Received: from relay.cs.net by RELAY.CS.NET id eu17161; 20 Sep 88 1:37 EDT For a start, the id is not surrounded by angle brackets ("<" and ">"). Secondly, "addr-spec" is defined to be ... addr-spec = local-part "@" domain ... there is definitely not an "@" sign either??????? One might think that the definition of "msg-id" is incorrect; however, for the "Message-ID:" field whose definition is ... "Message-ID" ":" msg-id ... I have seen the following ... Message-Id: <8809201329.AA26050@ncsuvx.ncsu.edu> ... which is in the correct format! What should the definition for the "id" section of an "Received:" field be? Are there a lot of gateways out there that have got it wrong? (My source for the RFC #822 definition is "Standard For The Format Of ARPA Internet Text Messages", dated August 13, 1982, revised by David H. Crocker). Thanks Mark Riley GECO (Geophysical Company Of Norway A/S) Internet: riley@gest01.sdr.slb.com SINet: m_gest01::riley Tel: +47 4 506437  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 14 Oct 88 03:02:19 EDT Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 13 Oct 88 14:27:23-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 13 Oct 88 03:24:56 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Oct 88 21:28:17 GMT From: att!alberta!ubc-cs!attvcr!tri-x!tjs@bloom-beacon.mit.edu (Tim Snider) Organization: TRI-X Technologies Inc., Vancouver, B.C., Canada Subject: pathalias Message-Id: <510@tri-x.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu #Take that you line-eater you! Could someone in the local area please mail me a copy of pathalias. I'd prefer if you could contact me first but I've gotten no previous replies so I could probably manage to wade through a few copies if you send it. The latest version I have is from 1985, I understand that the latest is past 1986. Please help me tidy up my mail system. Please Reply to: UUCP: tri-x!tjs (Tim Snider) Voice: (604)273-1077 (please avoid routing thru van-bc) Snail Mail: #200-10711 Cambie Rd.,Richmond, B.C., Canada, V6X 3G5 c/o TRI-X Technologies Inc.  Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 14 Oct 88 03:53:15 EDT Received: from BRAHMA.ACA.MCC.COM (BRAHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Fri 14 Oct 88 00:23:12-CDT Date: Fri, 14 Oct 88 00:23 CDT From: David Vinayak Wallace Subject: How come bitnet hosts always seem to reply to the return-path? To: header-people@mc.lcs.mit.edu Supersedes: <881014002247.5.GUMBY@BRAHMA.ACA.MCC.COM> Message-ID: <881014002310.6.GUMBY@BRAHMA.ACA.MCC.COM> Whenever I receive a reply from someone on bitnet, it always appears to have been sent to the return-path of the message, rather than the From address. What gives? Are you bitnet folks on this list ever going to fix this?  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 OCT 88 06:28:50 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Wed, 12 Oct 88 15:05:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 12 Oct 88 14:53:04 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Oct 88 16:47:08 GMT From: joyce!aai7!brunner@ames.arpa (Eric Brunner) Organization: SRI International, Menlo Park CA Subject: Re: Documentation on Internet/UUCP/??? possible types of mail addresses? Message-Id: <14172@joyce.istc.sri.com> References: <194@chip.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <194@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >Greetings... >SOOOO...I guess what I am asking is for a pointer to a definitive document >that addresses all sorts of address formats. You may want to read the article that appeared in the October 1986 issue of the CACM entitled "Notable Networks" by John Quarterman, the format of addresses for most of the known world (then, and now) are described. You may also want to look at the rules files in the sendmail sources for translation rules. Thomas Eric Brunner Manager, SRI IST Division Computer Facility, EJ309, x3130  Received: from MTUS5 (TCP 4345005001) by MC.LCS.MIT.EDU 16 Oct 88 22:43:17 EDT Received: from MTUS5 by MTUS5 ; Fri, 14 Oct 88 09:16:44 EST Date: Fri, 14 Oct 88 09:16:41 EST From: "Jeffery K. Bacon III" To: header-people@mc.lcs.mit.edu A newer (It should be the newest copy, right?) copy of pathalias, along with smail 3.some are available by anonymous ftp from simtel20.arpa, if you can do ftp.  Received: from MTUS5 (TCP 4345005001) by MC.LCS.MIT.EDU 16 Oct 88 22:43:26 EDT Received: from MTUS5 by MTUS5 ; Fri, 14 Oct 88 09:19:58 EST Date: Fri, 14 Oct 88 09:19:57 EST From: "Jeffery K. Bacon III" To: header-people@mc.lcs.mit.edu Subject: bitnet people Well...bitnet is not full of what one might call intelligent router systems. Often, as is the case here, we get to supply a full path ourselves. Needless to say, the less-informed often choose the easiest choice, the return-path, not knowing whether it will work or not. Forgive us our sins, master, and may TCP/IP be with us all soon. :-)  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 17 Oct 88 20:22:05 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8102; Fri, 14 Oct 88 21:29:26 EDT Received: from CFAAMP.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8101; Fri, 14 Oct 88 21:29:16 EDT Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer X1.25) with BSMTP id 3767; Fri, 14 Oct 88 21:33:07 EDT Date: Fri, 1988 Oct 14 21:19 EDT From: (John F. Chandler) PEPMNT@CFAAMP.BITNET To: HEADER-PEOPLE@MC.LCS.MIT.EDU, (David Vinayak Wallace) Gumby@MCC.COM Subject: Re: How come bitnet hosts always seem to reply to the return-path? In-reply-to: Gumby@MCC.COM message of Fri, 14 Oct 88 00:23:00 CDT Message-id: > Whenever I receive a reply from someone on bitnet, it always appears to > have been sent to the return-path of the message, rather than the From > address. What gives? Are you bitnet folks on this list ever going to > fix this? First, BITNET is far from a homogeneous domain, and mail user agents have widely varying behavior. Second, the "Return-path" field is almost always suppressed from the header, along with the "Message-id" and the others not truly essential to delivery. This helps keep the transmission load down. Third, mail distributed on BITNET for HEADER-PEOPLE usually comes with a "Reply-to" field of the list because the (re)distribution was apparently set up that way when WISCVM started drowning in mail. If you want replies to come directly back to you, you can specify your own "Reply-to".  Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU 17 Oct 88 21:58:39 EDT Received: from garnet.berkeley.edu by violet.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17l) id AA10100; Mon, 17 Oct 88 18:19:50 PDT Received: by garnet.berkeley.edu (1.2/Ultrix2.0-CFC.13) id AA23339; Mon, 17 Oct 88 18:19:46 pdt Date: Mon, 17 Oct 88 18:19:46 pdt From: netinfo%garnet.Berkeley.EDU@violet.berkeley.edu (Postmaster & BITINFO) Message-Id: <8810180119.AA23339@garnet.berkeley.edu> To: BACON%MTUS5.bitnet@jade.Berkeley.EDU Subject: pathalias routing information Cc: header-people@mc.lcs.mit.edu In reply to: From <@mc.lcs.mit.edu:BACON@MTUS5> Sun Oct 16 20:28:31 1988 Date: Fri, 14 Oct 88 09:16:41 EST From: "Jeffery K. Bacon III" To: header-people@mc.lcs.mit.edu A newer (It should be the newest copy, right?) copy of pathalias, along with smail 3.some are available by anonymous ftp from simtel20.arpa, if you can do ftp. One problem with pathalias for Internet mail sites is that it uses the UUCP map data. The UUCP map data assumes that you are in the UUCP zone using UUCP addressing. If you do not have UUCP links, for example, you are only an internet host, then you have to identify the internet names for UUCP/internet hosts and override the UUCP map data. Ideally this should be done for all UUCP/internet hosts. However there are network usage restrictions. Multiple gateways may also require some fine tuning (adjustments) to the pathalias routing data. If you are only originating traffic going to UUCP it is possible to identify one local UUCP gateway to be used, and to generate pathalias data in an internet gateway format. For example: uucppath-address@gateway-domainname or uucpdomain!uucpdomain!user@gateway-domainname where gateway-domainname is an internet domain name. Hopefully, your internet/UUCP mail gateway is a local one so you do not run into network usage restrictions. You should obtain permission to use the internet/UUCP gateway before you send all your UUCP traffic there. (Please note: ucbvax is not the internet/UUCP gateway for the whole world. There are others now.) Conversion to an Internet gateway address format is done by reading in the following uucp map data last and generating the pathalias data for "localhost": ----- # The following line defines the local internet/UUCP gateway gateway-domainname = uucp-node-name # # The following line flips addresses into internat format # if the pathalias data is generated for "localhost". localhost @uucp-gateway-domainname(DEDICATED) ----- Bill Wells, Postmaster ------------------------------------------------------------------------ | William Wells Telephone: COML: +1 415-642-9801, ATSS: 582-9801 | | Data Communication & Network Services postmaster@jade.berkeley.edu | | University of California at Berkeley netinfo@garnet.berkeley.edu | ------------------------------------------------------------------------  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 17 Oct 88 20:22:05 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8102; Fri, 14 Oct 88 21:29:26 EDT Received: from CFAAMP.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8101; Fri, 14 Oct 88 21:29:16 EDT Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer X1.25) with BSMTP id 3767; Fri, 14 Oct 88 21:33:07 EDT Date: Fri, 1988 Oct 14 21:19 EDT From: (John F. Chandler) PEPMNT@CFAAMP.BITNET To: HEADER-PEOPLE@MC.LCS.MIT.EDU, (David Vinayak Wallace) Gumby@MCC.COM Subject: Re: How come bitnet hosts always seem to reply to the return-path? In-reply-to: Gumby@MCC.COM message of Fri, 14 Oct 88 00:23:00 CDT Message-id: > Whenever I receive a reply from someone on bitnet, it always appears to > have been sent to the return-path of the message, rather than the From > address. What gives? Are you bitnet folks on this list ever going to > fix this? First, BITNET is far from a homogeneous domain, and mail user agents have widely varying behavior. Second, the "Return-path" field is almost always suppressed from the header, along with the "Message-id" and the others not truly essential to delivery. This helps keep the transmission load down. Third, mail distributed on BITNET for HEADER-PEOPLE usually comes with a "Reply-to" field of the list because the (re)distribution was apparently set up that way when WISCVM started drowning in mail. If you want replies to come directly back to you, you can specify your own "Reply-to".  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 OCT 88 01:48:25 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Wed, 19 Oct 88 21:32:02 EDT Received: from Think.COM by news.think.com; Wed, 19 Oct 88 21:18:36 EDT Return-Path: Received: from ames.arc.nasa.gov by Think.COM; Wed, 19 Oct 88 21:16:26 EDT Received: Wed, 19 Oct 88 18:19:16 PDT by ames.arc.nasa.gov (5.59/1.2) Received: by amdahl.uts.amdahl.com (/\=-/\ Smail3.1.6.1 #6.3) id ; Mon, 17 Oct 88 19:40 PDT Message-Id: Date: Mon, 17 Oct 88 19:40 PDT From: tron@uts.amdahl.com (Ronald S. Karr) To: header-people@mc.lcs.mit.edu Subject: Re: Smail3 and pathalias on simtel20.arpa >A newer (It should be the newest copy, right?) copy of pathalias, along >with smail 3.some are available by anonymous ftp from simtel20.arpa, >if you can do ftp. Being one of the two authors of Smail3, I would like to warn people that Smail3.1 is in alpha release. We did ask in the distribution's README file to restrict distribution, though it is a bit late now. Well, if people want the Smail3 alpha patch updates, please send mail to info-smail-request@uts.amdahl.com. In particular, support for the BSD BIND server just went out in the most recent patch (patch #10). Could somebody please send mail detailing the patch level of the sources on Simtel20? Also, if you are interested in Smail3, please request to be on our mailing list. tron |-<=>-| ARPAnet: amdahl!tron@Sun.COM tron@uts.amdahl.com UUCPnet: {decwrl,sun,uunet}!amdahl!tron PS. The version of pathalias that is included in the Smail3 distribution is not an "official" release by Peter Honeyman.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Oct 88 23:18:56 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 21 Oct 88 23:11:52 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 21 Oct 88 15:35:38 GMT From: cwjcc!hal!nic.MR.NET!tank!ncar!noao!asuvax!nud!sunburn!dover!waters@ohio-state.arpa (Mike Waters) Organization: Motorola CAD Mesa, AZ {dover} Subject: Re: pathalias Message-Id: <474@dover.uucp> References: <510@tri-x.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <510@tri-x.UUCP> tjs@tri-x.UUCP (Tim Snider) writes: > >Could someone in the local area please mail me a copy of pathalias. We are trying to get Unix/Unix mail working here, and seem to have everything BUT mail routing working. I too could use a copy or a pointer to an archive which has a copy. I have looked around in SIMTEL20 without success, but that may well be my lack of experience. Thanks in advance for any assistance. -- Mike Waters (for your EDIFication) Motorola SMART CAD Group - EDIF support Mesa, AZ ...!sun!sunburn!dover!waters OR moto@cad.Berkley.EDU  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 24 Oct 88 23:40:06 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 24 Oct 88 23:36:07 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 24 Oct 88 16:23:43 GMT From: munnari!basser!john@uunet.uu.net (John Mackin) Organization: Dept. of Comp. Science, Uni of Sydney, Australia Subject: Is anyone using the RFC822 address grammar from comp.sources.misc? Message-Id: <1557@basser.oz> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'd like to get in contact with anyone who has done anything with the yacc parser for RFC822 addresses that was posted to comp.sources.misc by David Herron, , back in October of 1987 (article <4959@ncoast.UUCP>). I've been working on it for a while and have fixed several bugs and improved its conformance to RFC822 in some ways; I'd like to find out what others have done with it, and share the fixes. If I don't get any responses to this, I'll post a patch to comp.sources.bugs in a couple of months, after the new version of the mailer I've put it into has been in production for a while. (Please don't mail me asking me to send you a copy of the original article; unless, that is, you're in Australia. See Brandon's periodical postings for a list of comp.sources.misc archive sites.) John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia john@basser.oz.AU (john%basser.oz.AU@UUNET.UU.NET) {uunet,mcvax,ukc,nttlab}!munnari!basser.oz!john  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 04:40:40 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 25 Oct 88 04:28:20 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 24 Oct 88 20:22:26 GMT From: bpa!cbmvax!vu-vlsi!devon!shockeye!hermit@rutgers.edu (Mark Buda) Organization: Competitive Computer Systems, Lancaster PA Subject: Re: pathalias Message-Id: <228@shockeye.UUCP> References: <510@tri-x.UUCP>, <474@dover.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <474@dover.uucp> waters@dover.UUCP (Mike Waters) writes: >In article <510@tri-x.UUCP> tjs@tri-x.UUCP (Tim Snider) writes: >> >>Could someone in the local area please mail me a copy of pathalias. > >We are trying to get Unix/Unix mail working here, and seem to have >everything BUT mail routing working. I too could use a copy or >a pointer to an archive which has a copy. I have looked around in >SIMTEL20 without success, but that may well be my lack of experience. tut.cis.ohio-state.edu has pathalias available via anonymous FTP. osu-cis has pathalias available via anonymous UUCP. They may be the same machine. Pathalias is in pathalias/pathalias9.[12].Z You can look at the file GNU.how-to-get for more complete information. >Thanks in advance for any assistance. You're welcome. You also will probably already know this by the time this gets to you... life in the backwaters of USENET sucks. -- Mark Buda / Smart UUCP: hermit@shockeye.uucp / Phone(work):(717)299-5189 Dumb UUCP: ...rutgers!bpa!vu-vlsi!devon!shockeye!hermit Entropy will get you in the end. "A little suction does wonders." - Gary Collins  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 09:10:09 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 25 Oct 88 08:58:25 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 25 Oct 88 12:19:49 GMT From: phri!roy@nyu.edu (Roy Smith) Organization: Public Health Research Institute, NYC, NY Subject: To parse the unparseable dream Message-Id: <3566@phri.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu What would you do if you saw the following on a To: line? Roy Smith I'm not sure what it's supposed to mean, but it certainly doesn't mean me. Actually, the odd part is that somehow it does mean me because it got to me (although as part of a several-bounce error message). Where would you start if you wanted to try to parse this, or would you just say it's illegal and throw up your hands? -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 14:55:16 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 25 Oct 88 14:48:09 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 25 Oct 88 18:31:17 GMT From: cwjcc!pirate!chet@ohio-state.arpa (Chet Ramey) Organization: CWRU Andrew R. Jennings Computing Center Subject: Re: To parse the unparseable dream Message-Id: <210@cwjcc.CWRU.Edu> References: <3566@phri.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3566@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > What would you do if you saw the following on a To: line? >Roy Smith I would (and so would my sendmail.cf) send the whole mess to Xerox and let them deal with it. This is a strict interpretation of RFC-822. >Where would you start if you wanted to try to parse this, or would you just >say it's illegal and throw up your hands? If I wanted to parse it, I'd take whatever's between the brackets, throw out the comments, and work on what's left. (And what is a sendmail.cf, if not the embodiment of it's creator's ideas about mail routing and addressing? :-) So, if you feed it through ruleset 3, it'll come back as philabs.philips.com.weiser.pa<@xerox.com> so that seems OK so far (of course, it may not be what was intended). Then try to resolve xerox.com, since we don't touch the local part, and send it off to them (hell, for all I know, Grapevine might actually make that local part into something useful when it gets there). Chet Ramey Network Operations Group, CWRU chet@cwjcc.CWRU.EDU Chet Ramey chet@cwjcc.CWRU.EDU Network Management Group chet@alpha.CES.CWRU.EDU Andrew R. Jennings Computing Center chet@pirate.CWRU.EDU Case Western Reserve University  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 19:25:24 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 25 Oct 88 19:24:53 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 25 Oct 88 22:19:02 GMT From: encore!necis!adamm@bu-cs.bu.edu (Adam Moskowitz) Organization: NEC Information Systems, Boxborough, MA Subject: Incorrect address on outgoing mail Message-Id: <784@necis.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu We're having some problems with our outgoing mail and I'm hoping someone out there in net.land has already solved them so I don't have to. When I send mail, it's often addressed to several people, some of whom are on a different systemt that the one I'm sending from. It gets to them fine, but when they try to reply all is hosed because the addresses they receive are wrong. To be more specfic: I say "mailx user1@host1, user2@host2, user3" (it's implied that user3 and I are on the same system)(I also seem to get the same results using elm). But when user1 gets the mail, the address for user3 still says "user3" and I claim it *should* say "user3@host3". Otherwise, how is user1's mailer supposed to know where to send the reply? We're using smail 2.5, supposedly updated on 15-Sep-87, on a System V box. I believe the "stock" /bin/mail is now masquerading as /bin/lmail. So, please email any possible solutions to the address shown below. If I'm off my rocker or missing something, email that too. Thanx. -- Adam S. Moskowitz ...!(backbone)!{necntc,encore}!necis!adamm adamm@necis.nec.com "Gonna die with a smile if it kills me!" -- Jon Gailmore  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Oct 88 20:25:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 25 Oct 88 20:20:48 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 25 Oct 88 17:54:50 GMT From: werner@astro.as.utexas.edu (Werner Uhrig) Organization: U. Texas, Astronomy, Austin, TX Subject: I would like to see a header Sender-Addressed-To: Message-Id: <3296@utastro.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu incoming mail arrives on my machine with a To-address which no longer contains the information of how the sender had originally addressed me, as the intermediate sites often modify the To-address as the mail gets passed on from site to site. I wished all mail would arrive with a header: X-Sent-To: X-CCed-To: ..etc.. as this is often the only way I can understand and comment on addressing problem the sender might be having. Often the CC-addresses arrive here mangled, as some sites along the way modify them, but others don't, leaving me to try to hand-knit addresses before I can send a REPLY (to) ALL has this been discussed before? has anyone implemented such? (I might as well start configuring our sendmail.cf do that to encourage others to follow ...) -- --------------------> PREFERED-RETURN-ADDRESS-FOLLOWS <--------------------- (ARPA) werner@rascal.ics.utexas.edu (Internet: 128.83.144.1) (INTERNET) werner%rascal.ics.utexas.edu@cs.utexas.edu (UUCP) ..!utastro!werner or ..!uunet!rascal.ics.utexas.edu!werner  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 26 Oct 88 06:01:33 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 4783; Wed, 26 Oct 88 02:10:51 EDT Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4782; Wed, 26 Oct 88 02:10:17 EDT Date: Tue, 25 Oct 88 23:09 PDT To: werner@ASTRO.AS.UTEXAS.EDU(Werner Uhrig) CC: header-people@MC.LCS.MIT.EDU From: Leonard D Woren Subject: Re: I would like to see a header Sender-Addressed-To: Well, I think it's finally time to post something that I've had sitting around for many years. I don't know where this originated, but consider my posting this to be my comment on additional header lines that don't provide increased function to the end user. Also, maybe it'll provide some amusement for readers of this list... Leonard D. Woren LDW@USCMVSA.BITNET LDW@MVSA.USC.EDU = LDW%MVSA.USC.EDU@Oberon.USC.EDU University of Southern California Date: 7 Apr 1977 1712-EST From: Bob Chansler at CMU-10A Reply-To: Lord High Executier@CMU-10A Subject: Re: Close, but no cigar To: BRIAN.REID at CMU-10A CC: chansler@CMU-10A Sender: BOB.CHANSLER at CMU-10A Message-ID: (CMU-10A) 7 Apr 1977 17:12:49 Bob Chansler In-Reply-To: Your message of April 6, 1977 My-Seq-#: 39492094 Yr-Seq-#: 4992488 Class: A Subclass: MCMXLVII Author: fred Typist: fred Terminal: TTY88 FE-L#: 44 Reason: Did Godzilla need a reason? Valid: Not before 12 Apr 1977 1321Z Suspend: After 19 Apr 1977 0000Z Spelling-errors-this-message: 0 Spelling-errors-to-date: 23 Weather: Light rain, fog. Forcast: Clearing by morning Psych-evaluation-of-sender: slightly unstable Security-level: Public Security-sublevel: 0 Authority-to-send: general Authority-to-rcv: general #-people-in-terminal-room: 12 XGP: UP-cutter not working Ht/Wt-sender: 76/205 Machines: M&Ms available but almond machine is empty M&Ms-Last-Nickel: 17 Remailed-To: John.Zsarnay at CMU-10A Remailed-From: Peter.Schwarz at CMU-10A Remailed-Date: Saturday, 22 September 1979 0155-EDT Origin: C410PS20 at CMU-10A; 22 Sep 1979 0155-EDT Remailed-To: Mike.Accetta at CMUA Remailed-From: John.Zsarnay at CMU-10A (A650JZ04) Remailed-Date: 22 September 1979 1615-EDT Origin: A650JZ04 at CMU-10A; 22 Sep 1979 1616-EDT Remailed-To: Fil.Alleva at CMU-10A Remailed-From: Mike Accetta (A650MA33) Remailed-Date: Saturday, 22 September 1979 2004-EDT Via: CMU-10A; 22 Sep 1979 2006-EDT Remailed-To: Ken.Wertz at CMU-10B Remailed-From: Fil.Alleva at CMU-10B (A650FA33) Remailed-Date: Monday, 24 September 1979 1023-EDT Via: CMU-10B; 24 Sep 1979 1025-EDT Remailed-To: Don.Provan at CMU-10A Remailed-From: Krafty Ken Wertz Remailed-Date: Monday, 24 September 1979 1029-EDT Origin: C425KW0F at CMU-10A; 24 Sep 1979 1036-EDT Remailed-To: Carolyn.Councill at CMU-10A Remailed-From: don.provan at CMU-10A Remailed-Date: Monday, 24 September 1979 1054-EDT Origin: C425DP0N at CMU-10A; 24 Sep 1979 1055-EDT Remailed-To: Eddie.Caplan @ CMUA Remailed-From: Carolyn.Councill at CMU-10A (C425CC33) Remailed-Date: Monday, 24 September 1979 1631-EDT Origin: C425CC33 at CMU-10A; 24 Sep 1979 1632-EDT Remailed-To: lawrence.butcher at CMU-10A Remailed-From: eddie caplan Remailed-Date: 24 September 1979 1634-EDT Origin: C425EC0F at CMU-10A; 24 Sep 1979 1635-EDT Remailed-To: Mike Kazar at CMU-10A, Craig Everhart at CMU-10A Remailed-From: Lawrence Butcher at CMU-10A (X335LB50) Remailed-Date: Tuesday, 25 September 1979 1811-EDT Origin: X335LB50 at CMU-10A; 25 Sep 1979 1812-EDT Remailed-To: sipb @ mc Remailed-From: Mike Kazar (C410MK50) Remailed-Date: Wednesday, 26 September 1979 0009-EDT I do not understand your concern about the size of message headers. -------  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Oct 88 06:25:33 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 26 Oct 88 03:40:24 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 Oct 88 04:18:06 GMT From: ukma!david@rutgers.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Subject: Re: To parse the unparseable dream Message-Id: <10437@s.ms.uky.edu> References: <3566@phri.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3566@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > What would you do if you saw the following on a To: line? > >Roy Smith Actually this isn't too bad ... The embedded comment is a little strange but is legal. Of course, we all know that "philabs.philips.com.weiser.pa" is really a couple of things concatenated together. The tail part of that is (as I recall) Mark Weiser's name & "domain" within Xerox. The rest is domain name for part of philips.com ... BUT, syntactically this address is perfectly correct. It is only wrong in its SEMANTICS. What our system here would do? Well, I'm assuming for the moment that MMDF's address parser is correct enough to handle that right. I believe that it is ... So anyway, we'd pass it over to xerox.com and it's their problem to figure out who to give it to... -- <-- David Herron; an MMDF guy <-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <-- <-- Controlled anarchy -- the essence of the net.  Received: from cs.utexas.edu (TCP 20024705411) by MC.LCS.MIT.EDU 26 Oct 88 14:47:50 EDT Posted-Date: Wed, 26 Oct 1988 13:43:39 CDT Received: from rascal.ics.utexas.edu by cs.utexas.edu (5.59/1.15) id AA29749; Wed, 26 Oct 88 13:47:47 CDT Received: by rascal.ics.utexas.edu (3.2/4.22) id AA17312; Wed, 26 Oct 88 13:43:42 CDT Date: Wed, 26 Oct 1988 13:43:39 CDT From: Werner Uhrig Reply-To: werner@rascal.ics.utexas.edu (Werner Uhrig) To: Justin Bur Subject: Re: I would like to see a header Sender-Addressed-To: In-Reply-To: Your message of Wed, 26 Oct 88 13:19:44 EDT Cc: justin@iro.umontreal.ca, header-people@cs.utexas.edu Message-Id: > There is no decent reason for anyone to go rewriting valid RFC822 > To: lines (except at gateways). It's probably explicitly forbidden > in the RFC, too. the *REAL* world, to my great lament, does not live by RFC822 alone; give me credit and assume that my suggestion was made because it would provide me useful information; not out of idle curiosity ... > Most sendmail.cf's that I have seen .... it's the ones we haven't seen ..... besides, we do agree that not the whole world uses sendmail, right? Who knows what they use in Europe, on Bitnet, on WeirdNet .... (-: PS: just take a look at the reply address my mailer generated when it faw your message From:-header; do I need to say more? From: Justin Bur so the reply address came out as: To: Justin Bur --------------------------> please send REPLIES to <------------------------ INTERNET: werner@rascal.ics.utexas.edu (Internet # 128.83.144.1) or: werner%rascal.ics.utexas.edu@cs.utexas.edu UUCP: ...!cs.utexas.edu!rascal.ics.utexas.edu!werner ALTERNATIVE: werner@astro.as.utexas.edu OR werner@utastro.UUCP  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Oct 88 15:55:40 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 26 Oct 88 15:53:40 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 Oct 88 16:11:13 GMT From: *!postman+@pt.cs.cmu.edu (Craig F. Everhart) Organization: Carnegie Mellon Subject: Re: To parse the unparseable dream Message-Id: References: <3566@phri.UUCP>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I could also take Roy Smith and, by hand, figure that maybe philabs.philips.com added itself as a source route (something like <@philabs.philips.com:weiser.pa@xerox.com>), then somebody's brain-dead (or ancient) sendmail.cf turned the colon into a dot, giving something like what you saw. If I believed that, I'd forward a report of the thing to the postmasters at philabs.philips.com and whatever other routing sites had been added in the Received: lines. Craig Everhart Andrew message system  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 27 Oct 88 16:23:40 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2203; Thu, 27 Oct 88 10:34:32 EDT Received: from IRLEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 2200; Thu, 27 Oct 88 10:33:59 EDT Received: by IRLEARN (Mailer X1.24) id 4430; Thu, 27 Oct 88 14:32:16 GMT Date: Thu, 27 Oct 88 14:30:22 GMT From: "Kieran Carrick,UCD,Ireland" Subject: Re: I would like to see a header Sender-Addressed-To: To: HEADER-PEOPLE@MC.LCS.MIT.EDU In-Reply-To: Message of Wed, 26 Oct 88 21:22:55 GMT from My colleagues here working on OSI and X.400 have commented that it is nice to see that the US Networking community are are beginning to create headers that look like x.400 addresses :-) Kieran Carrick EARN Country Coordinator - Ireland  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 27 Oct 88 16:55:53 EDT Received: from iros1.iro.umontreal.ca by RELAY.CS.NET id aa12438; 27 Oct 88 0:21 EDT Received: by iros1.iro.umontreal.CA (3.2-SMI) id AA09467; Wed, 26 Oct 88 15:45:57 EDT Message-Id: <8810261945.AA09467@iros1.iro.umontreal.CA> From: Justin Bur Date: Wed Oct 26 15:33:33 1988 In-Reply-To: Werner Uhrig's message of Wed, 26 Oct 1988 13:43 To: Werner Uhrig Subject: Re: I would like to see a header Sender-Addressed-To: Cc: header-people@MC.LCS.MIT.EDU, mouse@LARRY.MCRCIM.MCGILL.EDU I didn't intend to suggest that you were asking for your new header line for frivolous reasons, but rather to point out that the information you want is supposed to be present already. What I didn't make clear is that I consider the effort better spent to use the existing header lines properly rather than add new ones. In either case, obtaining compliance from everyone is practically impossible. Cleaning up the exist- ing line, as I see it, is more generally useful than defining a new one. Of course one could argue that the new line is guaranteed to be used properly, whereas the old one is known to be widely misused. That is, until the first time someone misreads the definition of the new line and writes software that destroys it, too. (As for that horrid From: line: yet another hazard of UUCP mail. The postmaster of the site mainly responsible for the mess will probably recognize it and insist again that it's not his fault.) -- Justin Bur Universite de Montreal - IRO Montreal (Qc) Canada H3C 3J7  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 OCT 88 20:05:38 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Thu, 27 Oct 88 13:03:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 27 Oct 88 03:31:07 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 Oct 88 22:40:18 GMT From: brian@ucsd.edu (Brian Kantor) Organization: The Avant-Garde of the Now, Ltd. Subject: Re: I would like to see a header Sender-Addressed-To: Message-Id: <1220@ucsd.EDU> References: <3296@utastro.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I've added the following to our sendmail.cf so that we'll add some useable addressing info as the mail passes through us; what we do is add the delivery address we see to the Received line. That won't do all that Werner suggested, but it is a help. HReceived: $?sfrom $s $.by $j ($v/$V)$?r via $r$.; $b id $i for $u --- Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu ucsd!brian BRIAN@UCSD  Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU 27 Oct 88 21:31:02 EDT Received: from localhost.cso.uiuc.edu by uxc.cso.uiuc.edu with SMTP (5.60+/IDA-1.2.5) id AA25455; Thu, 27 Oct 88 15:33:44 CDT To: Bob Larson Cc: header-people@MC.LCS.MIT.EDU, postmaster@CI.SEI.CMU.EDU, postmaster@SEI.CMU.EDU, postmaster@ANDREW.CMU.EDU, postmaster@SUN.COM, postmaster@JUNE.CS.WASHINGTON.EDU, postmaster@OBERON.USC.EDU, postmaster@AMES.ARC.NASA.GOV, postmaster@LLL-CRG.LLNL.GOV, postmaster@UUNET.UU.NET, postmaster@UMBC3.UMD.EDU, postmaster@TMC.EDU, postmaster@jade.berkeley.edu, postmaster@RELAY.CS.NET Subject: Re: Bogus rejections from unix systems In-Reply-To: Your message of Wed, 26 Oct 88 14:14:36 -0700. <24102688.16921465@AIS1> Date: Thu, 27 Oct 88 15:33:37 CDT Message-Id: <25451.593987617@uxc.cso.uiuc.edu> From: Paul Pomes (UofI-CSO 217-333-6262) The problem appears more to be in the user mail agent, which breaks addresses at white space and ",", than in sendmail. Invoking sendmail directly via /usr/lib/sendmail -q '<@nss.cs.ucl.ac.uk,@ecla.ucs.edu:info-prime-request@ais1>' caused uxc to contact nss.cs.ucl.ac.uk with the following conversation: 220 nss,cs,ucl.ac.uk Server SMTP etc >>> HELO uxc.cso.uiuc.edu 250 nss.cs.ucl.ac.uk >>> MAIL From: 250 OK >>> RCPT To: 550 (BHST) Unknown host/domain name in "info-prime-request <@ecla.ucs.edu:info-prime-request@ais1>" <@nss.cs.ucl.ac.uk,@ecla.ucs.edu:info-prime-request@ais1>... User unknown >>> QUIT Unfortunately nss.cs.ucl.ac.uk has become unreachable precluding the test of replacing the "..uk,@ecla..." replaced by "..uk:@ecla..."  Received: from ECLA.USC.EDU (TCP 3205200101) by MC.LCS.MIT.EDU 28 Oct 88 01:56:52 EDT Received: by AIS1; Wed, 26 Oct 88 14:14:36 PDT Date: Wed, 26 Oct 88 14:14:36 PDT From: Bob Larson Subject: Bogus rejections from unix systems To: header-people@MC.LCS.MIT.EDU Cc: postmaster@CI.SEI.CMU.EDU, postmaster@SEI.CMU.EDU, postmaster@ANDREW.CMU.EDU, postmaster@UXC.CSO.UIUC.EDU, postmaster@SUN.COM, postmaster@JUNE.CS.WASHINGTON.EDU, postmaster@OBERON.USC.EDU, postmaster@AMES.ARC.NASA.GOV, postmaster@LLL-CRG.LLNL.GOV, postmaster@UUNET.UU.NET, postmaster@UMBC3.UMD.EDU, postmaster@TMC.EDU, postmaster@JADE.BERKELEY.EDU, postmaster@RELAY.CS.NET, r.larson%AIS1@ECLA.USC.EDU Message-id: <24102688.16921465@AIS1> There seems to be a nasty bug in many unix mailers that causes them to reject messages with a (almost) valid rfc822 header. The line in question is: To: info-prime <@NSS.Cs.Ucl.AC.UK,@ecla.usc.edu:info-prime@ais1> Other than the fact that ais1 is not a valid domain, it is a usable and working address. (Mailers that don't try to validate all domains in rfc822 routes should accept this.) Some (most? sendmail sites?) unix mailers apperently mangle this to: To: info-prime <@NSS.Cs.Ucl.AC.UK>, @ecla.usc.edu:info-prime@ais1> and reject it because of the unbalanced '>'! Csnet at handles this slightly differently, and does deliver the mail with a "parse error in original version" warning. The Cc: recipents of this message are sites that sent rejection messages (many duplicates) and may not even be the sites guilty, since upstream sites do the rejection of errors recognised durring the SMTP session. If anyone wants copies of the messages from their site, or all 28 of them, let me know. Here are the relivent sections of a typical rejection message: [Recieved lines deleted] From: MAILER-DAEMON@pwcs.stpaul.gov (Mail Delivery Subsystem) Subject: Returned mail: Unable to deliver mail Message-Id: <8810260448.AA17826@pwcs.StPaul.GOV> To: INFO-PRIME-REQUEST%AIS1@ecla.usc.edu ----- Transcript of session follows ----- 554 ECLA.USC.EDU!INFO-PRIME-REQUEST%AIS1... Unbalanced '>' 554 johne... Unbalanced '>' 554 johne... Unbalanced '>' ----- Unsent message follows ----- [Recieved lines deleted] Via: uk.ac.umist.cns; Tue, 25 Oct 88 15:05:36 GMT (UMPA/20.200d) From: Ian Pallfreeman Message-Id: <4413.8810251440@sun> Subject: TeX driver for Printronix? To: info-prime <@NSS.Cs.Ucl.AC.UK>, @ecla.usc.edu:info-prime@ais1> Date: Tue, 25 Oct 88 14:40:26 BST X-Mailer: Elm [version 1.7] [text deleted] Bob Larson  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 28 Oct 88 07:02:23 EDT Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 88 12:04:04 PDT Date: Wed, 26 Oct 88 12:03:53 PDT From: JLarson.pa@Xerox.COM Subject: Re: To parse the unparseable dream To: roy%phri.UUCP@arisia.xerox.com, phri!roy@nyu.edu Cc: chet@cwjcc.CWRU.EDU, david@ms.uky.edu, header-people@mc.lcs.mit.edu, JLarson.pa@Xerox.COM Message-ID: <881026-120404-1351@Xerox> > What would you do if you saw the following on a To: line? >Roy Smith You should try to get someone to fix the broken mailer rather than worry about parsing smashed header fields. The most effective thing to do would be send the headers on the offending message to postmaster@xerox.com and your local site postmaster so they can determine which mailer(s) is (are) causing the problem and get it fixed. John  Received: from june.csl.sri.com (TCP 30003020453) by MC.LCS.MIT.EDU 28 Oct 88 13:51:39 EDT Received: by june.csl.sri.com (5.59e++/IDA-1.2.3-10) id AA16333; Fri, 28 Oct 88 10:50:05 PDT Date: Fri, 28 Oct 1988 10:50:01 PDT From: David L. Edwards To: Bob Larson Cc: header-people@MC.LCS.MIT.EDU Subject: re: Bogus rejections from unix systems Message-Id: IDA sendmail handles this correctly, in my opinion, by formatting the header line such that all mailers will find it acceptable while handling it correctly. The message failed because of an authorization failure from nss. See below which is the result of using the following to address: info-prime <@NSS.Cs.Ucl.AC.UK>, @ecla.usc.edu:info-prime@ais1> -dle From dle@june.csl.sri.com Fri Oct 28 10:27:02 1988 Received: by june.csl.sri.com (5.59e++/IDA-1.2.3-10) id AA16299; Fri, 28 Oct 88 10:27:02 PDT Date: Fri, 28 Oct 1988 10:27:00 PDT From: David L. Edwards To: info-prime Subject: TEST MESSAGE Message-Id: Lets see if we have the bug...  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 29 Oct 88 05:11:51 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 29 Oct 88 05:09:09 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 29 Oct 88 05:11:54 GMT From: utkcs2!cygnusx1!moore@gatech.edu (Keith Moore) Organization: CS Dept -- University of TN, Knoxville Subject: Re: I would like to see a header Sender-Addressed-To: ... (long) Message-Id: <611@utkcs2.cs.utk.edu> References: <3296@utastro.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3296@utastro.UUCP> werner@utastro.UUCP (Werner Uhrig) writes: >incoming mail arrives on my machine with a To-address which no longer >contains the information of how the sender had originally addressed me, >as the intermediate sites often modify the To-address as the mail gets >passed on from site to site. > >I wished all mail would arrive with a header: > >X-Sent-To: >X-CCed-To: >..etc.. > >as this is often the only way I can understand and comment on addressing >problem the sender might be having. Often the CC-addresses arrive here >mangled, as some sites along the way modify them, but others don't, >leaving me to try to hand-knit addresses before I can send a REPLY (to) ALL > >has this been discussed before? has anyone implemented such? >(I might as well start configuring our sendmail.cf do that to encourage >others to follow ...) Actually, this is easy to do. Just have either the mail user agent or the originating system's mailer add the header. The other mailers should pass it on undisturbed as long as they don't recognize it. For instance, X-Original-To: is probably reasonably safe. Subsequent mailers should not add such a header line anyway, since they cannot be sure that the header was not rewritten before it arrived at that machine. But why are the addresses being changed anyway? There are two good reasons that I can think of for addresses to be rewritten: (would someone like to suggest some others?) 1. The network being used requires source routing (e.g. UUCP), and the address must be rewritten at each machine it passes to make it valid for that machine. 2. The piece of mail in question is being gatewayed from one network to another network with a different addressing convention, and the addresses must be rewritten to be valid on the second network. In the latter case, it is useful if the mail gateway includes information about the address translation, perhaps in the Received: lines. What I would like to see is a set of network-specific headers added to a message when it crosses such a gateway, so that if the same message crosses another gateway to the original network, the original headers can be restored. For instance, if someone sends a message to me from a DECnet node UTKVX, the headers are originally something like this: From: JOE To: UTKCS2::"moore@cygnusx1.cs.utk.edu" When it reaches the DECnet-to-Internet gateway at UTKCS2, it gets converted to: From: JOE%UTKVX.DECNET@utkcs2.cs.utk.edu To: moore@cygnusx1.cs.utk.edu Now, if this piece of mail is somehow forwarded to another DECnet system (say UTKCS1) from cygnusx1, the From: line ends up looking something like this: From: UTKUX1::"JOE%UTKVX.DECNET%utkcs2.cs.utk.edu@cygnusx1.cs.utk.edu" when it could be as simple as From: UTKVX::JOE So, I'm thinking about having our gateways add header lines like X-UT-DECnet-To:, X-BITNET-To:, X-UT-PROFS-To:, and X-Internet-To: for messages that cross gateway boundaries, and having them recognize these lines if they are already in the header. I'd be interested to hear comments and criticisms about how well this scheme would work, and ideas for better ways to do this sort of thing. Keith Moore UT Computer Science Dept. Internet/CSnet: moore@utkcs2.cs.utk.edu 107 Ayres Hall, UT Campus BITNET: moore@utkcs1 Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 30 Oct 88 02:27:02 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 30 Oct 88 02:24:26 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 30 Oct 88 01:37:34 GMT From: mcdchg!chinet!jkingdon@gatech.edu (James Kingdon) Organization: Chinet - Public Access Unix Subject: Re: I would like to see a header Sender-Addressed-To: Message-Id: <6858@chinet.chi.il.us> References: <3296@utastro.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3296@utastro.UUCP> werner@utastro.UUCP (Werner Uhrig) writes: >has this been discussed before? has anyone implemented such? >(I might as well start configuring our sendmail.cf do that to encourage >others to follow ...) I know of at least 2 mailers that do so. PMDF for VAX/VMS (which is a mailer which supports TCP/IP, BITNET, DecNET, etc.) calls it X-VMS-To. The mailer that comes with JNET (which allows a VAX to speak the IBM RSCS protocols used over BITNET) calls it Original-To. Whether they do the same to CC I don't know. I suppose this kind of "chaos control" is a good idea but I'd rather focus my energy on trying to get everyone to accept the standard address format user@foo.bar.baz one way or another.  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 30 Oct 88 14:42:00 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 6931; Sun, 30 Oct 88 14:42:30 EST Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6928; Sun, 30 Oct 88 14:41:57 EST Date: Sun, 30 Oct 88 11:35 PST To: Bob Larson , header-people@MC.LCS.MIT.EDU, Paul Pomes (UofI-CSO 217-333-6262) From: Leonard D Woren Subject: Re: Bogus rejections from unix systems > Invoking sendmail directly via > > /usr/lib/sendmail -q '<@nss.cs.ucl.ac.uk,@ecla.ucs.edu:info-prime-request@ais1 > > caused uxc to contact nss.cs.ucl.ac.uk with the following conversation: ... > >>> RCPT To: > 550 (BHST) Unknown host/domain name in "info-prime-request <@ecla.ucs.edu:info > rime-request@ais1>" > <@nss.cs.ucl.ac.uk,@ecla.ucs.edu:info-prime-request@ais1>... User unknown The 550 message is correct, since the hostname was miskeyed. It's ECLA.USC.EDU, *not* ECLA.UCS.EDU .  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 5 Nov 88 04:53:12 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 5 Nov 88 04:52:28 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Nov 88 23:41:35 GMT From: munnari!vuwcomp!rata.vuw.ac.nz!newbery@uunet.uu.net (Michael Newbery) Organization: Computing Serv. Ctr, Victoria Uni., Wellington, New Zealand Subject: Widespread violation of RCF822 in "received" ? Message-Id: <14347@comp.vuw.ac.nz> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu This article is being posted on behalf of a friend who noticed the anomally while writing an RFC822 parser (in FORTRAN!) I checked and he seems to be right. The curious may wonder why a New Zealand site is forwarding stuff from Norway but that is another story... ----------------------------------------------------------------------- Would anyone out there like to explain the following problem/conflict with RFC #822 (the "Standard for ARPA Internet Text Messages" used in many mail systems) :- Problem: The received message "id" in a "Received:" field is not in the specified format for all mail I have seen (and a friend confirms this also). The definition for the "Received:" field is the following ... received = "Received" ":" ["from" domain] ["by" domain] ["via" atom] *("with" atom) ["id" msg-id] ["for" addr-spec] ";" date-time The definition for "msg-id" is the following ... msg-id = "<" addr-spec ">" Now observe an example "Received:" field ... Received: from relay.cs.net by RELAY.CS.NET id eu17161; 20 Sep 88 1:37 EDT For a start, the id is not surrounded by angle brackets ("<" and ">"). Secondly, "addr-spec" is defined to be ... addr-spec = local-part "@" domain ... there is definitely not an "@" sign either??????? One might think that the definition of "msg-id" is incorrect; however, for the "Message-ID:" field whose definition is ... "Message-ID" ":" msg-id ... I have seen the following ... Message-Id: <8809201329.AA26050@ncsuvx.ncsu.edu> ... which is in the correct format! What should the definition for the "id" section of a "Received:" field be? Are there a lot of gateways out there that have got it wrong? (My source for the RFC #822 definition is "Standard For The Format Of ARPA Internet Text Messages", dated August 13, 1982, revised by David H. Crocker). Thanks Mark Riley GECO (Geophysical Company Of Norway A/S) Internet: riley@gest01.sdr.slb.com SINet: m_gest01::riley Tel: +47 4 506437  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 7 Nov 88 08:58:33 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 5865; Mon, 07 Nov 88 08:58:57 EST Received: from Pythag.ucl.ac.be by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 5864; Mon, 07 Nov 88 08:58:23 EST Received: by BUCLLN11 (Mailer R2.01) id 3995; Mon, 07 Nov 88 08:59:03 +0100 Date: Mon, 07 Nov 88 08:53:19 +0100 From: "Alain FONTAINE (Postmaster - NAD)" Subject: Re: Widespread violation of RCF822 in "received" ? To: Header-People Discussion In-Reply-To: Message of Thu, 3 Nov 88 23:41:35 GMT from The Received: header line is added by each Mail Transfer Agent in the chain. In the Internet, MTA's normally use SMTP, defined in RFC821. Since SMTP, being a MTA protocol, specifies the generation of Received: header lines, it also contains a definition of that line. Unfortunately, this definition is not the same as the one you found in RFC822 (in RFC821, id is defined as 'any string'...). So, depending on which RFC you follow.... /AF  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 7 Nov 88 15:30:52 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0689; Mon, 07 Nov 88 15:30:59 EST Received: from MAINE.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0685; Mon, 07 Nov 88 15:30:09 EST Received: by MAINE (Mailer X1.25) id 0733; Mon, 07 Nov 88 14:22:35 EST Subject: Re: Widespread violation of RCF822 in "received" ? To: HEADER-PEOPLE@MC.LCS.MIT.EDU From: Barry D Gates Date: Mon, 7 Nov 88 14:18:35 EST >From: Michael Newbery > >Subject: Widespread violation of RCF822 in "received" ? > >What should the definition for the "id" section of a "Received:" field >be? Are there a lot of gateways out there that have got it wrong? I asked the same question about a month or two back on this list. The best I've been able to come up with that is usable is: ["id" (msg-id / local-part)] which I've yet to see anything that will fail it. If you think about it, the "domain" in the message-id is normally redundant as it is usually the same as the "by" clause on the Received tag if one was given (in the messages I've seen anyway). This particular syntax is also very easy to differentiate as well. Just grab the first token after the atom "id"; if it is the special "<" then you have a msg-id to parse, otherwise use the local-part format. Hope that helps, Barry...  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 1 Dec 88 06:03:40 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 1 Dec 88 05:54:16 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Dec 88 09:24:13 GMT From: deimos!ksuvax1!tar@rutgers.edu (Tim Ramsey) Organization: Kansas State University, Dept of Computing & Information Sciences Subject: Mail header wishlist (was Re: Another example why not to re-route) Message-Id: <1320@ksuvax1.cis.ksu.edu> References: <1005@asylum.sf.ca.us>, , <2696@sultra.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [ I've added comp.mail.headers and directed followups there since this thread seems to be moving in that direction. -- Tim] The Options: header is a good idea. How about a Bounced-By: header, to make it clear to mailing list repeaters that this mail shouldn't be broadcast to the list? It could include the reason the mail was bounced. -- Timothy Ramsey, USENET Keeper-Upper BITNET: tar@KSUVAX1 Internet: tar@ksuvax1.cis.ksu.edu UUCP: ...!rutgers!ksuvax1!tar -or- ...!{pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!tar  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 1 Dec 88 10:18:56 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 1 Dec 88 10:10:48 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Dec 88 15:04:19 GMT From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa (Karl Kleinpaste) Organization: OSU Subject: Re: Mail header wishlist Message-Id: References: , <2696@sultra.UUCP>, <1320@ksuvax1.cis.ksu.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu tar@ksuvax1.cis.ksu.edu (Tim Ramsey) writes: The Options: header is a good idea. How about a Bounced-By: header, to make it clear to mailing list repeaters that this mail shouldn't be broadcast to the list? It could include the reason the mail was bounced. That would be unnecessary if mailing lists would all make sure that, when distributing out to the list's recipients, an Errors-To: listname-request@listname-host-machine header were included. Then bounces would go to the admin only, and nowhere else. Also, it helps to have the From_ line indicate listname-request@listname-host-machine to keep vacation(1) happily silent. --Karl  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 1 Dec 88 13:41:27 EST Received: from sol.engin.umich.edu by XX.LCS.MIT.EDU with TCP/SMTP; Thu 1 Dec 88 13:39:22-EST From: bhoward@sol.engin.umich.edu To: karl%triceratops.cis.ohio-state.edu.uucp@ohio-state.arpa, header-people@mc.lcs.mit.edu Date: 1 Dec 1988 13:38 EST Subject: Re: Mail header wishlist From ohio-state.arpa!karl%triceratops.cis.ohio-state.edu.uucp Thu Dec 1 10:45:50 1988 From: karl%triceratops.cis.ohio-state.edu.uucp@ohio-state.arpa (Karl Kleinpaste) Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Date: 1 Dec 88 15:04:19 GMT Organization: OSU Subject: Re: Mail header wishlist Message-Id: References: , <2696@sultra.UUCP>, <1320@ksuvax1.cis.ksu.edu> tar@ksuvax1.cis.ksu.edu (Tim Ramsey) writes: The Options: header is a good idea. How about a Bounced-By: header, to make it clear to mailing list repeaters that this mail shouldn't be broadcast to the list? It could include the reason the mail was bounced. That would be unnecessary if mailing lists would all make sure that, when distributing out to the list's recipients, an Errors-To: listname-request@listname-host-machine header were included. Then bounces would go to the admin only, and nowhere else. Also, it helps to have the From_ line indicate listname-request@listname-host-machine to keep vacation(1) happily silent. --Karl From_ aren't valid rfc822. vacation should use appropriate rfc header (from:, reply-to:, whatever) bruce howard  Received: from tis.llnl.gov (TCP 30003010402) by MC.LCS.MIT.EDU 2 Dec 88 15:46:08 EST Return-Path: Received: by tis.llnl.gov (4.0/1.14-TIS) id AA16199; Fri, 2 Dec 88 12:36:36 PST Message-Id: <8812022036.AA16199@tis.llnl.gov> Date: Fri, 2 Dec 88 12:36:32 -0800 From: kehres@tis.llnl.gov (Tim Kehres) Subject: Re: Mail header wishlist To: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa Cc: header-people@mc.lcs.mit.edu X-Orig-Date: 1 Dec 88 15:04:19 GMT X-Orig-From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa (Karl Kleinpaste) X-Orig-Message-Id: In your message you write: > tar@ksuvax1.cis.ksu.edu (Tim Ramsey) writes: > The Options: header is a good idea. How about a Bounced-By: header, to make > it clear to mailing list repeaters that this mail shouldn't be broadcast to > the list? It could include the reason the mail was bounced. > > That would be unnecessary if mailing lists would all make sure that, > when distributing out to the list's recipients, an Errors-To: > listname-request@listname-host-machine header were included. Then > bounces would go to the admin only, and nowhere else. Also, it helps > to have the From_ line indicate listname-request@listname-host-machine > to keep vacation(1) happily silent. > > --Karl The main problem with including an "Errors-To:" field is that it is not conformant to RFC-822. More appropriate header fields to use (that are currently defined by RFC-822) include the "Sender:" as well as "Return-Path:" fields. From RFC-822: "4.3.1 RETURN-PATH This field is added by the final transport system that delivers the message to its recipient. The field is intended to contain definitive information about the address and route back to the message's originator......" Since most mailing lists can be thought of as re-submitting a message as opposed to relaying a message, the use of this field by the mailing list should be valid. "4.4.2 SENDER / RESENT-SENDER This field contains the authenticated identity of the AGENT (person, system or process) that sends the message. It is intended for use when the sender is not the author of the mes- sage, or to indicate who among a group of authors actually sent the message. If the contents of the "Sender" field would be completely redundant with the "From" field, then the "Sender" field need not be present and its use is discouraged (though still legal). In particular, the "Sender" field MUST be present if it is NOT the same as the "From" Field....." "4.4.4 AUTOMATIC USE OF FROM / SENDER / REPLY-TO For systems which automatically generate address lists for replies to messages, the following recommendations are made: o The "Sender" field mailbox should be sent notices of any problems in transport or delivery of the original messages. If there is no "Sender" field, then the "From" field mailbox should be used. o The "Sender" field mailbox should NEVER be used automatically, in a recipient's reply message....." Tim Kehres kehres@tis.llnl.gov  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Dec 88 04:48:35 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 3 Dec 88 04:43:49 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Dec 88 14:27:20 GMT From: rti!talos!kjones@mcnc.org (Kyle Jones) Organization: Philip Morris Research Center, Richmond, VA Subject: Re: Mail header wishlist Message-Id: <359@talos.UUCP> References: <2696@sultra.UUCP>, <1320@ksuvax1.cis.ksu.edu>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In Karl Kleinpaste writes: [concerning Bounced-By: header] >That would be unnecessary if mailing lists would all make sure that, >when distributing out to the list's recipients, an Errors-To: >listname-request@listname-host-machine header were included. This works only if everyone runs a mailer that supports this header. There is no mention of Errors-To: in RFC822. Sendmail claims to support this header, but smail (2.5) certainly does not. I say 'claims' because I recently had a mailing list that I run flooded with returned mail from a host running sendmail. An Errors-To: line was present in the message in question. For my money, the right way to avoid bounced mail hitting an entire mailing list is to make the From: header say -request instead of . This means that recipients must edit the To: line if they want to reply to the list, but that's a small price to pay. kyle jones ...!uunet!talos!kjones  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Dec 88 12:18:33 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 3 Dec 88 12:12:43 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Dec 88 16:51:40 GMT From: ukma!david@rutgers.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Subject: Re: Mail header wishlist Message-Id: <10645@s.ms.uky.edu> References: <1320@ksuvax1.cis.ksu.edu>, , <359@talos.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <359@talos.UUCP> kjones@talos.UUCP (Kyle Jones) writes: >In Karl Kleinpaste writes: >[concerning Bounced-By: header] >>That would be unnecessary if mailing lists would all make sure that, >>when distributing out to the list's recipients, an Errors-To: >>listname-request@listname-host-machine header were included. > An Errors-To: line was >present in the message in question. > >For my money, the right way to avoid bounced mail hitting an entire >mailing list is to make the From: header say -request >instead of . This means that recipients must edit the To: >line if they want to reply to the list, but that's a small price to pay. No no no no ... The *right* way to do this is to change the out-of-band return address to be -request@list-host.domain. I think this is even documented in an RFC somewhere, but is certainly the preferred practice on the Internet. And the main offenders are mailing lists run at sites running SendMail. On the internet the out-of-band information is carried as part of the SMTP conversations in the MAIL FROM:<> and RCPT TO:<> lines. In BITNET there isn't any good place to carry the information unless you're using BSMTP, and this is one of the reasons why BITNET should be converting to BSMTP. In UUCP, this information is carried in two places, the TO information is carried along as arguments to rmail and the FROM information is carried along in the "From" line. Most rmail's allow only one argument, which ends up requiring physically seperate messages be sent out for each person on the mailing list. This is one of the things which MMDF does right. Part of the package is the List Channel. It accepts messages meant for a mailing list and expands the TO portion of the out-of-band information to be all the people on the list. if -request exists as an alias in the system, changes the out-of-band FROM information to reflect this. resubmits the message to the system. (no header munging) A similar program would be easy to do to run under sendmail. Part of how this happens in MMDF is that you have a sequence of aliases like: : -outgoing@list-processor -outgoing: :include:/file -request: joe-blow In other words, you have to set up a pseudo-host so that you can direct mail to it. -- <-- David Herron; an MMDF guy <-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <-- <-- Controlled anarchy -- the essence of the net.  Received: from IU.AI.SRI.COM (TCP 1201200002) by MC.LCS.MIT.EDU 3 Dec 88 14:13:25 EST Date: Sat 3 Dec 88 11:13:06-PST From: Peter Karp Subject: Re: Mail header wishlist To: rti!talos!kjones@mcnc.org Cc: header-people@mc.lcs.mit.edu Message-ID: <597179586.0.PKARP@IU.AI.SRI.COM> In-Reply-To: <359@talos.UUCP> Mail-System-Version: Get real folks. RFC822 provides ways of solving this problem. If every mailer followed the specs, error messages would go to the right places. I see no point in proposing new specs that people will be just as lax in following. Peter -------  Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU 3 Dec 88 22:18:50 EST Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.60+/IDA-1.2.5) id AA10879; Sat, 3 Dec 88 21:19:17 CST Message-Id: <8812040319.AA10879@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 4115; Sat, 03 Dec 88 21:04:51 CST Date: Sat, 03 Dec 88 20:46:56 CST From: Philip Howard Subject: mailing list headers To: Tim Kehres , Header-People > The main problem with including an "Errors-To:" field is that it is not > conformant to RFC-822. More appropriate header fields to use (that are > currently defined by RFC-822) include the "Sender:" as well as > "Return-Path:" fields. From RFC-822: (RFC822 extract omitted) > Tim Kehres > kehres@tis.llnl.gov Because of mailing system security, one of the FROM CLASS fields must represent the true origin of the mail. Usually it is FROM: itself, but SENDER: usually provides a sufficient alterantive. However, in the case of mailing lists on some systems, there may be a need to identify: 1. Who wrote the message being distributed 2. Who actually sent the message to the mailing list 3. The mailing list itself, usually for contributing 4. The daemon that runs the mailing list 5. The mailing list administration Typically, there are fewer than 5 distinct addresses in a mailing, but the bindings between those identities that are the same address could be different in different cases. For example one system may usually have 3 and 4 be the same address while another has 4 and 5 the same address. Even if no actual case has 5 distinct addresses, we might need to consider the combinations as though there were 5 distinct addresses. Still, there even can be a need for all 5. Now can someone label each of the 5 addresses with the name of the RFC822 header field that should be used for it? If you are wanting to use the RESENT CLASS headers, consider: 6. Who resent the mail to mailing list 7. Who resent the mailing list mail to someone --phil--  Received: from wucs1.wustl.edu (TCP 20077075414) by MC.LCS.MIT.EDU 4 Dec 88 07:38:43 EST Received: from wubios.wustl.edu by wucs1.wustl.edu (5.59/1.33); id AA26493; Sun, 4 Dec 88 06:39:16 CST Return-Path: Received: by wubios.WUstl.EDU (4.0/Sun UNIX 4.0); Sun, 4 Dec 88 06:42:27 CST From: phil@wubios.WUstl.EDU (J. Philip Miller) Message-Id: <8812041242.AA13415@wubios.WUstl.EDU> To: header-people@mc.lcs.mit.edu (Header-People Distribution List) Date: Sun, 4 Dec 88 6:42:26 CST Subject: mailing list headers X-Mailer: Elm [version 1.5] > Date: Sat, 3 Dec 88 20:46:56 CST > From: Philip Howard > Subject: mailing list headers > > Because of mailing system security, one of the FROM CLASS fields must > represent the true origin of the mail. Usually it is FROM: itself, but > SENDER: usually provides a sufficient alterantive. However, in the case > of mailing lists on some systems, there may be a need to identify: > 1. Who wrote the message being distributed > 2. Who actually sent the message to the mailing list > 3. The mailing list itself, usually for contributing > 4. The daemon that runs the mailing list > 5. The mailing list administration > > Typically, there are fewer than 5 distinct addresses in a mailing, but the > bindings between those identities that are the same address could be different > in different cases. For example one system may usually have 3 and 4 be the > same address while another has 4 and 5 the same address. Even if no actual > case has 5 distinct addresses, we might need to consider the combinations as > though there were 5 distinct addresses. Still, there even can be a need for > all 5. Phil, you have writen one of the most cogent statements on this problem that I have seen in many months. Most contributors have simply resorted to mailer-bashing because someone else's mailing list grouped your 5 cases in a different way than on their own system. How these functions are grouped is typically a function of other software, administrivia and technical issues. Just because something works well in a Unix/sendmail environment does not mean it works right in an IBM RSCS-type environment. As to whether there needs to be new headers or not (I think there is such a need), 822 clearly allows for the registration of new header types. If such registration is done (As far as I know it has never been actually done), then the use of such headers IS 822 CONFORMING! -phil > > Now can someone label each of the 5 addresses with the name of the RFC822 > header field that should be used for it? If you are wanting to use the > RESENT CLASS headers, consider: > 6. Who resent the mail to mailing list > 7. Who resent the mailing list mail to someone > > --phil-- > >  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 DEC 88 05:30:17 EST Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Mon, 5 Dec 88 05:30:49 EST Received: from Think.COM by news.think.com; Mon, 5 Dec 88 05:19:55 EST Return-Path: Received: from ames.arc.nasa.gov by Think.COM; Mon, 5 Dec 88 04:43:37 EST Received: Mon, 5 Dec 88 02:11:42 PST by ames.arc.nasa.gov (5.59/1.2) Received: by amdahl.uts.amdahl.com (/\=-/\ Smail3.1.10.3 #10.1) id ; Mon, 5 Dec 88 08:03 GMT Received: by busboy.uts.amdahl.com (/\=-/\ Smail3.1.11.5 #11.3) id ; Mon, 5 Dec 88 00:02 PST Received: by tde.uts.amdahl.com (/\=-/\ Smail3.1.11.5 #11.5) id ; Mon, 5 Dec 88 00:02 PST Message-Id: Date: Mon, 5 Dec 88 00:02 PST From: tron@uts.amdahl.com (Ronald S. Karr) To: bhoward@sol.engin.umich.edu Subject: Re: Mail header wishlist Cc: header-people@mc.lcs.mit.edu >From_ aren't valid rfc822. vacation should use appropriate rfc header >(from:, reply-to:, whatever) The From_ sender address is the closest UUCP equivalent to the sender path described in RFC821 (SMTP). The SMTP sender path is the preferred address for error messages, so the philosophy of using the From_ line is not so inappropriate as you say it is. tron |-<=>-|  Received: from po2.andrew.cmu.edu (TCP 20000574551) by MC.LCS.MIT.EDU 6 Dec 88 11:01:01 EST Received: by po2.andrew.cmu.edu (5.54/3.15) id for header-people@mc.lcs.mit.edu; Tue, 6 Dec 88 11:01:00 EST Received: via switchmail; Tue, 6 Dec 88 11:00:49 -0500 (EST) Received: from apollo.andrew.cmu.edu via qmail ID ; Tue, 6 Dec 88 11:00:16 -0500 (EST) Received: from apollo.andrew.cmu.edu via qmail ID ; Tue, 6 Dec 88 11:00:02 -0500 (EST) Received: from Version.6.25.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.andrew.cmu.edu.rt.r3 via MS.5.6.apollo.andrew.cmu.edu.rt_r3; Tue, 6 Dec 88 11:00:02 -0500 (EST) Message-Id: Date: Tue, 6 Dec 88 11:00:02 -0500 (EST) From: "Craig F. Everhart" X-Andrew-Message-Size: 2805+0 To: header-people@mc.lcs.mit.edu Subject: Re: mailing list headers In-Reply-To: <8812040319.AA10879@uxc.cso.uiuc.edu> References: <8812040319.AA10879@uxc.cso.uiuc.edu> At the risk of participating in a header-name-calling war, I'd like to offer an interpretation of Philip Howard's fine analysis of header bindings that I believe is what the RFCs say: > 1. Who wrote the message being distributed Value of the From: field > 2. Who actually sent the message to the mailing list Value of the Sender: field > 3. The mailing list itself, usually for contributing Value of the To: field. Some distribution mechanisms might wish to interject this in a Reply-to: field, but that gets in the way of the author/sender's use of said field. > 4. The daemon that runs the mailing list Value of the Return-path: field, copied from the envelope; this reaches the list administration. It's not clear that recipients know how to communicate with the daemon itself, should it happen to have a mailing address. > 5. The mailing list administration Value of the Return-path: field, copied from the envelope > 6. Who resent the mail to mailing list Value of the ReSent-From: field, when the corresponding ReSent-To: field is the list submission address > 7. Who resent the mailing list mail to someone Value of the ReSent-From: field, when the corresponding ReSent-To: field is the address of ``someone''. Lots of folks don't live in the RFC821/RFC822 world and thus don't have routine access to all this information; unfortunately, RFC821 and RFC822 differ on where the errors-to information should go (821: the MAIL FROM:/Return-Path: information, 822: the Sender), even though Sender: can be useful to the composer of the original message composer as well. There are doubtless lots of presumptions I'm making. There's always a tension between whether the receiver of a message to be redistributed is a first-class mail recipient or not. If it is first-class, then the redistribution is a re-sending operation applied to a piece of received mail; if it's not first-class, redistribution is a matter of rewriting the envelope without opening the letter. My preference is for the latter; the ReSent-xxx headers are always messy for recipients to handle automatically. In any event, non-first-class-recipient redistribution only needs to mess with the envelope; errors go to the Return-path: information, as given in RFC821; and the redistributor isn't burdened with rewriting RFC822 headers at all. My own opinion is that the fact that sendmail implements Errors-to: and -owner doesn't make them a standard that others need to follow. Clearly, other views are possible. According to my understanding, it's a miracle that LISTSERV works at all; in RSCS-land there's no distinct envelope information (or none that you can count on), and LISTSERV is a first-class mail recipient, so it both has to have an address and has to muck with the preexisting message headers.  Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU 6 Dec 88 17:45:00 EST Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.60+/IDA-1.2.5) id AA04054; Tue, 6 Dec 88 16:43:27 CST Message-Id: <8812062243.AA04054@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 0730; Tue, 06 Dec 88 15:49:44 CST Date: Tue, 06 Dec 88 15:25:36 CST From: Philip Howard Subject: Re: mailing list headers To: "Craig F. Everhart" , header people In-Reply-To: Your message of Tue, 6 Dec 88 11:00:02 -0500 (EST) > > 3. The mailing list itself, usually for contributing > Value of the To: field. Some distribution mechanisms might wish to interject > this in a Reply-to: field, but that gets in the way of the author/sender's use > of said field. I forgot to include something here. There is ALSO another address, that being the address of who is receiving the mail from the mailing list system. Because of the way LISTSERV redistributes mail, it has to use this header. See later part about first-class mail receipt. This is not needed if.... BTW: I have also seen mailer-daemons that will not accept the mail unless it is address To: someone on their machine (or in Cc:). I think those are kind of sick, but I'm not going to offend people there with this because they cannot receive this header-people mail anyway. > > 4. The daemon that runs the mailing list > Value of the Return-path: field, copied from the envelope; this reaches the li > administration. It's not clear that recipients know how to communicate with t > daemon itself, should it happen to have a mailing address. > > 5. The mailing list administration > Value of the Return-path: field, copied from the envelope Would you mean (and is it legal) for there to be 2 different Return-path: headers when 4 and 5 are different? If it is legal 822, sounds good to me. BITNET's LISTSERV has an address, and mail to it is interpreted as a set of commands that include automatic subscribing and access to a file server with indexes related to mailing lists. A nifty system. > Lots of folks don't live in the RFC821/RFC822 world and thus don't have routin The MAILER used on lots of BITNET VM/CMS systems is partly RFC733 and partly RFC822 compatible. There is a new MAILER out, but I haven't been able to get a copy of it yet. > mail recipient or not. If it is first-class, then the redistribution is a > re-sending operation applied to a piece of received mail; if it's not > first-class, redistribution is a matter of rewriting the envelope without > opening the letter. My preference is for the latter; the ReSent-xxx headers a > always messy for recipients to handle automatically. In any event, > non-first-class-recipient redistribution only needs to mess with the envelope; This would make things a lot easier and it is possible to do even on VM/CMS using MAILER. Just send BSMTP to your server and make the server a known MAILER. This would be my preference, too. > Clearly, other views are possible. According to my understanding, it's a > miracle that LISTSERV works at all; in RSCS-land there's no distinct envelope > information (or none that you can count on), and LISTSERV is a first-class mai > recipient, so it both has to have an address and has to muck with the > preexisting message headers. Since early efforts to write a LISTSERV were done by students without access to their systems beyond ordinary user access, things just got started this way and never changed. It could change, but now it would be rather disruptive. Wait a while, and it will be a bigger disruption later.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 6 Dec 88 17:53:15 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 6 Dec 88 17:39:33 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 6 Dec 88 22:00:32 GMT From: mailrus!ulowell!page@ohio-state.arpa (Bob Page) Organization: University of Lowell, Computer Science Dept. Subject: Re: Mail header wishlist Message-Id: <10512@swan.ulowell.edu> References: <1320@ksuvax1.cis.ksu.edu>, , <359@talos.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Karl Kleinpaste writes: > [include] Errors-To: Errors-To: is a sendmail-ism. A stock sendmail will bounce errors to the Errors-To: address IN ADDITION to the From: address. You should use Sender: as per rfc822. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 6 Dec 88 23:38:15 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 6 Dec 88 23:29:40 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Dec 88 04:16:24 GMT From: unmvax!turing.unm.edu!mike@bloom-beacon.mit.edu (Michael I. Bushnell) Organization: University of No Money, Albuquerque, New Mexico Subject: Re: Mail header wishlist Message-Id: <2179@unmvax.unm.edu> References: <1320@ksuvax1.cis.ksu.edu>, , <359@talos.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <359@talos.UUCP> kjones@talos.UUCP (Kyle Jones) writes: In Karl Kleinpaste writes: [concerning Bounced-By: header] >That would be unnecessary if mailing lists would all make sure that, >when distributing out to the list's recipients, an Errors-To: >listname-request@listname-host-machine header were included. This works only if everyone runs a mailer that supports this header. There is no mention of Errors-To: in RFC822. Sendmail claims to support this header, but smail (2.5) certainly does not. I say 'claims' because I recently had a mailing list that I run flooded with returned mail from a host running sendmail. An Errors-To: line was present in the message in question. Hmmm...It appears I (who said the same thing as Karl) that you are correct. On the other hand, the Sender: field is unquestionable the proper location for errors to be sent. For my money, the right way to avoid bounced mail hitting an entire mailing list is to make the From: header say -request instead of . This means that recipients must edit the To: line if they want to reply to the list, but that's a small price to pay. Hmmmm...yeah. But then I suspect you will have to manually forward lots of postings from users who didn't manually edit the To: line. The best way is for mail addressed like so: To: mailinglist@foo.bar.bax From: Joe.User@my.machine to be transformed by foo.bar.bax when it resends the mail into Resent-From: mailinglist-request@foo.bar.bax Resent-Sender: mailinglist-request@foo.bar.bax To: mailinglist@foo.bar.bax From: Joe.User@my.machine The mail should be delivered using the Resent-* headers in preference to the originals...according to the RFC. How much you wanna bet that smail and sendmail both don't actually do this right...:-) The best defacto solution is probably to have the mail set to individual list subscribers be addressed To: mailinlist@foo.bar.bax Sender: mailinglist-request@foo.bar.bax From: Joe.User@my.machine Reply-To: mailinglist@foo.bar.bax If you want the from line changed, then go ahead--but you are asking to be filled with pain if you don't fix the Reply-To: line... -- Michael I. Bushnell \ This above all; to thine own self be true HASA - "A" division GIG! \ And it must follow, as the night the day, mike@turing.unm.edu /\ Thou canst not be false to any man. Numquam Gloria Deo / \ Farewell: my blessing season this in thee!  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 7 Dec 88 00:05:23 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 9113; Wed, 07 Dec 88 00:05:23 EST Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 9112; Wed, 07 Dec 88 00:05:20 EST Date: Tue, 06 Dec 88 21:00 PST To: header-people@MC.LCS.MIT.EDU From: Leonard D Woren Subject: Re: mailing list headers My personal view is that ReSent-xxx is a bad idea which should never have been included in the standard. It's too hard to determine exactly what's going on when there are ReSent- headers. And what happens if you resend a resent message??? This may or may not be a reasonable analogy, but if you receive a letter via snailmail, and you want to forward it to someone else, you don't stick more writing on the first envelope. You put the whole thing in a new envelope and resend it. This is how *I* think that resent e-mail should be done.  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 7 Dec 88 05:33:25 EST Received: by INFOODS id <00000EF7061@INFOODS.MIT.EDU> ; Wed, 7 Dec 88 05:28:00 EST Date: Wed, 7 Dec 88 04:28:16 EST From: John C Klensin Subject: mailing list headers and envelopes To: Leonard D Woren X-VMS-Mail-To: EXOS%"Leonard D Woren " Message-ID: <881207042816.00000EF7061@INFOODS.MIT.EDU> cc: header-people@MC.LCS.MIT.EDU I've been trying to ignore this discussion, since I think it is kicking a dead horse, but Leonard's comment has finally prompted me to start typing. First, and perhaps most important, there are three meta-problems with RFC821/822 that set part of the context of this discussion: (a) A lot of systems, including the most popular mailers used on U**X systems and the dominant mailer for VM/CMS systems on BITNET conform at the "mostly" level. As has been pointed out earlier in this discussion, if one adds headers, or makes more specific rules about how existing ones are used, someone out there will decline to pay any attention. So, at best you can make the situation a bit better--at great cost--but you can't solve it. One of the reasons for non-conformance is that the 821/822 logic was designed around the assumptions of strong envelopes and interactive (i.e., able to negotiate with each other) MTAs. In the design environment of SMTP (821), if the MTA on machine A tries to send a message to an unknown user on machine B, it gets an error message from the MTA on machine B in response to machine A's RCPT-TO message. At that point, the MTA on machine A can trash the message as it deems appropriate, having never transmitted the message body. To state this a little more clearly for the non-Internet readers of this list: RFC822 does not need rules about what machine B does to the (822) headers of an undeliverable message or which of them it uses to generate an error reply, because machine B *never* sees the message OR THE 822 HEADERS if its MTA reports to machine A's MTA that the message is undeliverable. Now, things like BSMTP provide some approximation to the "envelope" part of this business, but they can't approximate the interactive way in which SMTP uses that envelope in a "I want this delivered to Fred", "we don't have a Fred" dialogue. And, as has been pointed out, BITNET is exceedingly tolerant of messages that don't arrive with BSMTP envelopes, just as various other arrangements are tolerant of non-conforming header fields. Making rules is easy, the problem is getting people to follow them, especially people who think they know better and have "better ideas". (b) RFC822 was never designed to accomodate mailing list traffic in the form in which that traffic has evolved. Things look and feel peculiar because they are peculiar. While I'm very sympathetic to the analysis that has appeared here over the last few days, and to some of the specific suggestions, there is some stretching involved. For example, if RFC822 "Sender" is different from "From", the "Sender" is supposed to be the authenticated [human] agent of the message originator, who appears in "From". If I'm on my way out of the office, and I hand an e-mail message on paper to a secretary and say "please transmit this", then he or she becomes "Sender" and I become "From". Does the secretary want the bounce messages? No, probably not, but under other scenarios, the answer might be different. This sort of thing is, ultimately, a strong argument for an assortment of "Error-mumble" fields in RFC822 or its descendants, but see (a) above and (c) below. In the interim, it is sensible to devise strategies to get around the problems as much as possible without bothering to argue protocol-purity. More important, adding fields won't help very much if one of the hosts involved implements RFC821 as discussed under (a). If you don't see the message headers, but work only with the envelope, you can't do much with the message headers. To require that an RFC821 mail server accept any incoming message and analyse it so that it can return it to the "right" place would require a fairly major change in that protocol. I think it would also raise some security issues, but I don't want to think about that at the moment. (c) Like it or not, X.400, especially in the 1988 version, is looming on the horizon. It is going to be hard to get vendors, or even the protocol-specifying part of the research community, to make major investments in things like RFC822 headers when the shape of the future is as clear as X.400 is today. And, for better or worse, X.400 is populated with a rather complete set of "this kind of errors go to A, that kind go to B, acknowledgements go to C, and replies go to D" sorts of fields. Nothing said above should be taken as either an endorsement of, or enthusiasm about, X.400. I merely assert that it is a reality which sets some context for proposing header changes. Now, after that long introduction, Leonard Woren writes: >My personal view is that ReSent-xxx is a bad idea which should never >have been included in the standard. It's too hard to determine >exactly what's going on when there are ReSent- headers. And what >happens if you resend a resent message??? This may or may not be a >reasonable analogy, but if you receive a letter via snailmail, and >you want to forward it to someone else, you don't stick more writing >on the first envelope. You put the whole thing in a new envelope and >resend it. This is how *I* think that resent e-mail should be done. But, in 821/822 land, this is *exactly* what happens. RFC822 headers are not part of the envelope, they are a structured piece of the message. When I get a message from you, and I want to resend it to a third party, and my UA is smart enough to arrange a "forward" or "resend" operation correctly, all of the action goes on in the envelope that is constructed for the message to be resent. If I'm doing that with snailmail, I've probably discarded the envelope in which I received the message (this is consistent with Leonard's model) and so, to send the message to a third party, I make up a new envelope and send it out. So far, exact analogy, and I haven't mentioned a "Resent" header. BUT, I also do one other thing before sealing the envelope and dropping it in the postbox, which is to affix a sticky piece of paper to the message text that says "hey Joe, I think you should look at this too, --john". I'd suggest that this becomes part of the "header" (the letterhead and original addressee information) and, in RFC822's language, is Resent-to, Resent-from, and [X-]Resent-comment. Now, if "joe" sends it on again, he might take any of three courses of action: (a) remove my piece of sticky paper and replace it with his own, analogous to removing the original Resent fields and replacing them. (b) add his piece of sticky paper to the letter, analogous to adding additional Resent fields. (c) cut the interesting parts out of the letter and tape it to his own notes and then send that, analogous to building a new message, headers, envelope, and all, with him as "From" and no Resent fields at all. Yes, in the second case, one has to do a little deducing if you want to figure out the path the message travelled (especially if you don't have a full set of Received fields with full information), but you have that problem with the postal analogy also. Finally, note that there are at least a few conforming implementations of SMTP in which the actual body of the message text belongs to the local MTA, which thinks it is responsible for header authentication. You can read mail, you can extract mail from the system and repackage it, but the only way you ever get a Resent or Forwarded field involves asking the MTA to forward it for you: those fields imply a guarantee by the MTA that what you received you sent on, unaltered. If you copy the message text out and then try to send it, it is a new message as far as the system is concerned and you don't get Resent or Forwarded fields. John Klensin, Center for International Studies, MIT  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 Dec 88 13:08:25 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 7 Dec 88 12:53:57 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 5 Dec 88 10:28:48 GMT From: mcvax!inria!crcge1!lri!rd@uunet.uu.net (Roland Dirlewanger) Organization: LRI - Orsay. France. Subject: Validity check failed - What is it ? Message-Id: <316@lri.lri.fr> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Some gateways refuse to forward some messages issued by our site. This problem affects mostly BSMTP error messages. In the following example, some user at MIT.EDU sent a message to some user at our site (FRLRI61.BITNET). The local user name was wrong, so our mailer generated an error message back to the sender, an this message was rejected by CUNYVM. Could someone tell me why ? How does a gateway check the validity of some message ? Thanks a lot in advance. -- Roland Dirlewanger E-mail: rd@lri.fr Universite Paris Sud rd@lri.UUCP Laboratoire de Recherche en Informatique rd@FRLRI61.BITNET Batiment 490 Phone: +33 (1) 69 41 64 01 91405 Orsay Cedex -------------------- Here is the example: # Your mail was not delivered to some or all of its # intended recipients for the following reason(s): # # Validity check failed. # # --------------------RETURNED MAIL FILE-------------------- # Received: from FRLRI61(MAILER) by CUNYVM (Mailer R2.01) id 3865; # Fri, 02 Dec 88 11:11:13 EDT # From: MAILER-DAEMON@FRLRI61.BITNET # Received: by sun1.lri.fr, Fri, 2 Dec 88 16:58:16 +0100 # Date: Fri, 2 Dec 88 16:58:16 +0100 # Subject: Returned mail: User unknown # Message-Id: <8812021558.AB17631@sun1.lri.fr> # To: mailer@cunyvm # # ----- Transcript of session follows ----- # Connected to sun8: # >># RCPT To: # <<< 550 ... User unknown # 550 stephane... User unknown # # ----- Unsent message follows ----- # Received: by sun1.lri.fr, Fri, 2 Dec 88 16:58:16 +0100 # Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.01) with BSMTP id 3726; Fri, # 02 Dec 88 10:58:29 EDT # Received: from ATHENA by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 02 # Dec 88 10:54:50 EDT # Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28643; Fri, 2 Dec 88 10:54:29 EST # From: # Received: by HAWAII.MIT.EDU (5.45/4.7) id AA06057; Fri, 2 Dec 88 10:54:15 EST # Message-Id: <8812021554.AA06057@HAWAII.MIT.EDU> # To: stephane%frlri61.bitnet@cunyvm.cuny.edu # Date: Fri, 02 Dec 88 10:54:11 EST # Newsgroups: comp.mail.headers,comp.mail.sendmail Subject: Validity check failed - help needed Expires: References: Sender: Reply-To: rd@lri.UUCP () Followup-To: Distribution: world Organization: LRI - Orsay. France. Keywords: Some gateways refuse to forward some messages issued by our site. This problem affects mostly BSMTP error messages. In the following example, some user at MIT.EDU sent a message to some user at our site (FRLRI61.BITNET). The local user name was wrong, so our mailer generated an error message back to the sender, an this message was rejected by CUNYVM. Could someone tell me why ? How does a gateway check the validity of some message ? Thanks a lot in advance. -- Roland Dirlewanger E-mail: rd@lri.fr Universite Paris Sud rd@lri.UUCP Laboratoire de Recherche en Informatique rd@FRLRI61.BITNET Batiment 490 Phone: +33 (1) 69 41 64 01 91405 Orsay Cedex -------------------- Here is the example: # Your mail was not delivered to some or all of its # intended recipients for the following reason(s): # # Validity check failed. # # --------------------RETURNED MAIL FILE-------------------- # Received: from FRLRI61(MAILER) by CUNYVM (Mailer R2.01) id 3865; # Fri, 02 Dec 88 11:11:13 EDT # From: MAILER-DAEMON@FRLRI61.BITNET # Received: by sun1.lri.fr, Fri, 2 Dec 88 16:58:16 +0100 # Date: Fri, 2 Dec 88 16:58:16 +0100 # Subject: Returned mail: User unknown # Message-Id: <8812021558.AB17631@sun1.lri.fr> # To: mailer@cunyvm # # ----- Transcript of session follows ----- # Connected to sun8: # >># RCPT To: # <<< 550 ... User unknown # 550 stephane... User unknown # # ----- Unsent message follows ----- # Received: by sun1.lri.fr, Fri, 2 Dec 88 16:58:16 +0100 # Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.01) with BSMTP id 3726; Fri, # 02 Dec 88 10:58:29 EDT # Received: from ATHENA by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 02 # Dec 88 10:54:50 EDT # Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28643; Fri, 2 Dec 88 10:54:29 EST # From: # Received: by HAWAII.MIT.EDU (5.45/4.7) id AA06057; Fri, 2 Dec 88 10:54:15 EST # Message-Id: <8812021554.AA06057@HAWAII.MIT.EDU> # To: stephane%frlri61.bitnet@cunyvm.cuny.edu # Date: Fri, 02 Dec 88 10:54:11 EST #  Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU 7 Dec 88 15:30:21 EST Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.60+/IDA-1.2.5) id AA11512; Wed, 7 Dec 88 14:30:26 CST Message-Id: <8812072030.AA11512@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 0441; Wed, 07 Dec 88 13:35:33 CST Date: Wed, 07 Dec 88 13:22:54 CST From: Philip Howard Subject: mail analogies To: Header People The analogy of electronic mail to paper mail is a useful one. That model can provide a powerful base upon which to build an excellent mail system. THE FACT IS, IT JUST ISN'T USED. Every time my paper mail passes through a different postal delivery facility, it is NOT opened, NOR does some postal clerk write ON MY LETTER what postal facility processed this. I'm talking about "Received:". On occaision, the post office misdelivers the mail and it is usually detected at the post office of the wrong location. They often stamp the mail and send it on its way to the proper destination. When I have mail forwarded, an address label is added. ALL THIS HAPPENS ON THE ENVELOPE. I GET THE ENVELOPE AND CAN READ IT ALL. In electronic mail as per RFC821/822, this is not the model actually used. RFC821 (the envelope) does not provide for very many things to be written on the envelope. In practice, the electronic mailman also opens my mail for me (although he claims he doesn't read the text) and destroys the envelope. I don't know anything about X.400. Does it use this model? Until the standards for X.400 are public domain and available over the net, I doubt I will ever know.  Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 7 Dec 88 23:41:01 EST Received: from uunet.UU.NET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Wed, 07 Dec 88 23:41:09 EDT Received: from watmath.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA24714; Wed, 7 Dec 88 23:40:56 EST Received: from looking.uucp by watmath; Tue, 6 Dec 88 17:02:49 EST Received: by looking.UUCP (smail2.5) id AA11830; 6 Dec 88 16:54:40 EST (Tue) To: HEADER-PEOPLE%MC.LCS.MIT.EDU@CUNYVM.CUNY.EDU Date: Tue, 6 Dec 88 16:54:39 EST Subject: Re: I would like to see a header Sender-Addressed-To: In-Reply-To: Message from "Leonard D Woren" of Oct 25, 88 at 11:09 pm X-Mailer: Elm [version 1.5] Message-Id: <8812061654.AA11830@looking.UUCP> From: watmath!looking!funny@uunet.UU.NET (Funny Guy) Why not.  Received: from uxc.cso.uiuc.edu (TCP 1201400136) by MC.LCS.MIT.EDU 8 Dec 88 02:28:27 EST Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.60+/IDA-1.2.5) id AA00809; Thu, 8 Dec 88 01:27:21 CST Message-Id: <8812080727.AA00809@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 8704; Thu, 08 Dec 88 01:17:43 CST Date: Thu, 08 Dec 88 01:07:50 CST From: Philip Howard Subject: Re: Validity check failed - What is it ? To: Roland Dirlewanger Cc: Header People In-Reply-To: Your message of 5 Dec 88 10:28:48 GMT The mailer used on most BITNET VM/CMS hosts checks to be sure that the mail FILE originates from the same place that the RFC822 headers CLAIM that it originates. Based on the assumptions that the FILE origin is secure (not so, but more so that RFC822 headers) these are supposed to match. The FILE origin can match FROM: or SENDER: or some others. Alternatively, if the FILE originates from a known mailer (know to send mail in BSMTP format FILES) then such a mailer's file is acceptable no matter what the headers say. It is assumed the other mailer validated it. As postmaster for UIUCVMD.BITNET (=VMD.CSO.UIUC.EDU) I occaisionally see mail being rejected by our mailer just because some new bitnet node started sending mail from a mailer before the table that tells it what other mailers there are is updated to include the new one. In fact, just today I got one of these. I manually checked the table to see if it was known and it was NOT. Since someone from that node asked me about it, I responded to them telling them that their mailer was not known and no database entry existed for it. Whenever you get the validity check, see which BITNET node rejected the mail. The look at the Received: headers and see which BITNET node passed that mail on just before. The latter was unknown to the former.  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 8 Dec 88 09:14:32 EST Received: by INFOODS id <00000F43061@INFOODS.MIT.EDU> ; Thu, 8 Dec 88 09:08:46 EST Date: Thu, 8 Dec 88 08:38:22 EST From: John C Klensin Subject: Re; Sender-addressed-to To: watmath!looking!funny@UUNET.UU.NET X-VMS-Mail-To: EXOS%"watmath!looking!funny@uunet.UU.NET" Message-ID: <881208083822.00000F43061@INFOODS.MIT.EDU> cc: Header-People@MC.LCS.MIT.EDU > From: watmath!looking!funny@uunet.UU.NET > Why not. Because every single one of these do-it-yourself, not-incorporated-into- RFC822, poorly-documented-as-to-exactly-how-it-is-to-be-used, and supported-by-somewhere-between-25%-and-75%-of-hosts-and-mailers header fields... a) Adds confusion. b) Interferes with the proper operation of UAs that really try to validate headers and handle them in a consistent way. c) Considerably increases the network bandwidth needed to carry a trivial message and the amount of spare disk space someone needs to be prepared to receive e-mail. On this last point, consider the number of characters of headers, etc., needed now to transport the message body "why not.". And this message spared us both the common collection of clever "headers" (latitude, longitude, mothers-name, complaints-if-you-dont-like-my-headers,...), and the umpty-line "footers" that draw maps of states, etc. I don't think RFC822 is adequate for the ways in which mail is being used today, don't think that the relationship between 821 and 822 is quite right, don't think that the issues of using 822 for non-Internet MTAs (i.e., without 821) have ever been worked out well, and have a few other problems as well. But "let's add another header to try to paper over the problem" is not a solution. A project to rebuild and redefine 821 and 822, fix the definitions of fields so that their intent and uses was completely clear, and produce new RFCs, might be a good idea. But, practically, that has already been undertaken, and it is called X.400 and MOTIS (in CCITT and ISO, respectively). John Klensin, MIT Klensin@INFOODS.MIT.EDU  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 8 Dec 88 10:14:19 EST Received: by INFOODS id <00000F43063@INFOODS.MIT.EDU> ; Thu, 8 Dec 88 09:40:58 EST Date: Thu, 8 Dec 88 09:15:47 EST From: John C Klensin Subject: Re: mail analogies To: header-people@MC.LCS.MIT.EDU X-VMS-Mail-To: EXOS%"header-people@MC.LCS.MIT.EDU" Message-ID: <881208091547.00000F43063@INFOODS.MIT.EDU> Philip Howard suggests that no one has implemented e-mail the way paper mail works. I partially disagree. Let's keep in mind that any of these analogies, like most of the other analogies in the world, will break down if pushed long enough or hard enough, so I will give up, rather than quibble. Making the analogy "work" depends in part on a careful drawing of the boundaries between user mail software, UA, and MTA. There was a good explanation of this distinction on this list many months ago that I won't try to reproduce. The rest depends on realizing that RFC821/822 were designed, to some degree, around models of office/professional mail, not personal letters. Now, with those comments as background... I don't know how things work in Illinois, but when the MIT person who delivers mail to my office delivers it, he drops it in a pile in front of my secretary. He has not opened any envelopes, and he and his predecessors have annotated them only if there is a problem. Typically, any problem severe enough to require envelope annotation results in returning the mail to the sender, not delivering it, annotated, to me. So far my system is just like the one Phil described, considering the Post Office and that delivery person as the MTA process. That is what they do, and MTAs deal with envelopes. Now, my secretary OPENS THE ENVELOPES, whips out a rubber stamp, and affixes "received" and a date to the TOP OF THE LETTER. If the letter or package arrives in a non-standard way, or is otherwise peculiar, she may add additional annotation. She may even ignore the specific person addressed on the envelope, attach a routing slip with multiple names on it, and circulate the mail internally. The envelope may be discarded in this process, or its information content (postmark date, return address, and any annotations) may be attached to the message text (typically using a high-tech device called a paper clip). She is acting as my agent in doing this, and header-filtering, non-transport header rewriting, and rerouting based on headers (rather than on envelopes) is a User Agent function. Now, I get the message, and I do onto it whatever I do onto messages. If an answer is to go out on paper, I may scribble out (possibly on the computer) the message text and the name of the person the letter is to go to. That text then goes back to my user agent who: a) constructs complete headers (i.e., puts the thing on letterhead and attaches the internal and external addresses). b) constructs an envelope, puts addresses on it and the letter in it. and c) hands the envelope off to the mail transfer system. Finally, if something enters the transport system with our address, but that is not for anyone in our office, it can be intercepted and rejected either by the transport system (MIT's mailroom personnel) or when it gets to us. In either case, the envelope (!) is annotated and returned to the person listed as a "return address" on the envelope. If one of these comes back to us that we've sent someone else, the envelope is opened, the "received" stamp goes on the letter body, and the letter body is annotated (typically by a clipped-on part of the envelope that contains the rejection notice) to indicate that someone should deal with the bad address. That task is routed, by the UA, not by the MTA or the rejecting node, to the right person to straighten out bad mailing list entries (who is often not the message author and, in offices larger than ours, may not be the sender, either).  Received: from NNSC.NSF.NET (TCP 20026200662) by MC.LCS.MIT.EDU 8 Dec 88 14:07:30 EST To: header-people@mc.lcs.mit.edu Subject: RFC 821/822 standards Date: Thu, 08 Dec 88 14:06:41 -0500 From: Craig Partridge Hi folks: Given the recent life (or flames) on this list I thought folks might like an advance look at the upcoming Host Requirements text on using SMTP with RFC 822. (For those who don't know, the Host Requirements document is a sort of profile of what a TCP/IP Host should look like -- a careful walk through the RFCs and varying interpretations). Flames/coments to me, I'll pass them on to the working group. Craig craig@bbn.com or craig@nnsc.nsf.net 5.1 ELECTRONIC MAIL -- SMTP and RFC-822 5.1.1 INTRODUCTION In the TCP/IP protocol suite, electronic mail is exchanged using the Simple Mail Transfer Protocol (SMTP) in the format specified by RFC-822 [5.1:2]. SMTP is defined in RFC-821 [5.1:1]. Over the years, while SMTP has remained unchanged, the Internet community has made several changes in the way SMTP is used. In particular, changes in address formats and the way mail is routed have both been affected by the conversion to domain names. RFC-822 specifies the Internet standard format for electronic mail messages. Since this format is logically independent of the protocol used to transfer the message, RFC-822 is also used in some non-Internet mail environments (e.g., BITNET and CSNET) that use different mail transfer protocols than SMTP. RFC-822 supercedes an older standard, RFC-733, that may still be in use in a few places, although it is obsolete. The two formats are sometimes referred to simply by number (822 and 733). Internet Engineering Task Force [Page 98] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 5.1.2 PROTOCOL WALK-THROUGH This section covers both RFC-821 and RFC-822. The SMTP specification in RFC-821 is clear and contains numerous examples, so implementors should not find it difficult to understand. This section simply updates or annotates portions of RFC-821 to conform with current usage. RFC-822 is a long and dense document, defining a rich syntax. Unfortunately, incomplete or defective implementations of RFC- 822 are common, although nearly all of the many formats are actually used, so that a conforming implementation must recognize and interpret them properly. The reader should be aware that there are errors in the BNF grammar within the text of RFC-822. Use the BNF summary on the last two pages, which is correct. 5.1.2.1 The SMTP Model: RFC-821 Section 2 Mail is sent by a series of request/response transactions between a client, the "sender-SMTP," and a server, the "receiver-SMTP." These transactions pass (1) the message proper, which is composed of header and body, and (2) SMTP source and destination addresses, referred to as the "envelope." In the Internet model for electronic mail, the local file system is used for communication between the SMTP programs that perform inter-host message transfers and the user agent (UA) programs with which users read and compose mail. Thus, the receiver-SMTP is assumed to deliver a message to the target user specified in the envelope by writing the message into a file; for example, it might simply append the message to the user's "mail file." The user will subsequently read the mail from this file by running a UA program. Similarly, to originate mail the user creates a file using the UA program, which passes that file to the sender-SMTP for transmission. The envelope is constructed at the originating site, typically when the message is first queued for transmission by the sender-SMTP program. The envelope addresses may be derived from information in the message header, or supplied by the user interface (e.g., to implement a bcc: request), or derived from local configuration information (e.g., expansion of a mailing list.) The SMTP envelope cannot in general be re-derived from the header at a later hop in the Internet Engineering Task Force [Page 99] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 message transmission path, so the envelope is transmitted separately from the message itself using the MAIL and RCPT commands of SMTP. The text of RFC-821 suggests that mail is to be delivered to an individual user at a host. With the advent of the domain system and of mail routing using mail-exchange (MX) resource records, implementors should now think of delivering to a user at a domain, which may or may not be a particular host. This DOES NOT change the fact that SMTP is a host-to-host mail exchange protocol, and it has no important effect on the correctness of the SMTP model. 5.1.2.2 Canonicalization: RFC-821 Section 3.1 The domain names that a Sender-SMTP sends in MAIL and RCPT commands must have been "canonicalized," i.e., converted to the fully-qualified principal names. These must either name hosts directly or be resolvable into host names using MX records. 5.1.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 A receiver-SMTP must implement VRFY and should implement EXPN. However, it should be possible to disable EXPN in a particular installation, perhaps even selectively by list. DISCUSSION: SMTP users and administrators make regular use of these commands for diagnosing mail delivery problems. EXPN is controversial: it is useful for diagnosing mail loops, but some feel that it represents a significant privacy and perhaps even a security exposure. 5.1.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 The commands to send to a user's terminal (SEND, SOML, and SAML) have never been implemented in most mail systems, and these commands are not generally considered useful in the current Internet environment. 5.1.2.5 HELO Command: RFC-821 Section 3.5 The parameter to a HELO command must be a valid host domain name for the host containing the client SMTP; MX resolution must not be required. Internet Engineering Task Force [Page 100] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 A host may verify that this parameter really corresponds to the IP address of the sender. However, the receiver must not refuse to accept a message, even if the sender's HELO command fails verification. A recommended procedure is to insert a note about the unknown authenticity of the sender into the message header (e.g., in the "Received:" line). DISCUSSION: | Note that verifying the HELO parameter requires a | domain name lookup and may therefore take considerable | time. An alternative tool for tracking bogus mail | sources is suggested below (see "DATA Command".) | 5.1.2.6 Mail Relaying: RFC-821 Section 3.6 SMTP supports the relaying of mail and requires that a return path be constructed in the envelope as the message and envelope are passed along from relay to relay. Specifically, a mail relay host must add a source route to the SMTP return path within the envelope of each message as it is forwarded. For example, if a message sent from user@domain passes through relays X.relay and Y.relay before reaching the final destination, the return path in the envelope will be: @Y.relay,@X.relay:user@domain. The relay must add an appropriate "Received:" line to the header of a message that it forwards, but it should not alter any other header field. We distinguish a mail "relay," which forwards a message within the SMTP mail environment, from a mail "gateway," which passes a message between the SMTP environment and a different environment -- e.g., CSNET or BITNET.) The alternate destinations described by a set of MX records might list a set of SMTP mail relays within the Internet that have agreed to accept mail destined for a particular domain name, or they might point to a mail gateway between two heterogeneous mail environments. The rules for mail gateways are discussed in Section 5.1.3.7. 5.1.2.7 RCPT Command: RFC-821 Section 4.1.1 A host that supports a receiver-SMTP must support the reserved mailbox "Postmaster". Internet Engineering Task Force [Page 101] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 The receiver-SMTP must process RCPT commands as they arrive, rather than after the DATA command has transferred the message. RCPT failures will then be reflected in RCPT responses, not deferred until after message transfer. RCPT responses must not be delayed beyond a reasonable timeout (see Section 5.1.3.2.) For example, if a soft domain system error prevents immediate verification of an RCPT address, validity must be assumed. However, the expansion of a mailing list in a RCPT command should be deferred until after the message has been accepted from the sender-SMTP. DISCUSSION: Expanding a large mailing list may take a very long time. If expansion were not deferred, it would hold up SMTP transactions and perhaps cause spurious timeouts (see Section 5.1.3.2). 5.1.2.8 DATA Command: RFC-821 Section 4.1.1 | It is recommended that the receiver-SMTP supply a | "Received:" line that contains both (1) the name of the | source host as presented in the HELO command and (2) a | domain literal containing the IP address of the source, | determined from the TCP connection. | DISCUSSION: | This may provide enough information for tracking | illicit mail sources, without the overhead of verifying | the HELO information. | 5.1.2.9 SMTP Replies: RFC-821 Section 4.2 | A new reply code is defined for the VRFY command: | 252 Cannot VRFY user (e.g., info is not local), but | will take message for this user and attempt delivery. | A receiver-SMTP must send only the reply codes listed in | section 4.2.2 of RFC-821 or in this document. | A sender-SMTP must be able to recognize any legal reply code, i.e., code that conforms to Appendix E. A sender-SMTP must determine its actions only by the reply code, not by the text; any text, including no text at all, must be acceptable (except for 251 and 551 replies). Internet Engineering Task Force [Page 102] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 However, it is recommended that a receiver-SMTP use the text shown in examples in RFC-821, whenever appropriate. DISCUSSION: Interoperability problems have arisen with SMTP systems using reply codes that are not listed explicitly in RFC-821 Section 4.3 but are legal according to the theory of reply codes explained in Appendix E of that document. The space (blank) following the reply code is considered part of the text. 5.1.2.10 Transparency: RFC-821 Section 4.5.2 Implementors must be sure that their mail systems always add and delete periods to ensure message transparency. 5.1.2.11 WKS Use in MX Processing: RFC-974, p. 5 RFC-974 [5.1:3] recommended that the domain system be queried for WKS records, to verify that each proposed mail target does support SMTP. Later experience has shown that WKS is not widely supported, so the WKS step in MX processing is no longer recommended. The following are notes on RFC-822, organized by section of that document. 5.1.2.12 RFC-822 Time Zones: RFC-822 Section 5 The military time zones are incorrect: they count the wrong way from UT (the signs are reversed). There is a strong trend towards the use of numeric timezone indicators, and implementations should use numeric timezones instead of timezone names. However, all implementations must accept either notation. 5.1.2.13 RFC-822 Syntax Errors: RFC-822 Section 6.1 Errors in formatting or parsing 822 addresses are unfortunately common. This section mentions only the most common errors. A user agent must accept all valid RFC-822 address formats, and should never generate an illegal address syntax. Many systems erroneously use a route-addr, an address Internet Engineering Task Force [Page 103] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 specification within angle brackets such as , without a leading phrase. Of the following examples: From: "Craig Partridge" From: the first "From:" field is legal, but the second is not. Another common error is to leave out the semicolon after a group identifier. Many systems fail to fully-qualify domain names in messages they send out. Headers with illegal "From:" fields like: From: user@cs instead of: From: user@cs.myuniversity.edu are unfortunately common. Finally, many systems mis-parse multiple source routes such as: @relay1,@relay2,@relay3:user@domain. Therefore, it is recommended that this form not be used. The following alternative notation is accepted by many mail systems: user%domain%relay3%relay2@relay1 5.1.2.14 Domain Literals: RFC-822 Section 6.2.3 An Internet mailer must be able to accept and parse a domain literal whose contents ("dtext") are a dotted-decimal host address. This satisfies the requirement of Section 5.0.1 for the case of mail. 5.1.3 SPECIFIC ISSUES 5.1.3.1 SMTP Queueing Strategies The common structure of a host SMTP implementation includes user mailboxes, one or more areas for queueing messages in Internet Engineering Task Force [Page 104] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 transit, and one or more daemon processes for sending and receiving mail. The exact structure will vary depending on the needs of the users on the host and the number and size of mailing lists supported by the host. We describe several optimizations that have proved helpful, particularly for mailers supporting high traffic levels. Any queueing strategy must include: o Timeouts on all activities. See Section 5.1.3.2. o Never sending error messages in response to error messages. 5.1.3.1.1 Sending Strategy The general model of the sender-SMTP is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately must be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information. Retries continue until the message is transmitted or the sender gives up; the give-up time should be at least 4-5 days. The parameters to the retry algorithm must be configurable. When the same message is to be delivered to several users on the same host, only one copy of the message should be transmitted. That is, the sender-SMTP the sender should use the command sequence: RCPT, RCPT,... RCPT, DATA instead of the sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. Implementation of this efficiency feature is strongly recommended. The sender must not immediately retry a particular destination after one attempt has failed. In general, the retry interval should be at least 30 minutes; however, more sophisticated and variable strategies may be beneficial when the sending SMTP can determine the reason for nondelivery. DISCUSSION: Internet Engineering Task Force [Page 105] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 Experience suggests that failures are typically transient (the target system has crashed), favoring a policy of two connection attempts in the first hour the message is in the queue, and then backing off to once every two or three hours. The sender-SMTP can shorten the queueing delay by cooperation with the receiver-SMTP. In particular, if mail is received from a particular address, it is good evidence that any mail queued to send to that host can now be sent. The strategy may be further modified as a result of multiple addresses per host (see Section 5.1.3.4), to optimize delivery time vs. resource usage. A sender should keep a list of hosts it cannot reach and corresponding timeouts, rather than just retrying queued mail items. DISCUSSION: A sender-SMTP may have a large queue of messages for each unavailable destination host, and if it retried all these messages in every retry cycle, there would be excessive Internet overhead and the daemon would be blocked for a long period. Note that an SMTP can generally determine that a delivery attempt has failed only after a timeout of a minute or more; a one minute timeout per connection will result in a very large delay if it is repeated for dozens or even hundreds of queued messages. Similarly, the sender-SMTP may support multiple concurrent outgoing mail transactions to achieve timely delivery. However, some limit should be imposed to protect the host from devoting all its resources to mail. The use of the different addresses of a multihomed host is discussed below. 5.1.3.1.2 Receiving strategy The receiver-SMTP should attempt to keep a pending listen on the SMTP port at all times. This will require the support of multiple incoming TCP connections for SMTP. Some limit may be necessary. When the receiver-SMTP receives mail from a particular Internet Engineering Task Force [Page 106] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 host address, it may notify the sender-SMTP to retry any mail pending for that host address. 5.1.3.2 Timeouts in SMTP Timeouts are an essential feature of an SMTP implementation. If the timeouts are too long (or worse, there are no timeouts), Internet communication failures or software bugs in receiver-SMTP programs can tie up senders indefinitely. If the timeouts are too short, resources will be wasted with attempts that time out part way through message delivery. There are two approaches to timeouts in the sender-SMTP: (a) limit the time for each SMTP command separately, or (b) limit the time for the entire SMTP dialogue for a single mail message. Option (a), per-command timeouts, should be used. DISCUSSION: If option (b) is used, the timeout has to be very large, e.g., an hour, or else it must be a linear function of the size of the message being transmitted. A large fixed timeout leads to two problems: a failure can still tie up the sender for a very long time, and very large messages may still spuriously time out (which is a wasteful failure!). If proportional timing is chosen, it is difficult to determine the proportionality constant. Using the recommended option (a), a timer is set for each SMTP command and for each buffer of the data transfer. The latter means that the overall timeout is inherently proportional to the size of the message. Certain steps in the SMTP dialog may encounter significant delays at the receiver caused by looking up host names, expanding mailing lists, local file system operations, etc. We now present some specific recommendations for per-command timeouts, based on extensive experience with busy mail-relay hosts o Initial 220 Message A Sender-SMTP process must distinguish between a failed TCP connection and a delay in receiving the initial 220 greeting message. Many receiver-SMTPs will accept a TCP connection but delay delivery of the 220 message until their system load will permit more mail to be Internet Engineering Task Force [Page 107] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 processed. Senders should wait at least 5 minutes for the 220 message after the TCP connection is opened. o MAIL Command Senders should wait at least 5 minutes for the reply to a MAIL command. o RCPT Command Senders should wait at least 5 minutes for the reply to a RCPT command. (A longer timeout would be required if processing of mailing lists were not deferred until after the message was accepted). o DATA Initiation Senders should wait at least 2 minutes for the "354 Start Input" reply to a DATA command. o Data Block Senders should wait at least 3 minutes for the acknowledgment of each chunk of transmitted data. o DATA Termination When the receiver gets the final period terminating the message data, it typically performs processing to deliver the message to a user mailbox. A spurious timeout at this point would be very wasteful, since the message has been successfully sent. Senders should wait at least 10 minutes for the "250 OK" reply. A receiver-SMTP should have a timeout of at least 5 minutes while it is awaiting the next command from the sender. 5.1.3.3 Reliable Mail Receipt When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message), it is accepting responsibility for delivering or relaying the message. It should take this responsibility seriously and not lose the message for frivolous reasons, e.g., because the host later crashes or because of a predictable resource shortage. To the extent Internet Engineering Task Force [Page 108] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 possible, the receiver-SMTP should detect conditions that will preclude delivery to individual recipients and generate appropriate error replies to the respective RCPT commands. However, some delivery failures may be unavoidable. For example, it may be impossible for the receiver-SMTP to validate all the delivery addresses before accepting the message; this may happen, for example, because of a soft domain system error or because the target is a mailing list (see earlier discussion of RCPT.) If there is a later delivery failure, the receiver-SMTP must formulate and send error message to the MAIL FROM: address in the envelope (not an address in the message header.) However, if the MAIL FROM: address is null, the receiver-SMTP must not send an error message. A receiver-SMTP must implement some procedure to avoid receiving duplicate messages as the result of timeouts. DISCUSSION: One problem with all timeout schemes is that they aggravate an SMTP protocol problem that may permit duplicate copies of a message to be delivered. The problem comes when the SMTP receiver waits a long time before responding to the final "." that ends a message. Details of the problem and a recommended solution are described in RFC-1047 [5:1.4]. 5.1.3.4 Reliable Mail Transmission To transmit a message, a sender-SMTP will determine the IP address of the target host from the destination address in the envelope. Specifically, it will map the string to the right of the "@" sign into an IP address. This mapping or the transfer itself may fail with a soft error (see Section 6.1.2.3), so a sender-SMTP must be able to requeue outgoing mail when soft errors are encountered and move on to other requests. When it succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of (a) multihoming or (b) multiple MX records (see Section 6.1 below) or both. To provide reliable transmission of mail, the sender-SMTP must be able to rank such a list of IP addresses and to try (and retry) each of the addresses in this list until a delivery attempt succeeds. However, there should also be a configurable limit on the number of alternate addresses that can be Internet Engineering Task Force [Page 109] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 tried. The following information should be used to rank the host addresses: (1) Multiple MX Records -- these contain a preference indication that should be used in sorting the IP addresses. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by address preference), then the SMTP sender should pick one at random to spread the load across multiple mail exchanges for a specific organization; note that this is a refinement of the procedure in [6.1:3]. (2) Multihomed host -- For a multihomed target host, the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface (see Section 6.1.3.3 below) to have ordered this list by decreasing preference. SMTP must try them in the order presented. DISCUSSION: Although the capability to try multiple alternative addresses is required, there may be circumstances where specific installations want to limit or disable the use of alternative addresses. The subject of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counterargument is that it may result in unnecessary resource use. Note that the resource usage is strongly determined also by the sending strategy discussed in Section 5.1.3.1. 5.1.3.5 Domain Name Support SMTP implementations must use the mechanism defined in Section 6.1 for mapping between domain names and IP addresses. This means that every SMTP must include support for the domain name system. In particular, a sender-SMTP must support the MX record Internet Engineering Task Force [Page 110] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 scheme [5.1:3]. See also Section 7.4 of [6.1:2] for information on domain name support for SMTP. 5.1.3.6 Mailing Lists and Aliases An SMTP-capable host should support both the alias and the list form of address expansion for multiple delivery. DISCUSSION: An important mail facility is a mechanism for transforming or "expanding" a pseudo-mailbox address into a list of addresses to obtain multiple delivery of a single message. When a message is sent to such a pseudo-mailbox (sometimes called an "exploder"), copies are forwarded or redistributed to each mailbox in the expanded list. We rclassify such a pseudo-mailbox as an "alias" or a "list", depending upon the expansion rules: (a) Alias To expand an alias, the recipient mailer simply replaces the pseudo-mailbox address in the envelope with each of the expanded addresses in turn; the envelope and the message body are left unchanged. The message is then delivered or forwarded to each expanded address. (b) List To expand a list, the recipient mailer again replaces the pseudo-mailbox address in the envelope with each of the expanded addresses in turn. However, when the message is delivered or forwarded to each expanded address, the return address in the envelope is also changed to be the address of a person who administers the list. The message body is left unchanged and in particular, the "From" field of the message is unaffected. The return address in the envelope is changed so that all error messages generated by the final deliveries will be returned to the list administrator, not to the message originator, who generally has no control over the contents of the list and will typically find error messages Internet Engineering Task Force [Page 111] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 annoying. The list may be said to operate by "redistribution" rather than "forwarding." A useful conceptual model (not necessarily an implementation approach) is this: a mailing list is a UA function, not an SMTP function. Thus, the message is originally delivered into the mailbox of a UA daemon belonging to the mailing list administrator; this UA daemon remails the message to each entry in the list. 5.1.3.7 Mail Gatewaying Gatewaying mail between different mail environments, i.e., different mail formats and protocols, is complex and does not easily yield to standardization. However, some general guidelines may be given for a gateway between the Internet and another mail environment: o It is sometimes necessary to rewrite header fields when messages are gatewayed across mail environment boundaries. DISCUSSION: The other mail systems gatewayed to the Internet generally use a subset of RFC-822 headers. However, they do not have an equivalent to the SMTP envelope. Therefore, when a message leaves the Internet environment, it is generally necessary to fold the SMTP envelope information into the message header. A possible solution would be to create new header fields to carry the envelope information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:".) However, this would require changes in mail programs in the foreign environment. o From the Internet side, the gateway must accept all valid address formats in SMTP commands and in RFC-822 message fields and all valid RFC-822 messages. DISCUSSION: It is often tempting to restrict the range of Internet Engineering Task Force [Page 112] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 addresses accepted at the mail gateway to simplify the translation into addresses for the remote environment. This practice is based on the assumption that mail users have control over the addresses their mailers send to the mail gateway. In practice, however, users have little control over the addresses that are finally sent; their mailers are free to change addresses into any legal RFC-822 format. o The gateway must ensure that all header fields of a message that it forwards into the Internet meet the requirements for Internet mail. In particular, all addresses in "From:", "To:", "Cc:, etc., fields must be transformed (if necessary) to satisfy RFC-822 syntax, and they must be effective and useful for sending replies. o The translation algorithm used to convert mail from the Internet protocols to another environment's protocol must ensure that error messages are delivered to the sender listed in the SMTP envelope, not to the sender listed in the "From:" field of the RFC-822 message. DISCUSSION: Internet mail lists usually place the address of the mail list maintainer in the envelope but leave the original message header intact (with the "From:" field containing the original sender). This yields the behavior the average recipient expects: a reply to the header gets sent to the original sender, not to a mail list maintainer; however, errors get sent to the maintainer (who can do something about problem) and not the sender (who probably does not control the list). 5.1.3.8 Maximum Message Size Note that SMTP does not define a maximum size of a message. Some systems have a practical limitation as low as 10,000 bytes, while other systems can comfortably accept a document of 300,000 bytes or more in a single message. Users are expected to show good judgment when they send large messages. Internet Engineering Task Force [Page 113] ***DRAFT RFC*** APPLICATIONS LAYER -- MAIL November 11, 1988 5.1.4 REFERENCES [5.1:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August 1982. [5.1:2] "Standard For The Format of ARPA Internet Text Messages," D. Crocker, RFC-822, August 1982. This document obsoleted an earlier specification, RFC-733. [5.1:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, January 1986. [5.1:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, February 1988. Internet Engineering Task Force [Page 114]  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Dec 88 18:53:53 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 8 Dec 88 18:47:40 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Dec 88 02:02:49 GMT From: hpda!hpcuhb!hpcilzb!hpcea!marvit@bloom-beacon.mit.edu (Peter Marvit) Organization: HP Corporate Engineering - Palo Alto, CA Subject: Re: Mail header wishlist (was Re: Another example why not to re-route) Message-Id: <1760002@hpcea.CE.HP.COM> References: <1320@ksuvax1.cis.ksu.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu To prevent massive repostings to a distribution list, I use the addres form (described in RFC-822): To: NiceName-of-List: real-address@host, address-alias; I also include a From: List-request@myhost as well as the usual X-Errors-to and anything else I can think of. The above addressing convention works well for small mailing lists as well (inside an organization). -Peter marvit HP Labs  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 10:39:20 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 10 Dec 88 10:23:59 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Dec 88 01:55:36 GMT From: mcmi!hdr!unocss!fritz@uunet.uu.net (Tim Russell) Organization: U. of Nebraska at Omaha Subject: BSD 4.2 Mail not RFC822-compliant? Message-Id: <555@unocss.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Hi all, I recently acquired the MM mailer that Columbia has ported to Unix (it's in beta-test), and discovered a bug, for lack of a better word, in the Berkeley mail program. First off, let me set things up: this is on a Sequent Balance 8000, running Dynix 2.1.1 (BSD 4.2 and System V.2 together). I've also tried this on a Vax 8200 running Ultrix 2.3. Here's the deal: MM sends out messages with "From" headers of the form: From: Real Name which, I have come to find out, is used as an example throughout RFC822. The specific they use is "From: George Jones ". When I send a message out from MM to myself, and read and reply to it, however, Berkeley mail generates an extra, totally wrong, recipient. Here is a log of the Berkeley mail session (thanks to screen): -------------------- Mail version 2.18 5/19/83. Type ? for help. "/usr/spool/mail/fritz": 1 message 1 new >N 1 fritz@unocss.unl.edu Thu Dec 8 19:16 10/241 "Test message." & Message 1: From fritz Thu Dec 8 19:16:19 1988 Date: Thu, 8 Dec 1988 19:15:50 CST From: Tim Russell To: fritz Subject: Test message. Message-Id: Status: R This is a test message to demonstrate. & reply To: unl:fritz@edu fritz@unocss.unl.edu Subject: Re: Test message. -------------------- Notice the "To" line in the reply above? This is, as you can see, nowhere in the original message. According to RFC822, when an address of the form "
" is included in the header line, everything else should be ignored and this should be used as the address. The Ultrix mailer (fergvax.unl.edu) generated this as the "To" line under the same circumstances: To: fritz@fergvax.unl.edu fritz@fergvax.unl.edu Interestingly enough, when I tell MM to put my name in quotes, as in: From: "Tim Russell" neither of the mailers I tried had any problem at all. Wierdness abounds. Also, the problem can be fixed by including a "Reply-To" header, not of the same format, of course. People at Columbia tell me they have never had any problem of this kind. So, can anyone tell me what could be causing this? Is this a common problem? Does Berkeley know about it? Has it been fixed? Sorry for being so verbose, but I wanted to make the problem clear. Thanks for any help anyone can give me! -- ---------------------------------+-------------------------------------------- Tim Russell, Computer Operator | Internet: fritz@fergvax.unl.edu Campus Computing | Bitnet: russell@unoma1 University of Nebraska at Omaha | UUCP: uunet!btni!unocss!fritz  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 15:24:25 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 10 Dec 88 15:16:00 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 10 Dec 88 19:13:58 GMT From: cs.utexas.edu!execu!dewey@ohio-state.arpa (Dewey Henize) Organization: Home for Recalcitrant Hackers Subject: Help requested setting up smart mailer Message-Id: <401@execu.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Hello. With the holiday season coming, I'm going to waste a few hours of my employers time and attempt to get a 'smart' mail system going. I am, however, VERY confused about all this so I'm asking help from those of you that have fought this battle before, so I don't reinvent the wheel. Environment: We have a group of varied machines, including Sun's, Ultrix based Vaxen, HP's and others. We are currently running pretty much plain vanilla senmail, with one Sun handling our UUCP traffic and making mail look like it all comes from there. I have aliases set up such that mail coming into the system gets rerouted to users at the appropriate machines. We use YP on all the systems because of a very low number of system admin types (me, mostly) and a large and very often changing number of hosts. We have an Internet number assiged for us, as execu.com. So far, management hasn't approved the finances for a gateway, so we haven't done much else along that line till we convince them it's needed. It'll happen, but the time frame is flexible. So for now, we have to assume complete dependence on dialout connections. Goal: I'd much like to get our mail setup running a lot smarter. I have a copy of smail and pathalias, and for that matter run a set of maps through pathalias every night. We manually try to determine paths from this output but its not exactly a user friendly way to go about things. I've tried to RTFM but it confuses me. I end up with more questions at the end than I do answers. I keep coming back to the sendmail.cf file and after a bit it looks like I'm going in circles. So, is there anyone with a set of papers that you might be able to send that would help me? One of the biggest goals is that the nasty paths generated by replies to usenet articles would be cleaned up and optimized a bit, but it would also be wonderful if most of my user base could have a simpler, more obvious method of sending mail than trying to look up the address with our shell file and then hopefully typing it in correctly. I'm not looking to aggressively reroute mail passing through. Seems that causes more problems than its worth overall. I WOULD like to reroute the mail that arrives here and dies because of a bad path, and I would like to generate addresses (or restructure addresses) from mail and replies that come from here. I would guess that anything informative enough to help me would be fairly long, so please e-mail to me. I'll keep it all and would be more than willing to pass it on should others so wish. Thanks in advance for any and all help. Dewey Henize Execucom Systems Corp -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | There is nothing in the above message that can't be explained by sunspots. | | execu!dewey Dewey Henize | | Can you say standard disclaimer? I knew you could. Somehow... |  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 17:39:20 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 10 Dec 88 17:24:30 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 10 Dec 88 07:17:09 GMT From: killer!jolnet!stephen@eddie.mit.edu (Stephen Diercouff) Organization: Jolnet, public access Unix, Orland Park (Joliet) IL Subject: Re: From line Message-Id: <53@jolnet.ORPK.IL.US> References: <52@jolnet.ORPK.IL.US> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu sorry-my .signature got left off the last posting. -- Stephen Diercouff uucp: ames!killer!jolnet!mtbaker!stephen uw-beaver!tikal!camco!eskimo!mtbaker!stephen "A nod's as good as a wink to a blind bat." -Monty Python  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 17:39:29 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 10 Dec 88 17:24:56 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 10 Dec 88 07:13:34 GMT From: killer!jolnet!stephen@eddie.mit.edu (Stephen Diercouff) Organization: Jolnet, public access Unix, Orland Park (Joliet) IL Subject: From line Message-Id: <52@jolnet.ORPK.IL.US> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu My mailer inserts the line From ...., which causes no problems, except with one UUCP link, which uses smail. When my mail arrives there, smail does not recognise the From line, and inserts its own line-- From: uucp@mtbaker. My question is, does my mailer have a problem? Should I recompile it, adding the colon after the From , or is the problem with smail. I know that recompiling would work, but i'd rather not fix something that's not broken so it will work with something that is broken. If you respond to this via e-mail, please use one of the paths below. Thanks!  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Dec 88 19:39:36 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 10 Dec 88 19:24:36 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Dec 88 22:20:16 GMT From: sco!keithr@uunet.uu.net (Keith Reynolds) Organization: The Santa Cruz Operation, Inc. Subject: "Errors-To:" header (was Re: Mail header wishlist) Message-Id: <1518@scovert.sco.COM> References: <2696@sultra.UUCP>, <1320@ksuvax1.cis.ksu.edu>, ; Mon, 12 Dec 88 11:38:27 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Dec 88 16:17:40 GMT From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa (Karl Kleinpaste) Organization: OSU Subject: Re: "Errors-To:" header (was Re: Mail header wishlist) Message-Id: References: <1320@ksuvax1.cis.ksu.edu>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu "Errors-To:"? ... So, if the mailing list would put the "request" address in the "Sender" field... Yes, it was pointed out to me (several times!) that Errors-To: is a sendmail-ism; that'll teach me to put something to use which I see `documented' somewhere other than in an RFC. My local generalized mailing list management scheme has been altered to accommodate the use of *both* Errors-To: (to make sendmails happy) and Sender:. --Karl  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Dec 88 13:54:55 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 12 Dec 88 13:50:23 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Dec 88 17:34:18 GMT From: emory!arnold@gatech.edu (Arnold D. Robbins {EUCC}) Organization: Emory University Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <3502@emory.uucp> References: <555@unocss.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <555@unocss.UUCP> fritz@unocss.UUCP (Tim Russell) writes: >From fritz Thu Dec 8 19:16:19 1988 >Date: Thu, 8 Dec 1988 19:15:50 CST >From: Tim Russell >To: fritz >Subject: Test message. >Message-Id: >Status: R > >This is a test message to demonstrate. > >& reply >To: unl:fritz@edu fritz@unocss.unl.edu >Subject: Re: Test message. The problem is that the To: address does not have an "@dom.ain" part. For reasons I was not able to pin down, both the To: and the From: address need to be either fully domain'ed or non-domain'ed ("fritz") but having mixtures produces this problem. /usr/ucb/Mail very badly needs an overhaul; the AT&T folks basically have already done it, and called the result mailx. It is interesting to note that Sun's /usr/ucb/Mail is actually mailx. The way I fixed things was to have my sendmail always put a domain, even on mail from users on the same machine to each other. Mail was just too hard to fix. Sigh. -- Arnold Robbins -- Emory University Computing Center DOMAIN: arnold@unix.cc.emory.edu UUCP: { decvax, gatech, skeeve }!emory!arnold BITNET: arnold@emoryu1 PHONE: +1 404 727-7636 FAX: +1 404 727-2599  Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 12 Dec 88 15:50:40 EST Received: from CCRMA-F4 by SAIL.Stanford.EDU with PUP; 12-Dec-88 12:51 PST Date: 12 Dec 88 1250 PST From: Tovar Subject: Plausible use for "Errors-To:"?? To: Header-People@MC.LCS.MIT.EDU Those of you who have been on this list a very long time might remember my arguing against excess verbosity in headers. I'd say they are now completely out of hand, and something that should only be shown to the user upon request. Having said that, i'd like to give an argument (albeit not one that i could get very excited about) why "Errors-To:" might have legitimate uses. This is not to say that the current use of "Errors-to:" is necessary or appropriate. The combination of From:, To:, Sender:, and Resent-by: and Resent-To:, is probably sufficient for most purposes, at least in an environment largely inhabited by computer knowledgable people. But some folks are better than others at coping with this, and there have been more than one occasion where i would like to get mailer errors for specific users, so that i could help them out, at least to the degree of suggesting an appropriate address or explaining why they're losing, without having to wait until they've given up in frustration. Consider the following scenerio: Suppose an adminstrator, named Lee for purposes of discussion, has a secretary named Jan, and suppose Lynn maintains the mail system for a proverbial organization, say, Widgets, Inc. Now, Jan is great at dealing with microcomputer software, but networks are another matter... So, when Lee asks Jan to send Smith@Cybermumble a message, Lynn would like to also "look over their shoulders" when some sort of mailer error comes back. So Lynn might arrange to have the Jan's default header look something like this: From: widgets!marketing!lee@SBGTWY.Com To: Smith@Cybermumble.Com Sender: widgets!marketing!jan@SBGTWY.Com Errors-to: widgets!marketing!jan@SBGTWY.Com,widgets!marketing!lynn@SBGTWY.Com In this case, both people would get the mailer errors, and it is clear who the messge what from, and who actually sent the message. Obvious, it would not have made sense, from a human's standpoint, to have two addresses in the "Sender:" field, even if other mailers knew what to do about this. If there's some way of getting the same behavior with current setup and still convey reasonable information, i'd like to hear about it. Before flaming at me about this, please remember that i'm very reluctant to have any more cruft added to the header. I just thought the argument was at least interesting. Note that a mail maintainer might be able to hack things to always receive the errors (but perhaps not the message text) destined for certain users, i doubt these can be reliably distinguished from ordinary traffic. -- Tovar  Received: from almsal (TCP 30010712006) by MC.LCS.MIT.EDU 12 Dec 88 16:04:56 EST Date: Mon, 12 Dec 88 14:20:25 CST From: Bob Savacool To: header-people@MC.LCS.MIT.EDU Subject: Remove me from list To whom it may concern, Please remove me from the header-people mailing list. I realy need to shut this off. Bob Savacool cool@almsa-1  Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 12 Dec 88 20:49:11 EST Date: Mon 12 Dec 88 19:47:23-CST From: David Wallace Subject: Domains on local mail? To: emory!arnold@gatech.edu cc: header-people@mc.lcs.mit.edu In-Reply-To: <3502@emory.uucp> Message-ID: <12453956700.58.AI.GUMBY@MCC.COM> Date: 12 Dec 88 17:34:18 GMT From: emory!arnold@gatech.edu (Arnold D. Robbins {EUCC}) The way I fixed things was to have my sendmail always put a domain, even on mail from users on the same machine to each other. Mail was just too hard to fix. Sigh. I don't see what's wrong with that. Let the user's UA worry about removing domains from local addresses (in fact mine reformats most of the headers it chooses to present to me). It's not worth your MTA's worrying about it. Also, consider the case where the user FTPs his/her mail file to another machine and then wants to reply to a message... -------  Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU 12 Dec 88 22:40:21 EST Received: from garnet.berkeley.edu by violet.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17l) id AA08371; Mon, 12 Dec 88 19:39:25 PST Received: by garnet.berkeley.edu (1.2/Ultrix2.0-CFC.13) id AA13888; Mon, 12 Dec 88 19:39:20 pst Date: Mon, 12 Dec 88 19:39:20 pst From: netinfo%garnet.Berkeley.EDU@violet.berkeley.edu (Postmaster & BITINFO) Message-Id: <8812130339.AA13888@garnet.berkeley.edu> To: fritz@fergvax.unl.edu Subject: Re: BSD 4.2 Mail not RFC822-compliant? Cc: header-people@mc.lcs.mit.edu Tim, You are apparently running a very old version of BSD Unix "Mail" (Mail version 2.18 5/19/83). Current BSD 4.3 "Mail" is "UCB Mail Version 5.3 (2/18/88)" I believe the mail "reply" problem was fixed some years ago. Check with the vendors (DEC and Sequent Balance) for fixes. Or upgrade to a BSD 4.3 Unix derived operating system. Bill Wells postmaster@jade.berkeley.edu  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Dec 88 20:36:22 EST Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Tue 13 Dec 88 20:35:43-EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 13 Dec 88 18:14:20 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Dec 88 21:04:29 GMT From: amdahl!fai!ronc@ames.arpa (Ronald O. Christian) Organization: Fujitsu America, Inc. Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <1262@fai.UUCP> References: <555@unocss.UUCP>, <3502@emory.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu >The problem is that the To: address does not have an "@dom.ain" part. >For reasons I was not able to pin down, both the To: and the From: >address need to be either fully domain'ed or non-domain'ed ("fritz") >but having mixtures produces this problem. I just performed the same experiment (Sequent Symmetry running Dynix 3.0.something.... 12, I think) and did not see the problem. >The way I fixed things was to have my sendmail always put a domain, >even on mail from users on the same machine to each other. Yeah, I just looked again, and sendmail at our site does exactly the same thing. My network administrator is not here right now, so I can't say what he might have done (if anything) to fix the problem. I suspect a minor change to sendmail.cf. >/usr/ucb/Mail very badly needs an overhaul; the AT&T folks basically >have already done it, and called the result mailx. The AT&T salesperson pushed mailx really hard as a clean rewrite of berkeley Mail, but our copy (SysV on a Vax 11/780) dumped core randomly and frequently. Perhaps they've come out with something since that works? >It is interesting to >note that Sun's /usr/ucb/Mail is actually mailx. With how much work done by Sun?? At least the network stuff must have been added by Sun -- AT&T has only recently acknowledged the existance of SMTP mail. Ron -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) {amdahl, pyramid, sun, unisoft, uunet}!fai!ronc -or- ronc@fai.com  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 13 Dec 88 21:08:04 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 13 Dec 88 17:36:28 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Dec 88 21:44:42 GMT From: pasteur!helios.ee.lbl.gov!ace.ee.lbl.gov!leres@ames.arpa (Craig Leres) Organization: Lawrence Berkeley Laboratory, Berkeley Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <1463@helios.ee.lbl.gov> References: <555@unocss.UUCP>, <3502@emory.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu (Followups to ... uh ... gee, so many groups to choose from ... uh ... comp.mail.headers, yeah, that's the ticket.) Arnold D. Robbins writes: > For reasons I was not able to pin down, both the To: and the From: > address need to be either fully domain'ed or non-domain'ed ("fritz") > but having mixtures produces this problem. If the recipient is non-local, then all addresses in the message (including the sender) must be domainized. Otherwise, the recipient might have a difficult time replying to the message. Craig  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 DEC 88 23:54:55 EST Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Tue, 13 Dec 88 23:55:05 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 13 Dec 88 22:59:37 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Dec 88 21:59:05 GMT From: oliveb!3comvax!bridge2!auspex!guy@ames.arpa (Guy Harris) Organization: Auspex Systems, Santa Clara Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <698@auspex.UUCP> References: <555@unocss.UUCP>, <3502@emory.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu >The problem is that the To: address does not have an "@dom.ain" part. >For reasons I was not able to pin down, both the To: and the From: >address need to be either fully domain'ed or non-domain'ed ("fritz") >but having mixtures produces this problem. I think part of the problem may be that the 4.2BSD version of Mail got confused by the "." when it constructed the address for the reply; it may think that "." is a Berknet addressing character or something. This may be fixed in the 4.3BSD version. >/usr/ucb/Mail very badly needs an overhaul; the AT&T folks basically >have already done it, and called the result mailx. It is interesting to >note that Sun's /usr/ucb/Mail is actually mailx. It is also interesting to note that a lot of the overhauling of the address-handling portion of Mail wasn't done by AT&T; a much-closer-to-RFC822-compliant version that I did is in the 4.3BSD version of Mail and the S5R3 version of "mailx" (as well as the SunOS 4.0 "Mail"). There are still some holes in it, though.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Dec 88 05:04:30 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 14 Dec 88 04:57:02 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 14 Dec 88 00:43:35 GMT From: auspex!guy@uunet.uu.net (Guy Harris) Organization: Auspex Systems, Santa Clara Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <700@auspex.UUCP> References: <555@unocss.UUCP>, <3502@emory.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu >The problem is that the To: address does not have an "@dom.ain" part. >For reasons I was not able to pin down, both the To: and the From: >address need to be either fully domain'ed or non-domain'ed ("fritz") >but having mixtures produces this problem. I think part of the problem may be that the 4.2BSD version of Mail got confused by the "." when it constructed the address for the reply; it may think that "." is a Berknet addressing character or something. This may be fixed in the 4.3BSD version. >/usr/ucb/Mail very badly needs an overhaul; the AT&T folks basically >have already done it, and called the result mailx. It is interesting to >note that Sun's /usr/ucb/Mail is actually mailx. I don't know that "mailx" is a complete overhaul; they added a bunch of stuff, and may have cleaned up some things, but one thing they didn't touch was the address parsing. The 4.2BSD "Mail" and S5R2 "mailx" had a parser that claimed to be an RFC733 parser; the 4.3BSD "Mail" and S5R3 "mailx" picked up an updated parser I did that claims to be an RFC822 parser, although there are still some holes in it. The generation of "unl:fritz@edu" is, I suspect, due to the problem I cited above. However, the SunOS 4.0 "Mail", which is derived from the S5R2 "mailx" but has a bunch of 4.3BSD "Mail" and other fixes, including my updated parser, still generates two "fritz@unocss.unl.edu" in the "To:" line when you do "replyall".  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Dec 88 16:04:54 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 14 Dec 88 15:52:50 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 14 Dec 88 17:57:18 GMT From: oliveb!3comvax!bridge2!auspex!guy@ames.arpa (Guy Harris) Organization: Auspex Systems, Santa Clara Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <705@auspex.UUCP> References: <555@unocss.UUCP>, <3502@emory.uucp>, <1262@fai.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu >The AT&T salesperson pushed mailx really hard as a clean rewrite of berkeley >Mail, but our copy (SysV on a Vax 11/780) dumped core randomly and frequently. >Perhaps they've come out with something since that works? Calling "mailx" a "rewrite" of "Mail" is incorrect. The S5R2 "mailx" is basically an *enhanced* version of a "Mail" of somewhere between 4.1BSD and 4.2BSD vintage; the stuff they added is obviously new, but the 4.xBSD-derived stuff is pretty much unchanged. The S5R3 one may have changed more, but I still wouldn't call it a "rewrite". >>It is interesting to >>note that Sun's /usr/ucb/Mail is actually mailx. > >With how much work done by Sun?? At least the network stuff must >have been added by Sun -- AT&T has only recently acknowledged the >existance of SMTP mail. Basically, stuff from the 4.2BSD (and, later, 4.3BSD) "Mail" was merged back into the S5R2 "mailx" to make the SunOS "Mail". Among the stuff merged back was the use of "sendmail" to actually deliver mail, hence the support for SMTP or anything else you get "sendmail" to support. A bunch of other miscellaneous stuff was added as well.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 04:49:34 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 15 Dec 88 04:25:54 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Dec 88 03:15:41 GMT From: pyramid!csg@lll-lcc.llnl.gov (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <51056@pyramid.pyramid.com> References: <555@unocss.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <555@unocss.UUCP> fritz@unocss.UUCP (Tim Russell) writes: >... and discovered a bug, for lack of a better word, in the Berkeley mail >program. > >... this is on a Sequent Balance 8000, running Dynix 2.1.1.... To make a long story short, this is little a bug in the 4.2BSD version of Mail. Get your machine upgraded to Dynix 3.n, which uses the 4.3BSD version of Mail.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 06:19:40 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 15 Dec 88 06:04:33 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 14 Dec 88 11:27:38 GMT From: agate!saturn!ssyx.ucsc.edu!ulmo@labrea.stanford.edu (Brad Allen) Subject: Is dot valid in address for indicating absolute domain name? Message-Id: <5765@saturn.ucsc.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Is "foo.baz.org." with the trailing dot mentioned in an RFC? Is it supposed to be standard? Is it a standard? Who likes it? Should it be used? It denotes absolute (nonrelative) addressing to the local systems I use when using a few of the net facilities. (I have no affiliation, so ignore any implied organization)  Received: from gaak.LCS.MIT.EDU (TCP 2206400041) by MC.LCS.MIT.EDU 15 Dec 88 08:22:39 EST Received: by gaak.LCS.MIT.EDU id AA22958; Thu, 15 Dec 88 08:22:22 EST Date: Thu, 15 Dec 88 08:22:22 EST From: map@gaak.LCS.MIT.EDU (Michael A. Patton) Message-Id: <8812151322.AA22958@gaak.LCS.MIT.EDU> To: agate!saturn!ssyx.ucsc.edu!ulmo@labrea.stanford.edu Cc: header-people@mc.lcs.mit.edu In-Reply-To: (Brad Allen's message of 14 Dec 88 11:27:38 GMT <5765@saturn.ucsc.edu> Subject: Is dot valid in address for indicating absolute domain name? Trailing dots and other artifacts like that to the right of the @ are covered by the Domain Name System RFC sequence (1031-1035). RFC1033 mentions the two forms at the top of page 4 as a convention for the actual Domain data files, RFC1034 discusses this topic on page 8 as a user-interface issue, and RFC1035 revisits the discussion from RFC1033 in greater detail on page 34. In general your observation is correct, names ending in dot are complete and absolute while names without a trailing dot are relative (subject to extension). This is purely a question of external (i.e. in text) representation, the internal representations are always absolute. If a routine reading in a domain is presented with a relative name, it should extend it in whatever way is appropriate. In the case of a zone file for the DNS the extension is a previously given domain, for the more general user-interface (and this is the part that applies to mail headers, this group is about mail headers, remember :-) the name "should be completed by local software using knowledge of the local domain." They are "taken relative ... to a list of domains used as a search list. ... The most common interpretation uses the root `.' as either the single originor as one of the members...so a multi-label relative name is often one where the trailing dot has been omitted to save typing." [all quotes (except the atrocious takeoff on Alice's Restaurant) from RFC1034 page 8] As far as I know, there are only a few (or less, maybe even no :-) implementations that actually implement the "search list" operation in the right way. The most common is to try the local domain and root as the only extensions, and frequently only one of these based on whether there are already dots. I hope this information has been helpful to you. It is not complete in the minutae and not guaranteed to stay correct even long enough for the mail to reach you. The DNS is a moving target and this is one of the areas in the spec that people are flexing on to see what can be done as the spec stands and what is useful to be done that can't within the current spec. The simple general statement you made is (and is expected to stay) what the user sees of the operation. __ /| /| /| \ Mike Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology MAP@LCS.MIT.Edu, PostMaster@LCS.MIT.Edu, BUG-LCS-Domain@LCS.MIT.Edu, etc. Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 11:34:35 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 15 Dec 88 11:28:48 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Dec 88 15:57:45 GMT From: cs.utexas.edu!fletcher@ohio-state.arpa (Fletcher Mattox) Organization: U. Texas CS Dept., Austin, Texas Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <4352@cs.utexas.edu> References: <555@unocss.UUCP>, <51056@pyramid.pyramid.com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <51056@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >To make a long story short, this is little a bug in the 4.2BSD version of >Mail. Get your machine upgraded to Dynix 3.n, which uses the 4.3BSD version >of Mail. To make a short story (slightly) more accurate, n > 0.4. DYNIX 3.0.4 still uses the the 4.2 Mail. Fletcher  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 13:35:49 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 15 Dec 88 13:25:58 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Dec 88 16:51:11 GMT From: cfe+@andrew.cmu.edu (Craig F. Everhart) Organization: Carnegie Mellon Subject: Re: Is dot valid in address for indicating absolute domain name? Message-Id: References: <5765@saturn.ucsc.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I believe that it's mentioned in the domain-system specs, which for interchange purposes don't care if a name is suffixed with a dot or not. Some programs that act as user agents for the domain system use it to know whether to try appending local suffixes or not; I don't believe that that usage is anywhere in an RFC. One place that it's NOT is in RFC821 or RFC822; the mail address ``foo@bar.baz.'' is invalid RFC822. You can't append a dot to an RFC822 domain without invalidating it as an RFC822 domain. Craig Everhart  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 15 Dec 88 14:58:34 EST Date: Thu, 15 Dec 1988 14:54 EST Message-ID: From: Rob Austein To: agate!saturn!ssyx.ucsc.edu!ulmo@LABREA.STANFORD.EDU (Brad Allen) Cc: header-people@MC.LCS.MIT.EDU Subject: Is dot valid in address for indicating absolute domain name? The trailing dot stuff was added to the DNS between the first and second specifications (ie, between RFCs 882-883 and 1034-1035). The first I recall hearing of it was in a mail message from Paul Mockapetris on Namedroppers in response to people who claimed that the DNS had no provision for this kind of thing. DNS internal representations don't have any dots at all. RFC 821/822 compliant mailsystems MUST NOT put trailing dots in outgoing messages (disallowed by the BNF). It's ok for your mail composer/reader to use the syntax but the name must be cannonicalized before it escapes your machine. The TOPS-20 resolver code supports the trailing dot stuff along with per-site search paths (per-user would have been a real bear on TOPS-20, although Noel Chiappa came up with a cute idea for the basic mechanism). The TOPS-20 mailer cannonicalizes all hostnames anyway. I am not aware of any other implemntations that support the trailing dot syntax in their user interface (all implementations support it in master files, for self-preservation); I'd be interested in hearing about ones that do. --Rob  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Dec 88 23:05:04 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 15 Dec 88 23:02:28 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Dec 88 10:24:41 GMT From: mcvax!hp4nl!htsa!hanst@uunet.uu.net (Hans Trompert) Organization: AHA-TMF (Technical Institute), Amsterdam, Netherlands Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <668@htsa.uucp> References: <555@unocss.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <555@unocss.UUCP>, fritz@unocss.UUCP (Tim Russell) writes: > Hi all, > > I recently acquired the MM mailer that Columbia has ported to Unix > (it's in beta-test), and discovered a bug, for lack of a better word, > in the Berkeley mail program. > > First off, let me set things up: this is on a Sequent Balance 8000, > running Dynix 2.1.1 (BSD 4.2 and System V.2 together). I've also tried > this on a Vax 8200 running Ultrix 2.3. Greetings, We too have a Sequent Balance 8000, and we are running Dynix V3.0.4. We have never used the original mail, because we were told there are many problems using RFC822 mail headers. So we use RSMTP instead (originally written by Jack Jansen CWI Amsterdam Netherlands, uunet!mcvax!piring!jack or jack@cwi.nl). RSMTP (Realy Simple Mail Transfer Program) pretends to understand internet addresses, but what it does is just converting these addresses to uucp-like addresses: jack@cwi.nl becomes cwi.nl!jack. Installing RSMTP is rather straight forward, a manual is included, but you can also ofcourse examine the sources. For those who are interested we are willing to post those sources. Hans Trompert HTS "A" Amsterdam Netherlands --> hanst@htsa.uucp --> uunet!mcvax!htsa!hanst  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Dec 88 16:23:38 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 27 Dec 88 16:14:35 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 27 Dec 88 20:30:35 GMT From: rochester!uhura.cc.rochester.edu!msir@rutgers.edu (Mark Sirota) Organization: Univ. of Rochester, Computing Center Subject: Simple form of RFC 822? Message-Id: <569@ur-cc.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm writing a sendmail.cf for the University of Rochester, and I'm sitting here reading through RFC 822 to see if I missed any legal address-forms. Now, those of you who have tried to read RFC 822 before will hopefully agree that this is a difficult document to read. What I'm looking for is a relatively simple list of legal address-specifications in human-readable form (unlike RFC 822). Anyone have such a beast? -- Mark Sirota - University of Rochester, Rochester, NY Internet: msir@cc.rochester.edu Bitnet: msir_ss@uordbv.bitnet UUCP: ...!rochester!ur-cc!msir  Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 28 Dec 88 16:58:38 EST Received: from TWG.COM by twg.com with SMTP ; Wed, 28 Dec 88 13:24:35 PST Received: from obelix by Obelix.TWG.COM id aa05526; 28 Dec 88 15:25 PST Reply-To: James M Galvin To: Mark Sirota cc: header-people@mc.lcs.mit.edu Subject: Re: Simple form of RFC 822? In-reply-to: Your message of 27 Dec 88 20:30:35 GMT. <569@ur-cc.UUCP> Date: Wed, 28 Dec 88 13:25:47 -0800 Message-ID: <5524.599347547@twg.com> From: James M Galvin > What I'm looking for is a relatively simple list of legal > address-specifications in human-readable form (unlike RFC 822). Anyone > have such a beast? The answer may be simpler than you think. If you are writing it for your own machine, the only things you have to worry about are the addresses you understand. So, if you are an Internet host, the only addresses you have to understand are those with an "@" in them. If they don't have that, they are malformed. Now you have to decide if your are going to reject it, assume it is local and try to deliver, or push it off to a gateway. Similar statements can be made about other networks. Assuming it is local may be too generous, so you may wish to check for other "delimiter characters" (eg "!:") and then reformat and repeat. That, of course, is your original question. My position is, is it really necessary to be overly generous? Given that fully qualified host names are a necessity, must the mail system have all of the complexity needed to "clean up" after its users? I think it is time we forced some knowledge back onto the users. Require them to enter syntactically correct addresses. You may think I am cynical, but I seriously pose the question, "why be generous?" Comments and thoughts are solicited. Jim  Received: from uhura.cc.rochester.edu (TCP 20045760021) by MC.LCS.MIT.EDU 28 Dec 88 17:49:11 EST Received: by uhura.cc.rochester.edu id AA20958 (3.2wj3); Wed, 28 Dec 88 17:44:34 EST Message-Id: <8812282244.20958@uhura.cc.rochester.edu> Date: Wed, 28 Dec 88 17:44:34 EST From: msir@uhura.cc.rochester.edu (Mark Sirota) Reply-To: msir@cc.rochester.edu X-Mailer: Mail User's Shell (6.4 12/27/88) To: James M Galvin Subject: Re: Simple form of RFC 822? Cc: header-people@mc.lcs.mit.edu >> What I'm looking for is a relatively simple list of legal >> address-specifications in human-readable form (unlike RFC 822). Anyone >> have such a beast? > > The answer may be simpler than you think. If you are writing it for your > own machine, the only things you have to worry about are the addresses you > understand. Except that there's this thing called a standard, currently defined by RFC-822. All mailers on the internet should handle any address specified by this standard. > My position is, is it really necessary to be overly generous? Given that > fully qualified host names are a necessity, must the mail system have all > of the complexity needed to "clean up" after its users? I think it is > time we forced some knowledge back onto the users. Require them to enter > syntactically correct addresses. Oh, I agree absolutely. The mailer shouldn't have to figure out what the user meant; it should just bounce bad addresses. However, what I was looking for was the definition of a bad address (or, more particularly, the definition of a good address). Mark -- Mark Sirota - University of Rochester, Rochester, NY Internet: msir@cc.rochester.edu Bitnet: msir_ss@uordbv.bitnet UUCP: ...!rochester!ur-cc!msir  Received: from gaak.LCS.MIT.EDU (TCP 2206400041) by MC.LCS.MIT.EDU 28 Dec 88 17:56:03 EST Received: by gaak.LCS.MIT.EDU id AA29279; Wed, 28 Dec 88 17:54:24 EST Date: Wed, 28 Dec 88 17:54:24 EST Message-Id: <8812282254.AA29279@gaak.LCS.MIT.EDU> To: galvin@twg.com From: MAP@lcs.mit.edu Sender: map@gaak.LCS.MIT.EDU Cc: msir@cc.rochester.edu, header-people@mc.lcs.mit.edu In-Reply-To: James M Galvin's message of Wed, 28 Dec 88 13:25:47 -0800 <5524.599347547@twg.com> Subject: Re: Why process non-RFC822 style addresses Date: Wed, 28 Dec 88 13:25:47 -0800 From: James M Galvin [...] My position is, is it really necessary to be overly generous? Given that fully qualified host names are a necessity, must the mail system have all of the complexity needed to "clean up" after its users? I think it is time we forced some knowledge back onto the users. Require them to enter syntactically correct addresses. You may think I am cynical, but I seriously pose the question, "why be generous?" Because my users have no control over what will be handed them on incoming mail and thus used in a "Reply" command in the mailer. If I could somehow ensure that incoming messages had valid Internet addresses in all the appropriate fields (To:, From:, Reply-To:, etc.) then it wouldn't be a problem. The users are frequently not sophisticated enough to fix these up when they occur, if the mailer can make a guess that's right 75% of the time that reduces (by greater than 75% :-) the number of times I get calls about not being able to reach someone. If all the gateways would translate to valid RFC822, there wouldn't be a problem. But many of them don't (for various reasons, that's a whole 'nother can of worms I don't really want to open) and I am forced to deal with them, if I can do it automatically then I save myself work. Comments and thoughts are solicited. Jim __ /| /| /| \ Mike Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology PostMaster@LCS.MIT.Edu, Bug-LCS-Domain@LCS.MIT.Edu, MAP@LCS.MIT.Edu Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-)  Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 28 Dec 88 19:00:27 EST Received: from TWG.COM by twg.com with SMTP ; Wed, 28 Dec 88 15:45:03 PST Received: from obelix by Obelix.TWG.COM id aa06679; 28 Dec 88 17:46 PST Reply-To: James M Galvin To: MAP@lcs.mit.edu cc: msir@cc.rochester.edu, header-people@mc.lcs.mit.edu Subject: Re: Why process non-RFC822 style addresses In-reply-to: Your message of Wed, 28 Dec 88 17:54:24 EST. <8812282254.AA29279@gaak.LCS.MIT.EDU> Date: Wed, 28 Dec 88 15:46:27 -0800 Message-ID: <6675.599355987@twg.com> From: James M Galvin > Because my users have no control over what will be handed them on > incoming mail and thus used in a "Reply" command in the mailer. If I > could somehow ensure that incoming messages had valid Internet > addresses in all the appropriate fields (To:, From:, Reply-To:, etc.) > then it wouldn't be a problem. I agree that "gateways" may need more knowledge than the average host in a given local environment. But why not reject incoming mail that does not have valid Internet addresses? Oops, touched a nerve no doubt. There are two sets of addresses: those in the "envelope" as transported and managed by SMTP, and those in the message, more specifically in the headers of the message. Dare gateways touch the addresses in the headers as the message passes by to ensure replyability? Maybe the delivery process should just include the envelope addresses in the message when it is delivery, ie modify the message itself. Wait, I heard of that before; it is called "return-path". So why don't more user agents make use of it? ... The basic problem is electronic mail is a service. I do the best I can to provide a "good" service to my clients, someone else does the best he can to provide a "good" service and yet another person does the best she can to provide a "good" service. The trouble is that leaves us right where we started. It is time to start educating the users to educate their system administrators to change the fundamental principles upon which the mail service is based. Rather than each administrator being in his/her own world and compensating for the rest of the world, we have to start doing it right. Anyone disagree? Jim  Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 28 Dec 88 19:08:23 EST Received: from TWG.COM by twg.com with SMTP ; Wed, 28 Dec 88 15:31:03 PST Received: from obelix by Obelix.TWG.COM id aa06570; 28 Dec 88 17:32 PST Reply-To: James M Galvin To: msir@cc.rochester.edu cc: header-people@mc.lcs.mit.edu Subject: Re: Simple form of RFC 822? In-reply-to: Your message of Wed, 28 Dec 88 17:44:34 EST. <8812282244.20958@uhura.cc.rochester.edu> Date: Wed, 28 Dec 88 15:32:31 -0800 Message-ID: <6567.599355151@twg.com> From: James M Galvin > Except that there's this thing called a standard, currently defined by > RFC-822. All mailers on the internet should handle any address specified > by this standard. > However, what I was > looking for was the definition of a bad address (> or, more particularly, > the definition of a good address). You answered your own question, didn't you? But then, you originally asked for someone to explain in English what is a valid address, or at least to provide a set of examples of valid addresses. Well, 822 has an appendix of example addresses. To expand on that and offer some English rules, how about these for a start: 1. internet address must have an "@" in it, if not it is a local address. 2. "@" usage is either LOCAL@HOST1 or @HOST1,@HOST2,@HOST3:LOCAL. Determine which and deliver to HOST1. 3. Beware of quoted "@"'s. Jim  Received: from uhura.cc.rochester.edu (TCP 20045760021) by MC.LCS.MIT.EDU 28 Dec 88 21:18:29 EST Received: by uhura.cc.rochester.edu id AA22873 (3.2wj3); Wed, 28 Dec 88 21:15:43 EST Message-Id: <8812290215.22873@uhura.cc.rochester.edu> Date: Wed, 28 Dec 88 21:15:43 EST From: msir@uhura.cc.rochester.edu (Mark Sirota) Reply-To: msir@cc.rochester.edu X-Mailer: Mail User's Shell (6.4 12/27/88) To: James M Galvin , MAP@lcs.mit.edu Subject: Re: Why process non-RFC822 style addresses Cc: header-people@mc.lcs.mit.edu In message <6675.599355987@twg.com> James M Galvin writes: > It is time to start educating the users to educate their system > administrators to change the fundamental principles upon which the mail > service is based. Rather than each administrator being in his/her own > world and compensating for the rest of the world, we have to start doing it > right. This is all well and good, but it seems to contradict what you said earlier. There exists a decent standard, which, assuming it's used properly, should work well. So, rather than each of doing it however we feel, we should adhere to the standard. I believe you were the one who said: > If you are writing it for your own machine, the only things you have to > worry about are the addresses you understand. Perhaps I'm misunderstanding what you meant by that, but it sounds like you meant "wing it and make your users happy". Mark -- Mark Sirota - University of Rochester, Rochester, NY Internet: msir@cc.rochester.edu Bitnet: msir_ss@uordbv.bitnet UUCP: ...!rochester!ur-cc!msir  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 29 Dec 88 08:54:39 EST Received: by INFOODS id <00002752061@INFOODS.MIT.EDU> ; Thu, 29 Dec 88 08:48:45 EST Date: Thu, 29 Dec 88 08:35:50 EST From: John C Klensin Subject: RE: Re: Simple form of RFC 822? To: James M Galvin X-VMS-Mail-To: EXOS%"James M Galvin " Message-ID: <881229083550.00002752061@INFOODS.MIT.EDU> cc: header-people@MC.LCS.MIT.EDU James M Galvin writes: > ... > To expand on that and offer some English rules, how about >these for a start: >1. internet address must have an "@" in it, if not it is a local address. >2. "@" usage is either LOCAL@HOST1 or @HOST1,@HOST2,@HOST3:LOCAL. Determine > which and deliver to HOST1. >3. Beware of quoted "@"'s. I hope this is not what TWG is doing, because the second example in (2) is twice illegal: (a) <@host1,@host2:local@host3> may not appear without the bracketing <...> (b) The syntax <@hostn,@hostm:local> is illegal: there must be a domain name for the local address, i.e., <@host1,@host2:local@host3> In addition, it is in poor taste and probably a violation of the protocols to generate a "reply" address by using the Reverse-path. The only reasonable rule for a gateway to follow (with the understanding that some don't) is to have only legal internet addresses appear on the Internet. That means, in part, that any *address* appearing in an RFC-822 header on the Internet side of a gateway must be in Internet form and that all of the strings that are in the form @hostN above must be valid (registered/resolvable) domain names.  Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 29 Dec 88 11:28:19 EST Received: from TWG.COM by twg.com with SMTP ; Thu, 29 Dec 88 08:03:41 PST Received: from obelix by Obelix.TWG.COM id aa12368; 29 Dec 88 10:05 PST Reply-To: James M Galvin To: John C Klensin cc: header-people@mc.lcs.mit.edu Subject: Re: Simple form of RFC 822? In-reply-to: Your message of Thu, 29 Dec 88 08:35:50 EST. <881229083550.00002752061@INFOODS.MIT.EDU> Date: Thu, 29 Dec 88 08:05:05 -0800 Message-ID: <12366.599414705@twg.com> From: James M Galvin > I hope this is not what TWG is doing, because the second example in (2) > is twice illegal: No, we are definitely not doing this. They were offered as a suggested starting point, not complete solutions. The 2 comments you made are certainly correct. > In addition, it is in poor taste and probably a violation of the > protocols to generate a "reply" address by using the Reverse-path. Not true. The standard only requires that automatically generated address lists use the from/sender/reply-to, at a minimum. The return-path is intended to indicate a route back to the originator. There are no other restrictions on what a user agent provides. > The > only reasonable rule for a gateway to follow (with the understanding > that some don't) is to have only legal internet addresses appear on the > Internet. I agree, and my position is why should I at my site have to make up for improper gateways. I am suggesting that users should be required to begin to understand the complexities and thus pressure can be brought to bear to fix things. Note that I am not saying anything new. This discussion has gone on here and elsewhere many times before. I am beginning to feel much more strongly about it as a result of the recent Internet worm. I think that we should stop trying to be so "smart" everywhere, leaving the "smarts" in as few places as possible. Thus, stripped down sendmail configuration files should be available, and used much more often than what is currently distributed. Jim  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 Jan 89 17:28:08 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 7 Jan 89 17:09:51 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Jan 89 20:33:50 GMT From: cs.utexas.edu!execu!dewey@husc6.harvard.edu (Dewey Henize) Organization: Home for Recalcitrant Hackers Subject: Still trying to get smart routing working. Message-Id: <412@execu.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I posted about 3 weeks ago that I was trying to convert our systems to using smail and do some semi-intelligent routing... Well, so far it hasn't gone too well. I still have quite a list of folks that are also interested if I can figure out the problems, but the amount of solid info has been, uh, sparse. Smail seems to compile pretty well, but I'm running into real problems with the sendmail.cf file. We're a bsd (Sun 4.0.broken) site for a main server, and a lot of dec and sun and other machines around besides that. It appears that perhaps the sendmail.cf file is not reading the /etc/hosts file at all. Pathalias seems to be going ok, we run it every night and use the add'l tools to reformat for use by smail, etc. Some basic questions... Our alias file is, as Sun recommends, of the form fred: fred@execu joe: joe@prickleypear ...etc... Is this the right form for smail/sendmail? Should there be more/less info in there? The sendmail.cf from Sun seems to be messed up, at least according to the docs I read in one of the Sun manuals. Supposedly (no, I'm not a guru, not even close) the construct for a rhs of $:$>8 should direct more processing to ruleset 8 - but there isn't a S8 in the file... duh? Again, if anyone has any ideas that could help, please send them to me. And please don't worry about repeating what you think someone else would have surely said - they didn't, and if they do I'll STILL appreciate the info and confirmation. Final note - is anyone aware of a program called [perhaps] 'ease' for use in generating config files? I tried to look it up, but I don't see it anywhere in the indexes I've downloaded. Thanks Dewey Henize -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | There is nothing in the above message that can't be explained by sunspots. | | execu!dewey Dewey Henize | | Can you say standard disclaimer? I knew you could. Somehow... |  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 Jan 89 22:42:58 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 7 Jan 89 22:28:10 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 6 Jan 89 17:35:54 GMT From: mcvax!enea!kth!draken!chalmers!cs.chalmers.se!lindberg@uunet.uu.net (Gunnar Lindberg) Organization: Dept. of CS, Chalmers, Sweden Subject: Re: BSD 4.2 Mail not RFC822-compliant? Message-Id: <2820@fnatte.cs.chalmers.se> References: <555@unocss.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <555@unocss.UUCP> fritz@unocss.UUCP (Tim Russell) writes: > ... >From: Tim Russell >To: fritz > >& reply >To: unl:fritz@edu fritz@unocss.unl.edu I hope I haven't missed the point completely, but this used to happen here too. It seems like the routine "map()" in "src/ucb/Mail/names.c" does a lot of funny things with reply addresses, so we simply replaced it with a "return;" (well, its content, of course). What "map()" was really supposed to do I still don't know... Gunnar Lindberg  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Jan 89 06:27:58 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 8 Jan 89 06:07:39 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Jan 89 10:50:50 GMT From: nic.MR.NET!xanth!wisner@csd4.milw.wisc.edu (Bill Wisner) Organization: Old Dominion University, Norfolk Va. Subject: Re: Still trying to get smart routing working. Message-Id: <7094@xanth.cs.odu.edu> References: <412@execu.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <412@execu.UUCP> dewey@execu.UUCP (Dewey Henize) writes: >Our alias file is, as Sun recommends, of the form >fred: fred@execu >joe: joe@prickleypear >...etc... Sounds bogus to me. If fred and joe are real accounts that want to receive mail on another machine, give them .forward files. If they're not real accounts and you're setting up forwarding addresses, disregard this paragraph. >Is this the right form for smail/sendmail? The form is fine. Smail knows how to grok Sendmail's alias file format. >The sendmail.cf from Sun seems to be messed up, at least according to the docs >I read in one of the Sun manuals. Supposedly (no, I'm not a guru, not even >close) the construct for a rhs of $:$>8 should direct more processing to >ruleset 8 - but there isn't a S8 in the file... duh? If there is no ruleset 8, Sendmail will ignore that rule. >Final note - is anyone aware of a program called [perhaps] 'ease' for use in >generating config files? I tried to look it up, but I don't see it anywhere >in the indexes I've downloaded. Ease is a language reminiscent of C that you can use to specify a sendmail.cf file. The Ease program converts a file written in the Ease language into a sendmail.cf that can be digested by Sendmail. And now I wax religious: I dislike Ease. That puts me into a minority. Learning an entire new language just to keep one's mailer configured is ridiculous. Sendmail rules are simply pattern match-and-replaces. The syntax involved is actually easy to learn. The interactions between rulesets are also straightforward. The difficulty lies in knowing, in excruciating step-by-step detail, every trifling little action that must be taken to get Sendmail to deliver a message. Writing one's configuration in a different format won't change that. Ease is a waste of time. If you remain unconvinced and want to try Ease yourself, it's available from a comp.sources.unix archive. But it's still a waste of time. Bill, the man from Xanth  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Jan 89 19:58:07 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 8 Jan 89 19:43:13 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Jan 89 23:36:20 GMT From: vixie@decwrl.dec.com (Paul A Vixie) Organization: DEC Western Research Lab Subject: Re: Still trying to get smart routing working. Message-Id: References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [Wisner] # And now I wax religious: # # I dislike Ease. [...] I agree with most of your conclusions about Ease. However, I recommend that anyone interested in understanding sendmail's raw configuration language get Ease, read all of its documentation, and play with it for a week. This is how I finally learned enough about sendmail.cf to write one from scratch. I might have stayed with Ease if it had made multi-line strings possible; my "Received:" headers spanned a physical newline and the grammar that came with Ease at that time would have taken massive hacking to make that possible. Also, Ease cannot generate the extensions used by IDA. No fault on the part of its implementors, since IDA didn't exist when Ease was first conceived. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Jan 89 19:58:18 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 8 Jan 89 19:43:41 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Jan 89 23:31:27 GMT From: vixie@decwrl.dec.com (Paul A Vixie) Organization: DEC Western Research Lab Subject: Re: Still trying to get smart routing working. Message-Id: References: <412@execu.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [Henize] # Smail seems to compile pretty well, but I'm running into real problems with # the sendmail.cf file. We're a bsd (Sun 4.0.broken) site for a main server, # and a lot of dec and sun and other machines around besides that. It # appears that perhaps the sendmail.cf file is not reading the /etc/hosts # file at all. # [...] # The sendmail.cf from Sun seems to be messed up, at least according to the # docs I read in one of the Sun manuals. [...] I recommend that you try to use the sendmail.cf file that comes with the smail package rather than back-fitting Sun's config file to use smail for UUCP. The Sun config file was a nightmare last time I looked at it (in fairness, the one in Ultrix is not easy to figure out either), but the one that comes with smail is sufficient for most purposes, is relatively simple as sendmail config files go, and makes a great base for later additions. There are a few gotchas in the config file that smail builds for you, and the questions it asks you in its build script aren't very clear, but once you get something that barely works it is only an hour's work to get it to the 99% point, which is as far as sendmail is ever going to get you anyway. Moral: throw out the sendmail.cf that came from your CPU vendor and use the one that comes with smail. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 Jan 89 02:41:11 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 9 Jan 89 02:26:18 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Jan 89 07:00:20 GMT From: utkcs2!cygnusx1!moore@gatech.edu (Keith Moore) Organization: CS Dept -- University of TN, Knoxville Subject: sendmail incompatibility (was Re: Still trying to get ...). Message-Id: <697@utkcs2.cs.utk.edu> References: <412@execu.UUCP>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [Henize] >[...] >The sendmail.cf from Sun seems to be messed up, at least according to the >docs I read in one of the Sun manuals. [...] [Vixie] >I recommend that you try to use the sendmail.cf file that comes with the smail >package rather than back-fitting Sun's config file to use smail for UUCP. The [...] >Moral: throw out the sendmail.cf that came from your CPU vendor and use the > one that comes with smail. Even this is not always enough. It seems that some vendors have changed sendmail enough that config files for vanilla (i.e. Berkeley) sendmail don't work with the vendor-supplied version. Our standard .cf file works fine with 5.59, but breaks when I give it to either the Ultrix 3.0 sendmail or the SunOS 4.0 sendmail. I'm sure the required changes are minor, but I really have no way of knowing what is different about the vendors' versions. Rather than try and figure out a black box, we just run 5.59 on everything. Moral: throw out that /usr/lib/sendmail that came from your CPU vendor and use the one from ucbarpa.berkeley.edu. [Busily reverse-engineering the mail11 gateway so we can run Ultrix 3.0...] -- Keith Moore UT Computer Science Dept. Internet/CSnet: moore@utkcs2.cs.utk.edu 107 Ayres Hall, UT Campus BITNET: moore@utkvx Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Jan 89 04:44:01 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 10 Jan 89 04:36:08 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 10 Jan 89 08:22:33 GMT From: pasteur!cory.Berkeley.EDU!dheller@ucbvax.berkeley.edu (Dan Heller) Organization: University of California, Berkeley Subject: ucbarpa's sendmail config (was sendmail incompatibility ) Message-Id: <8688@pasteur.Berkeley.EDU> References: <412@execu.UUCP>, , <697@utkcs2.cs.utk.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <697@utkcs2.cs.utk.edu> moore@cygnusx1.cs.utk.edu (Keith Moore) writes: >Moral: throw out that /usr/lib/sendmail that came from your CPU vendor and >use the one from ucbarpa.berkeley.edu. I'm curious about something. This config file is used all over berkeley, as it is at many other sites. Sometimes, when mail is sent out or when mail is routed thru said machine, the name-server might fail and your hostname is not expanded correctly into the fully qualified domain. The result is the recipient gets mail that says something like: From: dheller@cory As opposed to From: dheller@cory.Berkeley.EDU Many times, I mail to people and they can't reply because "cory" doesn't make sense (cuz it's not qualified). The same problem happens when I mail to people at Santa Cruz Operation. "sco" talks to ucscc.ucsc.edu, so I address the mail: To: sco!user@ucscc.ucsc.edu but when ucsc gets the message, sometimes (when the name server fails to get info about "ucscc") it rejects the mail with the error: ucscc.ucsc.edu: I refuse to talk to myself. So, the bottom line is, is it possible to configure a sendmail.cf file so that if a hostname lookup or a name server lookup fails, it can be replaced by a known/preset value so that mail can continue to work as it should. Dan Heller  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 16 Jan 89 16:43:44 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 16 Jan 89 16:39:56 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Jan 89 07:52:38 GMT From: oliveb!3comvax!bridge2!fjd@ames.arpa (Farokh J. Deboo) Organization: 3Com Corp., Mt. View, CA Subject: Call for Papers: IEEE/EMS 1990 Conference in San Francisco Message-Id: <258@bridge2.3Com.Com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu My apologies for this large cross-posting. This is to invite prospecitve authors for papers relevant to the 1990 IEEE/EMS Conference (see announcement below)--- especially for any parties interested in chairing a session or submitting papers related to electonic mail in this context. Thank you, Farokh Deboo +----------------------------------------------------------------------+ | FIRST CALL FOR PAPERS | | 1990 International Engineering Management Conference | | in the San Francisco area | +----------------------------------------------------------------------+ | The IEEE/EMS Conference sponsored by the IEEE Engineering Manage- | | ment Society will be held in the San Francisco area between Oc- | | tober 22 and 24, 1990, with the theme: | | Management through the year 2000 and the Pacific Rim. | | | | This is an annual international conference dedicated to improving | | engineering management. Contributions are solicited that address, | | but are not limited to the following main topics: | | | | o Artificial Intelligence and Robotics | | o Company Management Styles from the entrepreneur to the establis- | | hed | | o Transition from Engineer to Manager | | o Management of Corporate R & D Centers | | o Micro Devices | | o Doing Business in the Pacific Rim, Europe, South America and | | Canada | | o Manufacturing Management & Factory Operations | | o Just-in-Time and Dock-to-Stock Techniques | | o Education for Manufacturing Managers | | o Manufacturing Technology | | | | Prospective authors are requested to submit one to two page | | abstracts of their presentation by April 30, 1990 to IEEE/EMS | | 1990, c/o Judith Baar Inc., 620 Abbie Court, Pleasanton, Califor- | | nia 94566. For further information call Judith Baar (415/484- | | 4795) or Michael Crocker (415/354-5240). | | | | The program committee is also looking for additional volunteers. | | If you are interested, please contact the Conference Chairman, Dr. | | Burton V. Dean at (408) 924-3551 or send mail to "sun!bridge2!fjd" | +----------------------------------------------------------------------+  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 18 Jan 89 21:00:18 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 18 Jan 89 20:54:39 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 18 Jan 89 23:36:09 GMT From: avsd!childers@bloom-beacon.mit.edu (Richard Childers) Organization: die Edelstahlratte Subject: Re: Still trying to get smart routing working. Message-Id: <412@avsd.UUCP> References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <7094@xanth.cs.odu.edu> wisner@xanth.cs.odu.edu (Bill Wisner) writes: >In article <412@execu.UUCP> dewey@execu.UUCP (Dewey Henize) writes: >>Our alias file is, as Sun recommends, of the form >>fred: fred@execu >>joe: joe@prickleypear >>...etc... >Sounds bogus to me. If fred and joe are real accounts that want to receive >mail on another machine, give them .forward files. If they're not real >accounts and you're setting up forwarding addresses, disregard this >paragraph. As far as I can tell, .forward files don't really fit into a LAN environment. In my case, I have about four or five YP domains, a corresponding number of networks, and need to maintain complete interconnectability, for everybody's convenience. But I can't mount everybody's home directory everywhere, that's unnecessary and crude - that's what /usr/lib/aliases is for. When I find .forward files in the LAN - usually as a result of receiving mail that looped round and round, before ending up in my mailbox as a problem report from MAILER-DAEMON - I cat /dev/null into them and chown them to root and chmod the sucker to 444 and that's that. Always use /usr/lib/aliases, and concentrate all your network problems into one place. .forward is an obsolete mechanism from a decade ago. >Bill, the man from Xanth What happened to Kent ? You guys merge ? (-: -- richard -- * Bismillah hir-Rahman nir-Rahim * * * * ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho * * AMPEX Corporation - Audio-Visual Systems Division, R & D *  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jan 89 05:02:09 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 19 Jan 89 05:00:29 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 19 Jan 89 06:52:09 GMT From: helios.ee.lbl.gov!ace.ee.lbl.gov!leres@nosc.mil (Craig Leres) Organization: Lawrence Berkeley Laboratory, Berkeley Subject: Re: Still trying to get smart routing working. Message-Id: <1715@helios.ee.lbl.gov> References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu>, <412@avsd.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Richard Childers writes: > When I find .forward files in the LAN - usually as a result of receiving > mail that looped round and round, before ending up in my mailbox as a problem > report from MAILER-DAEMON - I cat /dev/null into them and chown them to root > and chmod the sucker to 444 and that's that. This sounds gratuitously fascist to me. Luckly, it's not hard to remove such a file: helios 7 % ls -l .forward -r--r--r-- 1 root 0 Jan 18 22:40 .forward helios 8 % rm .forward rm: override protection 444 for .forward? y helios 9 % ls -l .forward .forward not found The advanced reader might want to use "rm -f .forward" Craig  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jan 89 14:02:27 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 19 Jan 89 13:53:06 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 19 Jan 89 16:32:06 GMT From: phri!roy@nyu.edu (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Subject: Re: Still trying to get smart routing working. Message-Id: <3656@phri.UUCP> References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu>, <412@avsd.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [Regarding the selection of newsgroups, I consider it fundamentally wrong to crosspost to foo.misc as well as foo.x, foo.y, and foo.z. I've directed followups to comp.mail.sendmail since that's the most appropriate group.] In article <412@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes: > Always use /usr/lib/aliases, and concentrate all your network problems into > one place. .forward is an obsolete mechanism from a decade ago. I'd almost agree with that, except that it would be nice if people could set up things like vacation on their own (do you, as postmaster, really want to change /usr/lib/aliases every time somebody goes on vacation or comes back?) Of course, the alternative is to have sendmail (or whatever MTA you use) deal with vacation processing itself. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jan 89 19:02:57 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 19 Jan 89 18:56:07 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 19 Jan 89 18:57:06 GMT From: auspex!guy@uunet.uu.net (Guy Harris) Organization: Auspex Systems, Santa Clara Subject: Re: Still trying to get smart routing working. Message-Id: <868@auspex.UUCP> References: <412@execu.UUCP>, <7094@xanth.cs.odu.edu>, <412@avsd.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu >Always use /usr/lib/aliases, and concentrate all your network problems into >one place. .forward is an obsolete mechanism from a decade ago. "From a decade ago"? In other words, "sendmail" existed in early 1979? News to me. "delivermail" may have existed then, but as I remember it had "/usr/lib/aliases" but *not* ".forward" files, so "/usr/lib/aliases" *antedates* ".forward" files. ".forward" is not obsolete; it serves purposes other than to forward mail from a user's "alternate" accounts to their "primary" account. For one thing, it lets you run all your mail through a filter, or a "mail watcher" such as "vacation".... (As for mounting everybody's home directory everywhere, while it isn't necessary, it can sure be *convenient* at times - if I have to work on several different machines, it's nice to be able to have my environment travel with me.)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Jan 89 22:17:52 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 21 Jan 89 22:07:13 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 19 Jan 89 11:39:21 GMT From: mcvax!cernvax!ethz!solaris!wyle@uunet.uu.net (Mitchell Wyle) Organization: SOT Sun Cluster, Swiss Federal Institute of Tech. Subject: simple encryption in mail Message-Id: <508@solaris.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am in need of a simple encryption scheme for mail messages which can be used by many different mail readers. I'd prefer if it could work with mh, mailx, /usr/ucb/Mail, mm, and mush. A simple "pager" such as more with encryption built-in might do the trick. A mail administrator (Hi Hannes!) here reads my mail as it goes out, and I assume he reads mail when it arrives as well. Please flame him at: lubich%komsys.inf.ethz.ch@relay.cs.net or lubich@ethz.uucp. There are some standards coming in this regard, but I'd prefer something I can use now. Thanks, -Mitch (wyle@ethz.uucp) -- -Mitchell F. Wyle wyle@ethz.uucp Institut fuer Informationsysteme wyle@inf.ethz.ch ETH Zentrum / 8092 Zurich, Switzerland +41 1 256 5237  Received: from Jester.CC.MsState.Edu (TCP 20204460100) by MC.LCS.MIT.EDU 23 Jan 89 11:56:46 EST Received: by Jester.CC.MsState.Edu (4.0/2.5); id AA05549; Mon, 23 Jan 89 10:56:18 CST Date: Mon, 23 Jan 89 10:56:18 CST From: Frank W. Peters Message-Id: <8901231656.AA05549@Jester.CC.MsState.Edu> To: header-people@mc.lcs.mit.edu Subject: Subscription Greetings, Please add the mail sublist to your mailing list. Please direct any problems to me at . Please note that you may already have an existing distribution to me directly. If so, please remove me when you add the new list. Thank You Frank Peters ============================================================================= Systems Programmer | Mississippi State University Phone: (601) 325-2942 | Computing Center and Services Internet: peters@CC.MsState.Edu | Post Office Drawer CC BITNET: PETERS@MSSTATE.BITNET | Mississippi State, MS. 39759 =============================================================================  Received: from Jester.CC.MsState.Edu (TCP 20204460100) by MC.LCS.MIT.EDU 23 Jan 89 12:05:05 EST Received: by Jester.CC.MsState.Edu (4.0/2.5); id AA05571; Mon, 23 Jan 89 11:04:40 CST Date: Mon, 23 Jan 89 11:04:40 CST From: Frank W. Peters Message-Id: <8901231704.AA05571@Jester.CC.MsState.Edu> To: header-people@mc.lcs.mit.edu Subject: Apology Please forgive the subscription request which I inadvertantly sent to the entire mailing list. I really do know better. Frank Peters ============================================================================= Systems Programmer | Mississippi State University Phone: (601) 325-2942 | Computing Center and Services Internet: peters@CC.MsState.Edu | Post Office Drawer CC BITNET: PETERS@MSSTATE.BITNET | Mississippi State, MS. 39759 =============================================================================  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 23 Jan 89 19:33:37 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 23 Jan 89 19:31:12 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 23 Jan 89 14:05:08 GMT From: cunyvm!maine.bitnet!michael@psuvm.bitnet Organization: University of Maine System Subject: Re: simple encryption in mail Message-Id: <1119MICHAEL@MAINE> References: <508@solaris.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I can't quite tell where you are located, but if it is inside the USA then your mail administrator should know that by reading your mail as it comes and goes he is (unless he can reasonably cite system security, which I doubt) breaking the law. There is a law in this country (PL99-508, "The Electronic Communications Privacy Act of 1986") that specifically prohibits intercepting and reading of electronic mail and other forms of electronic communication. You could probably sue him and win on the grounds of privacy invasion. Secondly, a good simple encryption scheme is ROT-13, but it does not require a key, so your administrator could also decrypt your stuff, assuming he reads this and wants to continue his illegal activity. Just rotate each alphabetic letter through the alphabet 13 positions. Thus, 'A' becomes 'N' and 'Z' becomes 'M', etc. To reverse it, simply do the same rotation again and things go back to their previous state. Hope this helps you. Michael Johnson "We are the Priests of the Temples University of Maine System of Syrinx. Our great computers fill Computing and Data Processing Services the hallowed halls." - Neil Peart  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 24 Jan 89 17:19:32 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 24 Jan 89 17:02:53 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 24 Jan 89 20:14:02 GMT From: mailrus!cwjcc!hal!nic.MR.NET!shamash!raspail!steve@ohio-state.arpa (Steve Schonberger) Organization: Control Data Corporation, Arden Hills, MN Subject: Re: simple encryption in mail Message-Id: <1178@raspail.UUCP> References: <508@solaris.UUCP>, <1119MICHAEL@MAINE> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <1119MICHAEL@MAINE>, MICHAEL@MAINE writes: > I can't quite tell where you are located, but if it is inside the USA then > your mail administrator should know that by reading your mail as it comes > and goes he is (unless he can reasonably cite system security, which I doubt) > breaking the law. There is a law in this country (PL99-508, "The Electronic > Communications Privacy Act of 1986") that specifically prohibits intercepting > and reading of electronic mail and other forms of electronic communication. This is not correct. Any place that provides mail may choose whether to be follow this law or not. The law is that a mail provider must do everything possible to ensure the privacy of communications if they say their mail is private. By saying their mail is private, they bring themselves under the same body of law that keeps the Post Office and telephone companies from inspecting communications that they pass. The advantage of this to a mail provider is that having the provider legally bound to be secure is a good selling point, because people like secure mail. The disadvantage is that they are liable for criminal (not just civil) penalties if they breach that privacy, and possibly civil penalties if someone outside their organization invades their privacy through flaws in their security. If someone is unable to provide communication security comparable to a telephone conversation (the case with _all_ mail going through the net), doesn't want to bother making it that secure (the case within most sites), or just doesn't want to put themselves at legal risk, they can state that their system is not guaranteed secure, at which point they can do whatever they feel like to their mail. A lot of local bulletin board systems I use have statements saying that it is not their policy to read or alter mail, but that they refuse to guarantee that it is secure. By saying this they free themselves of any legal responsibility connected with that law. I do not know what that law says about the default case. In other words, I am not sure if a mail provider is assumed to guarantee privacy if they don't specifically disclaim it, or if they are assumed to disclaim it unless they specifically guarantee it. I'd be curious to know, if anyone can provide a direct quote of the law on that matter. To bring this all back to the topic of this newsgroup, I think that the only way you can expect mail to be private, legal guarantees or not, is to encrypt it. A standard mail header to indicate encryption would be a good thing, though the message looking like garbage data accomplishes the same thing. Steve Schonberger steve@raspail.uucp raspail!steve@shamash.cdc.com ...!uunet!rosevax!shamash!rapail!steve  Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 26 Jan 89 16:18:25 EST Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by XX.LCS.MIT.EDU with TCP/SMTP; Thu 26 Jan 89 09:19:14-EST To: header-people@mc.lcs.mit.edu Subject: SIGCOMM Call for papers Date: Thu, 26 Jan 89 08:48:19 -0500 From: Craig Partridge CALL FOR PAPERS ACM SIGCOMM '89 SYMPOSIUM Communications Architectures and Protocols Austin, Texas September 20-22, 1989 (Tutorials September 19th) The symposium provides an international forum for the presentation and discussion of communication network appli- cations and technologies, as well as recent advances and proposals on communication architectures, protocols, algo- rithms, and performance models. Authors are invited to sub- mit full papers concerned with both theory and practice. The areas of interest for the symposium include, but are not limited to the following: analysis and design of computer network architectures and algorithms, innovative results in local area networks, computer-supported collaborative work, network interconnection and mixed-media networks, high-speed networks, resource sharing in distributed systems, distri- buted operating systems and databases, protocol specifica- tion, verification, and analysis. Papers should be about 20 double-spaced pages long and should have an abstract of 100-150 words. All submitted papers will be reviewed and will be judged with respect to their quality and relevance. Authors of accepted papers will be expected to sign an ACM copyright release form. The Proceedings will be distributed at the symposium and pub- lished as a special issue of SIGCOMM Computer Communication Review. A few of the submitted papers will be selected for publication in the ACM Transactions on Computer Systems. Submit 5 copies of each paper to the program chairman: Dr. Mohamed Gouda, Computer Sciences Department, University of Texas at Austin, Austin TX 78712, USA; Telephone: (512) 471-9532; EMAIL: gouda@cs.utexas.edu For more information about the symposium, contact Dr. L.H. Landweber, General Chair, Computer Sciences Dept., Univer- sity of Wisconsin, 1210 W. Dayton St., Madison, WI 53706; Tel: (608) 262-1204; EMAIL: landweber@cs.wisc.edu. STUDENT PAPER AWARD Papers submitted by students will enter a student-paper award contest. Among the accepted papers, a maximum of four outstanding papers will be awarded (1) full conference registration and (2) a travel grant of $500 US dollars. IMPORTANT DATES Deadline for paper submission: March 20, 1989 Notification of acceptance: May 19, 1989 Camera-ready manuscript due: June 19, 1989 SYMPOSIUM COMMITTEE General Chair: L.H. Landweber, University of Wisconsin, USA Program Chair: M. Gouda, University of Texas, USA Local Arrangements: M. Gouda, University of Texas, USA ------- End of Forwarded Message  Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 27 Jan 89 12:54:32 EST Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 26 Jan 89 23:36:03-EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 26 Jan 89 23:29:10 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 27 Jan 89 03:44:57 GMT From: ccncsu!longs.LANCE.ColoState.Edu!steved@boulder.colorado.edu (Steve Dempsey) Organization: Colorado State University, Fort Collins, CO 80523 Subject: Re: simple encryption in mail (no more legal discussion) Message-Id: <1073@ccncsu.ColoState.EDU> References: <1178@raspail.UUCP>, <508@solaris.UUCP>, <1119MICHAEL@MAINE> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <1178@raspail.UUCP>, steve@raspail.UUCP (Steve Schonberger) writes: > In article <1119MICHAEL@MAINE>, MICHAEL@MAINE writes: >> [in article <508@solaris.UUCP> wyle@solaris.UUCP (Mitchell Wyle) writes:] >> [looking for a simple encrypton method because his mail is watched] > > [lengthy discussion about legal aspects of the SA's rights & wrongs > regarding interception and perusal of private mail DELETED] Ok, this poor fellow asks for a simple way to protect his private e-mail, and what does he get? A meta-discussion on legalities. Well, here is my suggestion for implementing the simple encryption in a UNIX environment: The sender: % crypt < msg.txt > cypher (use previously agreed-upon key) % uuencode cypher < cypher > cypher.uu % mail whoever@wherever -s crypted_message < cypher.uu The recipient: % mail (receive mail, save in appropriate file) % uudecode cypher.uu % crypt < cypher > msg.txt (must have same key as sender) % more msg.txt Simple enough? Of course, you'll have to communicate the crypt key by some other means in advance. Steve Dempsey, Center for Computer Assisted Engineering Colorado State University, Fort Collins, CO 80523 +1 303 491 0630 INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 28 Jan 89 06:34:38 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 28 Jan 89 03:51:58 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 28 Jan 89 03:38:39 GMT From: ndcheg!ndmath!krueger@iuvax.cs.indiana.edu (Andreas Krueger) Organization: Math. Dept., Univ. of Notre Dame Subject: Re: simple encryption in mail (no more legal discussion) Message-Id: <1298@ndmath.UUCP> References: <508@solaris.UUCP>, <1119MICHAEL@MAINE>, <1073@ccncsu.ColoState.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <1073@ccncsu.ColoState.EDU>, steved@longs.LANCE.ColoState.Edu (Steve Dempsey) writes: > >In article <1178@raspail.UUCP>, steve@raspail.UUCP (Steve Schonberger) writes: > >In article <1119MICHAEL@MAINE>, MICHAEL@MAINE writes: > >> [in article <508@solaris.UUCP> wyle@solaris.UUCP (Mitchell Wyle) writes:] > >> [looking for a simple encrypton method because his mail is watched] > > > > [lengthy discussion about legal aspects of the SA's rights & wrongs > > regarding interception and perusal of private mail DELETED] > > Ok, this poor fellow asks for a simple way to protect his private e-mail, > and what does he get? A meta-discussion on legalities. Well, here is > my suggestion for implementing the simple encryption in a UNIX environment: > > [A few lines of commands using "crypt" which would do the job] Unfortunately, legal aspects aren't quite over if this poor fellow is not in the US, for (quote from man crypt): > RESTRICTIONS > This program is not available on software shipped outside > the U.S. krueger@ndmath.math.nd.edu (* Disclaimer: Restrictions quoted herein are not my own *)  Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 30 Jan 89 13:42:21 EST Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Sun 29 Jan 89 04:05:44-EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 29 Jan 89 03:58:08 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 29 Jan 89 07:37:51 GMT From: sargas.usc.edu!tli@oberon.usc.edu (Tony Li) Organization: University of Southern California, Los Angeles, CA Subject: Re: simple encryption in mail (no more legal discussion) Message-Id: <15005@oberon.USC.EDU> References: <1119MICHAEL@MAINE>, <1073@ccncsu.ColoState.EDU>, <1298@ndmath.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Crypt isn't the best thing to use. There's a package called Crypt Breakers Workbench that has been posted which is quite useful when trying to break a crypt'ed file. Tony Li - USC University Computing Services - Dain Bramaged. Uucp: oberon!tli Bitnet: tli@kylara, tli@ramoth Internet: tli@sargas.usc.edu  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Jan 89 20:20:46 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 31 Jan 89 20:11:57 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 28 Jan 89 07:39:47 GMT From: avsd!childers@bloom-beacon.mit.edu (Richard Childers) Organization: die Edelstahlratte Subject: administration fascism Message-Id: <445@avsd.UUCP> References: <7094@xanth.cs.odu.edu>, <412@avsd.UUCP>, <1715@helios.ee.lbl.gov> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu leres@helios.ee.lbl.gov (Craig Leres) writes: >Richard Childers writes: >> When I find .forward files in the LAN ... I cat /dev/null into them and chown them to root and chmod the sucker to 444 and that's that. >This sounds gratuitously fascist to me. Luckly, it's not hard to remove >such a file ... But it is impossible to edit it until it is removed, and provokes the required dialogue between user and administrator ... which is all I ask. >The advanced reader might want to use "rm -f .forward" One presumes that the advanced reader doesn't mangle his .forward ... Actually, I have been at enlightened sites where /usr/lib/aliases was writeable by the world. But if you can't trust your users to edit /usr/lib/aliases, then you probably can't trust them to edit .forward, either. > Craig -- richard -- * -= If it works, it must be a Fluke =- * * * * ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho * * AMPEX Corporation - Audio-Visual Systems Division, R & D *  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Jan 89 23:20:55 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 31 Jan 89 23:15:33 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Feb 89 03:56:56 GMT From: unmvax!unmvax.cs.unm.edu!mike@bloom-beacon.mit.edu (Michael I. Bushnell) Organization: University of No Money, Albuquerque, New Mexico Subject: Re: administration fascism Message-Id: <2253@unmvax.unm.edu> References: <412@avsd.UUCP>, <1715@helios.ee.lbl.gov>, <445@avsd.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <445@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes: >One presumes that the advanced reader doesn't mangle his .forward ... > >Actually, I have been at enlightened sites where /usr/lib/aliases was writeable >by the world. But if you can't trust your users to edit /usr/lib/aliases, then >you probably can't trust them to edit .forward, either. Hmmm...I disagree. We are an "enlightened" site which lets people edit /usr/lib/aliases. If someone f*cks up, then we have the simple solution of asking "who changed the XXX alias to YYY?" and then we can explain to them the necessity of being more careful in the future. But if we decided that people were not trustable, then there is a hell of a difference between mangling your OWN .forward (which only screws up your own mail) and mangling /usr/lib/aliases (which can steal other peoples' mail, break vital mailing lists, etc.). In short, it may be quite rational to protect users from eachother (by protecting /usr/lib/aliases), but it IS facism to "protect" people from themselves. Michael I. Bushnell \ This above all; to thine own self be true GIG! \ And it must follow, as the night the day, mike@turing.cs..unm.edu /\ Thou canst not be false to any man. Hmmmm.............. / \ Farewell: my blessing season this in thee!  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 1 Feb 89 09:15:02 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 1 Feb 89 04:30:26 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Feb 89 05:01:14 GMT From: bionet!agate!helios.ee.lbl.gov!ace.ee.lbl.gov!leres@csd4.milw.wisc.edu (Craig Leres) Organization: Lawrence Berkeley Laboratory, Berkeley Subject: Re: administration fascism Message-Id: <1818@helios.ee.lbl.gov> References: <445@avsd.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Several weeks ago, Richard Childers wrote: > When I find .forward files in the LAN ... I cat /dev/null into them and > chown them to root and chmod the sucker to 444 and that's that. Shortly after, I wrote: > This sounds gratuitously fascist to me. Luckly, it's not hard to remove > such a file ... More recently Richard Childers writes: > But it is impossible to edit it until it is removed, and provokes the required > dialogue between user and administrator ... which is all I ask. When one of my users botches his/her .forward file (this is a rare event, perhaps my users are smarter than yours) I find that mail(1) provides an interface that is completely sufficient to "provoke" dialogue with the user. Not once have I had to play power games with superuser privileges to achieve this goal. Craig  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 1 Feb 89 17:36:01 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 1 Feb 89 17:18:28 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Feb 89 13:12:58 GMT From: texbell!uhnix1!sugar!karl@bellcore.bellcore.com (Karl Lehenbauer) Organization: Sugar Land Unix - Houston, TX Subject: Re: administration fascism Message-Id: <3376@sugar.uu.net> References: <7094@xanth.cs.odu.edu>, <412@avsd.UUCP>, <2253@unmvax.unm.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <2253@unmvax.unm.edu>, mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes: > Hmmm...I disagree. We are an "enlightened" site which lets people edit > /usr/lib/aliases. If someone f*cks up, then we have the simple solution > of asking "who changed the XXX alias to YYY?" and then we can explain to > them the necessity of being more careful in the future. Thus the cost of providing the flexibility of letting people edit /usr/lib/aliases is that, when they screw up, mail screws up -- sometimes a little, sometimes a lot. I don't know if I would call this policy "enlightened." I would say it balances things a little more toward ease-of-use at the cost of reducing reliability. Why do they need to edit /usr/lib/aliaes anyway? How often does this happen? -- -- uunet!sugar!karl | "We've been following your progress with considerable -- karl@sugar.uu.net | interest, not to say contempt." -- Zaphod Beeblebrox IV -- Usenet BBS (713) 438-5018  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 1 Feb 89 19:21:01 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 1 Feb 89 19:03:48 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Feb 89 23:22:39 GMT From: unmvax!unmvax.cs.unm.edu!mike@bloom-beacon.mit.edu (Michael I. Bushnell) Organization: University of No Money, Albuquerque, New Mexico Subject: Re: administration fascism Message-Id: <2254@unmvax.unm.edu> References: <412@avsd.UUCP>, <2253@unmvax.unm.edu>, <3376@sugar.uu.net> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3376@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >In article <2253@unmvax.unm.edu>, mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes: >> Hmmm...I disagree. We are an "enlightened" site which lets people edit >> /usr/lib/aliases. If someone f*cks up, then we have the simple solution >> of asking "who changed the XXX alias to YYY?" and then we can explain to >> them the necessity of being more careful in the future. > >Thus the cost of providing the flexibility of letting people edit >/usr/lib/aliases is that, when they screw up, mail screws up -- sometimes >a little, sometimes a lot. I don't know if I would call this policy >"enlightened." I would say it balances things a little more toward >ease-of-use at the cost of reducing reliability. Why do they need to >edit /usr/lib/aliaes anyway? How often does this happen? They (the faculty) maintain several mail aliases for various groups. They even *create* such aliases relatively frequently. No one's *ever* screwed up anyone else's mail. This makes creating mailing lists easy for arbitrary users. Michael I. Bushnell \ This above all; to thine own self be true GIG! \ And it must follow, as the night the day, mike@turing.cs..unm.edu /\ Thou canst not be false to any man. Hmmmm.............. / \ Farewell: my blessing season this in thee!  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 1 Feb 89 19:21:18 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 1 Feb 89 18:52:59 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Feb 89 18:52:00 GMT From: auspex!guy@uunet.uu.net (Guy Harris) Organization: Auspex Systems, Santa Clara Subject: Re: administration fascism Message-Id: <926@auspex.UUCP> References: <412@avsd.UUCP>, <1715@helios.ee.lbl.gov>, <445@avsd.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu >But it is impossible to edit it until it is removed, and provokes the required >dialogue between user and administrator ... which is all I ask. Maybe yes, maybe no; they may just get ticked off, as I presume Mr. Leres would (and as I probably would, too), and just remove it without talking to the administrator. >Actually, I have been at enlightened sites where /usr/lib/aliases was writeable >by the world. But if you can't trust your users to edit /usr/lib/aliases, then >you probably can't trust them to edit .forward, either. Incorrect. You can screw more people by monkeying with "/usr/lib/aliases" than you can by editing ".forward"; by editing the former you can foul up the delivery of mail to people other than yourself without their consent.  Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 3 Feb 89 08:20:30 EST Received: from gallua.bitnet by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7711; Fri, 03 Feb 89 08:20:19 EST Date: Fri, 3 Feb 89 08:19 EST From: "E. Remington" Subject: INFORMATION To: HEADER-PEOPLE@MC.LCS.MIT.EDU X-VMS-To: IN%"HEADER-PEOPLE@MC.LCS.MIT.EDU" Hi, my name is Elizabeth Remington. I am writing to you from Gallaudet University in D.C. I am new to the bitnet and arpanet systems and I am trying to find get more information on gateways and how they work. I am trying to reach a person in London on what I believe is called a PSDN (public service data network ?), specifically Primenet. If you know anyone I could contact who may have any ideas or a direction I could look in please let me know. Thanks for your help. Elizabeth  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 Feb 89 11:37:00 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 4 Feb 89 11:22:57 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Feb 89 21:05:15 GMT From: mcvax!hp4nl!uva!dik@uunet.uu.net (Casper H.S. Dik) Organization: Faculteit Wiskunde & Informatica, Universiteit van Amsterdam Subject: Re: administration fascism Message-Id: <608@uva.UUCP> References: <1715@helios.ee.lbl.gov>, <445@avsd.UUCP>, <2253@unmvax.unm.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <2253@unmvax.unm.edu> mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes: >In article <445@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes: > >>Actually, I have been at enlightened sites where /usr/lib/aliases was writeable >>by the world. But if you can't trust your users to edit /usr/lib/aliases, then >>you probably can't trust them to edit .forward, either. > > >Hmmm...I disagree. We are an "enlightened" site which lets people edit >/usr/lib/aliases. If someone f*cks up, then we have the simple solution >of asking "who changed the XXX alias to YYY?" and then we can explain to >them the necessity of being more careful in the future. Hmmm... you must trust your users very much. People can not only steal other peoples mail, but can add an alias like myalias: |/myhome/myprogram The program /myhome/myprogram will be executed with the uid sendmail uses for untrusted mailers. If it is daemon (it is on my systems) the user could then 'do some things I will not disclose here' and become root in a matter of minutes. At that point he can do more damage to your system than you can repair in the time saved by letting your users edit /usr/lib/aliases. >In short, it may be quite rational to protect users from eachother (by >protecting /usr/lib/aliases), but it IS facism to "protect" people from >themselves. Agreed > Michael I. Bushnell \ This above all; to thine own self be true > GIG! \ And it must follow, as the night the day, >mike@turing.cs..unm.edu /\ Thou canst not be false to any man. > Hmmmm.............. / \ Farewell: my blessing season this in thee! ____________________________________________________________________________ Casper H.S. Dik University of Amsterdam | dik@uva.uucp The Netherlands | ...!uunet!mcvax!uva!dik  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 Feb 89 17:22:09 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 4 Feb 89 17:07:04 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 4 Feb 89 21:53:51 GMT From: unmvax!turing.cs.unm.edu!mike@bloom-beacon.mit.edu (Michael I. Bushnell) Organization: University of No Money, Albuquerque, New Mexico Subject: Re: administration fascism Message-Id: <2264@unmvax.unm.edu> References: <445@avsd.UUCP>, <2253@unmvax.unm.edu>, <608@uva.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <608@uva.UUCP> dik@uva.UUCP (Casper H.S. Dik) writes: >Hmmm... you must trust your users very much. >People can not only steal other peoples mail, but can add an alias like >myalias: |/myhome/myprogram Our goal for security is to prevent users from doing accidental damage. We can restore the system from tape in a matter of hours--with little loss of data. The offending person is easily determined, and we can easily use administrative means to can them. >The program /myhome/myprogram will be executed with the uid sendmail uses >for untrusted mailers. If it is daemon (it is on my systems) the user >could then 'do some things I will not disclose here' and become root >in a matter of minutes. In the interests of letting people know what we mean, you could, for example, modify the atq and have jobs executed as root. The atq is, on most systems, owned by daemon, so daemon can modify it and have jobs run under any uid. >At that point he can do more damage to your system than you can repair >in the time saved by letting your users edit /usr/lib/aliases. As I said, not too much damage. We don't worry. Administrative control is far better than online security. Michael I. Bushnell \ This above all; to thine own self be true GIG! \ And it must follow, as the night the day, mike@turing.cs..unm.edu /\ Thou canst not be false to any man. Hmmmm.............. / \ Farewell: my blessing season this in thee!  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 Feb 89 23:07:09 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 4 Feb 89 22:56:53 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 4 Feb 89 18:25:50 GMT From: mcvax!kth!enea!maxim!prc@uunet.uu.net (Robert Claeson) Organization: ERBE DATA AB Subject: Re: simple encryption in mail (no more legal discussion) Message-Id: <485@maxim.ERBE.SE> References: <508@solaris.UUCP>, <1119MICHAEL@MAINE>, <1298@ndmath.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <1298@ndmath.UUCP>, krueger@ndmath.UUCP (Andreas Krueger) writes: > Unfortunately, legal aspects aren't quite over if this poor > fellow is not in the US, for (quote from man crypt): > > > RESTRICTIONS > > This program is not available on software shipped outside > > the U.S. So let's use DES instead. Even though not included in the export versions of UNIX, it's universally available and the algorithms are well-known. One can even use it to send mail to Russia :-). -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden "No problems." -- Alf Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE BITNET: rclaeson@ERBE.SE  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 6 Feb 89 12:13:53 EST Received: by INFOODS id <0000224F061@INFOODS.MIT.EDU> ; Sun, 5 Feb 89 12:44:33 EST Date: Sun, 5 Feb 89 12:00:32 EST From: John C Klensin Subject: Re: 'administration fascism', alias files, etc. To: header-people@MC.LCS.MIT.EDU X-VMS-Mail-To: EXOS%"header-people@mc.lcs.mit.edu" Message-ID: <890205120032.0000224F061@INFOODS.MIT.EDU> People, I am not familiar with the intimate details of sendmail operation, but it may be that (a) this conversation chain has gone on about long enough in this list, especially since it is no longer a discussion relevant to the list (if it ever was) and (b) that an observation from "outside" might be useful. Summary of where I think the dialogue stands: - Letting users edit these files in arbitrary ways is quite dangerous. A moderately smart and slightly malicious user, or one who is trying to prove system insecurity, can manage the alias file in ways that provide enough privilege and access to pretty well damage a system and destroy and/or browse other user's files. - At the same time, considerable system convenience can be realized, and inconvenience to both users and system administrators avoided, if users are permitted to edit their own records. - For at least some installations, backup arrangements are considered adequate to rapidly restore the system and user files from any damage caused by accidental or malicious damage, and post hoc administrative sanctions are considered an adequate remedy for any malicious or repeated problems. For those installations, convenience may outweigh security/privacy. Now, two suggestions: (1) Move this discussion elsewhere. Many of us who are interested in headers and related issues are not terribly interested in this discussion. More important, there are probably lots of people in the U**X/sendmail communities who are, or should be, very interested in this discussion but are not seeing it because they are not interested in header issues (or think that they aren't). On the other hand, please let's avoid a discussion chain on appropriateness: if the participants in this chain disagree, please just ignore this remark. (2) Multics provides an extremely straightforward way to deal with problems like this one that both provides the convenience and avoids the potential risks. It has parallels on several other systems (some of them otherwise fairly retarded, and should be easily simulated on UNIX). You don't give "users" access to modify the file. You do give that access to a special user, or to a daemon. "Users" make changes in their entries by sending a message to the special user that says "please edit my entry to read....". The special user or daemon searches the file, finds the entry for the submitting user, and alters it as requested. Assuming that the special user or daemon can adequately authenticate the sender on your particular system (if you can't do that, you have other problems), this effectively gives anyone the ability to change his or her own entry. It effectively prevents anyone but a system administrator from changing anyone else's entry and, if you feel a need to do so, permits you to use the special user or daemon to filter what types of change request are permitted. Now, if this is a big issue, why doesn't someone do something about it? John Klensin Klensin@INFOODS.MIT.EDU  Received: from oodis01.arpa (TCP 3202400024) by MC.LCS.MIT.EDU 6 Feb 89 19:10:49 EST Return-Path: Received: by oodis01.arpa id AA25747; Mon, 6 Feb 89 10:50:48 MST Message-Id: <8902061750.AA25747@oodis01.arpa> Date: Mon Feb 6 10:50:46 1989 From: kerr@oodis01.arpa (Grant Kerr) Subject: Return-receipt-to header field To: header-people@mc.lcs.mit.edu Return-Receipt-To: kerr@oodis01.arpa Status: N It seems that some mail systems send messages to the message originator when a user and/or system receives a mail message. On our system it uses the "Return-receipt-to:" header to do this function. What systems support this? Does any RFC refer to this header field? (I couldn't find one) grant (kerr@oodis01.arpa)  Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 7 Feb 89 21:04:46 EST Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Tue 7 Feb 89 08:54:55-EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 7 Feb 89 08:41:42 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Feb 89 13:41:22 GMT From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa (Karl Kleinpaste) Organization: OSU Subject: Re: administration fascism Message-Id: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu comp.mail.headers, right? Yeah, I thought so. There *is* a comp.mail.misc, folks.  Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 7 Feb 89 21:04:46 EST Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Tue 7 Feb 89 08:54:55-EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 7 Feb 89 08:41:42 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Feb 89 13:41:22 GMT From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa (Karl Kleinpaste) Organization: OSU Subject: Re: administration fascism Message-Id: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu comp.mail.headers, right? Yeah, I thought so. There *is* a comp.mail.misc, folks.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 Feb 89 23:57:58 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 7 Feb 89 23:51:13 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Feb 89 04:07:24 GMT From: helios.ee.lbl.gov!ace.ee.lbl.gov!leres@nosc.mil (Craig Leres) Organization: Lawrence Berkeley Laboratory, Berkeley Subject: Re: administration fascism Message-Id: <1875@helios.ee.lbl.gov> References: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Karl Kleinpaste writes: > comp.mail.headers, right? Yeah, I thought so. There *is* a > comp.mail.misc, folks. Why so uptight, Karl? Too much caffeine? Craig  Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Feb 89 04:49:51 EST Received: from po3.andrew.cmu.edu by XX.LCS.MIT.EDU with TCP/SMTP; Tue 7 Feb 89 12:17:48-EST Received: by po3.andrew.cmu.edu (5.54/3.15) id for header-people@mc.lcs.mit.edu; Tue, 7 Feb 89 11:53:27 EST Received: via switchmail; Tue, 7 Feb 89 11:53:18 -0500 (EST) Received: from larimer.andrew.cmu.edu via qmail ID ; Tue, 7 Feb 89 11:50:48 -0500 (EST) Received: from Messages.7.2.N.CUILIB.3.45.SNAP.NOT.LINKED.larimer.andrew.cmu.edu.rt.r3 via MS.5.6.larimer.andrew.cmu.edu.rt_r3; Tue, 7 Feb 89 11:50:38 -0500 (EST) Message-Id: <0XvltSy00Uk4I9pW8S@andrew.cmu.edu> Date: Tue, 7 Feb 89 11:50:38 -0500 (EST) From: Nathaniel Borenstein X-Andrew-Message-Size: 8833+0 To: kerr@oodis01.arpa (Grant Kerr) Subject: Re: Return-receipt-to header field Cc: header-people@mc.LCS.MIT.EDU, "Craig F. Everhart" In-Reply-To: <8902061750.AA25747@oodis01.arpa> References: <8902061750.AA25747@oodis01.arpa> Well, the Andrew Message System implements one such feature. We got some way towards writing up an RFC, and then sort of tailed off, but for what it is worth, here is what we wrote up about it circa 2 years ago -- the format is Scribe input, but it should be pretty readable anyway. Nathaniel S. Borenstein Manager, Andrew Applications Development Information Technology Center Carnegie Mellon University @b(RFC XXX) @center[An end-to-end delivery notification feature for ARPA Internet Messages Nathaniel S. Borenstein Craig F. Everhart Information Technology Center Carnegie-Mellon University Pittsburgh, Pennsylvania, 15213 nsb+@@andrew.cmu.edu Abstract @quotation[A standardized Ack-To field allows mail reading systems to implement a "confirmation" feature whereby the users can request confirmation that a piece of mail has actually been received by the recipient. The type of confirmation defined for the User-Reciept-To feature is "end-to-end" in the sense that it confirms actual receipt by the final reader (the human being) rather than the completion of some stage of the delivery process (e.g. the entry of the message into the recipient's mailbox). The feature has been designed to conform to the Internet mail standard RFC 822 and to be plausibly converted to and from the X.400 Delivery Notification service at future SMTP-X.400 gateways. This proposal calls for the creation of three new standard Intenet mail headers, "Ack-To", "Ack-type", and "Ack"]] @Section(Introduction ) This RFC proposes a new addition to the set of standard headers which may appear in Internet mail as defined by RFC 822. The purpose of the new "Ack-To" header is to facilitate confirmation that a message has indeed been delivered to its intended recipient. Although the feature appears simple, it has been carefully designed to meet a few key criteria: @begin(itemize) Conformity to RFC 822 Interoperability with X.400 Non-interference with the functioning of mail systems that do not implement the feature. Independence from other types of confirmation schemes with different semantics, which have been implemented independently. @end(itemize) The last criterion is necessary because there has been and continues to be a significant amount of disagreement regarding the most desirable form of delivery notification. Some efforts have been made in the past, such as the 4.2/3 BSD sendmail program's use of the "Return-Reciept-To" header, which requests automatic notification of the completion of key steps in the delivery process. Rather than assert that the "end-to-end" return receipt proposed in this document is the "correct" form of delivery notification, we simply offer it as an alternative, to be implemented by those systems that regard it as desirable. @Section(Alternative Models for Delivery Notification) Ideally, a delivery notification mechanism would provide a one-to-one mapping onto successful deliveries: if the user receives a delivery notification, he could be certain that the message had been delivered, and if the notification never arrived, he could be certain the message had never been delivered. Unfortunately, this ideal mechanism is rendered virtually impossible by the fundamental uncertainty of internetwork mail delivery, which is of course itself one of the major motivating factors in providing such a service. Since it is always conceivable that mail will be lost, it is always conceivable that mail confirming successful delivery will be lost. While one can imagine mechanisms that would guarantee this mapping, their implementation would be essentially as hard as implementing completely reliable mail delivery in the first place. In the absence of any medium-term prospects of such reliability, a useful delivery notification scheme should be designed to be much easier to implement. Given that the ideal guarantee can not be made, an alternative is to guarantee that the receipt of a delivery notification implies that the recipient received the mail, but to make no guarantees about the absence of receipt. That is the position taken in this proposal. Another point where notions of delivery confirmation may differ is in the point at which the confirmation is generated. The two major choices here are confirmation of delivery and confirmation of human receipt. In the former case, the receipt guarantees simply that the message was put somewhere (e.g. a mailbox) where the user could be expected to find it. In the latter case, the position specified in this proposal, the receipt guarantees that the message was actually seen by the human recipient. (Of course, no guarantee can be made that the right human being read the message, especially given the unatuthenticated nature of internetwork mail, but the recipient's identity should be checked to the extent that the authentication facilities on the recipient's system permit.) The receipt by human being was selected for this proposal because it seems the stronger of the two guarantees, and is well within the implementation capabilities of most mail systems. In order to better accommodate the mix of possible acknowledgement types, a third, optional header is defined, the "Ack-type" header. If present, this field indicates the type of acknowledgement being provided, as indicated below. @Section(Specification of the Ack-To header) The User-Reciept-To header has a syntax identical to the Reply-To header, as defined in RFC 822. It specifies a destination address to which the delivery confirmation should be mailed. It may be identical to the From or Reply-To header, but need not be. When a User-Reciept-To header is used, a Message-ID header is required. @Section(Specification of the Ack-Type header) The Ack-Type header is optional. If provided, it should have one of a small set of designated values, indicated the type of confirmation being provided. In particular, "Ack-type: explicit" indicates that the mail was actually read by the human user and that the user explicitly agreed to send the acknowledgement. Other values for the Ack-type field should be published as needed. @section(Specification of the Delivery Notification Message) When the user agent in a mail system shows a user a new message requesting confirmation with the Ack-To header, it may generate a corresponding delivery notification message. (The term "may" implies not only that many mail systems may not implement this feature, but also that some may choose to give the user the option of sending or not sending such a confirmation.) In this case, it will send a message to the destination address specified in the Ack-To header. That message should contain a "Ack" header, the contents of which should be simply the Message-ID header of the message being confirmed. In addtion, it is recommended that, for the benefit of users of mail systems that do not automatically correlate return-reciepts, two additional steps be taken in the composition of the confirmation message. First, the Subject header should be composed of the word "Confirming: " followed by the subject of the original message. Second, the body of the message should contain a suitable explanatory phrase, one that will be meaningful if read by a human being. A sample can be found in the following section. Finally, it is recommended that, when the delivery notification message is sent, the user agent makes some note of the fact in order to prevent the sending of a duplicate notification message in the future. @section(Example) The following shows a matched pair of messages, the first requesting delivery notification, and the second (presumably automatically generated) providing it. @begin(programexample) From: Nathaniel Borenstein Subject: How are you? Date: Sun, 25 Oct 87 09:46:54 -0500 (EST) To: "Craig F. Everhart" Ack-To: Nathaniel Borenstein Message-ID: Hi, Craig. This is just a test of the user-receipt feature. - Nathaniel From: "Craig F. Everhart" Subject: Confirming: How are you? Date: Sun, 25 Oct 87 10:46:54 -0500 (EST) To: Nathaniel Borenstein Ack: Message-ID: This message confirms the receipt by "Craig F. Everhart" of a message from "Nathaniel Borenstein " on the subject "How are you?" dated "Sun, 25 Oct 87 09:46:54 -0500 (EST)". This is an "explicit" receipt, which means that the user saw the message and agreed to send this confirmation. @end(programexample) @section(References) 1. Crocker, David H. RFC 822: Standard for the Format of ARPA Internet Text Messages. Network Information Center, August 13, 1982.  Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Feb 89 21:56:34 EST Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 8 Feb 89 14:43:49-EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 8 Feb 89 14:25:16 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Feb 89 03:22:43 GMT From: avsd!childers@bloom-beacon.mit.edu (Richard Childers) Organization: die Edelstahlratte Subject: Re: administration fascism Message-Id: <463@avsd.UUCP> References: <445@avsd.UUCP>, <2253@unmvax.unm.edu>, <608@uva.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu dik@uva.UUCP (Casper H.S. Dik) writes: >mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes: >>In short, it may be quite rational to protect users from eachother (by >>protecting /usr/lib/aliases), but it IS facism to "protect" people from >>themselves. >Agreed I beg to disagree, gentlebeings. I am not intent on 'protecting users from each other' when I forbid ~{user}/.forward files ... I am protecting myself. It's not a matter of facism. It's a matter of functionality. I have a mandate, as it were, to maintain the mail subsystem. I also have an unofficial mandate to order my tasks in such a way as to avoid wasting my time. Reading mail to 'root' from 'MAILER-DAEMON', time after time, is a waste of my time. I know what the problem is, I know there is no way I'll ever be able to educate the entire user community, there's always someone browsing the manual - and that, in itself, is a blessing of sorts, since they aren't asking me - so I created a solution, the simplest, cheapest solution I could think of. It works. The meter for determining if the mailer subsystem works, is whether you get any mail from users or MAILER-DAEMON complaining. That's the only meter that really counts. I'm not interfering in anyone's productivity, I'm keeping them from impinging on mine. You may call it administrative fascism ... but I think of it as facilitating things, overall ... maintaining functionality, at the cost of an occasional damaged ego, perhaps, but maintaining functionality. One person objects, but they are inevitably a minority. Is this fascism ? >> Michael I. Bushnell \ This above all; to thine own self be true >> GIG! \ And it must follow, as the night the day, >>mike@turing.cs..unm.edu /\ Thou canst not be false to any man. >> Hmmmm.............. / \ Farewell: my blessing season this in thee! -- richard -- * "Do not look at my outward shape, but take what is in my hand." * * -- Jalaludin Rumi, 1107-1173 * * ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho * * AMPEX Corporation - Audio-Visual Systems Division, R & D *  Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 9 Feb 89 23:39:42 EST Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 9 Feb 89 21:41:09-EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 9 Feb 89 21:26:47 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Feb 89 22:13:38 GMT From: mcvax!kth!enea!front.se!zap@uunet.uu.net (Svante Lindahl) Organization: Front Capital Systems, Stockholm, Sweden Subject: Re: simple encryption in mail (no more legal discussion) Message-Id: <293@front.se> References: <508@solaris.UUCP>, <1119MICHAEL@MAINE>, <485@maxim.ERBE.SE> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <485@maxim.ERBE.SE>, prc@maxim.ERBE.SE (Robert Claeson) writes: # In article <1298@ndmath.UUCP>, krueger@ndmath.UUCP (Andreas Krueger) writes: [ crypt is no good 'cause: ] # > > RESTRICTIONS # > > This program is not available on software shipped outside # > > the U.S. # So let's use DES instead. Even though not included in the export versions # of UNIX, it's universally available and the algorithms are well-known. Yes, definitely available: In volume 10 of comp.sources.unix (summer '87): des DES encryption routines and a login front-end In volume 7 of comp.sources.unix (fall '86): des Purported DES program in C Also available in volume 10: cbw (5 parts) Crypt Breaker's Workbench -- Svante  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Feb 89 15:45:34 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 15 Feb 89 15:38:49 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 10 Feb 89 22:32:17 GMT From: clsib21!lpi!jdc@bbn.com (Dustin Clampitt ) Organization: Language Processors Inc., Framingham MA Subject: Fortune 16/32 parts forsale Message-Id: <276@lpi.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I have just dis-assembled a couple Fortune 16/32 Systems. If you have a need for any replacement parts just let me know. If there is no immediate interest it's all going into the junk parts box. I have: - Motherboards - Keyboards - Monitors - Monitor video boards (ONLY for Fortunes) - Disk controllers cards (ONLY for Fortunes) - Serial I/O cards - Memory cards - Power supplies Make me an offer. I can ship UPS COD. Dustin Clampitt jdc@lpi.uucp -- Dustin Clampitt "Is it Saturday yet?" | Language Processors, Inc. (LPI) | 959 Concord Street, Framingham, Mass. 01701-4613 | UUCP: ....!harvard!necntc!lpi!jdc  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 1 Mar 89 11:06:17 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1419; Wed, 01 Mar 89 11:05:05 EST Received: from VM1.TAU.AC.IL by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1264; Wed, 01 Mar 89 10:59:45 EST Received: by TAUNIVM (Mailer R2.02) id 5115; Wed, 01 Mar 89 17:22:10 IST Date: Wed, 01 Mar 89 17:15:50 IST From: Hank Nussbacher Subject: Problems with .IL domain To: header-people@mc.lcs.mit.edu Reply-To: Hank Nussbacher .IL is a registered upper level domain with SRI. Unfortunately, there is now a .IL.US which stands for Illinois in the USA. It appears that various mailers like to drop off the .US suffix leaving an address with just .IL. Here is an example of what can happen: >220 VM1.TAU.AC.IL Columbia MAILER R2.02 BSMTP service ready. >050 HELO CUNYVM.BITNET >250 VM1.TAU.AC.IL Hello CUNYVM.BITNET >050 TICK 3619 >250 3619 ... that's the ticket. >050 MAIL FROM: >250 ... sender OK. >050 RCPT TO: >250 ... recipient OK. >050 DATA >354 Start mail input. End with . >554-Mail not delivered to some or all recipients: >554 Mail service is not available for >050 QUIT >221 VM1.TAU.AC.IL Columbia MAILER BSMTP service done. > >Original message follows: > >Received: from CUNYVM.BITNET by VM1.TAU.AC.IL (Mailer R2.02) with BSMTP id > 4842; Wed, 01 Mar 89 17:03:26 IST >Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.02A) with BSMTP id 3619; Wed, > 01 Mar 89 10:03:10 EST >Received: from gatech.edu by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Wed, > 01 Mar 89 10:03:07 EST >Received: by gatech.edu (5.58/GATECH-8.6) > id AA26887 for heiby@mcdchg.chi.il; Wed, 1 Mar 89 10:01:29 EST >Date: Wed, 1 Mar 89 10:01:29 EST >From: win@gatech.edu (Win Strickland Jr) >Message-Id: <8903011501.AA26887@gatech.edu> >To: heiby@mcdchg.chi.il >Subject: Re: phone bill blues I have seen cases where the RFC822 header did have the .IL.US but the SMTP envelope only had .IL. In the case above, neither has the extra .US that should be there. I think someone should take care of this. I would imagine that of the 50 states, there must be quite a few with a matching European or Far East country that has their upper level domain registered. I am not on this list, so please reply directly to me if you have a solution. Hank  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 Mar 89 13:50:58 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 2 Mar 89 13:40:14 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Mar 89 18:25:57 GMT From: mailrus!wasatch!cs.utah.edu!mike@ohio-state.arpa (Mike Hibler) Organization: University of Utah, Computer Science Dept. Subject: VAXen for sale (Salt Lake City, UT) Message-Id: <1223@wasatch.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu This is posted for a friend. Send mail to him, not me: --- For sale: VAX 8650.................. floating point accelerator Unibus expansion box 80Mb ram Star Coupler HSC50 4 RA82's 3 RA81's TA78 tape drive DEC maintained since purchase VMS,DECNET,C,PASCAL,FORTRAN,LISP,BLISS CMS,MMS,PCA,LSE,SCAN,ETHERNIM,SPM $380,000 VAX 750..................... floating point accelerator RA81 disk TU80 tape 6Mb ram ethernet controler DEC maintained since purchase $10,000 6 VAXSTATION II's........... VR260 19" monocrhome monitors dual floppy disks 6Mb to 10Mb ram 30Mb to 150Mb disk DEC maintained since purchase $7,000 to $8,000 Howard Hughes Medical Institute Al Tingey 801-581-4157 al%howard@cc.utah.edu  Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 9 Mar 89 19:33:31 EST Received: from TWG.COM by twg.com with SMTP ; Thu, 9 Mar 89 16:32:00 PST Received: from obelix by Obelix.TWG.COM id aa22109; 9 Mar 89 18:36 PST Reply-To: James M Galvin To: header-people@mc.lcs.mit.edu Subject: 3 month old waiting mail message Date: Thu, 09 Mar 89 16:36:17 -0800 Message-ID: <22104.605493377@twg.com> From: James M Galvin This is outstanding! I just got this waiting mail message for a message I sent to header-people almost 3 months ago. In fact, I just got several of them. Jim ------- Forwarded Message Sender: mmdf@bbn.com From: BBN Mail System (MMDF) To: @bfly-vax.bbn.com,@ice.bbn.com,@f.bbn.com,@mc.lcs.mit.edu,@TWG.COM:ga lvin@TWG.COM Date: Mon, 6 Mar 89 3:01:37 EST Subject: Waiting mail (msg.kn02771) After 4 days (78 hours), your message has not yet been fully delivered. Attempts to deliver the message will continue for 8 more days. No further action is required by you. Delivery attempts are still pending for the following address(es): ~RSCHAAF@ice.bbn.com (host: ice.bbn.com) (queue: smtp) Problems usually are due to service interruptions at the receiving machine. Less often, they are caused by the communication system. Your message begins as follows: Received: from bfly-vax.bbn.com by BBN.COM id kn02771; 2 Mar 89 20:44 EST Received: from ice.bbn.com by BFLY-VAX.BBN.COM id nb04282; 2 Mar 89 17:49 EST Received: from f.bbn.com by NONAME.bbn.com id ab00522; 28 Dec 88 20:36 EST Received: from MC.LCS.MIT.EDU by F.BBN.COM; Wed 28 Dec 88 20:45:53-EST Received: from twg.com (TCP 3201200111) by MC.LCS.MIT.EDU 28 Dec 88 19:08:23 ES T Received: from TWG.COM by twg.com with SMTP ; Wed, 28 Dec 88 15:31:03 PST Received: from obelix by Obelix.TWG.COM id aa06570; 28 Dec 88 17:32 PST Reply-To: James M Galvin To: msir@cc.rochester.edu cc: header-people@mc.lcs.mit.edu Subject: Re: Simple form of RFC 822? In-reply-to: Your message of Wed, 28 Dec 88 17:44:34 EST. <8812282244.20958@uhura.cc.rochester.edu> Date: Wed, 28 Dec 88 15:32:31 -0800 Message-ID: <6567.599355151@twg.com> From: James M Galvin > Except that there's this thing called a standard, currently defined by > RFC-822. All mailers on the internet should handle any address specified ... ------- End of Forwarded Message  Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 21 Mar 89 13:35:09 EST Received: by ATHENA.CS.YALE.EDU; Tue, 21 Mar 89 13:35:26 EST Date: Tue, 21 Mar 89 13:35:26 EST From: Pradeep Varma Full-Name: Pradeep Varma Message-Id: <8903211835.AA10658@ATHENA.CS.YALE.EDU> Received: by yale-ring (node-acee/ACEE) via WIMP-MAIL (Version 1.3/1.5) ; Tue Mar 21 13:18:41 To: header-people@mc.lcs.mit.edu Subject: "too many hops" hi, I am maintaining some mailing lists, and often when I broadcast a message sent to me, I get bouncebacks because of "too many hops". An example of such a bounceback is enclosed. I would greatly appreciate it if someone could suggest a scheme that would take care of this problem while redirecting the mail to the lists automatically. Thanks for any answers, Pradeep P.S I know a manual hack. Take the incoming mail message to an editor and strip the "Received: ... " lines from it before sending it off again. But I don't particularly like it. I think it will mess up people replying to the original message. 1989/03/18.09:58:12,8316;01 Received: by YALE-RING-MAIL-GW via SSMTP ($Revision: 1.19 $) ; Fri Mar 17 19:43:19 1989 Received: from uunet.UU.NET by ELI.CS.YALE.EDU; Fri, 17 Mar 89 19:35:10 EST Full-Name: Received: from mcvax.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA07527; Fri, 17 Mar 89 19:36:54 -0500 Received: by mcvax.cwi.nl via EUnet; Fri, 17 Mar 89 15:40:37 +0100 (MET) Received: from irisa.irisa.fr by inria.inria.fr (5.61+/89.0.5) via Fnet-EUnet id AA11104; Fri, 17 Mar 89 08:41:10 +0100 (MET) Message-Id: <8903170741.AA11104@inria.inria.fr> Received: by irisa.irisa.fr; Fri, 17 Mar 89 08:42:22 +0100 (3.2/M3.1) Date: Fri, 17 Mar 89 08:42:22 +0100 From: mcvax!irisa.fr!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem) Subject: Returned mail: Unable to deliver mail To: ----- Transcript of session follows ----- 554 ... Mail loop detected 554 sendall: too many hops (15 max) ----- Unsent message follows ----- Received: by irisa.irisa.fr; Fri, 17 Mar 89 08:42:22 +0100 (3.2/M3.1) Received: by inria.inria.fr (5.61+/89.0.5) via Fnet-EUnet id AA11078; Fri, 17 Mar 89 08:40:33 +0100 (MET) Received: from kth.se by enea.se (5.57++/1.103) via EUnet id AA28932; Fri, 17 Mar 89 06:59:37 +0100 (MET) Received: from chalmers.se by kth.se (5.57+IDA+KTH/4.0) id AA28226; Fri, 17 Mar 89 06:55:49 +0100 Received: from fnatte.cs.chalmers.se by chalmers.se id AA28711; Fri, 17 Mar 89 06:57:49 +0100 Received: from chalmers.se by fnatte.cs.chalmers.se id AA10843; Fri, 17 Mar 89 06:57:04 +0100 Received: from kth.se by chalmers.se id AA28703; Fri, 17 Mar 89 06:56:35 +0100 Received: from enea.se by kth.se (5.57+IDA+KTH/4.0) id AA28159; Fri, 17 Mar 89 06:52:23 +0100 Received: by enea.se (5.57++/1.103) via EUnet id AA28836; Fri, 17 Mar 89 06:54:53 +0100 (MET) Received: by mcvax.cwi.nl via EUnet; Fri, 17 Mar 89 06:44:50 +0100 (MET) Received: from CS-GW.CS.YALE.EDU by uunet.UU.NET (5.61/1.14) with SMTP id AA08339; Thu, 16 Mar 89 15:17:00 -0500 Received: by ELI.CS.YALE.EDU; Thu, 16 Mar 89 12:12:54 EST Resent-Date: Tue, 14 Mar 89 17:30:41 CST Resent-Message-Id: <8903161712.AA11470@ELI.CS.YALE.EDU> Received: by yale-ring (node-acee/ACEE) via WIMP-MAIL (Version 1.3/1.5) ; Thu Mar 16 12:00:25 Received: by YALE-RING-MAIL-GW via SSMTP ($Revision: 1.19 $) ; Tue Mar 14 18:38:52 1989 Received: from a.cs.uiuc.edu by ELI.CS.YALE.EDU; Tue, 14 Mar 89 18:29:50 EST Received: from reddy (reddy.cs.uiuc.edu) by a.cs.uiuc.edu with SMTP (UIUC-5.52/9.7) id AA03940; Tue, 14 Mar 89 17:31:16 CST Received: by reddy (4.0/9.7) id AA08852; Tue, 14 Mar 89 17:30:41 CST Date: Tue, 14 Mar 89 17:30:41 CST From: reddy%reddy.cs.uiuc.edu@a.cs.uiuc.edu (Uday S. Reddy) Message-Id: <8903142330.AA08852@reddy> To: kamin@tatoo.inria.Fr Cc: fp@YALE.ARPA In-Reply-To: Sam Kamin's message of Wed, 8 Mar 89 11:15:01 +0100 <8903081014.AA06940@inria.inria.fr> Subject: Haskell comments - please post to fp mailing list Reply-To: reddy@a.cs.uiuc.edu Resent-From: varma@YALE.ARPA Resent-To: fp-other@YALE.ARPA, fp-others-under-us@YALE.ARPA, fp-local@YALE.ARPA, fp-us1@YALE.ARPA, fp-us2@YALE.ARPA, fp-us3@YALE.ARPA  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Mar 89 15:29:03 EST Date: Tue, 21 Mar 1989 15:31 EST Message-ID: From: Rob Austein To: Pradeep Varma Cc: header-people@MC.LCS.MIT.EDU Subject: "too many hops" In-reply-to: Msg of 21 Mar 1989 13:35-EST from Pradeep Varma Removing "Received:" headers shouldn't affect anybody's ability to reply. Received headers are intended for tracing purposes only. Any mail User Agent (UA) that attempts to do clever things with Received headers is broken. Humans who have to analyze Received headers to figure out how to reply to a message are victims of broken mailers. Since you are reposting these messages, presumably you can verify that the From: or Reply-To: headers look moderately reasonable before passing the messages along. Having mailer daemons that count Received headers is a cute idea but probably misguided, as your problems show; the correct thing to do would be to count, or preferably do some kind of intelligent analysis on, entries in the Return-Path. (Yes, I know that there are hosts that don't update the return path, but then there are hosts that don't add received headers either, gotta draw a line somewhere....) The real problem appears to be that the mailer in question has an "unreasonably low" value set for what it thinks is a mailer loop (15 probably seemed like a reasonable idea when it was chosen, years ago). Unless you can convince the owners of the mailers in question to fix this behavior, stripping out the Received lines when you repost is probably as good a kludge as you're going to get. --Rob  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Mar 89 05:45:43 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 25 Mar 89 05:20:08 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 24 Mar 89 12:35:26 GMT From: oliveb!apple!well!pokey@ames.arpa (Jef Poskanzer) Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal Subject: Is comp.mail.headers dead? Message-Id: <11074@well.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu This newsgroup has not has any traffic in quite a while. Is it dead? Should we give it a decent burial? As I recall, this newsgroup is gatewayed to mailing list. Perhaps the mailing list is active but the gateway is broken? --- Jef Jef Poskanzer jef@helios.ee.lbl.gov ...well!pokey  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Mar 89 03:31:05 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 27 Mar 89 03:26:48 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 Mar 89 13:56:06 GMT From: attcan!dptcdc!berner!contact!rlerdorf@uunet.uu.net (Rasmus Lerdorf) Organization: Contact User Supported BBS. Toronto, Ontario. Subject: Re: Is comp.mail.headers dead? Message-Id: <446@contact.UUCP> References: <11074@well.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu At the risk of sounding completely ignorant here, what is the topic of discussion in this poor lonely newsgroup? -- /> Rasmus Lerdorf | `-_-' | Hurra for Danske piger! <\ // rlerdorf@contact.UUCP | 'U` | Support the morally handicapped \\  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Mar 89 13:31:21 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 27 Mar 89 13:25:06 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 27 Mar 89 18:07:41 GMT From: mailrus!shadooby!wisner@ohio-state.arpa (Bill Wisner) Organization: Amnesia International Subject: Re: Is comp.mail.headers dead? Message-Id: <236@shadooby.cc.umich.edu> References: <11074@well.UUCP>, <446@contact.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu No, it's not dead. Just quiet. That happens periodically.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Mar 89 19:16:24 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 27 Mar 89 19:05:02 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 27 Mar 89 21:42:56 GMT From: att!pegasus!ech@bloom-beacon.mit.edu (Edward C Horvath) Organization: AT&T ISL Middletown NJ USA Subject: Re: Is comp.mail.headers dead? Message-Id: <2723@pegasus.ATT.COM> References: <236@shadooby.cc.umich.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu From article <236@shadooby.cc.umich.edu>, by wisner@shadooby.cc.umich.edu (Bill Wisner): > No, it's not dead. Just quiet. That happens periodically. Hmm, sounds like the parrot..."It's just pinin' for the fjords"  Received: from Cs.Ucl.AC.UK (TCP 20004003004) by MC.LCS.MIT.EDU 29 Mar 89 05:08:44 EST Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id aa01448; 29 Mar 89 10:04 GMT To: header-people@mc.lcs.mit.edu Subject: 987 - try again Date: Wed, 29 Mar 89 11:01:48 +0100 Message-ID: <24996.607168908@UK.AC.UCL.CS> From: Steve Kille Source-Info: purple.cs.ucl.ac.uk Your message could not be delivered to.... To: ifip-gtwy@tis.llnl.gov cc: mailgroup@Cs.Ucl.AC.UK, header-people@ms.lcs.mit.edu, rare-wg1@vax.runit.unit.uninett, iso@sri-nic.arpa, iso-tg@compsci.bristol.ac.uk Subject: RFC 987 (88) Phone: +44-1-380-7294 Date: Wed, 29 Mar 89 09:45:57 +0100 Message-ID: <18186.607164357@UK.AC.UCL.CS> From: Steve Kille Source-Info: purple.cs.ucl.ac.uk I'm posting this message wide - apologies to those who get duplicates. Please do NOT reply to all of the CC lists. RFC 987 is a specification to map between RFC 822 based protocols and X.400 (1984). I have just completed the first draft of the version to map to X.400 (1988) - a quite substantial update. For now, I am calling this RFC 987(88). I hope that this specification can gain wide acceptance, following input from all interested parties. I propose to use the ifip-gtwy list to discuss this specification. I will be circulating the specification by mail in two weeks time (April 11th) - experience has suggested that there are too many interested parties without file transfer access. This should give interested people sufficient time to get onto the list. Send to ifip-gtwy-request@tis.llnl.gov. For UK people send to arpa-mhs-request@uk.ac.ucl.cs. I suggest that other Europeans should get national expansions. People should also get themselves copies of X.400 (88) - at least the DIS. I'm sure that "how to get the standard" will be discussed on ifip-gtwy. I am proposing to hold a meeting on 27-28 June in London to finalise this specification following electronic discussion. Put this date in your diaries! If there is sufficient request, it may be useful to also hold a one day meeting sometime in early May. Steve ------- End of Forwarded Message  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 29 Mar 89 15:27:23 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 1766; Wed, 29 Mar 89 15:28:37 EST Received: from CARLETON.CA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8222; Wed, 29 Mar 89 15:28:36 EST Received: by CARLETON (Mailer); Wed, 29 Mar 89 15:14:13 EST Date: Wed, 29 Mar 89 15:12:15 EST From: Walter_Roberson%CARLETON.CA@mitvma.mit.edu To: header-people@mc.lcs.mit.EDU Message-Id: <890329.15124491.020412@ADMIN.CP6> Subject: mangled 'From:' starting with '!' Check out the mangled From: field in the header quoted below. I've enclosed most of it just for completeness. The message was redistributed by the apollo mailing list: our system had it marked as being from apollo-request@umix.cc.umich.edu . Thus, the From: field shown below was in the body of the message, not in the envelope of the resent message. Anyone care to take a guess which system was responsible for putting the '!' as the first component of the From: path? Walter Roberson ---- begin quoted message --- Received: by CARLETON (Mailer); Wed, 29 Mar 89 14:42:35 EST Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.01) with BSMTP id 8377; Wed, 29 Mar 89 14:10:50 EST Received: from umix.cc.umich.edu by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP ; Wed, 29 Mar 89 14:10:41 EST Received: by umix.cc.umich.edu (5.54/umix-2.0) id AA00853; Wed, 29 Mar 89 07:21:26 EST Received: by umix.cc.umich.edu (5.54/umix-2.0) id AA06936; Wed, 29 Mar 89 05:54:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA00984; Wed, 29 Mar 89 02:43:44 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for apollo-arpa@umix.cc.umich.edu (apollo@umix.cc.umich.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Mar 89 21:49:26 GMT From: !sharp%calgary%alberta%ncc%pyramid%oliveb.uucp@apple.com (Maurice Sharp) Subject: Re: EMACS for Apollo? Message-Id: <979@cs-spool.calgary.UUCP> References: <42467373.f81c@lexington.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu E-MAIL : sharp@ksi.cpsc.UCalgary.CA EAN : sharp@calgary.CDN --- end of quoted message --- Walter Roberson  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Apr 89 10:03:34 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Apr 89 09:59:05 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Apr 89 15:40:19 GMT From: mcvax!ukc!tcdcs!tcdmath!ajudge@uunet.uu.net (Alan Judge) Organization: Maths Dept., Trinity College, Dublin Subject: Re: mail headers Message-Id: <712@maths.tcd.ie> References: <5463@ozdaltx.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >Wouldn't it be wonderful to receive e-mail WITHOUT scads of >notations of 'Received by:' at the beginning of each >message? Does anyone really care what system received the >message, that systems ID number and a time stamp to boot? I >can tell what sites the message went through by looking at >the path line plus I can read the date the message was sent >and I know when I received it. Most system administrators will tell you that the Received headers are very useful when diagnosing problems or holdups in mail. With the number of "intelligent" mailers out there now, they are also of considerable use in finding out how messages are being routed. Most mail messages do not have a "path line" (this is a news only phenomenon) and most smart mailers do *not* modify the mail headers (such as from:) to indicate what sites the message has been through. Therefore without the Received headers there is no way to determine the routing of the message. Without routing information it is sometimes impossible to reply at all. For example, a mail message I just received just said mmdf2@relay.cs.net in the From: line. Without Received lines I would not know it had been through tcdcs, ccvax.ucd.ie, irlearn.bitnet, cunyvm.cuny.edu, relay.cs.net Admittedly, some mailers put in useless information into headers, but I think that the host name and time should definitely be kept. Anyway, if you are using a nice mail reader you shouldn't even see headers like Received, Message-id etc.. unless you explicitly ask. >Not to mention the bytes saved in transmission by >eliminating all this garbage. What can be done???? Transmission times for mail are usually dwarfed by those for news anyway. >Scotty >{ames,rutgers,texsun,smu}!killer!ozdaltx!sysop -- Alan Judge, SysAdmin, Dept. of Maths, Trinity College, Dublin, Ireland. Smart: ajudge@maths.tcd.ie Stupid: ...!uunet!maths.tcd.ie!ajudge P.S. I have crossposted to comp.mail.headers and directed followups there since this does not belong in news.sysadmin.  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 11 Apr 89 22:20:24 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 2240; Tue, 11 Apr 89 22:22:24 EDT Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 9650; Tue, 11 Apr 89 22:21:52 EDT Date: Tue, 11 Apr 89 19:19 PDT From: Leonard D Woren To: Header People Subject: Hostname in Message-Id I have a philosophy question regarding the host name which must appear in the Message-Id: line. Suppose that I send one message to two recipients, one at foo.bar.edu, and the other at mung.bitnet . Since my host is on both networks, it has two names -- MVSA.USC.EDU and USCMVSA.BITNET . The message id as seen by the user at foo.bar.edu should be "local.part@MVSA.USC.EDU", but the message id as seen by the Bitnet user should be "local.part@USCMVSA". This offends my sensibilities. I claim that RFC 822 requires that all copies of one message have identical message ids. Since most Bitnet mailers can be handed mail to .....edu addresses and deliver it correctly, via a gateway if necessary, I see no reason why the Bitnet recipient should not get the same message id as the Internet recipient. In other words, always use my Internet name in the Message-Id. Comments? I had a long argument with another mail expert who claims that the Message-Id should be transformed at network boundaries the same way that From:/To:/Cc: are transformed. I claim that this invalidates the Message-Id, since there are now multiple copies of a single message with differing message ids. Leonard D. Woren Senior MVS Systems Programmer MVS Postmaster University of Southern California  Received: from valeria.cs.ucla.edu (TCP 20354640044) by MC.LCS.MIT.EDU 12 Apr 89 00:51:20 EDT Return-Path: Received: by valeria.cs.ucla.edu (Sendmail 5.59/2.16) id AA05030; Tue, 11 Apr 89 21:15:38 PDT Date: Tue, 11 Apr 89 21:15:35 PDT From: Rich Wales Message-Id: <890412.041535z.05012.wales@valeria.cs.ucla.edu> To: Leonard D Woren Cc: header-people@MC.LCS.MIT.EDU Subject: Re: Hostname in Message-Id In-Reply-To: Message of Tue, 11 Apr 89 19:19 PDT from "Leonard D Woren " <8904112259.aa27835@mintaka.lcs.mit.edu> Leonard -- Replying to your question about whether the host name in a Message-ID should be changed depending on which network the messages goes out on: My understanding is that this should *not* be done. Two reasons: (1) As you pointed out, name-changing in Message-ID's would make it impossible for different recipients on the two different networks to be sure they were both talking about the same message. (2) The domain naming system was designed with the idea that each host would have exactly *one* primary name, irrespective of whatever network(s) it might be on. The whole concept of having domain-style names ending in ".BITNET", ".UUCP", ".CSNET", etc. is considered an evil abomination by domain purists. To be sure, the operational realities of some networks have forced some sites to adopt multiple, network-specific names -- but this has never been accepted offi- cially, and you aren't going to find anything in any of the RFC's that acknowledges the legitimacy of this practice. -- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683 3531 Boelter Hall // Los Angeles, California 90024-1596 // USA wales@CS.UCLA.EDU ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales "Fate protects fools, little children, and ships named _Enterprise_."  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 12 Apr 89 08:55:21 EDT Received: by INFOODS id <000000D5072@INFOODS.MIT.EDU> ; Wed, 12 Apr 89 08:49:35 EDT Date: Wed, 12 Apr 89 07:48:06 EDT From: John C Klensin Subject: Re: Hostname in Message-Id To: Leonard D Woren , header-people@MC.LCS.MIT.EDU X-VMS-Mail-To: EXOS%"Leonard D Woren ", EXOS%"header-people@MC.LCS.MIT.EDU" Message-ID: <890412074806.000000D5072@INFOODS.MIT.EDU> I think this response should be subtitled as "stop worrying about things you can't change". In my capacity of a self-designated DNS purist, your reasoning is absolutely correct: one host, one name regardless of what it happens to be connected to, with one qualification, noted below. And gateways should, pragmatically, not mess with any fields that they don't have to mess with. Message-IDs are not such a field, especially since the gateway can't know how the ID itself (independent of host names) is created by the sending system. If it did, it might discover a need to transform them to, say, local time. A half-transformed field is always worse than a fully-transformed field. But there is a qualification to all of this. Never (well, hardly ever) did even the most optimistic believe that either RFC822 or the DNS would apply to all of the machines, on all of the networks, in the world. They were designed so that, if successful, they could serve that role, but without the expectation that they *would* serve that role. If you have a host that is reached from the Internet and that does not obey the DNS rules, or even the RFC822 rules, then (i) that is why there are conventions about embedding non-Internet host names in the 'local part' of an address and (ii) gateways have to be somewhat aggressive about the transformations they perform. The aggressiveness is expected to be bidirectional, although there is no way to enforce this and, in some cases, it can't work. "Bidirectional" implies that, if a gateway performs a transformation as a message goes through a gateway, that the translation is invertable and that the inverse operation is performed by whatever gateway, or meta-gateway, passes the message back. That is possible in practice with real gateways that do not also house the UAs. But, when you, Leonard, have a machine that is hosted on both BITNET and the Internet (note that I'm discussing its connections, not its name), and you send something out via BITNET and get it back via the Internet via someone else's gateway, I don't know what expectations you can have. In any event, the "single name" rules of the DNS apply to something that we can think of, conceptually, as an "extended Internet": networks that are part of the DNS namespace and that obey other Internet rules, including the Internet's view of what gateways should do to headers of messages passed in and out. By that definition, it is not clear that BITNET is a member of the "extended Internet". As you say, from a DNS purist standpoint, "foo.BITNET" is an obscenity, and it is a public obscenity if "foo.bar.edu" also exists and is the same machine. But only some BITNET machines have names that are registered with the DNS. Indeed, only some of them run MAILERs that support DNS names and RFC822. And, from a purist standpoint, any gateway that permits a message to enter the Internet that contains header fields or field components not specified in RFC822 is, at least, ill-behaved. Given what the INTERBIT machines don't filter, there is another argument that, while BITNET co-exists reasonably well with the Internet, it is not part of this conceptual extended Internet. Now, let me reconstruct some early, and very informal, discussions: If you care about what is in a Message-ID, and are on a host different from the originator, you are going well beyond what RFC822 and its predecessors intended for that field. If you are a gateway, and transform it, you are probably obligated to transform it back before sending to the original host. And, since you probably can't get that right, you should probably keep hands off. But correct universal use of a Message-ID requires going well beyond what RFC822 specifies. Assume that I'm operating in a workstation environment, with a local UA, but with the MTA on the next machine down the line. Assume further that my "address" is on the machine with the MTA, that I communicate with it using "post office" protocols, not ordinary SMTP. Just to complicate life, assume that the MTA-machine is a multiprocessor, with a high degree of parallel capability. Let's also assume that the MTA machine is a host on multiple networks, some of which are *not* part of the DNS, even at the MX level, for one reason or another, and some of which don't use anything resembling RFC822. In this environment, there are significant advantages to seeing the workstations (I may use different ones on different days) as a UA function, not an MTA function. That reasoning is consistent with the SMTP/RFC822 boundary: you don't see Message-IDs in the envelope, do you? But, if "host" in the Message-ID is going to be the MTA hostname, then it is going to be hard to guarantee uniqueness--at least uniqueness that you, the receiver, can understand and use. I can give it to you probabilistically. Or we can encode the latitude and longitude (to the nearest 20cm) of the sender (not the workstation, please) and the time (in GMT, to the nearest half-second) in the Message-ID to make it unique. That raises a few other problems, but... Finally, people who believe that gateways should transform Message-ID fields are probably obligated to believe that they should transform "Received" fields. But that is a potential catastrophe, destroying all of the information needed when something goes wrong. Note that, when we (as an Internet host) get a message forwarded from your BITNET side via an INTERBIT gateway, I see a Received field that says ".. from UCBMVSA.BITNET by MITVMA.MIT.EDU ... with BSMTP...". It is followed (in time) by a Received field containing "from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP...) ... with BSMTP...". Want to argue for something else? I do, but the "it should transform" argument would like it less, and that would use "MITVMA.BITNET" where "MITVMA.MIT.EDU" appears above, but "mitvma.mit.edu" where that appears in lower case. It is in that intra-machine transfer that "gateway" happens, and, before that, these are separate networks with different protocols. Conclusion: (1) Gateways should probably not change them. (2) If you consider your host to be part of the DNS, and part of the extended Internet in all of its transactions and in all of the networks to which it is attached, then it should have only one name in all of those (that?) namespace. (3) If you count on any of this, you are looking for trouble. Please consider a related problem, which is more interesting and more of a problem: You send mail to header-people@mc.lcs.mit.edu. mc.lcs.mit.edu is an Internet site, with no direct connections to BITNET. Something at your end decides to route that message via BITNET, presumably because it has been told to prefer BITNET and its DOMAIN NAMES tables (the closest BITNET gets to DNS MX resolution) says "send it to MITVMA via BITNET". MITVMA gets it, opens an SMTP connection to MC, and sends the message off. So far, so good. But the gateway code on MITVMA says "this got here via BITNET, it may have to go back via BITNET" and "fixes" your address so that it says "LDW%MVSA.USC.EDU@mitvma.mit.edu". But if I, or MC, 'reply' to that, we violate the principle that says that we don't use network B to carry a message between two hosts on network A. Question: what should the gateway do? Consider that, if the message originates from a bitnet-connected host that is not part of the DNS, it must say user%host.BITNET@mitvma.mit.edu If it says anything else, it is in violation of the DNS (and 822 rule) that says that nothing runs around the Internet with something that looks like a host name in an address that isn't a [DNS-registered] host name. Should it look MVSA.USC.EDU up with the DNS and leave the address in LDW@MVSA.USC.EDU if it finds an "A" record? How about if it finds an "A" record or an "MX" record? (Keep in mind that many MILNET hosts, and more than a few other Internet hosts, still lack DNS resolvers). Whatever the answer to that question, would finding an MX record that points back to MITVMA change your answer? And, finally, if it does that lookup and finds a CN record that says your name is "CORRAL" and not "OUTLAW" (no apologies to the slandered who are using non-primary names in their From fields), should it "fix" it? I suggest that, whatever your answer, the gateway can't do the "right" thing without actually looking up the putative DNS name and being sure that it is one. And then, sometimes, you are not going to like the answer to any firm rule, since MITVMA may know some things about connections, transport arrangements, and temporary congestion points at the time the message is answered that you can't know, a day or two earlier. On the other hand, this situation could use a better set of rules. Someone should propose some. John Klensin, MIT Klensin@INFOODS.MIT.EDU  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 09:31:50 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 3192; Wed, 12 Apr 89 09:33:50 EDT Received: from Pythag.ucl.ac.be by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 3211; Wed, 12 Apr 89 09:32:05 EDT Received: by BUCLLN11 (Mailer R2.03B) id 3422; Wed, 12 Apr 89 09:35:30 +0200 Date: Wed, 12 Apr 89 09:32:23 +0200 From: "Alain FONTAINE (Postmaster - NAD)" Message-Id: <890412.093223.+0200.af@sei.ucl.ac.be> Subject: Re: Hostname in Message-Id To: Header-People Discussion In-Reply-To: Message of Tue, 11 Apr 89 19:19:00 PDT from If at BITNET site still has no software dealing with domain addressed mail, there is only a very small probability (to say the least) that it will have any software handling the 'message-id' header item... So I can't see any reason to put a BITNET NJE hostname in a 'message-id' header line... /AF  Received: from HUSC3.HARVARD.EDU (TCP 20031600465) by MC.LCS.MIT.EDU 12 Apr 89 10:02:49 EDT Date: Wed, 12 Apr 89 09:53 EDT From: Danny Padwa Subject: Multi-Networked Hosts (was Hostname in Message-ID) To: header-people@mc.lcs.mit.EDU, John C Klensin , Leonard D Woren X-VMS-To: IN%"header-people@mc.lcs.mit.edu", IN%"John C Klensin ", IN%"Leonard D Woren ",PADWA I think John hit the nail on the head when discussing the difficulties faced by gateways that are "multi-homed" on both BITnet (or other non-RFC822 systems) and the Internet. One major problem is that our Interbit gateways perform address munging that cannot be undone by us here. I can't count how many messages I've received with return addresses of the form: user%host.bitnet@cunyvm.cuny.edu How do I respond? RFC822 pretty clearly prohibits me from messing with the local part of this address (user%host.bitnet) and sending it directly over BITnet. Yet sending via CUNYVM is clearly inefficient. One possible solution to this is to rename the INTERBIT gateways from the Internet side, more along the lines of the BITnet solution. There, instead of pointing records towards any specific gateway, all hosts send mail to the gateway address on node "INTERBIT", which is routed to the closest node. Perhaps we could allocate a subspace of the DNS and put such "special" gateways in there. Then, the INTERBIT gateways could all set return addresses to be INTERBIT.GATES.NET or INTERBIT.BIT.NET or some other monstrosity. Then (how is this for ugly, awful, despicable hacking?) any host that is on both nets can munge its mailer configuration files to strip away INTERBIT from either side, and process the remaining address. I know this violates our "never-make-exceptions-to-the-rules" rule, but since any such multi-netted host must have complex mailer configurations anyway, you can't really complain. While we're on the topic of incompatibilities between the BITnet and Internet, I think we need to address BITnet's "wanton" use of invalid domain-style names. I don't mind any non-Internet site calling itself foo.bar, as long as proper MX records are located somewhere. Harvard and Berkeley both provide MX service for BITnet only sites that want domain names.....sites that insist on using names not in the DNS only manage to greatly confuse things. Any suggestions? Danny Padwa Harvard University VMS Network Programmer Padwa@Husc3.Harvard.Edu Padwa@Husc3.Bitnet  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 10:02:51 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 3308; Wed, 12 Apr 89 10:04:41 EDT Received: from IRLEARN.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 3595; Wed, 12 Apr 89 10:02:22 EDT Received: by IRLEARN (Mailer X1.24) id 3149; Wed, 12 Apr 89 12:32:28 GMT Date: Wed, 12 Apr 89 12:25:56 GMT From: "Niall O'Reilly (NOREILLY@IRLEARN.UCD.IE)" Subject: Re: Hostname in Message-Id To: HEADER-PEOPLE@MC.LCS.MIT.EDU cc: Tom Wade In-Reply-To: Message of Tue, 11 Apr 89 19:19:00 PDT from I agree with Leonard. Message-Id fields should not be munged by gateways. I don't see what functional benefit there could be in munging them. There may be an aesthetic advantage, but I think that the functional must come first in this case. Now, it seems to me a matter of no functional significance which of the (perhaps multiple) domain- or node- aliases is used in forming the Message-Id. Niall O'Reilly EARN/.IE gatemaster [Hmm ... I wonder what my own gateway does ... 8-)]  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 15:43:54 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 4509; Wed, 12 Apr 89 15:45:21 EDT Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 8696; Wed, 12 Apr 89 15:45:20 EDT Date: Wed, 12 Apr 89 12:39 PDT To: Danny Padwa Cc: header-people@MC.LCS.MIT.EDU From: Leonard D Woren Subject: Re: Multi-Networked Hosts (was Hostname in Message-ID) > While we're on the topic of incompatibilities between the BITnet and > Internet, I think we need to address BITnet's "wanton" use of invalid > domain-style names. I have repeatedly argued this point in a number of Bitnet forums, and I always lose. My argument is that sites that are not reachable on the Internet (via DNS) MUST NOT be allowed to use DNS-style names. Bitnet-only sites all too often don't have a reasonable perspective on these things. > I don't mind any non-Internet site calling itself > foo.bar, as long as proper MX records are located somewhere. Harvard and > Berkeley both provide MX service for BITnet only sites that want domain > names.....sites that insist on using names not in the DNS only manage > to greatly confuse things. YES! The :Interconnect.MX value in Bitnet's DOMAIN NAMES file should be banned, and Bitnet sites with DNS-style names without MX service should be banned. Leonard D. Woren Senior MVS Systems Programmer MVS Postmaster University of Southern California  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 17:43:52 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 4831; Wed, 12 Apr 89 17:45:48 EDT Received: from NIHCU.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 0035; Wed, 12 Apr 89 17:45:19 EDT To: HEADER-PEOPLE@MC.LCS.MIT.EDU From: "Roger Fajman" Date: Wed, 12 Apr 89 17:40:37 EDT Subject: Re: Multi-Networked Hosts (was Hostname in Message-ID) > > While we're on the topic of incompatibilities between the BITnet and > > Internet, I think we need to address BITnet's "wanton" use of invalid > > domain-style names. > > I have repeatedly argued this point in a number of Bitnet forums, and > I always lose. My argument is that sites that are not reachable on > the Internet (via DNS) MUST NOT be allowed to use DNS-style names. > Bitnet-only sites all too often don't have a reasonable perspective on > these things. > > > I don't mind any non-Internet site calling itself > > foo.bar, as long as proper MX records are located somewhere. Harvard and > > Berkeley both provide MX service for BITnet only sites that want domain > > names.....sites that insist on using names not in the DNS only manage > > to greatly confuse things. > > YES! The :Interconnect.MX value in Bitnet's DOMAIN NAMES file should > be banned, and Bitnet sites with DNS-style names without MX service > should be banned. All BITNET domains should be reachable through the Internet. For those sites who do not have their own, Harvard and Berkeley provide the domain name service, with suitable MX records. The only exceptions are a few old domains like .UUCP for which name service is not allowed. No new domains like that are allowed to be created in BITNET. :interconnect.MX has nothing to do with sending mail from the Internet to BITNET. It exists to aid sites that have both BITNET and Internet connections in making a decision about which network to use for sending the mail.  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 12 Apr 89 18:52:29 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5064; Wed, 12 Apr 89 18:53:47 EDT Received: from DBNGMD21.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 0898; Wed, 12 Apr 89 18:47:01 EDT Message-ID: <"89-04-13-00:19:56.52*GRZ027"@DBNGMD21.BITNET> Date: Thu, 13 Apr 89 00:19 To: Header-People Discussion From: Peter Sylvester +49 228 8199645 Subject: Re: Hostname in Message-Id I would like to see the JANET internal version of an internet orinated message-id. It is known the JANET uses a "domain format" which is syntactically identical to RFC822 but the domains are just reversed. Therefore message-id are hopefully either reversed in all gateways between JANET and internet. All Internet/Bitnet gateways do at least some EBCDIC/ASCII translation. This might not be considered as "header munging" but it is known that IBM has some problems to define globally unique translate tables for some special characters. I would like to know how I could gateway some internet message-id into some X.400 ip-message-id *without* "header-munging", in this case it is at least a different "encoding". For details I refer to RFC987. If a BITNET internal mail system that has NO internet "name" wants to generate a globally unique id, how can it do that? It could create @node.BITNET as a suffix and ((un)fortunately) there would be no conflict with a "correct" internet message-id. What about all the uucp mail systems that have no internet name? Ah hm, somehow someone managed to get a @uunet.uu.net suffix..... These examples/questions are somewhat heretic. Good morning Peter Sylvester GMD Bonn  Received: from icsa.rice.edu (TCP 20012417002) by MC.LCS.MIT.EDU 12 Apr 89 19:20:59 EDT Received: from ICSA.RICE.EDU by icsa.rice.edu (IBM VM SMTP R1.2) with BSMTP id 3692; Wed, 12 Apr 89 18:20:58 CDT Received: by RICE (Mailer R2.01) id 3689; Wed, 12 Apr 89 18:20:53 CDT Date: Wed, 12 Apr 89 18:11:23 CDT From: "Mark R. Williamson" Subject: Re: Multi-Networked Hosts (was Hostname in Message-ID) To: HEADER-PEOPLE@MC.LCS.MIT.EDU In-Reply-To: Message of Wed, 12 Apr 89 12:39:00 PDT from On Wed, 12 Apr 89 12:39:00 PDT Leonard D Woren said: >> names.....sites that insist on using names not in the DNS only manage >> to greatly confuse things. > >YES! The :Interconnect.MX value in Bitnet's DOMAIN NAMES file should >be banned, and Bitnet sites with DNS-style names without MX service >should be banned. WHOA! The :Interconnect.MX doesn't relate to this topic! It flags quite a different situation, namely that a domain (Internet registered) has nodes reachable only by MX records, so that sites operating gateways which don't understand MX records won't try to ship mail to those domains through the Internet. If you want to ban names not in the DNS, you want to ban entries with :Interconnect.NO, not MX which, like :Interconnect.YES, flags domains accessible through DNS. Mark R. Williamson  Received: from MCC.COM (TCP 20017405412) by MC.LCS.MIT.EDU 12 Apr 89 19:22:08 EDT Received: from OGHMA.ACA.MCC.COM (OGHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Wed 12 Apr 89 18:13:04-CDT Date: Wed, 12 Apr 89 18:11 CDT From: David Vinayak Wallace Subject: No Domain service => No Domain names? To: Leonard D Woren cc: Danny Padwa , header-people@MC.LCS.MIT.EDU In-Reply-To: The message of 12 Apr 89 14:39 CDT from Leonard D Woren Message-ID: <19890412231137.7.GUMBY@OGHMA.ACA.MCC.COM> Date: Wed, 12 Apr 89 12:39 PDT From: Leonard D Woren I have repeatedly argued this point in a number of Bitnet forums, and I always lose. My argument is that sites that are not reachable on the Internet (via DNS) MUST NOT be allowed to use DNS-style names. Bitnet-only sites all too often don't have a reasonable perspective on these things. I guess I don't have a resonable perspective either. I understand your position but not your argument; in fact I haven't the faintest idea why forbidding it would be useful.  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 12 Apr 89 20:11:32 EDT Received: by INFOODS id <00000156143@INFOODS.MIT.EDU> ; Wed, 12 Apr 89 20:05:26 EDT Date: Wed, 12 Apr 89 19:27:45 EDT From: John C Klensin Subject: RE: Re: Hostname in Message-Id To: Peter Sylvester +49 228 8199645 X-VMS-Mail-To: EXOS%"Peter Sylvester +49 228 8199645 " Message-ID: <890412192745.00000156143@INFOODS.MIT.EDU> cc: header-people@MC.LCS.MIT.EDU Peter, I agree with what you are saying (if I understand it), but am not sure what it means in practice. Fortunately, nothing in RFC822 (or anywhere else) guarantees universality of names, only uniqueness within a given name space, of which the Internet DNS for host names is one. JANET is a different name space, regardless of what obvious mapping rules apply between Internet domain names and JANET domain names. I hope that the gateways either translate message-ids, or don't translate them, but that they do it (or not) consistently. In my purist capacity, I have a lot of reservations about the Internet-registered domain ".UK", since, while there may be a host "known as" xxx.AC.UK, there are no hosts whose "name is" xxx.AC.UK, only a host whose "name is" UK.AC.xxx. The reversing operation implies that the we have GATEWAYs, not simply Mail eXchangers, between the two networks. That is, of course, the case, but it implies Internet addressing to, e.g., user%UK.AC.xxx@gateway, where the "gateway" is an Internet DNS name, not use of an MX to user@xxx.AC.UK. In my practical capacity, I'd be happy to be spared the annoyance. That said, a *gateway* getting hold of a message ID might decide to insure its uniqueness in the target network. That is clearly an optional service, at least as I read the protocols. And, whatever the transformation is, probably the gateway name is part of it. And that gateway, and all of the other gateways between the two networks, had better know how to undo what they have done. The real message, again, is that RFC822 message ids were never intended to be taken too seriously. They are, after all, even optional--a message need not have one at all. >All Internet/Bitnet gateways do at least some EBCDIC/ASCII >translation. This might not be considered as "header munging" >but it is known that IBM has some problems to define globally >unique translate tables for some special characters. It is header and message munging. But the theory is that this is transparent for two reasons: (i) the same transformations are performed going through those gateways from right to left as are performed going from left to right. For that purpose, it is not relevant whether the translations are correct (whatever that means), only that they are invertible. As I suggested in my earlier note, much of the problem underlying Leonard's complaints is that large fractions of BITNET/NETNORTH/EARN/etc behave as if they are part of the Internet name space, without being part of the Internet name space. If they were, then every name on those networks that looks like a DNS name could be resolved by asking an Internet name server and each and every one of those server inquiries would yield either an "A" record--an IP address to which mail could be sent for that host--or an MX record that would point to a carefully-chosen "nearby" gateway, with no nonsense about "INTERBIT" from the Internet side. But they aren't, and people are breaking the rules and introducing much confusion. To make things worse, some of those hosts pretend to be part of the Internet name space for some purposes and not for others. > I would like to know how I could gateway some internet message-id >into some X.400 ip-message-id *without* "header-munging", in this >case it is at least a different "encoding". For details I refer >to RFC987. Here, there is absolutely no problem (or a great problem, but a different one). The X.400 system does not use RFC822. It doesn't even claim to use RFC822, but "mostly" use it (which is how I would describe both BITNET/etc and most of the UUCP sites). To get from an X.400 mail system to an Internet mail system, you need a gateway and a serious header translation activity (not just "munging", which usually is used to refer to the modification of headers between one RFC822 network and another (nearly) RFC822 network). I would not expect message-ids to translate in any particularly useful way, at least in the absence of a strong standard, which RFC987 is not. >If a BITNET internal mail system that has NO internet "name" >wants to generate a globally unique id, how can it do that? >It could create @node.BITNET as a suffix and ((un)fortunately) >there would be no conflict with a "correct" internet message-id. It does whatever it likes. Once you move outside the Internet name space, and the DNS, the *meaning* of the syntax is compromised. An extreme purist might state this as "if you don't have a registered domain name, then you are not conforming to RFC822, regardless of what syntax you choose". Within BITNET, there is no problem with @node.BITNET. Within some other network, there might be no problem with @latitude.longitude. If these messages cross into the Internet, then the gateways have to figure out what to do with them, and, more important, whether errors of type I are better or worse than errors of type III. In other words, do you prefer to risk deciding that something is unique when it isn't, or deciding that something isn't unique when it is? The one problem the gateway has is that intelligent choices cannot be made heuristically. If people on BITNET care what message-ids look like in BITNET and/or what the gateways should do with them, then appropriate technical committees should be convened to settle on the appropriate syntax and generating rules for BITNET message id fields, and then the gateways could take advantage of those rules. >What about all the uucp mail systems that have no internet name? >Ah hm, somehow someone managed to get a @uunet.uu.net suffix..... There is a misunderstanding here. The UUNET consortium made a case, just as CSNET did, for what is, relative to the original rules, a minor (and convenient) kludge. So there is a domain ".net", with a domain server, and it has a few subdomains. One of those is ".uu.net", another is ".cs.net". The latter has several hosts, some of which are not even gateways. As far as the DNS is concerned, the fact that UUNET.UU.NET is the MX host for a lot of DNS-registered uucp sites is nothing more than an interesting coincidence. And its appropriate behavior with regard to message ids is just like the BITNET situation: if there were a rule and consistency with the UUCP community about the assignment of message-ids, then the gateway could do something interesting, intelligent, and consistent with them (whether to preserve or to modify). If there is no rule, then it does whatever it does, and people should not over-rely on message-ids. And, again as with BITNET, the problems arise with hosts that exist on both networks. If I can get mail either from the Internet or from UUCP directly, and I care about message IDs, I need to know the rules for message IDs on both the UUCP and Internet sides, and then I need to know exactly what transformations the gateway is performing. Since there is more than one gateway, I also need to hope that all of them do the same thing (whatever it is), or my UA is going to need to track back through the Received paths (if they were supplied) to figure out which gateways were involved so that I can reverse (or canonicalize) their transformations. No one ever said that this was going to be easy. John Klensin, MIT  Received: from hanna.cac.washington.edu (TCP 20064074001) by MC.LCS.MIT.EDU 13 Apr 89 00:02:57 EDT Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu (5.61/6.12) id AA10432; Wed, 12 Apr 89 21:00:50 -0700 Return-Path: Date: Wed, 12 Apr 1989 20:57:30 PDT From: Mark Crispin Subject: re: Hostname in Message-Id To: Leonard D Woren Cc: Header People In-Reply-To: Message of 303616 from Leonard D Woren Message-Id: Leonard Woren - I agree with you 100%. The whole point of a Message-ID is defeated if mail gateways are allowed to transmogrify them. It is for this reason that I feel it was somewhat of a mistake to have the local-part@domain syntax for message IDs, since it was inevitable that someone would get this idea... -- Mark -- -------  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 01:46:28 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5491; Wed, 12 Apr 89 22:42:44 EDT Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 2702; Wed, 12 Apr 89 22:41:40 EDT Date: Wed, 12 Apr 89 19:38 PDT To: David Vinayak Wallace Cc: header-people@MC.LCS.MIT.EDU From: Leonard D Woren Subject: Re: No Domain service => No Domain names? Somehow, we've gotten a bit off the track of "Header-People". I didn't realize how big the can of worms was that I opened by my original query about Message-Id. (Well, I *thought* that I was asking a _simple_ question...) It seems that I may have a partial (or complete :-( ) misunderstanding of the Bitnet :Interconnect. definition and usage. In any case, if my mailer is handed a piece of mail with a DNS-style name for the destination, assuming it has MX support (which it doesn't yet -- ACC, are you listening???), then my mailer better be able to send that piece of mail out over the Internet. I guess the following problem may be unrelated, but the way things are now, mail to Internet sites often goes out over Bitnet, for example, postings to Header-People. I wonder if there's a bug in my MTA in the address form that it uses for this case? Should it be using LDW@USCMVSA.BITNET to send to MC.LCS.MIT.EDU, because it is going to use the Bitnet path to MIT? Even so, why does MIT mangle the address into LDW%MVSA.USC.EDU@MITVMA.MIT.EDU? Shouldn't it leave it as LDW@MVSA.USC.EDU??? Leonard D. Woren Senior MVS Systems Programmer MVS Postmaster University of Southern California  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 01:47:12 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5597; Thu, 13 Apr 89 00:48:05 EDT Received: from NIHCU.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 2971; Thu, 13 Apr 89 00:48:04 EDT To: HEADER-PEOPLE@MC.LCS.MIT.EDU From: "Roger Fajman" Date: Thu, 13 Apr 89 00:04:11 EDT Subject: Re: Multi-Networked Hosts (was Hostname in Message-ID) > >YES! The :Interconnect.MX value in Bitnet's DOMAIN NAMES file should > >be banned, and Bitnet sites with DNS-style names without MX service > >should be banned. > > WHOA! The :Interconnect.MX doesn't relate to this topic! It flags > quite a different situation, namely that a domain (Internet registered) > has nodes reachable only by MX records, so that sites operating > gateways which don't understand MX records won't try to ship mail to > those domains through the Internet. If you want to ban names not in > the DNS, you want to ban entries with :Interconnect.NO, not MX which, > like :Interconnect.YES, flags domains accessible through DNS. > > Mark R. Williamson No, that isn't right either. I quote from DOMAIN GUIDE (available from LISTSERV@BITNIC): :interconnect - This field can have one of three values: YES This domain is directly connected to the Internet, and mail that can be sent via BITNET/EARN/NETNORTH can therefore also be sent via the Internet. If even a single host within the stated domain cannot be reached directly via the Internet, then the domain must be defined as either NO or MX. NO This domain is wholly or partly inaccessible from the Internet. This domain could be one of the non-Internet-style domains like .HEPNET and .UUCP, or it might be only registered with (not connected to) the Internet. It could also be a domain now in the process of connecting or one simply preferring delivery via BITNET. Mail to this domain must be sent via BITNET/EARN/NETNORTH to the named gateway (otherwise, delivery may be impossible or unnecessarily slow). MX This domain is wholly accessible from the Internet, but one or more hosts within the domain are not directly connected. Sites in BITNET/EARN/NETNORTH providing general gateway services that lack the ability to handle MX records must send any mail for this domain to the named gateway, but mailers equipped to handle MX records may send mail via the Internet. :served - This field indicates that BITNIC is supplying nameservice on your behalf via the Berkeley and Harvard nameservers. If you have coded :interconnect.MX or :interconnect.YES, then remove the :served tag from your entry. If you have coded :interconnect.NO then you can request BITNIC nameservice. If you receive nameservice from sites other than Berkeley and Harvard, then remove the :served tag from your entry. If your domain already appears in DOMAIN NAMES, and you wish to obtain nameservice support (for example, if you are losing your Internet connection and, thus, your current nameservice), please contact DOMAINS@BITNIC and request this service for your domain. NOTE: "directly connected to the Internet" refers only to hosts that listen to TCP port 25 for incoming mail and have IP addresses. Unquote. All BITNET domains are in the DNS because all should be providing their own name service or getting it provided for them by Harvard and Berkeley. The only exceptions are those few, such as .UUCP, that don't conform to the rules of the DNS and so cannot have name service. No more like those are being created. Now there can be hosts in BITNET domains that are not reachable through the Internet. This is a clearly undesirable situation. Ideally, :interconnect.NO should be used only for BITNET domains that are not connected to the Internet at all. If there is a domain that is only partially reachable through the Internet, then it must be providing its own name service and the situation should be correctable by adding MX records pointing to an appropriate INTERBIT gateway for the BITNET-only hosts. The domain would then be designated :interconnect.MX.  Received: from Cs.Ucl.AC.UK (TCP 20004003004) by MC.LCS.MIT.EDU 13 Apr 89 04:03:25 EDT Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id aa01698; 13 Apr 89 7:57 GMT To: John C Klensin cc: header-people@mc.lcs.mit.edu Subject: Re: Hostname in Message-Id Phone: +44-1-380-7294 In-reply-to: Your message of Wed, 12 Apr 89 19:27:45 -0400. <890412192745.00000156143@INFOODS.MIT.EDU> Date: Thu, 13 Apr 89 08:57:33 +0100 Message-ID: <20337.608457453@UK.AC.UCL.CS> From: Steve Kille Source-Info: purple.cs.ucl.ac.uk Anyon interested in gatewaying between JNT Mail (Janet) and RFC 822 should real mailgroup note 15 "Gatewaying Between RFC 822 and JNT Mail", by myself (May 1984). This is the approved approach. The document may be obtained from info-server@cs.ucl.ac.uk Mesage Ids are not mentioned. This was an error. A gateway should reverse the domain order in message Ids. The MMDF based gateways ( nsfnet-relay (aka nss.cs.ucl.ac.uk), ean-realy, and ukc) do not get this right. I don't think it is too big a deal. Steve  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 09:02:30 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 6364; Thu, 13 Apr 89 09:04:21 EDT Received: from Pythag.ucl.ac.be by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 5393; Thu, 13 Apr 89 09:03:11 EDT Received: by BUCLLN11 (Mailer R2.03B) id 2736; Thu, 13 Apr 89 14:02:13 +0200 Date: Thu, 13 Apr 1989 14:02:04 +0200 From: "Alain FONTAINE (Postmaster - NAD)" Message-Id: <890413.131040.+0200.af@sei.ucl.ac.be> Subject: Re: Hostname in Message-Id To: Header-People Discussion In-Reply-To: Message of Wed, 12 Apr 89 07:48:06 EDT from > But correct universal use of a Message-ID requires going well beyond >what RFC822 specifies. Assume that I'm operating in a workstation >environment, with a local UA, but with the MTA on the next machine down >the line. Assume further that my "address" is on the machine with the . etc... (in a few words : what should sit in the 'host' field of the message-id in a complex environment) The very fact that this problem exists is in my (humble?) opinion one more indication that the structure of the current addresses (user@host) is completely outdated. It dates back when time-sharing machines were the norm. Today, giving the kind of environments described in the referred message, individuals should have addresses of the form : 'name.domn.domn-1. .dom2.dom1'. To say it otherwise : the DNS should be used up (down?) to the individual level. This would eliminate problems like the one stated in the referred message, and also would allow a more regular treatment of all cases. For example, name servers could contain MX records for individuals. Was it not the original intent of the DNS that any 'object' in the world could someday be designated by a domain? The syntax 'user@host' forbids this to be true for a large class of objects, like mailboxes and processes... This may be completely heretic, idiotic or worse. If so, I would really enjoy a correction. /AF  Received: from HUSC3.HARVARD.EDU (TCP 20031600465) by MC.LCS.MIT.EDU 13 Apr 89 09:44:46 EDT Date: Thu, 13 Apr 89 09:41 EDT From: Danny Padwa Subject: Re: Hostname in Message-Id To: Header-People Discussion X-VMS-To: IN%"Header-People Discussion ",PADWA Sorry to throw more fuel on the fire, but one of the major problems encountered in this MX-records-for-BITnet-only-domains question is that very few BITNET domains are actually registered on the servers at Harvard and Berkeley (or at least the one at Harvard). In fact, the following is a complete list (if it ain't here, Harvard doesn't have info about it!): alleg.edu hampshire.edu pepperdine.edu trinity.edu br ie pt uri.edu bsu.edu irl rose-hulman.edu urich.edu bucknell.edu maine.edu sg claremont.edu naic.edu towson.edu conncoll.edu oberlin.edu trincol.edu Berkeley may know about some that Harvard doesn't (doubtful). The import of all of this is that if I (on my multi-networked host) have a message for any BITnet-only domain that is not in the above list, it probably will not be handled properly!!! The clear solution is to disallow Internet messages with return addresses for invalid domains. Gateway filtering? :-) :-) - Danny Padwa Harvard VMS Networking  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 13 Apr 89 10:20:36 EDT Received: by INFOODS id <0000020B031@INFOODS.MIT.EDU> ; Thu, 13 Apr 89 10:19:55 EDT Date: Thu, 13 Apr 89 10:17:41 EDT From: John C Klensin Subject: RE: Re: Hostname in Message-Id To: "Alain FONTAINE (Postmaster - NAD)" X-VMS-Mail-To: "Alain FONTAINE (Postmaster - NAD)" Message-ID: <890413101741.0000020B031@INFOODS.MIT.EDU> cc: header-people@MC.LCS.MIT.EDU Alain FONTAINE writes: > (in a few words : what should sit in the 'host' field of the > message-id in a complex environment) > >The very fact that this problem exists is in my (humble?) opinion one >more indication that the structure of the current addresses (user@host) >is completely outdated. I think "completely" is an exaggeration. > It dates back when time-sharing machines were the norm. At least partially true, although that criticism is more appropriately addressed to RFC822 than to the DNS. More on that below. > Today, giving the kind of environments described in the >referred message, individuals should have addresses of the form : > 'name.domn.domn-1. .dom2.dom1'. >To say it otherwise : the DNS should be used up (down?) to the >individual level. I think the user / host distinction is still useful for some purposes. If I were to make the above statement, it would actually make a user /host / domain distinction. That is another discussion. However, please keep in mind that the DNS is defined in terms of the identification of "resources". I prefer not to be a resource-object, thank you. And the discussions of mail and mail headers in this list tend to obscure the fact that, when the domain resolvers are used to identify host-type resources, there is a big difference between "A" and "MX" records. For example, I can usually make Telnet or FTP connections to the latter (and I can even ask the DNS whether or not those protocols are supported). FTP connections to people are not, in general, practical. Now there are alternate ways to think about DNS-like systems that would use different syntax, semantics, and notions about "objects". You are unlikely to change the DNS today. Instead, if this problem is interesting, look at X.500. If it does not meet your needs, or seems to violate things that you have known, from experience, for years, please start complaining to your national CCITT administration, write articles, etc. We can avoid repeating the X.400 debacle iff whatever weaknesses exist in X.500 are identified early on, and fixed before there are implementations in production use. >This would eliminate problems like the one stated in the referred >message, and also would allow a more regular treatment of all cases. For >example, name servers could contain MX records for individuals. Was it >not the original intent of the DNS that any 'object' in the world could ?someday be designated by a domain? The syntax 'user@host' forbids this >to be true for a large class of objects, like mailboxes and processes... I don't believe this would fix the problem raised in the original mesasge. I don't have time to debate the point, but much of that original issue derived from partial adherence to the DNS, resulting in the same "host" having different names in different networks. Partial compliance to any system, and the absence (or non-observance) of canonicalization rules, will produce similar difficulties. The message-id problem can be "fixed" with no alterations to the DNS, in any event. The problem here is not the DNS, it is: (a) local decisions about observance/non-observance and interpretations about what to do under various circumstances. The RFCs provide little guidance, and are sometimes ignored regardless. (b) While the criticism of "developed for timesharing" is only partially valid for the DNS, it is clearly applicable to RFC822. That protocol is a slight revision, to fix major problems and confusions (note "slight" and "major") in much older protocols that date almost to the beginning of the ARPANET (back to when we discovered that mail should not, after all, just be a special case of file transfer). That field is easily extended in reasonable ways. Most of the extensions can be made within the existing syntax, by decisions at an individual host, but they are worthwhile for close message identification elsewhere only if there is a protocol that specifies -- really -- what should be in there and how the subfields should be handled. The postoffice issue is, for example, easily handled by a close reading of 4.6.1 of RFC822: "by the host that generates it". "It":= the message id, not the message. Can the postoffice machine (which is what is running SMTP) generate a unique message-id? Sure. Can it identify the user, as it knows her or him in the local-part? Sure, note "not necessarily meaningful to humans". RFC822 is not broken, only underspecified for some of the uses to which people are trying to put it. The DNS is still less broken, at least in these cases. Summary: - The DNS is not all things to all people. Neither of the problems identified in this discussion--message-id uniqueness and unneeded gateway routings--are serious challenges to it. - If you don't like the DNS, start studying X.500, which you might be able to affect and, more important, probably has a longer-term impact. - Incompatible changes to the DNS are unlikely to happen at this point unless catastrophic problems are demonstrated. To my knowledge, none have been. These mail difficulties are certainly not in that category. - RFC822 never guaranteed that Message-IDs could be reliably used for some of the purposes to which people now want to put them. Many of the problems arise in conjunction with those uses and could, in principle, be solved, by specification of the format of the local-part of the Message-ID field. - Most of the *real* problems result from a combination of misbehaving gateways (which make transformation they can't reverse or which can't make choices that require technology unavailable to them) or mis-use of the DNS. The misuses include hosts that use DNS-style names that are not registered and hosts that use multiple names. These problems are violations of the protocols, violations of the spirit of the DNS, violations of good sense, or just consequences of complicated problems that have been inadequately thought out and documented. Writing more and better rules might solve the last of these; it does nothing for the others. >This may be completely heretic, idiotic or worse. If so, I would really >enjoy a correction. /AF It is none of those things. It is, however, severely non-pragmatic: - on a practical, rather than theoretical basis, you should be looking for the minimal changes that will fix a problem. "Replace the DNS" is not the minimal change in this situation. Even theory is perhaps better applied to the next version of X.500, not the DNS. - And, to quote an old New England comment, "if it ain't broke, don't fix it". It is not clear that there is anything broken in the DNS or in the RFC822 definition of the Message-ID field. What is "broken", because it has never been adequately defined, is how gateways between highly interconnected networks should behave under a series of circumstances. In the USA, this problem arises with the huge number of interconnections and gateways between UUCP and the Internet and the slightly less huge number between BITNET and the Internet (in case those of you on the far side of the water don't know, the INTERBIT sites are a tiny fraction of the institutions with gateway capability or multi-hosted machines). In the UK, someone should verify that the transformations performed by the Internet gateway in London and by the EARN gateway at Rutherford are identical or properly identified, and that each gateway is able to reverse the transformations of the other. Those of you who have only a single gateway connecting a non-Internet network with the Internet, or a non-RSCS network with EARN, or whatever, should consider yourselves fortunate, as many problems are thereby eliminated. John Klensin, Klensin@INFOODS.MIT.EDU  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 11:48:22 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 6842; Thu, 13 Apr 89 11:50:15 EDT Received: from CUNYVM.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 7173; Thu, 13 Apr 89 11:50:14 EDT Received: by CUNYVM (Mailer R2.01) id 2484; Thu, 13 Apr 89 11:47:22 EDT Date: Thu, 13 Apr 89 11:32:07 EDT From: Ben Yalow Subject: RE: Re: Hostname in Message-Id To: HEADER-PEOPLE@MC.LCS.MIT.EDU In-Reply-To: Message of Wed, 12 Apr 89 19:27:45 EDT from > As I suggested in my earlier note, much of the problem underlying >Leonard's complaints is that large fractions of BITNET/NETNORTH/EARN/etc >behave as if they are part of the Internet name space, without being >part of the Internet name space. If they were, then every name on those >networks that looks like a DNS name could be resolved by asking an >Internet name server and each and every one of those server inquiries >would yield either an "A" record--an IP address to which mail could be >sent for that host--or an MX record that would point to a >carefully-chosen "nearby" gateway, with no nonsense about "INTERBIT" >from the Internet side. But they aren't, and people are breaking the >rules and introducing much confusion. To make things worse, some of >those hosts pretend to be part of the Internet name space for some >purposes and not for others. > > >No one ever said that this was going to be easy. > >John Klensin, MIT > > Actually, the whole INTERBIT hack for BITNET->Internet mail is only known to the BITNET side (in theory). A BITNET node needs to know that the gateway is at SMTP@INTERBIT, and to send mail to there - only the INTERBIT sites need to know that that INTERBIT isn't a real node hung off CUNYVM the way the maps would indicate. From the Internet side, you can send mail to a user at a BITNET node by sending mail to user%bitnode.BITNET@gateway, where gateway is any machine you know has agreed to act as a gateway (such as CUNYVM.CUNY.EDU == CUNYVM on BITNET). All of the INTERBIT machines do header munging to produce that address on the BITNET addresses we send out (like From:, etc), and do the reverse transformation on the way back - an Internet site can usually just reply without worrying about address transformations. The problems (aside from no MX on the INTERBIT gateways, which should change soon) come from domain style names on purely BITNET sites, and those are getting MX service from Harvard/Berkeley as new ones are registered. The other problem comes from figuring out which physical network to send mail on between domains that are on more than one network, and this is a problem the domain system is NOT designed to deal with - domains are purely administrative methods of dealing with namespace management, and don't handle transport issues. The problems of which transport level services to use are probably not solvable merely by looking at a domain name - you'll get a path that will work, but may not be optimal. Solving THAT problem is much tougher, and I don't know that anybody has really even figured out what should be done, much less how to do it. ----------------- Ben Yalow BITNET: YBMCU@CUNYVM INTERNET: YBMCU@CUNYVM.CUNY.EDU City University of New York 555 W 57 St NY, NY 10019 212-903-3623  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 13 Apr 89 13:26:30 EDT Received: by INFOODS id <00000319092@INFOODS.MIT.EDU> ; Thu, 13 Apr 89 13:22:20 EDT Date: Thu, 13 Apr 89 13:21:23 EDT From: John C Klensin Subject: RE: Re: No Domain service => No Domain names? To: header-people@MC.LCS.MIT.EDU X-VMS-Mail-To: EXOS%"header-people@mc.lcs.mit.edu" Message-ID: <890413132123.00000319092@INFOODS.MIT.EDU> Leonard, (1) Yes, BITNET sites without DNS registrations should not use DNS style names. If they do, they should expect to not have mail returned, something that may be about to start happening to them, by coincidence. But BITNET is, by definition, limited anarchy. So, if, by custom or convention, these are legal names within BITNET, then they are legal names within BITNET. They just are not legal names on the Internet. Beyond that, what means "forbid". RFC822 "forbids" the use of time zones like "CEZ". If I had a nickel... What you going to do, call the protocol police? Problem is, there are no protocol police and, if there were, they would be powerless. The only realistic form of "forbid" is pressure on the gateway maintainers to not pass certain classes of "illegal" stuff. (2) MITVMA trashes your address for two reasons. The first dominates, but the second should: (2a) They can't transform it into <@MITVMA.MIT.EDU:user@host> because the "version 1" BITNET mailers can't deal with that form. Version 2 can, and you will start seeing this stuff. However, its effective use depends on the receiving UA having enough sense to say "I know that 'host' is a DNS name, and I can ignore that source routing and look the thing up myself". Few do. So, once MITVMA does that rewrite, when I reply to you, you will get the message over the Internet, but via MITVMA, not direct from here. (2b) <@MITVMA.MIT.EDU:user@mumble.BITNET> or <@MITVMA.MIT.EDU:user@host.unregistered> are DNS-illegal addresses. user%mumble.BITNET@MITVMA.MIT.EDU and user%host.unregistered@MITVMA.MIT.EDU are legal addresses - always - since they say to send to a valid DNS host which knows how to interpret the local-part. In theory, if the gateway is well-behaved, it puts out direct addresses (no routing) or the source route form for all addresses arriving over BITNET that are DNS[-registered] names, and %-kludge addresses for non-DNS names. If I were making the decisions, I'd apply the following rules to a hostname arriving from BITNET: 1) If the host name contains no periods, use user%host@MITVMA.MIT.EDU. Or user%host.BITNET@MIT..., whichever makes the SMTP server happier. 2) If the host name contains .BITNET, use user%host.BITNET@MITVMA... 3) If the host name contains periods and is not in the second category, actually do the DNS lookup. If the lookup succeeds, use <@MITVMA.MIT.EDU:user@host>. If it fails, reject the mail and send it back, with a not-very-polite note explaining how easy it is to register domain names and how to do it. It would not require very many invocations of this rule to solve the problem. But I don't make the decisions, and you should not hold your breath. Discussions with BITNET tech reps and on the INTERBIT list are probably the right way to pursue this if you are interested. >I guess the following >problem may be unrelated, but the way things are now, mail to Internet >sites often goes out over Bitnet, for example, postings to >Header-People. This is, in and of itself, a bug, but I think we've covered that. > I wonder if there's a bug in my MTA in the address >form that it uses for this case? Should it be using >LDW@USCMVSA.BITNET to send to MC.LCS.MIT.EDU, because it is going to >use the Bitnet path to MIT? Rule 1: The DNS is supposed to be path-independent. Rule 2: DNS names are legal names on BITNET, eight-character NJE/RSCS host ids are legal names on BITNET, and NJE/RSCS host ids suffixed by .BITNET are legal names on BITNET. Only DNS-like names that are not registered are in a gray area. Rule 3: If something is transmitted between BITNET nodes, rule 2 applies. If something is transmitted between BITNET nodes and then through a gateway onto the Internet, enforcement of Internet naming rules (in which only DNS *host* names are legal and local-parts don't count) is a gateway responsibility. You should not worry about tricking the gateway into doing something "better"; you can't win at that game. Rule 4: Given rule 2, and the arguments for "one box, one name" which you understand very well, using the DNS name in your address is the right thing to do, in both networks. What names the MTAs use to communicate with each other is another question, but who cares. Same comment on Message-IDs, which is what I tried to say several days ago. > Even so, why does MIT mangle the address >into LDW%MVSA.USC.EDU@MITVMA.MIT.EDU? Shouldn't it leave it as >LDW@MVSA.USC.EDU??? Nope. See above. It can "leave" it only if it is willing to take responsibility for two things: (a) MVSA.USC.EDU is a DNS-name (not merely something that looks like one). (b) MVSA.USC.EDU, as a DNS-name, resolves to the same host as MVSA.USC.EDU on BITNET does. The real argument for "no domain, no name" is to make this question go away so that identity can be relied upon. And, if I had my druthers, it would apply a fourth rule, s.t. it would "leave it" only if, in addition, (c) MVSA.USC.EDU resolves to an "A" record (an IP address), not an MX. If it resolves to an MX, I'd rather see either: <@MITVMA.MIT.EDU:LDW@MVSA....> or <@designated-mail-exchanger:LDW@MVSA...> rather than "leaving" the thing, at least until MX support is universally available. Even then, this is useful and harmless. John Klensin, Principal Research Scientist, MIT Klensin@INFOODS.MIT.EDU  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 13 Apr 89 13:50:14 EDT Received: by INFOODS id <0000026B072@INFOODS.MIT.EDU> ; Thu, 13 Apr 89 13:46:30 EDT Date: Thu, 13 Apr 89 13:45:29 EDT From: John C Klensin Subject: Re: Hostname in Message-Id To: header-people@MC.LCS.MIT.EDU X-VMS-Mail-To: EXOS%"header-people@mc.lcs.mit.edu" Message-ID: <890413134529.0000026B072@INFOODS.MIT.EDU> My, am I sorry I started this. Ben Yalow is completely correct. I mentioned the INTERBIT business from the Internet side only because I've seen yet another suggestion this week that involves a convoluted scheme to make "INTERBIT" or some surrogate for it a legal Internet name. It is, as Ben says, a hack, and should be kept a BITNET-local hack. >All of the INTERBIT machines >do header munging to produce that address on the BITNET addresses we >send out (like From:, etc), and do the reverse transformation on the >way back - an Internet site can usually just reply without worrying >about address transformations. I think part of this discussion has been about whether the header munging that is done is optimal, or as close to optimal as possible. It clearly works. >The problems ... change soon) come from domain style names on purely >BITNET sites, and those are getting MX service from Harvard/Berkeley as >new ones are registered. Those that ask and/or register. Those that don't ask *are* the problem. > The other problem comes from figuring out which physical network to >send mail on between domains that are on more than one network, and ... Looking at the name can't help. Looking at the resource record might, but, as you say, it is a tough problem. On the other hand, having a BITNET->Internet gateway map user@foo.bar.edu, where foo.bar.edu is a valid DNS name that will return an "A" record, into, e.g., user%foo.bar.edu@cunyvm.cuny.edu (because the message was received from BITNET and is being sent to the Internet) tends to obscure whatever intelligence an MTA on the Internet might try to apply. If that MTA is well-behaved, it *must* send the message back to cunyvm, since it is forbidden to try to construe a local-part. And I guess that is the core of the problem as I see it. John Klensin Klensin@INFOODS.MIT.EDU  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 18:29:22 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 8204; Thu, 13 Apr 89 18:31:17 EDT Received: from NIHCU.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 5375; Thu, 13 Apr 89 18:31:16 EDT To: PADWA@HUSC3.HARVARD.EDU cc: HEADER-PEOPLE@MC.LCS.MIT.EDU From: "Roger Fajman" Date: Thu, 13 Apr 89 18:27:10 EDT Subject: Re: Hostname in Message-Id > Sorry to throw more fuel on the fire, but one of the major problems > encountered > in this MX-records-for-BITnet-only-domains question is that very few BITNET > domains are actually registered on the servers at Harvard and Berkeley (or > at least the one at Harvard). (remainder deleted) What is supposed to be the case is that all the others are providing their own name service. A few months ago I was assured by John Chandler, who has been involved in registration of BITNET domains, that that was in fact the case. He also told me that care would be taken to insure that new domains would have name service. I sent him a copy of your message to see if he can verify that this is continuing to be done.  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 13 Apr 89 23:35:34 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 8898; Thu, 13 Apr 89 23:37:28 EDT Received: from CFAAMP.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 8829; Thu, 13 Apr 89 23:37:27 EDT Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer R2.03B) with BSMTP id 9067; Thu, 13 Apr 89 23:35:30 EDT Date: Thu, 1989 Apr 13 19:21:58 EDT From: (John F. Chandler) PEPMNT@CFAAMP.BITNET To: HEADER-PEOPLE@MC.LCS.MIT.EDU, (Danny Padwa) PADWA@HUSC3.HARVARD.EDU, (Roger Fajman) RAF@NIHCU.BITNET cc: (Scott Bradner) SOB@HUSC6.HARVARD.EDU, (Hank Nussbacher) HANK@BARILVM.BITNET Subject: Re: Hostname in Message-Id In-reply-to: PADWA@HUSC3.HARVARD.EDU message of Thu, 13 Apr 89 09:41:00 EDT Message-id: > Sorry to throw more fuel on the fire, but one of the major problems > encountered in this MX-records-for-BITnet-only-domains question is > that very few BITNET domains are actually registered on the servers at > Harvard and Berkeley (or at least the one at Harvard). In fact, the > following is a complete list (if it ain't here, Harvard doesn't have > info about it!): > > alleg.edu hampshire.edu pepperdine.edu trinity.edu > br ie pt uri.edu > bsu.edu irl rose-hulman.edu urich.edu > bucknell.edu maine.edu sg > claremont.edu naic.edu towson.edu > conncoll.edu oberlin.edu trincol.edu The key word is BITNET-only. There are two kinds of BITNET-only domains, namely, Internet-conforming and non-conforming. The latter group includes such things as MFENET and WUSTL, which no sane person would try to reach from an Internet host without explicitly using some sort of "%" notation or source routing -- such domains can't ever be served by Harvard, Berkeley, or any other name server, since they can't ever be registered with SRI-NIC. The former group (Internet-compliant), on the other hand, includes only 18 domains (as of March 30), and the above list includes fully 17 of those 18 plus ALLEG.EDU and BR (which may be new in the last two weeks), BSU.EDU (which hasn't gotten around to registering with BITNIC), and IRL (which is obsolete). The only missing BITNET-only domain is CUN.EDU, and I wonder why Harvard doesn't have it -- the root server points to Harvard and Berkeley for it, and I expect Berkeley does have it. In any case, this is the only real problem, and it can be solved easily by Harvard. Note that the monthly distribution of DOMAIN NAMES from BITNIC clearly shows which domains are served by Harvard and Berkeley (via the :served.YES tag). John  Received: from Cs.Ucl.AC.UK (TCP 20004003004) by MC.LCS.MIT.EDU 17 Apr 89 03:40:26 EDT Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id aa03009; 17 Apr 89 7:35 GMT To: header-people@mc.lcs.mit.edu, ifip-gtwy@tis.llnl.gov Subject: Message Ids + domain flipping Date: Mon, 17 Apr 89 08:33:37 +0100 Message-ID: <3401.608801617@UK.AC.UCL.CS> From: Steve Kille Source-Info: purple.cs.ucl.ac.uk Header people, A short while back, I wrote: > To: John C Klensin > cc: header-people@mc.lcs.mit.edu > Subject: Re: Hostname in Message-Id > > Mesage Ids are not mentioned. This was an error. A gateway should > reverse the domain order in message Ids. I received a private prod from Jon Postel, and rethought. I'd like to entirely retract this orginal statement. RFC 822 and JNT Mail are clear about message IDs - the domain component has no (external) semantics (Unfortunately, this is made by not stating semantics, rather than explictly noting the lack of semantics). Leaving them alone is the only safe method to preserve them. UK recipients of this message will note that it has an RFC 822 ordered domain in the message id - correctly not transformed. 987 People (esp. those in the UK), The reason I suggested mapping of message ids was following a conversation with Jim, about message IDs being broken on traversal of a pair of 987 gateways (examing a broken message, rather than theoretical issues). Because the 987 message id mapping uses the domain -> O/R Address mapping, the UK and US mappings become different. As the current 987 mapping seems clean, we concluded that a JNT Mail/RFC 822 mapping should flip domains. On reflection, such a mapping would cause chaos for JNT Mail / RFC 822 interworking. Therefore, there is a need to change RFC 987. I propose that for message ID mappings that: 1) Where no "natural" mapping can be found, that the O/R Address is mapped onto a single DD attribute. This will make DD based message IDs reverse mappable at every 987 gateway. 2) The JNT Mail annexe note that domains in message id are treated in RFC 822 order. This will lead to a mechanically generated (and reversible) mapping for every id. Comments? (Please try to avoid replying to both mailing lists!) Steve  Received: from SH.CS.NET (TCP 30007663403) by MC.LCS.MIT.EDU 17 Apr 89 11:16:41 EDT Received: by SH.CS.NET id ac12436; 17 Apr 89 11:16 EDT To: "Alain FONTAINE (Postmaster - NAD)" cc: header-people@mc.lcs.mit.edu Subject: re: Hostname in Message-Id Date: Mon, 17 Apr 89 11:02:20 -0400 From: Craig Partridge > The very fact that this problem exists is in my (humble?) opinion one > more indication that the structure of the current addresses (user@host) > is completely outdated. It dates back when time-sharing machines were > the norm. Today, giving the kind of environments described in the > referred message, individuals should have addresses of the form : > 'name.domn.domn-1. .dom2.dom1'. > To say it otherwise : the DNS should be used up (down?) to the > individual level. > > This would eliminate problems like the one stated in the referred > message, and also would allow a more regular treatment of all cases. For > example, name servers could contain MX records for individuals. Was it > not the original intent of the DNS that any 'object' in the world could > someday be designated by a domain? The syntax 'user@host' forbids this > to be true for a large class of objects, like mailboxes and processes... > > This may be completely heretic, idiotic or worse. If so, I would really > enjoy a correction. /AF It certainly isn't heretical. Systems like Grapevine/Clearinghouse have done something like it for years. The key problem is finding a system for naming individuals that scales nicely for mailing lists and which also makes it easy for individuals to move their mailbox. The original Grapevine papers suggest this was and is a tricky enterprise and I think may explain why we haven't seen this scheme pursued more. As a sort of half-step, I've tried to encourage people to set up their organizational mail systems so that their users can be mailed to as user@. Examples of this are: craig@bbn.com kzm@twg.com pvm@isi.edu hr@ibm.com The benefit, if you can manage your user namespace this well, is that if the user moves within an organization, no one has to see it. Craig  Received: from uxc.cso.uiuc.edu (TCP 20237527062) by MC.LCS.MIT.EDU 17 Apr 89 19:58:05 EDT Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.61+/IDA-1.2.8) id AA03678; Mon, 17 Apr 89 18:57:51 -0500 Message-Id: <8904172357.AA03678@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 1336; Mon, 17 Apr 89 13:50:02 CDT Date: Mon, 17 Apr 89 13:40:00 CDT X-Date: Mon, 17 Apr 89 13:40:00 CDT (Even tax day is on monday now) From: Philip Howard X-From: Philip Howard Subject: restructuring addresses X-Subject: restructuring addresses To: Header People X-To: Header People Mailing-List: header-people Another good reason for restructuring address such that my address: phil@vmd.cso.uiuc.edu becomes just: or in the root-down order: phil.vmd.cso.uiuc.edu edu.uiuc.cso.vmd.phil is that I might want to have mail sent to me on this timesharing system in such a way that I can have a mail agent program break it down even further. I subscribe to several mailing lists, but it all arrives in an arbitrary sequence at one mailbox. I might like to have multiple LOGICAL mailboxes. I could have mail sent to: or in the root-down order: hdr-ppl.phil.vmd.cso.uiuc.edu edu.uiuc.cso.vmd.phil.hdr-ppl Now of course the old way can do this, too, but with the new way, it would be a lot easier and a lot more consistent. Then we would not have to dream up new headers just to allow user mail agents to discriminate mail depending on its purpose (e.g. Mailing-list: header-people).  Received: from uxc.cso.uiuc.edu (TCP 20237527062) by MC.LCS.MIT.EDU 17 Apr 89 20:03:54 EDT Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.61+/IDA-1.2.8) id AA03780; Mon, 17 Apr 89 19:02:53 -0500 Message-Id: <8904180002.AA03780@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 2663; Mon, 17 Apr 89 14:33:27 CDT Date: Mon, 17 Apr 89 14:31:23 CDT From: Philip Howard Subject: Trying again to header-people To: Header People I'm trying once again.... with all 3 rejected messages. I leave the error headers in because I know this crowd loves 'em. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Received: from UIUCVMD by VMD.CSO.UIUC.EDU (Mailer X1.25) with BSMTP id 7158; Thu, 13 Apr 89 21:14:18 CDT Received: from uxc.cso.uiuc.edu by VMD.CSO.UIUC.EDU (IBM VM SMTP R1.2) with TCP; Thu, 13 Apr 89 21:14:17 CDT Received: by uxc.cso.uiuc.edu (5.61+/IDA-1.2.8) id AA04190; Thu, 13 Apr 89 21:13:16 -0500 Date: Thu, 13 Apr 89 21:13:16 -0500 From: Mail Delivery Subsystem Message-Id: <8904140213.AA04190@uxc.cso.uiuc.edu> To: PHIL@uiucvmd.bitnet Subject: Returned mail: Host unknown ----- Transcript of session follows ----- <<< RCPT TO: <<< DATA 550 MC.LCS.MIT.EDU (TCP-U)... 550 Host unknown 554 ... 550 Host unknown (Non recoverable name server error) ----- Unsent message follows ----- Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.61+/IDA-1.2.8) id AA04181; Thu, 13 Apr 89 21:13:16 -0500 Message-Id: <8904140213.AA04181@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 3101; Thu, 13 Apr 89 19:08:38 CDT Date: Thu, 13 Apr 89 19:02:10 CDT From: Philip Howard Subject: header munging To: Header People Here is one reason I don't like header munging: Someone subscribes to a mailing list here by sending mail. Their FROM address is munged along the way. There subscription is automatically entered and all seems fine... until their userid is terminated. Then the host system they are on sends back a rejection message, containing the address EVEN FURTHER munged up, and no longer easy to compare for removing the entry from the list. If a FROM address is already in a domain format, why change it? I can accept changing a!b!c!d into d%c%b@a or d@c:@b:@a or visa-versa, but changing user@a.b.c.domain into anything else doesn't make any sense. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Received: from UIUCVMD by VMD.CSO.UIUC.EDU (Mailer X1.25) with BSMTP id 4886; Fri, 14 Apr 89 01:47:18 CDT Received: from uxc.cso.uiuc.edu by VMD.CSO.UIUC.EDU (IBM VM SMTP R1.2) with TCP; Fri, 14 Apr 89 01:47:15 CDT Received: by uxc.cso.uiuc.edu (5.61+/IDA-1.2.8) id AA14055; Fri, 14 Apr 89 01:46:28 -0500 Date: Fri, 14 Apr 89 01:46:28 -0500 From: Mail Delivery Subsystem Message-Id: <8904140646.AA14055@uxc.cso.uiuc.edu> To: PHIL@uiucvmd.bitnet Subject: Returned mail: Host unknown ----- Transcript of session follows ----- <<< RCPT TO: <<< DATA 550 MC.LCS.MIT.EDU (TCP-U)... 550 Host unknown 554 ... 550 Host unknown (Non recoverable name server error) ----- Unsent message follows ----- Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.61+/IDA-1.2.8) id AA14051; Fri, 14 Apr 89 01:46:28 -0500 Message-Id: <8904140646.AA14051@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 3351; Thu, 13 Apr 89 11:30:01 CDT Date: Thu, 13 Apr 89 11:14:35 CDT From: Philip Howard Subject: Re: Multi-Networked Hosts (was Hostname in Message-ID) To: Header People In-Reply-To: Your message of Wed, 12 Apr 89 17:40:37 EDT Instead of ":interconnect.MX" it might have been clearer to some had ":DeliveryNetwork.Internet" been used instead, to perform basically the same function. That field, as Roger Fajman points out, is essential to some computers that are on BITNET like our own. What this field means is that the host does have domain name service, and that it is therefore possible (and usually preferable) to deliver it via Internet. The fact that the IBM SMTP program does not as yet deliver according to MX record lookups from the name server does not hinder us. I have setup a mechanism around the problem, and can deliver mail to all sites that are MX reachable, via Internet. Some European and Japanese sites are not delivered this way by a local override because for some reason, the recipient is charged costs for delivery by Internet and not via Bitnet. But I can deliver by MX routing if I want to. So what are these "'wanton' use of invalid domain-style address"? If you are talking about "nodename.BITNET", would you also apply the same argument against "nodename.UUCP"? So what would you suggest be done (including specific examples)? If you include "upgrade software", be sure to include the names of the vendors of the software needing upgrade. This is often easier said than done. All Bitnet-only sites should be reachable from an Internet-only site provided that someone does the name service. But since such things are not yet setup, we live with what we have now, and it works for the time being. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Received: from UIUCVMD by VMD.CSO.UIUC.EDU (Mailer X1.25) with BSMTP id 0108; Sun, 16 Apr 89 16:57:20 CDT Received: from uxc.cso.uiuc.edu by VMD.CSO.UIUC.EDU (IBM VM SMTP R1.2) with TCP; Sun, 16 Apr 89 16:57:18 CDT Received: by uxc.cso.uiuc.edu (5.61+/IDA-1.2.8) id AB12400; Sun, 16 Apr 89 16:53:02 -0500 Date: Sun, 16 Apr 89 16:53:02 -0500 From: Mail Delivery Subsystem Message-Id: <8904162153.AB12400@uxc.cso.uiuc.edu> To: PHIL@uiucvmd.bitnet Subject: Returned mail: Cannot send message for 2 days ----- Transcript of session follows ----- 421 MC.LCS.MIT.EDU (TCP-U)... Deferred: Connection timed out during user open with MC.LCS.MIT.EDU ----- Unsent message follows ----- Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.61+/IDA-1.2.8) id AA17861; Fri, 14 Apr 89 15:33:36 -0500 Message-Id: <8904142033.AA17861@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 6851; Fri, 14 Apr 89 15:24:33 CDT Date: Fri, 14 Apr 89 15:11:48 CDT From: Philip Howard Subject: bitnet-only To: Header People > not be handled properly!!! The clear solution is to disallow Internet messages > with return addresses for invalid domains. Gateway filtering? :-) :-) As clear as mud. If you got the mail from SOMEWHERE, hopefully you know where. If the FROM address makes no sense to you then THIS IS THE TIME (and perhaps ONLY TIME) to munge the return address by putting in the host name of WHERE YOU GOT IT (not your own). THEN send it on. Now tell me that if every host followed this convention, that the mail could not get back once/if it found its way to the destination. As mail comes from BITNET (originating at a BITNET-only node) the FROM address will be transformed from to . When it reaches your node (you are not the gateway, but an intermediate) and if you don't know how to deliver to ".bitnet", then assume that who you got it from (HELO) knows because they DIDN'T munge it. Now the FROM address will look like: <@where.it.came.from:user@node.bitnet> Remember there are two roles here that can take place in different sites. The BITNET gateway takes the non-DNS BITNET-ish address and changes into a psuedo-DNS (.bitnet) form. On subsequent delivery to another host (including the final destination) which might NOT know what to do with ".bitnet", THAT host will fix the reference. Since the gateway knows about BITNET, it does not need to munged any further than adding ".bitnet" if delivery is local. Phil Howard ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 17 Apr 89 20:46:04 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 5894; Mon, 17 Apr 89 20:47:00 EDT Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3357; Mon, 17 Apr 89 20:46:27 EDT Received: (from AccesMVS@USCMVSA for USCMVSA via NJE) (UCLA/Mail V1.410 M-ACP-1664-40); Mon, 17 Apr 89 17:34:52 PDT Received: from MC.LCS.MIT.EDU by MVSA.USC.EDU with TCP; Mon, 17 Apr 89 17:34:47 PST Received: from uxc.cso.uiuc.edu (TCP 20237527062) by MC.LCS.MIT.EDU 17 Apr 89 19 :58:05 EDT Received: from VMD.CSO.UIUC.EDU by uxc.cso.uiuc.edu with SMTP (5.61+/IDA-1.2.8) id AA03678; Mon, 17 Apr 89 18:57:51 -0500 Message-Id: <8904172357.AA03678@uxc.cso.uiuc.edu> Received: by UIUCVMD (Mailer X1.25) id 1336; Mon, 17 Apr 89 13:50:02 CDT Date: Mon, 17 Apr 89 13:40:00 CDT X-Date: Mon, 17 Apr 89 13:40:00 CDT (Even tax day is on monday now) From: Philip Howard Subject: restructuring addresses X-Subject: restructuring addresses To: Header People Mailing-List: header-people Another good reason for restructuring address such that my address: phil@vmd.cso.uiuc.edu becomes just: or in the root-down order: phil.vmd.cso.uiuc.edu edu.uiuc.cso.vmd.phil is that I might want to have mail sent to me on this timesharing system in such a way that I can have a mail agent program break it down even further. I subscribe to several mailing lists, but it all arrives in an arbitrary sequence at one mailbox. I might like to have multiple LOGICAL mailboxes. I could have mail sent to: or in the root-down order: hdr-ppl.phil.vmd.cso.uiuc.edu edu.uiuc.cso.vmd.phil.hdr-ppl Now of course the old way can do this, too, but with the new way, it would be a lot easier and a lot more consistent. Then we would not have to dream up new headers just to allow user mail agents to discriminate mail depending on its purpose (e.g. Mailing-list: header-people).  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 17 Apr 89 21:53:48 EDT Return-Path: Received: from regin.think.com by Think.COM; Mon, 17 Apr 89 21:53:51 EDT Received: by regin.think.com; Mon, 17 Apr 89 21:53:08 EDT Date: Mon, 17 Apr 89 21:53:08 EDT Message-Id: <8904180153.AA01122@regin.think.com> From: Robert L. Krawitz Sender: rlk@Think.COM To: HEADER-PEOPLE@mc.lcs.mit.edu In-Reply-To: <8904172357.AA03678@uxc.cso.uiuc.edu> Subject: restructuring addresses Date: Mon, 17 Apr 89 13:40:00 CDT From: Philip Howard is that I might want to have mail sent to me on this timesharing system in such a way that I can have a mail agent program break it down even further. I subscribe to several mailing lists, but it all arrives in an arbitrary sequence at one mailbox. I might like to have multiple LOGICAL mailboxes. Now of course the old way can do this, too, but with the new way, it would be a lot easier and a lot more consistent. Then we would not have to dream up new headers just to allow user mail agents to discriminate mail depending on its purpose (e.g. Mailing-list: header-people). I have a tool to do something like this, called Personal Mail Daemon (pmd). This program was originally written by Jim Aspnes (now at CMU), and has been hacked now and then. It scans headers and drops mail into appropriate (most of the time) mailboxes. There's nothing that prevents you from doing this with the current mail scheme (except for fascist administrators). I could, for example, create a mailbox named header-people.rlk@think.com and direct mail from this list to it (or third-class.rlk@think.com for rdist trash and the like :-) ). Even with your scheme, mailbox creation would likely be under some sort of administrative control at many sites. This isn't to detract from your proposal. I just believe that there's nothing to prevent sites from implementing heirarchical mailboxes currently, or forbidding them under your scheme. As the maintainer of info-nets, however, I sympathize with your desire for a standardized naming scheme for mailboxes. arpalists#info-nets@andrew.cmu.edu, for example, has to be escaped to make sendmail understand it when it's in an address file; info-nets.arpalists.andrew.cmu.edu or info-nets.arpalists@andrew.cmu.edu would make more sense, but I suspect that the former would be easier to understand than the latter. Implementing this might be a hassle, however; lots of nameservers would have to know how to MX an address like this. Of course, this was said five years ago about the current domain scheme, and most people have adapted quite well, and anything that would force Certain Other Networks to conform to a standard would win... One point that you don't explicitly bring up, but that I suspect you notice, is that the division between local and global parts is somewhat arbitrary. The % and ! syntaxes (which after all are just structured uses of the local part to do source routing) make this clear. The common foo%host@bar.com often seems to be a way to get mail to something which should be foo@host.bar.com, except that bar.com doesn't have its act together. Some organizations (Xerox, for example) seem to be way ahead of the game, with "registry" systems. foobar.pa@xerox.com (foobar at Palo Alto) could obviously be written as foobar.pa.xerox.com under your scheme. foobar@pa.xerox.com would make just as much sense, at that. So given all this, just what is a practical definition of a local part of an address? Does it make sense to have an undifferentiated heirarchical address space, or does the local part of an address still make sense? ames >>>>>>>>> | Robert Krawitz 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111  Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 18 Apr 89 08:34:14 EDT Received: from ODUVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8561; Tue, 18 Apr 89 08:33:57 EDT Date: Tue, 18 Apr 89 07:11:17 EST To: header-people@mc.lcs.mit.edu From: TAN100C%ODUVM.BITNET@CUNYVM.CUNY.EDU Comment: CROSSNET mail via SMTP@INTERBIT Date: 18 April 1989, 07:10:59 EST From: TAN100C at ODUVM To: header-p at mc.lcs.mit.ed Please sign me off this list. Thank you.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Apr 89 23:22:06 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 19 Apr 89 23:03:11 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 20 Apr 89 01:20:38 GMT From: uhccux!roberta@humu.nosc.mil (Roberta Hodara) Organization: University of Hawaii Subject: x.400 Message-Id: <3798@uhccux.uhcc.hawaii.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Can somebody tell me what x.400 is ? Also is vms mail complying to x.400 ? Please reply to : roberta@uhccux.uhcc.hawaii.edu  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Apr 89 10:57:40 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 21 Apr 89 09:56:59 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 20 Apr 89 22:17:57 GMT From: hpda!hpcuhb!hpindda!ala@bloom-beacon.mit.edu (Alyson L. Abramowitz) Organization: HP Information Networks, Cupertino, CA Subject: Re: x.400 Message-Id: <3760001@hpindda.HP.COM> References: <3798@uhccux.uhcc.hawaii.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu / hpindda:comp.mail.headers / roberta@uhccux.uhcc.hawaii.edu (Roberta Hodara) / 6:20 pm Apr 19, 1989 / Can somebody tell me what x.400 is ? Also is vms mail complying to x.400 ? Please reply to : roberta@uhccux.uhcc.hawaii.edu ---------- X.400 is the name of a standard put out by CCITT. Generally when people say X.400 they mean the X.400 Series of Recommendations|MOTIS. These are a series of standards documents from CCITT and ISO which provide store and forward messaging. The most common usage of this standard is as a basis for electronic mail. X.400 is a superset of the functionality available on the internet and includes usage of non-text messages, a Directory, etc. I believe the standard VMS product is not compliant to X.400 but rather uses its own, proprietary, protocol.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Apr 89 11:25:20 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 21 Apr 89 10:56:09 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 21 Apr 89 13:36:48 GMT From: pacific.mps.ohio-state.edu!miami.mps.ohio-state.edu!verber@ohio-state.arpa (Mark A. Verber) Organization: Ohio State University, Physics Department Subject: Re: x.400 Message-Id: <162@pacific.mps.ohio-state.edu> References: <3798@uhccux.uhcc.hawaii.edu>, <3760001@hpindda.HP.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I agree that the native DEC mail system is not X.400 curtently, but DECnet Phase V is to be full ISO (whatever that means). This will include supporting X.400 and X.500 directory service (or whatever they are calling it these days). There are at least two add on commerical packages for X.400 that run on Vax/VMS machines today. Cheers, Mark A. Verber | There are two major products that verber@mps.ohio-state.edu | come out of Berkeley: LSD and BSD OSU Physics, 174 W 18th, Cols, OH 43210 | UNIX. We don't believe this to 1-614-292-8002 | be a coincidence.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Apr 89 22:29:22 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 21 Apr 89 21:38:45 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 21 Apr 89 18:32:45 GMT From: uhccux!roberta@humu.nosc.mil (Roberta Hodara) Organization: University of Hawaii Subject: target mail Message-Id: <3813@uhccux.uhcc.hawaii.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Has anybody out there had any experience with Target mail. We are thinking about buying it for our VAX network. One possible problem is the address field is short so we wouldn't be able to get to our BITNET node via our UNIX but, TArget says that in the next release the address will be lengthened.ZZ  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Apr 89 09:43:22 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 22 Apr 89 09:36:27 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 21 Apr 89 19:24:36 GMT From: mcvax!unido!sbsvax!emma@uunet.uu.net (Martin Emmerich) Organization: Universitaet des Saarlandes, Saarbruecken, W-Germany Subject: Re: x.400 Message-Id: <726@sbsvax.UUCP> References: <3798@uhccux.uhcc.hawaii.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3798@uhccux.uhcc.hawaii.edu>, roberta@uhccux.uhcc.hawaii.edu (Roberta Hodara) writes: > Can somebody tell me what x.400 is ? Also is vms mail complying to x.400 ? This is x.400 ;-) x.400 is a Message handling System, which is an own Standard. All other Mail-Formats can be converted to x.400 . Here in Germany we have a field test, sponsored by the Deutsche Bundespost. Thus all mail going via x.400 (as this one) is free. /\/> / ,--- / | Snail: Hangweg 9 / / _ __-/- o _ /-- __ __ _ __ o _ /_ | D-6601 Buebingen / /_/_(_/(_/(_(_/ ( /___//(_//(_(/_/(_(_(_/ ( | Voice: +(49)6805/8299 ---------------------------------------------------+------------------------- X.400: emma@sbsvax.informatik.uni-saarland.dbp.de | Z-Net: aniel@eiko.zer  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 25 Apr 89 06:39:08 EDT Received: by INFOODS id <00000329064@INFOODS.MIT.EDU> ; Tue, 25 Apr 89 06:06:45 EDT Date: Tue, 25 Apr 89 05:45:19 EDT From: John C Klensin Subject: Re: X.400 and VMS mail To: header-people@MC.LCS.MIT.EDU X-VMS-Mail-To: EXOS%"header-people@mc.lcs.mit.edu" Message-ID: <890425054519.00000329064@INFOODS.MIT.EDU> >I agree that the native DEC mail system is not X.400 curtently, >... 1) Current VAX Mail is not X.400-compliant. The ways are too numerous to mention, but the DEC VAX Mail product doesn't even support enough in the way of envelope (trivial) and headers (none) to support RFC822. 2) The mail in DEC's All-in-One product is claimed to be X.400-compliant today, and Digital has participated in a number of interworking demonstrations involving the use of that system communicating with others via gateways. This is also stated as "Digital has it now". Whoops: you don't run All-in-One? I'm sure someone would be happy to sell it to you. -:) >DECnet Phase V is to be full ISO (whatever that means)... It doesn't mean much of anything, in and of itself. "Full ISO" might mean "we support at least one protocol at each level", "we have redesigned our level boundaries to be complaint with the ISO OSI model", as well as "we are really supporting substituting other ISO-model modules, at any arbitrary level, with DECNet modules and we are integrating that into the standard DECNet product at no extra cost". There are also many other possibilities, and I haven't seen anything that I would consider to be equivalent to the last statement. In particular, a moderately well-integrated package of All-in-One providing a few applications-level protocols including MOTIS (to all intents and purposes, this is how ISO spells 'X.400'), a re-layering and a few revised system calls, and an improved interface that uses VAX-PSI as a transport level, rather than more traditional DECNet transport, would be "fully ISO-complaint"; Note also that there are a lot of vendors who say "we support X.400 interworking" who mean "we have built our system so that, while it does not use X.400 internally, and cannot communicate directly with X.400 systems, we have this nice gateway arrangement that we will sell or lease you that will talk with the X.400-complaint GATEWAYS to other systems." There isn't much wrong with that approach, unless you expect to run a wire between a half-dozen machines, each of which "supports" X.400 that way, and expect that they will talk with each other in the same sense that a half-dozen, e.g., TCP/IP systems running SMTP will talk with each other. > This will include supporting X.400 and X.500 directory service... That is what they (CCITT) are calling it/them. But I haven't seen that announcement from Digital with regard to VMS. All-in-One is another story. Moral: Don't believe everything you read. Especially product announcements. John Klensin, Klensin@INFOODS.MIT.EDU  Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 26 Apr 89 07:46:58 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 4333; Wed, 26 Apr 89 07:48:05 EDT Received: from ODUVM.BITNET (TAN100C) by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 8899; Wed, 26 Apr 89 07:48:05 EDT Date: Wed, 26 Apr 89 07:41:41 EST To: header-people@mc.lcs.mit.edu From: TAN100C%ODUVM.BITNET@mitvma.mit.edu Comment: CROSSNET mail via MAILER@MITVMA Date: 26 April 1989, 07:41:18 EST From: TAN100C at ODUVM To: header-people at mc.lcs.mit.edu Please sign me off from this list. Thank you.  Received: from LispM.SLCS.SLB.COM (TCP 20016401600) by MC.LCS.MIT.EDU 1 May 89 11:27:23 EDT Received: from SLCS.SLB.COM by LispM.SLCS.SLB.COM via INTERNET with SMTP id 36710; 28 Apr 89 10:52:41 CDT Received: from GLOWWORM.LispM.SLCS.SLB.COM by linus.SLCS.SLB.COM (4.0/SLCS Mailhost 1.0) id AA13169; Fri, 28 Apr 89 10:54:03 CDT Date: Fri, 28 Apr 89 10:52 CDT From: Chris Garrigues <7thSon@SLCS.SLB.COM> Subject: A mail routing question To: header-people@MC.LCS.MIT.EDU Supersedes: <19890427152700.4.7THSON@GLOWWORM.LispM.SLCS.SLB.COM>, <19890427152748.5.7THSON@GLOWWORM.LispM.SLCS.SLB.COM> Comments: Retransmission of failed mail. Message-Id: <19890428155247.5.7THSON@GLOWWORM.LispM.SLCS.SLB.COM> Another group in our company is eliminating a UUCP link to CS.UTEXAS.EDU because they can now route mail through us over SMTP/TCP. Naturally, we want to be certain that anything which worked before still will continue to work. One test case which came up was mail to: cs.utexas.edu!ibmaus!user What this was doing was sending the mail via UUCP to CS.TEXAS.EDU, and then again via UUCP from there to IBMAUS. When I got this address, I rewrote it as: user%ibmaus@cs.utexas.edu I didn't write it as: ibmaus!user@cs.utexas.edu because "a!b@c" is poorly defined. This message got shipped properly to CS.UTEXAS.EDU who then bounced it because IBMAUS wasn't a known host. My fix for this was to turn any non-domainized hosts in a UUCP path into host.UUCP when the !'s are rewritten into %'s, so this example now comes out like this: user%ibmaus.UUCP@cs.utexas.edu but I'm not convinced that this is the right thing in the general case. I can't always assume that such hosts are UUCP hosts, can I? What if the address is something like this: hosta.domain!hostb!decnetgateway!hostc!user Where the decnetgateway is looking at undomainzed hosts and routing them to whatever is the appropriate network. This would become: user%hostc.UUCP%decnetgateway.UUCP%hostb.UUCP@hosta.domain I wouldn't expect the same smart decnetgateway which will turn "hostc!user" into "hostc::user" to also turn "user@hostc.UUCP" into "hostc::user", although it would turn "user@hostc.DECNET" into "hostc::user". Is there a right answer? Chris  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 May 89 03:44:26 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa00218; 21 May 89 14:30 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6390; Sun, 21 May 89 14:19:24 EDT Received: from EDVZ.Uni-Wien.AC.AT by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 8262; Sun, 21 May 89 14:19:23 EDT Received: by AWIUNI11 (Mailer R2.01) id 6166; Sun, 21 May 89 17:44:58 MEZ Date: Sun, 21 May 89 17:45 MEZ To: HEADER-PEOPLE@MC.lcs.mit.edu From: MAIER%EDVZ.UNI-SALZBURG.ADA.AT@mitvma.mit.edu Comments: +++ Changed X.430-Header: +++ x = BASIC TO: x FROM: "Franz Maier" x MESSAGE ID: ;292 x BODY TYPE: IA5TEXT Message-ID: <8905211430.aa00218@mintaka.lcs.mit.edu> PLEASE ADD ME TO YOUR MAILING LIST  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Jun 89 08:49:16 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22235; 7 Jun 89 8:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 7 Jun 89 08:41:58 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Jun 89 06:06:07 GMT From: Chris Bradley Organization: Coredump Central Subject: RFC822 And New BBS compatibility with UUCP Message-Id: <239@escargot.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Hello everybody, I am currently writing a BBS that will EVENTUALLY incorporate UUCP mail. I would like to be as compatible as possible, and would like from you, the users, two things: 1: A list or "god" list of things I need to include/omit in my message headers. (RFC822 Compliant, preferably) 2: Suggestions or ideas that would improve upon the current UUCP mail headers. Any help, references, or suggestions are gladly accepted and appreciated. Thanks! -->Chris  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Jun 89 16:46:21 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21430; 8 Jun 89 16:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 8 Jun 89 16:26:42 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Jun 89 19:15:23 GMT From: Scott Horne Organization: Yale University Computer Science Dept, New Haven, CT 06520-2158 Subject: Time-zone abbreviations in international mail Message-Id: <63066@yale-celray.yale.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I've established an e-mail connexion with someone in Beijing. I recently posted some news he sent me to `soc.culture.china', to which I often submit articles. The contact in Beijing asked me not to reveal his name or address; I agreed to this. Now some people in that newsgroup are accusing me of faking the mail just because I won't identify the author. I yielded more than I wanted to by posting the header without the paths and names. This still didn't convince some people; in fact, one person has called me a liar and a forger! (See his article in that group.) His reason? According to him, times on mail from Asia and Australia are given in Greenwich Mean Time, and my header contains things like `HKT' (``Hong Kong Time'') and `JST' (``Japan summer time''). I know I'm right on this, for I *did* receive that mail from Beijing. But would someone please tell him (preferably by posting to `soc.culture.china' or sending me mail, a summary of which I'll post there) that my header is genuine (or ``could be'', for cynics like him)? Advance thanks. --Scott Scott Horne Hacker-in-Chief, Yale CS Dept Facility horne@cs.Yale.edu ...!{harvard,cmcl2,decvax}!yale!horne Home: 203 789-0877 Box 7196 Yale Station, New Haven, CT 06520 Work: 203 432-1205 Summer address: 175 Dwight St, New Haven, CT I wish I *could* represent Yale, but Benno Schmidt won't let me....  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Jun 89 06:04:06 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa13552; 9 Jun 89 5:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 9 Jun 89 05:29:09 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Jun 89 05:14:19 GMT From: der Mouse Organization: McGill University, Montreal Subject: worst header mangling I've seen Message-Id: <1555@mcgill-vision.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu And I thought I'd seen some bogus addresses! Here's what showed up in my mailbox today. (I've deleted the body, and though I think it's probably not his fault, have replaced the sender's username with xxxx.) Purely for your edification and enlightenment :-) From mcvax!inesc!MAILER-DAEMON@uunet.uu.net Thu Jun 8 21:44:29 1989 Received: from uunet.uu.net by Larry.McRCIM.McGill.EDU (5.54) id <8906090144.AA14492@Larry.McRCIM.McGill.EDU>; Thu, 8 Jun 89 21:44:14 EDT Received: from mcvax.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA18632; Thu, 8 Jun 89 21:43:58 -0400 Received: by mcvax.cwi.nl via EUnet; Fri, 9 Jun 89 03:27:54 +0200 (MET) Message-Id: <8906090127.AA10090@mcvax.cwi.nl> Date: Thu, 8 Jun 89 13:20:19 EDT From: mcvax!inesc!MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem) Subject: Returned mail: User unknown To: MAILER-DAEMON@larry.mcrcim.mcgill.edu Status: RO ----- Transcript of session follows ----- mail11: mailer-daemon, unknown addressee at HOST 550 host!MAILER-DAEMON... User unknown ----- Unsent message follows ----- Received: by inesc.UUCP (1.2/Ultrix2.2) id AA29675; Fri, 9 Jun 89 00:56:28 GMT Received: by mcvax.cwi.nl via EUnet; Fri, 9 Jun 89 01:21:03 +0200 (MET) Received: from Larry.MCRCIM.MCGILL.EDU by uunet.uu.net (5.61/1.14) with SMTP id AB16251; Thu, 8 Jun 89 16:18:03 -0400 Received: from uunet.uu.net by Larry.McRCIM.McGill.EDU (5.54) id <8906081720.AA07486@Larry.McRCIM.McGill.EDU>; Thu, 8 Jun 89 13:20:19 EDT Date: Thu, 8 Jun 89 13:20:19 EDT From: Mail Delivery Subsystem Subject: Returned mail: Data format error Message-Id: <8906081720.AA07486@Larry.McRCIM.McGill.EDU> To: ----- Transcript of session follows ----- 554 ... Unbalanced '>' 554 ... Unbalanced '<' xxxx not found uumail: can't find xxxx in database 554 ... Unbalanced '>' 554 ... Unbalanced '<' 554 ... Unbalanced '>' 501 ... Data format error ----- Unsent message follows ----- Received: from uunet.uu.net by Larry.McRCIM.McGill.EDU (5.54) id <8906081720.AA07483@Larry.McRCIM.McGill.EDU>; Thu, 8 Jun 89 13:20:19 EDT Received: from mcvax.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA25912; Thu, 8 Jun 89 13:19:53 -0400 Received: by mcvax.cwi.nl via EUnet; Thu, 8 Jun 89 19:08:05 +0200 (MET) Received: by host.fctunl.rccn.pt (1.2-UNL-Apr 26) id AA19980; Thu, 8 Jun 89 13:05:42 GMT Date: Thu, 8 Jun 89 13:05:42 GMT From: mcvax!unl!MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem) Subject: Returned mail: Unable to deliver mail Message-Id: <8906081305.AA19980@host.fctunl.rccn.pt> To: mcvax!larry.mcrcim.mcgill.edu>@xxxx@iros1< ----- Transcript of session follows ----- 554 inesc::iros1@mcvax!larry.mcrcim.mcgill.edu!xxxx... Unbalanced '>' ----- Unsent message follows ----- Date: Thu, 8 Jun 89 13:05:42 GMT From: larry.mcrcim.mcgill.edu>@xxxx@iros1<@mcvax.uucp To: ap%host@inesc.uucp Subject: der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Jun 89 03:28:54 EDT Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa09950; 10 Jun 89 3:25 EDT Received: by INFOODS id <00003553172@INFOODS.MIT.EDU> ; Sat, 10 Jun 89 03:20:19 EDT Date: Sat, 10 Jun 89 03:18:54 EDT From: John C Klensin Subject: Time zones and other messed-up headers To: @MINTAKA.LCS.MIT.EDU:header-people@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu X-VMS-Mail-To: EXOS%"<@xx.lcs.mit.edu:header-people@mc.lcs.mit.edu>" Message-ID: <890610031854.00003553172@INFOODS.MIT.EDU> Scott, Your correspondent is living in an unreal world, in which everyone has the same understanding of the protocols and uses them the same way. Before coming back to the time zones, he or she might fairly accuse you of forging your own address: it came through to here as Horne-Scott@yale-zoo.arpa, and under the DNS, that address does not exist any more. Since it is an illegal address, you obviously do not exist, if you follow the logic. Or one could assume old, and slightly misbehaving (ok, more than 'slightly' misbehaving) software, rather than rampant conspiracy. Some mail systems would reject the mail and throw it away, since the return address is invalid, others (most) will let it through and hope the receiver can straighten it out. Now to time zones. The RFC that defines legal time zones in mail defines and permits three-letter time zone codes only for those zones that cross North America, more or less. That means no three-letter codes for Europe, no three-letter codes for Asia, etc. The RFC (822, incidentally), then specifies that any time zone (including those for which three letter codes are defined) can be specified by either one-letter "military" codes or by a signed offset from UT (GMT to a first approximation, but your correspondent is wrong on that count also). The "military" ones are not heavily used, and are gradually being discouraged. However, dates are transmitted in ASCII text, and "adaptations" and "extensions", however prohibited, are very common. I've heard the reasons justified in certain central European countries as, approximately, "the stupid, provincial, Americans gave their time zone names, but not anyone else's, obviously extensions are the right thing to do". So they do, and confusion abounds, since many of those three-letter codes in common use are not unique. But the situation is the same as your address. A few mail agents will take it upon themselves to police such things, and declare the header invalid, or transform the time zone (or the date-time) into a comment before passing the mail on in order to avoid violating the protocol themselves. But most don't, and you could circulate mail several times around the world with a time zone of YDT, standing presumably for Yale Daylight Time. So your correspondent could more reasonably say "call the protocol police, someone in China is sending mail with invalid time zones" or "he can't be from China, the mail was transmitted with a one-byte character code, rather than Hangi". I don't/can't have any opinion about the validity of your mail, but the claim that the time-zone nonsense proves anything is nonsense. And there *are* mechanisms for getting email to and from China, however slow and inefficient, so it seems to me that the burden of proof is on your accusers. John Klensin Center for International Studies MIT Klensin@INFOODS.MIT.EDU  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Jun 89 07:59:43 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24073; 10 Jun 89 7:54 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 10 Jun 89 07:22:43 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Jun 89 13:27:00 GMT From: John Pettitt Organization: Specialix International, London, UK. Subject: Return-view-to: Message-Id: <3990@slxsys.specialix.co.uk> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Is the `Return-view-to:' header legal ? If so what should a user agent do with it ? > X-Mailer: SCO Office Portfolio (version 1.0) > To: jpp > Subject: test > Return-receipt-to: jpp > Return-view-to: jpp > From: jpp While I'm on the subject what whould I do with return receipt tickets from dead `non-domain' mailers (like sco op) ? John Pettitt postmaster@specialix.co.uk -- John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR {backbone}!ukc!slxsys!jpp jpp@slxinc.uucp jpp@slxsys.specialix.co.uk Tel: +44-1-941-2564 Fax: +44-1-941-4098 Telex: 918110 SPECIX G >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Jun 89 18:47:01 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28411; 10 Jun 89 18:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 10 Jun 89 17:49:39 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 10 Jun 89 21:43:35 GMT From: Joe Buck Organization: Entropic Processing, Inc., Cupertino, CA Subject: Re: Time-zone abbreviations in international mail Message-Id: <3292@epimass.EPI.COM> References: <63066@yale-celray.yale.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <63066@yale-celray.yale.UUCP> Horne-Scott@cs.yale.edu (Scott Horne) writes: >I've established an e-mail connexion with someone in Beijing. I recently >posted some news he sent me to `soc.culture.china', to which I often submit >articles. The contact in Beijing asked me not to reveal his name or address; >I agreed to this. > >Now some people in that newsgroup are accusing me of faking the mail just >because I won't identify the author. I yielded more than I wanted to by >posting the header without the paths and names. > >This still didn't convince some people; in fact, one person has called me a >liar and a forger! (See his article in that group.) His reason? According >to him, times on mail from Asia and Australia are given in Greenwich Mean > Time, >and my header contains things like `HKT' (``Hong Kong Time'') and `JST' >(``Japan summer time''). The person who made this accusation against you is confused about the difference between news (netnews) and mail. The example he gave about "what headers look like" showed headers from a news article, not from a mail message. That is, it had a "Newsgroups:" line, no "Received" headers, and gave a time in GMT. On the other hand, the headers you showed don't prove that much, though, trusting person that I am, I don't see why I shouldn't believe you. They look like they may have come from a real message. By the way, I'm curious. Just what did you do to stir up such hate against you? Seems like the people accusing you of things only need to see your name to start frothing at the mouth. Are you really the evil agent of international communism that they say you are? :-) -- -- Joe Buck jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jun 89 00:49:39 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00598; 11 Jun 89 0:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 10 Jun 89 23:50:32 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Jun 89 03:01:00 GMT From: Mark Harris Organization: U of M Engineering, Ann Arbor, Mich. Subject: RFC-822 'phrase' question Message-Id: <43c2245d.129dc@blue.engin.umich.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I have noticed that a number of mailers will generate From: lines like: From: John Q. Public This is clearly wrong according to a strict interpretation of RFC-822, since periods are not allowed in a 'phrase', unless they are part of a 'quoted-string', which must be enclosed in quotes. Not only have I found that several mailers use such syntax, but some RFCs as well! (In fact, the above line was taken from RFC-821, page 53.) Is such syntax acceptable, or should my mailer put quotes around all user names containing periods? On a related note, I have also seen the following header: In-Reply-To: Your message of Tue, 30 May 89 15:49:35 EDT Although it may look pretty, this header is also wrong according to RFC-822 since neither commas nor colons are allowed in a 'phrase'. This header would look a lot uglier if quotes were used, however. Are all mailers that generate either of these two types of headers broken, or am I missing something? I know that there is a correction to the RFC-822 'mailbox' definition in the Host Requirements RFC, but have there been other changes that I missed? Thanks in advance to anyone that can enlighten me. -- Disclaimer: I speak only for myself. Mark Harris  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jun 89 16:50:54 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05909; 11 Jun 89 16:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 11 Jun 89 15:32:51 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Jun 89 19:27:33 GMT From: Dan Heller Organization: University of California, Berkeley Subject: Re: Return-view-to: Message-Id: <14552@pasteur.Berkeley.EDU> References: <3990@slxsys.specialix.co.uk> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: > Is the `Return-view-to:' header legal ? If so what should a user > agent do with it ? a User Agent? Don't you mean the Transport Agent? User agents don't deal with things like retrun-reciept-to, etc... MTAs to. but nevertheless, this is something I haven't heard of before, so I won't venture a guess as to what to do with it. However, I might shed some light on the origin of the problem. > > X-Mailer: SCO Office Portfolio (version 1.0) This comes frokm sco's funky little Office Automation package they developed. Mail was written without domains in mind or the foresight of a networking community. That is, this mailer does not handle mailing outside of sco very well. If it successfully delivers mail out of sco, the headers are outrageous -- it only allows one address on the To: header and it has all the names, address, domains, hostnames, pathes and sometimes even comment all scrunched together with a wild assortment of bangs and at's and the like interspersed between them. I once got a header: To: island!michaelb@island.sun.argv.uucp!jamescb.sco.maui@heller.dan.com when it was supposed to be addressed to: To: sun!island!maui!argv (dan heller), jamescb@sco.com, michaelb The good side of this is that sco does has a growing community of mush users within the company. Dan Heller  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jun 89 12:53:32 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa22906; 12 Jun 89 12:49 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6499; Mon, 12 Jun 89 12:48:50 EDT Received: from ICSA.RICE.EDU by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 6375; Mon, 12 Jun 89 12:48:50 EDT Received: by RICE (Mailer R2.03B) id 8465; Mon, 12 Jun 89 11:19:20 CDT Date: Mon, 12 Jun 89 11:13:42 CDT From: "Mark R. Williamson" Subject: Re: Return-view-to: To: HEADER-PEOPLE@mc.lcs.mit.edu In-Reply-To: Message of Sun, 11 Jun 89 19:27:33 GMT from Message-ID: <8906121249.aa22906@mintaka.lcs.mit.edu> On Sun, 11 Jun 89 19:27:33 GMT Dan Heller said: >In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt) > writes: >> Is the `Return-view-to:' header legal ? If so what should a user >> agent do with it ? >a User Agent? Don't you mean the Transport Agent? User agents don't deal >with things like retrun-reciept-to, etc... MTAs to. but nevertheless, this >is something I haven't heard of before, so I won't venture a guess as to what >to do with it. ... Since the original message cited both Return-reciept-to: and Return-view-to: lines, my guess is that the latter (new to me as well) requests a message when the original is seen by the user, while the former is to happen when the message is "delivered" (available to be read). Although it is certainly arguable that delivery receipts are the province of Transport Agents, receipts indicating "viewing" can only be issued by a User Agent (since the Transport Agent presumably has no way of detecting that action). Can anyone suggest a meaning for Return-view-to: that could be handled by a Transport Agent? Mark R. Williamson, Rice University, Houston, TX; MARK@ICSA.RICE.EDU ------------------------- The above opinions are my own and not necessarily those of Rice University.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jun 89 15:59:55 EDT Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa29784; 12 Jun 89 15:58 EDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.51) id ; Mon, 12 Jun 89 12:57:23 -0700 Date: Mon, 12 Jun 89 12:56:58 PDT From: postel@venera.isi.edu Posted-Date: Mon, 12 Jun 89 12:56:58 PDT Message-Id: <8906121956.AA07988@bel.isi.edu> Received: by bel.isi.edu (5.54/5.51) id AA07988; Mon, 12 Jun 89 12:56:58 PDT To: header-people@mc.lcs.mit.edu Subject: Time zones and other messed-up headers Return-Path: Date: Fri, 22 Feb 85 14:55 EST From: Gary Dixon Subject: Re: zone sources To: Saltzer@MIT-MULTICS.ARPA cc: "Gary M. Palter" , James A Falksen Resent-Date: 22 Feb 85 22:43 EST Resent-From: Saltzer@MIT-MULTICS.ARPA Resent-To: postel@USC-ISIF.ARPA Resent-Comment: Jon, -- Remember the discussion a couple of months ago about time zone designators and the Multics protocol police rejection of things not in your specification? Well, the Multics central guru bureau has reversed field, and is about to start accepting any time zone designator in a much larger legal list, which I attach for your amusement. If you should ever find yourself faced with a need to reissue the relevant RFC and a demand for further time zone definitions, these people, in classic Multics fashion, seem to have gotten off to a somewhat scholarly start (notwithstanding the astrology reference.) -- Now if we could just get the ISO people to debate things like this instead of proposing presentation management protocols before anyone has built one, they might actually provide us a useful service. -- Regards, Jerry -- ------- Hi, Jerry: Gary Palter relayed your inquiry on Multics time zones to me, as project leader of the software team which developers the new Multics date/time software. Jim Falksen was the other team member, and he supplied our starting set of time zone names, which were then augmented based upon customer input. Our investigations haven't turned up any standards for zone names, other than the ANSI standard for US names. It took some digging to find any references which listed zone names and offsets. Jim Falksen used the following sources to form his initial list of time zone names: from THE ASTROLOGY ANNUAL REFERENCE BOOK, 1981 by Marcian B. MacGregor and Zipporah Pottenger Dobyns, Ph.D. "STANDARD TIME(ZONE TIME): At an International Conference held in Washington D.C. on October 1, 1884, the Greenwich Meridian was adopted as the prime meridian (0 degrees), with equal division of the world in 24 fifteen-degree time zones (as originally proposed by Sanford Fleming, a Canadian civil and railway engineer). Subsequently the following International Time Zones were adopted: -0000 WET Western European Time -0100 WAT West Africa Time -0200 AT Azores Time -0300 BST Brazil Std Time -0330 NFT Newfoundland Time -0400 AST Atlantic Std Time -0500 EST Eastern Std Time -0600 CST Central Std Time -0700 MST Mountain Std Time -0800 PST Pacific Std Time -0900 YST Yukon Std Time -1000 CAT Central Alaska Time -1030 HST Hawaiian Std Time *Hawaii adopted -1000 in 1947 -1100 NT Nome Time -1100 BT Bering Time -1200 IDLW INternational Date Line, West +0100 CET Central European Time +0200 EET Eastern European Time, USSR Zone 1 +0300 BT Baghdad Time, USSR Zone 2 +0330 IT Iran Time +0400 USSR Zone 3 +0500 USSR Zone 4 +0530 IST Indian Standard Time +0600 USSR Zone 5 +0630 NST North Sumatra Time +0700 SST South Sumatra Time, USSR Zone 6 +0730 JT Java Time +0800 CCT China Coast Time, USSR Zone 7 +0830 MT Moluccas Time +0900 JST Japan Std Time, USSR Zone 8 +0930 SAST South Australia Std Time +1000 GST Guam Std Time, USSR Zone 9 +1130 USSR Zone 10 +1130 NZT New Zealand Time *adopted +1200 in 1945 +1200 IDLE International Date Line, East" A second source was THE AMERICAN EPHEMERIS, 1971 to 1980, By Neil F Michelsen. "Time Zones of the World +0000 GMT Greenwich -0100 WAT West Africa -0200 AT Azores -0300 Brazil Zone 2 -0330 NST Newfoundland -0400 AST Atlantic -0500 EST Eastern -0600 CST Central -0700 MST Mountain -0800 PST Pacific -0900 YST Yukon -1000 AHST Alaska-Hawaii -1030 HST Hawaiian -1100 NT Nome -1100 BST Bering -1200 Int'l Date Line +0100 CET Central European +0100 MET MIddle European +0200 EET Eastern European +0300 BT Baghdad +0400 USSR Zone 3 +0500 USSR Zone 4 +0530 IST Indian +0600 USSR Zone 5 +0630 NST North Sumatra +0700 SST South Sumatras +0730 JT Java +0800 CCT China Coast +0900 JST Japan +0930 SAST South Australia +1000 GST Guam +1200 NZT New Zealand" From these two lists we derived the following times. Items below which are starred were added to the basic list at customer request. known time zones: |-11:00 nt Nome Time | |-10:00 ahst Alaska-Hawaii Standard Time | | | -9:00 yst Yukon Standard Time | | | | -8:00 pst Pacific Standard Time | | | | | -7:00 mst Mountain Standard Time | | | | | -7:00 pdt Pacific Daylight Time | | | | | | -6:00 cst Central Standard Time | | | | | | -6:00 mdt Mountain Daylight Time | | | | | | | | | | | |-11:00|-10:00| -9:00| -8:00| -7:00| -6:00| -5:00| -4:00| -3:00| -2:00| | | | | | | | | | | | Eastern Standard Time est -5:00| | | | Central Daylight Time cdt -5:00| | | | Atlantic Standard Time ast -4:00| | | Eastern Daylight Time edt -4:00| | | Newfoundland Standard Time nst -3:30 | | Greenland Standard Time gst -3:00| | Atlantic Daylight Time adt -3:00| | Azores Time at -2:00| | -1:00 wat West Africa Time | | +0:00 ut Universal Time | | +0:00 z Universal Time | | +0:00 gmt Greenwich Mean Time | | | +1:00 bst British Summer Time (*) | | | +1:00 cet Central European Time | | | +1:00 met Middle Europe Time | | | +1:00 mewt Middle Europe Winter Time | | | +1:00 swt Swedish Winter Time (*) | | | +1:00 fwt French Winter Time (*) | | | +1:00 hfh Heure Francais d'Hiver (*) | | | | +2:00 mest Middle Europe Summer Time | | | | +2:00 eet Eastern European Time | | | | +2:00 sst Swedish Summer Time (*) | | | | +2:00 fst French Summer Time (*) | | | | +2:00 hfe Heure Francais d'Ete (*) | | | | | +3:00 bt Baghdad Time | | | | | | +4:00 zp4 GMT +4 hours. | | | | | | | +5:00 zp5 GMT +5 hours. | | | | | | | | | | | | -1:00| +0:00| +1:00| +2:00| +3:00| +4:00| +5:00| +6:00| +7:00| +8:00| | | | | | | | | | | | Indian Standard Time ist +5:30 | | | GMT +6 hours. zp6 +6:00| | | (*) West Australian Standard Time wast +7:00| | Java Time jt +7:30 | (*) West Australian Daylight Time wadt +8:00| China Coast Time cct +8:00| | +9:00 jst Japan Standard Time | +9:30 cast Central Australian Standard Time (*) | +9:30 sast South Australian Standard Time | |+10:00 east East Australian Standard Time (*) | | +10:30 cadt Central Australian Daylight Time (*) | | +10:30 sadt South Australian Daylight Time (*) | | |+11:00 eadt East Australian Daylight Time (*) | | | |+12:00 nzt New Zealand Time | | | | | | +9:00|+10:00|+11:00|+12:00| Also, we have recently received a request to add +12:00 nzst New Zealand Standard Time (*) +13:00 nzdt New Zealand Daylight Time (*) but haven't added them to our table yet. Hope this helps. Gary  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jun 89 17:20:41 EDT Received: from Valeria.CS.UCLA.EDU by mintaka.lcs.mit.edu id aa13634; 12 Jun 89 17:15 EDT Return-Path: Received: by valeria.cs.ucla.edu (Sendmail 5.61.ucla-32/2.16) id AA23422; Mon, 12 Jun 89 14:14:56 -0700 Date: Mon, 12 Jun 89 14:14:54 PDT From: Rich Wales Message-Id: <890612.211454z.23383.wales@valeria.cs.ucla.edu> To: header-people@mc.lcs.mit.edu Subject: Re: Time zones and other messed-up headers References: Message of Mon, 12 Jun 89 12:56:58 PDT from "postel@venera.isi.edu" <8906121956.AA07988@bel.isi.edu> Regarding Gary Dixon's message, posted to HEADER-PEOPLE by Jon Postel: If nothing else, I think this hopelessly unwieldy list illustrates why the only truly reasonable thing to do is to *mandate* the use of numeric offsets relative to UT -- with the option to include a local time zone abbreviation as a *comment*. Any software which wished to work with a time stamp (e.g., in order to sort mail by date/time) could then use the numeric offset and would not have to worry about trying to decipher an obscure (and possibly ambigu- ous!) abbreviation. -- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683 3531 Boelter Hall // Los Angeles, California 90024-1596 // USA wales@CS.UCLA.EDU ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales "This is yet another example of how our actions have random results."  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 07:49:37 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02176; 13 Jun 89 7:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 13 Jun 89 07:18:34 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Jun 89 01:06:38 GMT From: John Diamant Organization: HP SESD, Fort Collins, CO Subject: Re: Return-view-to: Message-Id: <7260009@hpfclp.SDE.HP.COM> References: <3990@slxsys.specialix.co.uk> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu > In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: > > Is the `Return-view-to:' header legal ? If so what should a user > > agent do with it ? > a User Agent? Don't you mean the Transport Agent? User agents don't deal > with things like retrun-reciept-to, etc... MTAs to. That's an interesting point, and it may be that the relevant mail standards say that (I don't know; I'm not familiar with either of the above mentioned headers), but it wouldn't be a very useful interface if the MTA implemented return-receipt-to. A return receipt is analagous to a registered letter. A receipt should only be generated when the recipient has actually seen the letter. To have the MTA supply the receipt would be misleading at best. All it would tell you is that the mail arrived on the destination host. This is unfortunate as UAs aren't supposed to have to deal with things like that, but really, it's the only way to implement a return receipt correctly. John Diamant Software Engineering Systems Division Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 13:44:25 EDT Received: from MNEMOSYNE.ACA.MCC.COM by mintaka.lcs.mit.edu id aa06404; 13 Jun 89 13:41 EDT Received: from SURYA.CYC-WEST.MCC.COM by MNEMOSYNE.ACA.MCC.COM via DIAL with SMTP id 33686; 13 Jun 89 12:01:43 CDT Received: from XANTHIPPE.cyc-west.mcc.com by SURYA.CYC-WEST.MCC.COM via INTERNET with SMTP id 19352; 13 Jun 89 09:59:30 PDT Date: Tue, 13 Jun 89 10:00 PDT From: David Vinayak Wallace Subject: Return-view-to: To: John Diamant cc: header-people@mc.lcs.mit.edu In-Reply-To: <7260009@hpfclp.SDE.HP.COM> Message-ID: <19890613170001.6.GUMBY@XANTHIPPE.cyc-west.mcc.com> Date: 13 Jun 89 01:06:38 GMT From: John Diamant This is unfortunate as UAs aren't supposed to have to deal with things like that, but really, it's the only way to implement a return receipt correctly. To re-open a perennial topic, having the UA send the receipt doesn't assure you of much. What's correct? If you fail to receive a receipt, does that mean that the user didn't see the message or that s/he disabled the receipt mechanism? (and of course it doesn't solve the hermaneutic problem of whether or not the user understood, much less actually read the message). Once again, an analogy with the hardcopy postal system applies. The post ofifice only guarantees delivery of an envelope; it makes no claims about the contents. If you really want to know if the user "got the message" you must resort to a higher-level protocol (e.g. by putting "Let me know what you think about this" in the body of your message).  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 14:17:47 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06975; 13 Jun 89 14:16 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 13 Jun 89 13:45:52 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Jun 89 07:03:30 GMT From: John Pettitt Organization: Specialix International, London, UK. Subject: Re: Return-view-to: Message-Id: <4037@slxsys.specialix.co.uk> References: <14552@pasteur.Berkeley.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu From article <14552@pasteur.Berkeley.EDU>, by dheller@cory.Berkeley.EDU (Dan Heller): > In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: >> Is the `Return-view-to:' header legal ? If so what should a user >> agent do with it ? > a User Agent? Don't you mean the Transport Agent? User agents don't deal > with things like retrun-reciept-to, etc... MTAs to. but nevertheless, this > is something I haven't heard of before, so I won't venture a guess as to what > to do with it. However, I might shed some light on the origin of the problem. > >> > X-Mailer: SCO Office Portfolio (version 1.0) > This comes frokm sco's funky little Office Automation package they developed. > The good side of this is that sco does has a growing community of mush > users within the company. > Dan Heller The Return-view-to: is by definition a user agent problem. The idea is it sends a receipt when the user reads (views) the mail, not on final transport stage. The reason for my original posting is that we have just installed SCO OP for our non-technical users and they are sending mail using the OP mailer (which for all it's faults is not bad for non technical users). One of the `features' of the op mailer is that is can generate `view' receipts and track which ones you have had back so far. My problem is that the technical users all use mush (what else ? :-) and now I have to hack support for view receipts into mush. I would like to do a good job of it, I.E. conform to any standards that may be applicable and be compatible with the rest of the world. So the orgiginal question remains: What should a mail user agent do with `Return-view-to:' ? John Pettitt postmaster@specialix.co.uk -- John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR {backbone}!ukc!slxsys!jpp jpp@slxinc.uucp jpp@slxsys.specialix.co.uk Tel: +44-1-941-2564 Fax: +44-1-941-4098 Telex: 918110 SPECIX G >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 15:29:01 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07744; 13 Jun 89 15:17 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 13 Jun 89 15:02:05 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Jun 89 18:59:22 GMT From: Dan Heller Organization: University of California, Berkeley Subject: Re: Return-view-to: Message-Id: <14602@pasteur.Berkeley.EDU> References: <14552@pasteur.Berkeley.EDU>, <4037@slxsys.specialix.co.uk> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Note, I added comp.mail.mush and comp.unix.xenix to the newsgroups list ... In article jpp@slxsys.specialix.co.uk (John Pettitt) writes: > From article by dheller@cory.Berkeley.EDU (Dan Heller): > > In article jpp@specialix.co.uk (John Pettitt) writes: > >> Is the `Return-view-to:' header legal ? If so what should a user > >> agent do with it ? > > a User Agent? Don't you mean the Transport Agent? User agents don't deal > > with things like retrun-reciept-to, etc... MTAs do. but nevertheless, this > > is something I haven't heard of before, so I won't venture a guess as to what > > to do with it. However, I might shed some light on the origin of the problem. > >> > X-Mailer: SCO Office Portfolio (version 1.0) > > This comes from sco's funky little Office Automation package they developed. > > The good side of this is that sco does has a growing community of mush > > users within the company. > > Dan Heller > > The Return-view-to: is by definition a user agent problem. The idea is it > sends a receipt when the user reads (views) the mail, not on final transport > stage. The reason for my original posting is that we have just installed SCO > OP for our non-technical users and they are sending mail using the OP > mailer (which for all it's faults is not bad for non technical users). > One of the `features' of the op mailer is that is can generate `view' receipts > and track which ones you have had back so far. My problem is that the > technical users all use mush (what else ? :-) and now I have to hack > support for view receipts into mush. > I would like to do a good job of it, I.E. conform to any standards that > may be applicable and be compatible with the rest of the world. So the > orgiginal question remains: > What should a mail user agent do with `Return-view-to:' ? > > John Pettitt > postmaster@specialix.co.uk As you've described it, this is a very potentially buggy thing to do: the UA should not be involved. However, let's address the issue anyway... What should the UA do with Return-View-To: headers? The same as what the MTA does with Return-Receipt-To: headers -- mail back to the person or address listed on the header. This means one of two things has to happen -- either the address on the header has to be complete and guranateed to work as it is sent by the originator of the message, or the MTAs in the path have to know about and modify this header en route. The latter, of course, is impossible since there is no specification for this in the RFC. It also implies the same problems that Return-Path: and From: headers have --that the address might be invalid due to bad or inconsistent MTAs (see previous discussion about rewriting From: lines in comp.mail.misc). Therefore, this new option must be restricted to a local (LAN) environment. It's somewhat easier to implement this way, but many problems still exist. As for the header and it's content, just have the user's login name only listed: Return-View-To: argv When the UA decides to reply to the user, it simply replies to the address listed -- the MTA will resolve the login name (via aliases file or whatever). Seems simple enough ... but this won't work anyway. Consider the following arguments. If the UA is responsible for this, then consider what happens when the user reads a message: a reply is now automatically sent, the message is flagged for having read the message and for having been replied to, but the user e(x)its out of the mail program not updating anything. There is no way to save the fact that the message has been read or replied to. Ok, let's hypothetically solve that problem by forcing updates for such situations. 'x' will now update -only- those messages that have been replied to. What happens if the folder is read-only? The forced updated cannot happen. Let's say that the user hasn't read the message, but instead has saved it in another folder or a filename or has printed it on the printer. Should these actions be considered as having 'read' the message? It's a hazy area here, but I would argue "no" because it is not unlike another hop in the path of the delivery of the message. The printer does not imply that the user has read the message, nor does saving it to a plain file. If you save it to a folder, you could save the extra information that the message has been return-view-to'ed, but what if you read the message *after* having saved it. The message has been viewed and the originator replied to, but what happens when the user reads the message in that other folder the message was previously saved to? As far as that folder is concerned, it hasn't been read yet. Should it generate another reply? How would it know not to? The more I think about this, the more I conjure up cases which break this system -- it is poor design to try to have the UA do it. But, in spite of all that and if you really want to do it in mush, then you want to add a new flag (VIEWED) in mush.h as it will be a new flag added to the m_flags field of the "msg" data structure. Go into display_msg() and when the message is read (is_read() is called), you can kludge a reply_to_hdr value set to Return-Receipt-To and call reply_to() on that message and generate an automatic reply indicating that the message has been viewed. Dan Heller  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jun 89 19:20:34 EDT Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa19338; 13 Jun 89 19:17 EDT Received: from naggum.uu.no by ifi.uio.no (5.61++/1.15) with SMTP id AA14868; Wed, 14 Jun 89 01:17:56 +0200 Received: by naggum.uu.no (Xpresmail/2.1A) id AA18134; Wed, 14 Jun 89 01:12:18 +0200 Date: Wed, 14 Jun 89 01:12:18 +0200 From: Erik Naggum Subject: Re: Return-view-to: To: header-people@mc.lcs.mit.edu, jpp@slxsys.uucp Message-Id: <8906132312.AA18134@naggum.uu.no> I have written a few mailers over my time as a programmer and mail user. I have also sent a lot of mail and received several lots of mail. Thus established credentials, now for the comments. :-) A proper, standard-conforming mail reader (a.k.a. "user agent") shall, according to the operating standards in the Internet, take NO ACTION upon seeing headers like "Return-Receipt-To" and "Return-View-To". As long as mail does not enter the Internet, any action can be taken, of course, and for in-house, company-wide, etc, mail, this could be a feature. For mail crossing the line of demarcation between local network and the Internet, such headers should not elicit action, and any messages resulting from them should be dropped on the floor with no return message to any part in the mail transaction. I have seen a few mailers who have produced the "R-R-To" header, and have never seen any feature to turn the damn thing off. What if I don't want receipts? What if I want the person in question to give a hint of his receiving my letter? (A higher-level "protocol" was mentioned. This is the Right Thing.) Get rid of both of these headers on Internet mail. As I said, what is done on company-wide mail, is entirely up to the company, and I think that the best solution would be to enable the mail reader to detect the receipt of either kind and set appropriate flags on the replied-to message and/or the copy of the sent message. This is, after all, possible within a company, but I would assume that the formats of these messages would need standardization to be useful. No such standards exist on the Internet. Maybe they should. They should be implemented by mail readers at both ends and relieve the user of reading machine-generated receipts. (The same is true for error messages, but that's another question.) Aside from the technical details of implementation, this is also a political question. Do we really want to teach our users not to reply to "receipts"? (If this is not implemented in the mail reader.) Conclusion: For company-wide, in-house mail: Great, do what you want. For Internet mail, remove them or standardize them completely. Cheers, --Erik Naggum +----+ +----+ Email: erik@naggum.uu.no || enag@ifi.uio.no === | === / Snail: Naggum Software; 1560 VIKA; 0118 OSLO; NORWAY === | === / Phone: +472-717-822 (office, all hours) -352-977 (fax) +----+ +----+ Quote: "These are my opinions, not those of my employees."  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jun 89 07:35:56 EDT Received: from ssyx.UCSC.EDU by mintaka.lcs.mit.edu id aa07861; 14 Jun 89 7:34 EDT Received: by ssyx.ucsc.edu (4.0/1.1) id AA22925; Wed, 14 Jun 89 04:34:37 PDT Date: Wed, 14 Jun 89 04:34:37 PDT To: header-people@mc.lcs.mit.edu From: Brad Allen Subject: re: Re: Return-view-to: In-Reply-To: <7260009@hpfclp.SDE.HP.COM> of 13 Jun 89 01:06:38 GMT; #7207 References: <3990@slxsys.specialix.co.uk> <7260009@hpfclp.SDE.HP.COM> Message-Id: <1989JE14.104217,7209;ULMO@SSYX.UCSC.EDU> > A receipt should only be generated when the recipient has actually seen > the letter. To have the MTA supply the receipt would be misleading at best. > All it would tell you is that the mail arrived on the destination host. > > This is unfortunate as UAs aren't supposed to have to deal with things like > that, but really, it's the only way to implement a return receipt correctly. It should be specified what the ack is, what it is referring to. I find acks acceptable in any form, as long as they are correct to an authenticity which I accept. i.e. if I ask for receipt or acknowledgement, I might be satisfied knowing that the mail got to any of the following: - the proper section of the world - the general area - the site - the department - the host machine - the particular user mailbox - the user Depending on the situation. It is ok to ACK something as long as you are not lying. For instance, there is a difference between "user has read this letter" and "user deleted this letter without reading it", and I wouldn't want to get the former ack when in fact the latter ack is the truth. If the user doesn't want to let me know whether he read it personally, he may opt to have a less fruitful ack come through: "mail made it to user mailbox and user has dealt with it" or even "mail made it to user mailbox". If a host is incapable of acking something that I ask it to ack, I ought to know that somehow. It can be implicitly understood that acks closer to the destination make any requests for acks further from the destination (earlier in the path) unimportant, but this would also have to be considered by any standard for definition. What I'm saying is that I want flexibility, only because that seems much more realistic and useful to me. I can imagine some sort of header specifying various types of acks I want, and a standard dictating what requests were subsets and supersets of other requests and/or replies, how to do them, what unrequested acks mean, the machine-parsable format of an ack, etc. On a different note, I find it appalling that the Internet mail standards do not use ACK as a reliability measure. The top level protocol should always have some reliable mechanism of ACK, and I'm sick of this being the human. I point out also that any link in the chain which does not use an ack will break the chain. I have lost many hundreds of messages because my own user mailer reception program would malfunction for one reason or another (full disk, bug in program, renamed object, you name it), and the mail got bounced to wherever it came from. I would like ACKs to take care of this as well.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jun 89 19:35:46 EDT Received: from [128.208.120.3] by mintaka.lcs.mit.edu id aa07242; 14 Jun 89 19:34 EDT Return-Path: Received: from Tomobiki-Cho.CAC.Washington.EDU (localhost) by Tomobiki-Cho.CAC.Washington.EDU (NeXT-0.8/UW-NDC Revision: 1.60.MRC ) id AA06153; Wed, 14 Jun 89 16:32:33 PDT Date: Wed, 14 Jun 1989 16:15:26 PDT From: Mark Crispin Sender: mrc@tomobiki-cho.cac.washington.edu Subject: re: Re: Return-view-to: To: Brad Allen Cc: header-people@mc.lcs.mit.edu In-Reply-To: <1989JE14.104217,7209;ULMO@SSYX.UCSC.EDU> Message-Id: Although I understand the reason why many people want return receipts in Internet mail, I'm extremely skeptical that they'll ever be implemented. This discussion comes up every couple of years and eventually it dies down, but not after a lot of chest-pounding and pontificating. The existing netmail has a system of acks. A mail client accepts responsibility for a message -- to deliver it or to return a negative answer to the sender. It cannot surrender responsibility for the message until it has received a positive answer from a mail server that the server has accepted responsibility for the message. As long as each link in the chain maintains the return path correctly, there is no problem in transmitting the NACK. Note that the same mechanisms that can cause a message or a NACK to be destroyed can also destroy an ACK (or forge an ACK). Leaving that aside... I can think of a lot of reasons why individuals or organizations would not implement return receipts. One excellent reason is the staggering legal consequences it may engender. Can you imagine being served with a lawsuit via netmail? It's not as crazy as it sounds. I for one do *not* want a program deciding for me whether or not to acknowledge a message. I believe that any communication which is so urgent that it requires direct positive confirmation of contact is best done by telephone. -- Mark -- -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jun 89 20:17:42 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07827; 14 Jun 89 20:16 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 14 Jun 89 19:55:11 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 14 Jun 89 17:56:44 GMT From: Frank Mayhar Organization: Bull HN Los Angeles Development Center Subject: Re: Return-view-to: Message-Id: <438@ladcgw.ladc.bull.com> References: <14552@pasteur.Berkeley.EDU>, <4037@slxsys.specialix.co.uk>, <14602@pasteur.Berkeley.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Here's an idea: Have the UA inform the MTA that Message-ID such-and-such, located in file x, needs a Return-view-to processed. The MTA then looks in the indicated file for that message-id, and if it's there, it generates the return and marks the message accordingly. So the UA simply informs the MTA when a particular message has been read (and contains a return-view-to header), and the MTA actually does the work. What are the problems with this? Any? -- Frank Mayhar ..!uunet!ladcgw!frank (frank@ladc.bull.com) Bull HN Los Angeles Development Center 5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jun 89 21:09:05 EDT Received: from [128.229.36.16] by mintaka.lcs.mit.edu id aa08408; 14 Jun 89 21:05 EDT Received: from localhost.ARPA by confusion.ads.com (5.59/1.11) id AA01657; Wed, 14 Jun 89 17:05:15 PST Message-Id: <8906150105.AA01657@confusion.ads.com> To: header-people@mc.lcs.mit.edu Subject: Change of address. In-Reply-To: Your message of 13 Jun 89 18:59:22 +0000. <14602@pasteur.Berkeley.EDU> Date: Wed, 14 Jun 89 17:05:14 PST From: barry@ads.com Please change barry@confidence.princeton.edu to barry@ads.com. Thanks, barry  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jun 89 13:28:03 EDT Received: from [192.31.95.1] by mintaka.lcs.mit.edu id aa05374; 15 Jun 89 13:26 EDT Received: by uccuxa.ucop.edu (5.57/Ultrix2.4-C) id AA28662; Thu, 15 Jun 89 10:27:54 PDT Date: Thu, 15 Jun 89 10:27:54 PDT From: Pat McGarry Message-Id: <8906151727.AA28662@uccuxa.ucop.edu> To: header-people@mc.lcs.mit.edu Subject: Mailing List Please take me off of this list.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jun 89 00:29:57 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20625; 16 Jun 89 0:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 15 Jun 89 23:55:13 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 16 Jun 89 03:33:19 GMT From: Cliff Joslyn Organization: SUNY Binghamton, NY Subject: ed/awk script to strip mail headers Message-Id: <2199@bingvaxu.cc.binghamton.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu A kind person recently sent my an ed script to strip "boring" news header lines (e.g. References, Via, etc.) Could someone be so kind as to do the same for mail? Or I guess I can write my own, if you make me. ;-> ;-> Thanks. -- O----------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large | Systems Science, SUNY Binghamton, vu0112@bingvaxu.cc.binghamton.edu V All the world is biscuit shaped. . .  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 07:55:09 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16067; 22 Jun 89 7:48 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 22 Jun 89 07:31:05 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 21 Jun 89 20:33:09 GMT From: Walter Underwood Organization: HP SW Engineering Systems - Palo Alto, CA Subject: Re: RFC-822 'phrase' question Message-Id: <1760002@hp-ses.SDE.HP.COM> References: <43c2245d.129dc@blue.engin.umich.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu > I have noticed that a number of mailers will generate From: lines like: > From: John Q. Public A safe version of this is: From: (John Q. Public) JQP@MIT-AI.ARPA In strict 822-land, the angle brackets are only allowed if there is a route address, but the draft host requirements RFC amends the BNF to allow that. The above example could have angle brackets, but they are not necessary. wunder  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 11:13:19 EDT Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa27826; 22 Jun 89 11:06 EDT Received: from naggum.uu.no by ifi.uio.no (5.61++/1.15) with SMTP id AA13641; Thu, 22 Jun 89 17:07:27 +0200 Received: by naggum.uu.no (Xpresmail/2.1A) id AA18400; Thu, 22 Jun 89 16:36:34 +0200 Date: Thu, 22 Jun 1989 16:01:44 MET DST From: Erik Naggum Subject: Re: RFC-822 'phrase' question To: Walter Underwood Cc: RFC822 still requires something here Message-Id: <8906221436.AA18400@naggum.uu.no> > > I have noticed that a number of mailers will generate From: lines like: > > From: John Q. Public Strictly speaking, this is in violation of the syntax for a "phrase", just as you are concerned about. > A safe version of this is: > > From: (John Q. Public) JQP@MIT-AI.ARPA > > In strict 822-land, the angle brackets are only allowed if there is a > route address, but the draft host requirements RFC amends the BNF to > allow that. The above example could have angle brackets, but they > are not necessary. It could _NOT_ have angle brackets with the current, unamended RFC822! You also misrepresent the issue by muddying the water around the need and allowance for angle brackets. The current syntax, to be amended by Host Requirements (at least the last draft I have), is: mailbox = addr-spec / phrase route-addr also note that route-addr = "<" [ route ] addr-spec ">" where route is clearly optional. The problem addressed in the draft Host Requirements is the requirement of a phrase in an angle-bracketed addr-spec. This will be alleviated thus (pending approval of the HR RFC): mailbox = addr-spec / [ phrase ] route-addr This I view as a Good Thing. The following characters are (still) illegal in a phrase (i.e. making it several words and/or phrases with delimiters between them): ( ) < > @ , ; : \ " . [ ] (Note that although `(' and ')' are illegal in a word, they are legal at any point where a space is legal, thus may legally terminate a word, perhaps making it one of several words in a phrase.) To conclude, the first gripe on From: John Q. Public is valid, and the standards (RFC821 OR RFC822)should be amended to correct it, and From: (John Q. Public) is illegal under the current syntax. I don't know RFC733. Anybody knows if the first From address is a relic from bygone times? Cheers, and happy parsing to you all, --Erik Naggum +----+ +----+ Email: erik@naggum.uu.no --or-- enag@ifi.uio.no === | === / Snail: Naggum Software; POB 1560 VIKA; OSLO 0118; NORWAY === | === / Phone: +47-2-717-822 (office, etc) -352-977 (fax) +----+ +----+ "These are my opinions, and not those of my employees."  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 17:06:47 EDT Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa02307; 22 Jun 89 16:40 EDT Received: from hpsdel.sde.hp.com by hp-sde.sde.hp.com ; Thu, 22 Jun 89 10:38:08 pdt Received: by hpsdel ; Thu, 22 Jun 89 10:37:53 pdt Date: Thu, 22 Jun 89 10:37:53 pdt From: Walter Underwood Message-Id: <8906221737.AA23741@hpsdel.sde.hp.com> To: hp-sdd!uunet!naggum.uu.no!erik@sde.hp.com Cc: header-people@mc.lcs.mit.edu In-Reply-To: Erik Naggum's message of Thu, 22 Jun 1989 16:01:44 MET DST <8906221436.AA18400@naggum.uu.no> Subject: RFC-822 'phrase' question I almost didn't mention the angle bracket stuff. I should have said that they are only required for route addresses. I prefer: From: jqp@host.domain (John Q. Public) but I haven't checked that rigorously. The common use of angle brackets is thanks to (you guessed it!) sendmail, which uses them to help disambiguate UUCP and ARPA addresses. It looks like the robustness principle really applies here, and that mailers should be be very conservative in what they generate and liberal in what they accept. wunder  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 16:48:15 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03225; 23 Jun 89 16:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 23 Jun 89 16:25:33 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 23 Jun 89 19:57:14 GMT From: Chris Garrigues Organization: Schlumberger Lab for CS, Austin, TX Subject: Re: RFC-822 'phrase' question Message-Id: <399@linus.SLCS.SLB.COM> References: <43c2245d.129dc@blue.engin.umich.edu>, <1760002@hp-ses.SDE.HP.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <1760002@hp-ses.SDE.HP.COM> wunder@hp-ses.SDE.HP.COM (Walter Underwood) writes: >> I have noticed that a number of mailers will generate From: lines like: >> From: John Q. Public > >A safe version of this is: > > From: (John Q. Public) JQP@MIT-AI.ARPA > >In strict 822-land, the angle brackets are only allowed if there is a >route address, but the draft host requirements RFC amends the BNF to >allow that. The above example could have angle brackets, but they >are not necessary. > >wunder I don't see the problem with the other form. Some of the rules from RFC822: authentic = "From" ":" mailbox ; Single author / ( "Sender" ":" mailbox ; Actual submittor "From" ":" 1#mailbox) ; Multiple authors ; or not sender mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec route-addr = "<" [route] addr-spec ">" addr-spec = local-part "@" domain ; global address and a parse tree of the sample given above: From: John Q. Public => From: phrase => From: phrase => From: phrase route-addr => From: mailbox => authentic What's the problem? Chris Garrigues, 7thSon@SLCS.SLB.COM  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 19:08:43 EDT Received: from hanna.cac.washington.edu by mintaka.lcs.mit.edu id aa04908; 23 Jun 89 19:04 EDT Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu (5.61/UW-NDC Revision: 1.99 ) id AA10103; Fri, 23 Jun 89 16:03:24 -0700 Date: Fri, 23 Jun 1989 15:52:44 PDT From: Mark Crispin Sender: mrc@tomobiki-cho.cac.washington.edu Subject: Re: RFC-822 'phrase' question To: Chris Garrigues Cc: header-people@mc.lcs.mit.edu In-Reply-To: <399@linus.SLCS.SLB.COM> Message-Id: In <399@linus.SLCS.SLB.COM>, Chris Garrigues writes: >>> I have noticed that a number of mailers will generate From: lines like: >>> From: John Q. Public >What's the problem? Due to a now-archaic theory of how names should work, the period after "Q" is not valid. Once upon a time, people thought that periods should be considered significant at the RFC-822 level. Study further what constitutes a "phrase" and you'll see the problem. A lot of mail software simply treats period as an ordinary alphanumeric character. However, this is contrary to what RFC-822 expects you will do. I wish the Host Requirements RFC would change this. The correct header line, From: "John Q. Public" looks ugly to many people. -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jun 89 15:44:53 EDT Received: from icsib.Berkeley.EDU by mintaka.lcs.mit.edu id aa29202; 23 Jun 89 22:15 EDT Received: by icsib.Berkeley.EDU (4.0/SMI-4.0) id AA04472; Fri, 23 Jun 89 19:18:41 PDT From: Eric Allman Message-Id: <8906240218.AA04472@icsib.Berkeley.EDU> To: Walter Underwood Cc: header-people@mc.lcs.mit.edu Subject: Re: RFC-822 'phrase' question In-Reply-To: Walter Underwood's message of Thu, 22 Jun 89 10:37:53 -0700. <8906221737.AA23741@hpsdel.sde.hp.com> Date: Fri, 23 Jun 89 19:18:38 PDT These days I try to stay out of "email wars", but I just had to respond to this one. N.B.: I'm responding only to the rather common misunderstanding in this message, not trying to trash the author. > Date: Thu, 22 Jun 89 10:37:53 pdt > From: Walter Underwood > Subject: RFC-822 'phrase' question > The common use of angle brackets is thanks to (you guessed it!) > sendmail, which uses them to help disambiguate UUCP and ARPA > addresses. This makes about as much sense as claiming that DEC is responsible for ASCII because they used it in the VT100 series. Angle brackets were part of published standards long before sendmail was even a gleam in its father's eye -- in fact, they were a royal pain to support, and (to my mind) added nothing of value. They do nothing to help disambiguate UUCP and ARPA addresses. There are many legitimate things wrong with sendmail, perhaps the worst being that it tried to bridge the gap between two entrenched standards (the ad hoc UUCP standard and the NCP/RFC733 ARPA world) and several emerging new worlds, notably the TCP/RFC822 world. The latter worlds were changing rapidly -- during the development of RFC821/822, sendmail adapted to at least a half dozen different draft versions within days of their release, providing important practical input to those specifications. Unfortunately, the flexibility that made that all possible is now an albatross, engendering formidable configuration files. (Believe it or not, the first sendmail.cf was about one page long; ruleset 0 was but a few lines. Unfortunately, I then had to add support for "@dom.ain.a,@dom.ain.b:user@dom.ain.c", which uses three punctuation characters instead of one, and is in some cases left recursive and in other cases right recursive. I also had to support the "user@hostc@hostb@hosta" syntax, specified in 733, later disallowed by administrative fiat, but still used all too heavily in the real world. I had to support nested angle brackets -- disallowed in 822, but permitted in 733; another of those features from hell that refused to die. At the time, CMU made heavy use of spaces in login names, and again sendmail managed to handle both the new and the old syntaxes. The word "at" (surrounded by spaces) was equivalent to "@" in 733-land, but sendmail coped. Several sites, including Berkeley, used ":" to separate hostname from username [as in host:user]; an especially exciting development in view of the fact that 822 had two reserved uses for the colon in addresses. Much to my shock and delight, many sites had defined "^" as an equivalent to "!" in UUCP addresses [to avoid the conflict with "!" in csh] -- it seems this had to be supported as well. I finally gave up on the "list: userA, userB, ... , userZ;" syntax, which managed to overload colon and comma, add semicolon, and be ambiguous as well, but I did accept the varient "list:;" syntax. Every single one of these -- and others that I have the discretion to avoid discussing) bloated the configuration file a little bit more.) This flexibility was great at the time, but now all it does is obfuscate the issues. If you want to credit sendmail with something, credit it for helping bring UNIX onto the Internet. Credit it for allowing communication between UUCP and the ARPAnet without requiring that UUCPers type in 822-compliant headers. Credit it for helping to make possible a world in which you can send mail to someone in Australia without knowing that your message goes through UUCP, then Internet, then X.25 something-or-other, then ACSnet, and probably a few others in between. Credit it for allowing users to continue to use their existing user interface programs, rather than insisting that they salute the new flag. Make your own choice whether to lambast or laud sendmail for refusing to decide whether "hostA!user@hostB" should be sent to hostA or hostB, deferring that decision for the local site -- even allowing sysadmins to make that decision based on the value of the hostA and hostB strings. It certainly helped perpetuate the confusion such addresses implied; but it also helped users ease their way from local networks to global networks. You can decide the value of header rewriting. It helped the development of automatic "reply" commands in mailers, without requiring that they know the topology of the internet, but it also handed miles of ropes to sloppy sysadmins, and allowed multiple address formats (such as host!user versus user@host) to continue far longer the shootout that would otherwise have probably resulted. Roll the dice about inserting "Apparently-To:" -- I didn't do this of my own volition. Several people wanted me to just add To: lines, but I resisted because messages sent to several people from outside a sendmail-based world could be delivered with an inaccurate distribution list. Using "Apparently-To:" at least admitted to the possibility of error. I'm sorry to be so verbose here; I didn't know I had it in me. I put five years into sendmail, all of it unpaid time, and I guess I still feel a bit protective. For the record, I know that the time is nearing for sendmail to step aside for something that makes a new set of assumptions. But please acknowlege that sendmail was a success for its time: it helped us move forward, and the next generation of mailers will be built on sendmail's shoulders, not on its toes. eric  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jun 89 03:35:03 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa07574; 24 Jun 89 20:28 EDT Received: by uunet.uu.net (5.61/1.14) id AA23322; Sat, 24 Jun 89 19:55:45 -0400 Date: Sat, 24 Jun 89 19:55:45 -0400 From: Rick Adams Message-Id: <8906242355.AA23322@uunet.uu.net> To: eric@icsib.berkeley.edu, wunder@sde.hp.com Subject: Re: RFC-822 'phrase' question Cc: header-people@mc.lcs.mit.edu While we're blaming mailers for things, lets not forget to blame MMDF for the abusive use of source routes where none are required. The protypical example is a certain large mail realy in the Boston area who think that they way to deal with MX records is to generated a source route. This is clearly unnecssary. I'll bet fully half of my 870 line sendmail config file is dealing with source routes from places that should know better. Yes they're legal, but their typical use can only be described as an unnecessary pain in the ass. Every time I get mail from some MMDF site complaining about not properly handling source routes (when there is no reason for specify a source route in the first place!) I come a little closer to ripping out all of the source route code from sendmail and laughing when someone complains that I'm violating the "standard" There is no place for source routes in the current mail system (MX records removed the last excuse). They should be abolished. --rick  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jun 89 18:43:13 EDT Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa04025; 25 Jun 89 18:38 EDT Received: by ifi.uio.no (5.61++/1.15) id AA09492; Mon, 26 Jun 89 00:15:22 +0200 Sender: Erik Naggum Date: Mon, 26 Jun 1989 0:15:21 MET DST From: Erik Naggum To: Rick Adams Cc: eric@icsib.berkeley.edu, wunder@sde.hp.com, header-people@mc.lcs.mit.edu Subject: Re: RFC-822 'phrase' question In-Reply-To: Rick Adam's message of Sat, 24 Jun 89 19:55:45 -0400 Message-Id: > There is no place for source routes in the current mail system > (MX records removed the last excuse). They should be abolished. > > --rick In the headers of messages they are unnecessary as well as cumbersome for users, and they introduce obstacles to adressering that are reminiscent of UUCP bang-path adressing prior to pathalias. The question is very different in the SMTP envelope, however. I, for one, favor stronger use of source routes in the envelopes, to make return paths easier to traverse. There seems to be a clause in the Host Requirements Draft RFC which requires an SMTP relay to add its own canonicalized domain name to the From (MAIL) line in the envelope, and understand it in the To (RCPT) lines. Users should also be _able_ to specify source routes, when a scenic route is deemed necessary. Provisions for support of the source routes should not be ripped out of mailers. Au contraire! It should be much easier to follow the standards. (While I commend Eric's effort on sendmail, indeed I am grateful to him, time has come to allow for simpler products in a more homogenous mail world. That's _more_ homogenous, and I also speak from the user's point of view, not about functionality.) --Erik Naggum The last defender of source routes. PS: I apologize for the violation of RFC822 in the format of the Date field.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 09:35:57 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa06552; 26 Jun 89 0:35 EDT Received: by uunet.uu.net (5.61/1.14) id AA21874; Sun, 25 Jun 89 23:44:17 -0400 Date: Sun, 25 Jun 89 23:44:17 -0400 From: Rick Adams Message-Id: <8906260344.AA21874@uunet.uu.net> To: erik@naggum.uu.no Subject: Re: RFC-822 'phrase' question Cc: eric@icsib.berkeley.edu, header-people@mc.lcs.mit.edu, wunder@sde.hp.com It is a fundamentally flawed assumption that source routes may be reversed to form a valid mail path. There are too many one way mail gateways in the world. Use of source routes encourage the concept that all routes are bidirectional and are the optimal path. I dont care what the standard says. The reality is that you can not necessarily reverse a source route and get a valid mail path. The entire point of a domain naming system is to separate the name from the route. Virtually everyone agrees that this is good. If it is good, then source routes are bad. The Recevied lines already provide all of the information that you might get from the source routes should you actually need that information. Think of Postal Mail for a minute. Do you really care what person stuck the mail in your mailbox? Do you really want to send all of your reply mail back through that person? What if they are sick for a week? The same argument applies to electronic mail. --rick  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 14:33:52 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa28616; 26 Jun 89 14:27 EDT Received: from microsoft.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA27702; Mon, 26 Jun 89 14:24:22 -0400 From: microsoft!t-dannyp@uunet.uu.net Message-Id: <8906261824.AA27702@uunet.uu.net> To: header-people@mc.lcs.mit.edu Subject: Source Routes Cc: padwa@husc3.harvard.edu Date: Mon Jun 26 10:57:36 1989 Rick, I agree that in an environment without brain-dead mailers, source routes would be an evil thing, and would be almost criminal. However, we don't live in such a world......think of all of the "dumb" mailers out there....many people still can't handle MX records!! In that kind of environment, source routes are still needed.... especially when all of the malfunctioning gateways that are operating are considered. It is tempting to say "Well, if your gateway doesn't work, then fix it!", but the sad reality is that we must keep our users happy. Until such time as all "domain-style" addresses are optimally accessable by MX-derived routes (optimally meaning without to many extraneous trips across the country) I will continue to recommend source-routes to my users.....I can't see any alternative. Danny Padwa Harvard VMS Network Programmer Padwa@Husc3.Harvard.Edu (at Microsoft for the summer...mail is forwarded) Note: The above opinions are my own, probably not those of my employers.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 14:46:35 EDT Received: from hanna.cac.washington.edu by mintaka.lcs.mit.edu id aa28841; 26 Jun 89 14:43 EDT Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu (5.61/UW-NDC Revision: 1.99 ) id AA23824; Mon, 26 Jun 89 11:40:28 -0700 Date: Mon, 26 Jun 1989 11:27:25 PDT From: Mark Crispin Sender: mrc@tomobiki-cho.cac.washington.edu Subject: Re: RFC-822 'phrase' question To: Rick Adams Cc: eric@icsib.berkeley.edu, wunder@sde.hp.com, header-people@mc.lcs.mit.edu In-Reply-To: <8906242355.AA23322@uunet.uu.net> Message-Id: A fanatic gleam appears in MRC's eye as he scans the message from Rick Adams suggesting that source routes be abolished. "Vindication!" he screams. After six and a half years of preaching that source routes were useless, he being of the %-hack cult, it seems that the religion has taken fruit. Let the Word be spread throughout the land! Then he calms down, and a mood of depression sinks in, as he realizes that now he will never have the experience, the joy, the fufilment... Yes, he'll have to strike "implement source routes" from the TOPS-20 mailsystem "to-do" list. Such sorrow! Tongue firmly in cheek, -- Mark -- -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 18:03:59 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa02409; 26 Jun 89 17:57 EDT Received: by uunet.uu.net (5.61/1.14) id AA15079; Mon, 26 Jun 89 17:56:26 -0400 Date: Mon, 26 Jun 89 17:56:26 -0400 From: Rick Adams Message-Id: <8906262156.AA15079@uunet.uu.net> To: header-people@mc.lcs.mit.edu, microsoft!t-dannyp@uunet.uu.net Subject: Re: Source Routes Cc: padwa@husc3.harvard.edu Why do you think a mailer that does not handle MX records will be able to correctly handle source routes. The now semi-official percent-hack takes care of the gateway situation. Sorry, try again.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jun 89 19:57:03 EDT Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa06272; 26 Jun 89 19:54 EDT Received: by ifi.uio.no (5.61++/1.15) id AA18099; Tue, 27 Jun 89 01:54:19 +0200 Date: Tue, 27 Jun 1989 1:54:16 MET DST From: Erik Naggum To: Rick Adams Cc: header-people@mc.lcs.mit.edu, t-dannyp@microsoft.uucp, padwa@husc3.harvard.edu Subject: Re: Source Routes In-Reply-To: Your message of Mon, 26 Jun 89 17:56:26 -0400 Message-Id: > The now semi-official percent-hack takes care of the gateway > situation. > > Sorry, try again. If you seclude the use of the %-hack to the envelope, as I suggest one do with source routes, all is well, but experience shows that hosts that are likely to use the %-hack, splat it all over the place, and also reduce to rubbles the once-working mixed-mode addresses. This is one argument against the %-hack. As we are 100% forbidden to parse the local-part, but required to let all parts of a source route be MX-resolvable (as the current draft goes), we might have reduced the size of the local-part, and user agents can exploit the knowledge that all parts of the source route are adressable directly in replies. They have no such capability with %-hacked local- parts. This is one argument against the %-hack and for source routes. We should perhaps require gateways who recognize themselves as the domain strip themselves from the %-hacked address and UNDO the bleeding %-hack in the way they introduced it. This would work, while what they do now is to translate foo!user@bar to foo!user%bar@gateway, and then send to foo with uucp when it gets back to gateway. That's the main reason I hate the %-hack vehemently! With "semi-official" things, it's no guarantee it will work, and with increasing local-parts, things will get increasingly messy, and no mailers are allowed to do anything with it. This is one argument against semi-officialness. --Erik the last defender of source routes PS: Standardize functionality, not broken implementations.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 00:34:45 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa14091; 27 Jun 89 0:21 EDT Received: by uunet.uu.net (5.61/1.14) id AA19140; Mon, 26 Jun 89 22:33:34 -0400 Date: Mon, 26 Jun 89 22:33:34 -0400 From: Rick Adams Message-Id: <8906270233.AA19140@uunet.uu.net> To: enag@ifi.uio.no Subject: Re: Source Routes Cc: header-people@mc.lcs.mit.edu As we are 100% forbidden to parse the local-part, but required to let all parts of a source route be MX-resolvable (as the current draft goes), we might have reduced the size of the local-part, and user agents can exploit the knowledge that all parts of the source route are adressable directly in replies. They have no such capability with %-hacked local- parts. This is one argument against the %-hack and for source routes. If ALL parts of the address are MX resolvable, then WHAT PURPOSE does a source route have? The Received lines provide the route trace. The MX records provide the routing. Whats left other than redundancy and ugliness? Note that the principal users of source routes do NOT restrict themselves to MX resolvable addresses which makes a bad situation even worse.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 00:46:58 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa06952; 27 Jun 89 0:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 27 Jun 89 00:26:34 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 Jun 89 10:31:10 GMT From: Greg Miller Subject: Re: RFC-822 'phrase' question Message-Id: <2377@uwovax.uwo.ca> References: <43c2245d.129dc@blue.engin.umich.edu>, <1760002@hp-ses.SDE.HP.COM>, <399@linus.SLCS.SLB.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <399@linus.SLCS.SLB.COM>, 7thson@daffy.slcs.slb.com (Chris Garrigues) writes: > and a parse tree of the sample given above: > From: John Q. Public => > What's the problem? The problem is that unquoted periods in the name tag are not allowed by RFC 822. So the above should be written as - From: "John Q. Public" //Greg Miller//  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 01:31:11 EDT Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa29861; 28 Jun 89 1:28 EDT Received: by garnet.berkeley.edu (5.57/1.32) id AA08206; Tue, 27 Jun 89 22:28:36 PDT Date: Tue, 27 Jun 89 22:28:36 PDT From: Postmaster & BITINFO Message-Id: <8906280528.AA08206@garnet.berkeley.edu> To: header-people@mc.lcs.mit.edu Subject: Re: Source Routes Cc: rick@uunet.uu.net In reply to: If ALL parts of the address are MX resolvable, then WHAT PURPOSE does a source route have? Postmasters will still have a use for source routing to override a bad MX record, in order to send a message to get the MX record fixed. I had to do that last week when a host did not realize that they needed to add a host MX record to override a wildcard MX record for their site. They had SMTP running, but my mailer which looks for a MX record first (as it should) used the wildcard MX instructions and thus did not make a direct SMTP connection based on the inet address (A record). Bill Wells postmaster@jade.berkeley.edu netinfo@garnet.berkeley.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 05:12:04 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20753; 28 Jun 89 5:09 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 28 Jun 89 04:56:15 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 28 Jun 89 01:12:41 GMT From: Jim Anderson Organization: Anderson O-Brien, Inc., St. Paul, MN Subject: Smail patches for Subject line problem Message-Id: <217@aob.aob.mn.org> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Quite a while ago, there was a patch posted for smail to fix a problem where, if smail didn't see the headers in the right order (I think this is it anyway), it would drop the Subject: line into the body of the message. Anyway, I thought I had saved it, but now that I need to get them installed, I can't find the patches. Does anybody out there still have the patches or remember what the fix was? Thanks. -- Jim Anderson (612) 636-2869 Anderson O'Brien, Inc New mail:jim@aob.mn.org 2575 N. Fairview Ave. Old mail:{rutgers,gatech,amdahl}!bungia!aob!jim St. Paul, MN 55113 "Fireball... Let me see... How did that go?"  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 06:32:33 EDT Received: from [128.114.133.1] by mintaka.lcs.mit.edu id aa21398; 28 Jun 89 6:31 EDT Received: by ssyx.ucsc.edu (4.0/1.1) id AA29541; Wed, 28 Jun 89 01:06:20 PDT Date: Wed, 28 Jun 89 01:06:20 PDT To: header-people@mc.lcs.mit.edu From: Brad Allen Message-Id: <1989JE28.071941,7248;ULMO@SSYX.UCSC.EDU> Subject: re: source routes and Rick asking why Source routes are useful for both rerouting around network problems as well as expand the destination of an MX'd host to the appropriate address on the MXing host. Network problems are many -- bad packet routing; one out of a collection of links in the network go down, and source route will help route around it; bad UUCP Map stuff (this is not really relevant to Internet proper but serves as a good example). A conceivable example of an MX using source routes: mist.aptos.ca.us preference = 10, mail exchanger = SSYX.UCSC.EDU Mail to user@mist.aptos.ca.us gets sent to SSYX.UCSC.EDU. When SSYX receives this piece of mail, it looks the address of this up in the UUCP Map pathalias output, finds this line: mist.aptos.ca.us splat!mist!%s and sends the mail off to UUCP host splat. Well, SSYX could just as easily have used source routing, converting mist.aptos.ca.us -> @splat.uucp:user@mist.aptos.ca.us or even (preferably if the mailer could handle it) mist.aptos.ca.us -> @splat.aptos.ca.us:user@mist.aptos.ca.us since @something1:something3@something2 is RFC822 whereas something1!something2!something3 is not. Splat will soon understand these routes, as will Mist. (Yes yes I know, splat already understands something1!something2!something3 form.) For the record, postmaster@ssyx flopped on making sure source routing works via the sendmail there. It doesn't, since the commas get in the way, and he has tweaked sendmail many times to get it working (for many reasons -- MXes, UUCP Mappings, to get away from the brain damaged version of sendmail and sendmail.cf Sun put out, deal with NFS hosts which some have SMTP and some don't but they all use the same directory, etc.) I can understand the argument against keeping source routes. However, the standard is the standard, and it does provide a standard way to do a needed task. I haven't studied RFC822 that much and often wonder how it is expected that @domain1,@domian2:mailbox@domain3 is supposed to be distinguished from two distinct recipients (@domain1 and @domain2:mailbox@domain3)? I can see that looking INTO the address @domain1 reveals a missing mailbox, but so what? Is that the clue the mailers are to go by? Conceivably something to @host could be SMTP'd to the host just as is, with a null username, and the host would know what to do with it (such as mail to @LastName.City.State.US where the owner didn't want to be redundant), even though the format is supposed to be user@host. What's the answer?? Which brings up the question of why we need the "@" sign. When is user.name.domain.name going to be a valid mailbox? I can easily conceive of examples ... ulmo.aptos.ca.us getting sent to me; postmaster.uunet.uu.net getting sent to Rick ... etc.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 10:35:21 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24072; 28 Jun 89 10:30 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 28 Jun 89 10:22:34 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 28 Jun 89 01:54:01 GMT From: "Govind N. Kamat" Organization: Univ. of Cincinnati, College of Engg. Subject: "Status" header Message-Id: <1322@uceng.UC.EDU> Sender: header-people-request@MC.lcs.mit.edu To: header-people@MC.lcs.mit.edu I keep noticing a header called "Status" in certain mail, with field values like "R" and "OR". What is this header supposed to represent? It doesn't seem to be part of RFC822. -- Govind N. Kamat College of Engineering kamat@uceng.UC.EDU University of Cincinnati Cincinnati, OH 45221, USA  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 11:45:37 EDT Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa25140; 28 Jun 89 11:39 EDT Received: by ifi.uio.no (5.61++/1.15) id AA03737; Wed, 28 Jun 89 17:38:57 +0200 Date: Wed, 28 Jun 1989 17:38:54 MET DST From: Erik Naggum To: "Govind N. Kamat" Cc: header-people@mc.lcs.mit.edu Subject: Re: "Status" header In-Reply-To: Your message of 28 Jun 89 01:54:01 GMT Message-Id: > I keep noticing a header called "Status" in certain mail, with field > values like "R" and "OR". It's part of the BSD Mail program (a.k.a mailx) flags support. When you see new messages, they have N in the first column. When you have not read a message before you leave your mailbox, it will show U in the header summary next time you read mail. These correspond to no status, and "O" status, respectively. When you have read a message, it will be flagged "R". If it also old, it's "RO". > What is this header supposed to represent? It doesn't seem to be part > of RFC822. What you see in your mailbox does not have to be RFC822-compliant at all. In most cases it is, vaguely, but there's no standardized way to do this. RFC822 specifies the format of INTERNET text format, not mailbox text formats. There is even a discussion in there about this specific difference. --Erik Naggum +----+ +----+ Email: erik@naggum.uu.no --or-- enag@ifi.uio.no === | === / Snail: Naggum Software; POB 1560 VIKA; OSLO 0118; NORWAY === | === / Phone: +47-2-717-822 (office, etc) -352-977 (fax) +----+ +----+ "These are my opinions, and not those of my employees."  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 12:01:39 EDT Received: from SH.CS.NET by mintaka.lcs.mit.edu id aa25348; 28 Jun 89 11:53 EDT To: Rick Adams cc: eric@icsib.berkeley.edu, wunder@sde.hp.com cc: header-people@mc.lcs.mit.edu Subject: Re: RFC-822 'phrase' question Date: Wed, 28 Jun 89 11:12:02 -0400 From: Daniel Long Message-ID: <8906281153.aa25348@mintaka.lcs.mit.edu> The protypical example is a certain large mail realy in the Boston area who think that the way to deal with MX records is to generate a source route. This is clearly unnecssary. Rick, Since we're under fire here, I want to be sure I'm clear on what you're firing at :-). Is that when MMDF relays mail it adds itself to the RFC-821 sender field (which, I believe is required per section 5.2.6 of the draft Host Requirements RFC). Or is that RELAY.CS.NET has its MMDF configured to append @relay.cs.net on mail relayed through it (which affects header rewriting). If it's the former, then I'd be happy to help change MMDF's behavior if the powers-that-be want to change the spec (although I don't think it's wise). If it's the latter, then I'm also willing to consider turning off that "feature". We were mostly waiting for the rest of the world to get their act together and understand MX records. I'd be easily convinced that that time has come but I also want to be sure we don't cut off mail to those organizations we serve through RELAY.CS.NET. We currently do the @relay.cs.net rewrite on mail being sent to most destinations. We have an exception list for folks who have told us they don't want it. One solution might be to make the default be to not do the rewrite and to have an exception list for any destinations that don't yet support MX. Suggestions? Dan  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 12:06:54 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25488; 28 Jun 89 12:01 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 28 Jun 89 11:45:05 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 28 Jun 89 13:52:45 GMT From: Karl Kleinpaste Organization: Ohio State Computer Science Subject: Re: "Status" header Message-Id: References: <1322@uceng.UC.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu That's being done by Berkeley Mail. If you have source, see ucb/Mail/send.c. Gross. Pick another MUA.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 13:11:07 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa14928; 28 Jun 89 13:07 EDT Received: by uunet.uu.net (5.61/1.14) id AA25873; Wed, 28 Jun 89 13:06:47 -0400 Date: Wed, 28 Jun 89 13:06:47 -0400 From: Rick Adams Message-Id: <8906281706.AA25873@uunet.uu.net> To: long@sh.cs.net Subject: Re: RFC-822 'phrase' question Cc: eric@icsib.berkeley.edu, header-people@mc.lcs.mit.edu, wunder@sde.hp.com Say, for example, I'm a csnet site and I send mail to user@site.oz.au csnet relay properly goes and finds the MX record that says ship it to uunet. uunet gets a RCTP TO: line that looks like: RCPT TO: <@uunet.uu.net:user@site.oz.au> I object to the gratuitious addition of the @uunet.uu.net. (I also object to its addition to the MAIL FROM line, but my argument on that is with the standard, not with your implementation). My complaints are all about the RCPT TO line and they seem to be present in lots of MMDF sites. csnet-relay is just one of the more obvious. I think about 1/3 of the sendmail.cf changes we make are to cope with "unusual" use of source routes. There was also a truly horrible problem with routing for .NZ that I can't remember the exact nature of. We were getting things like: RCPT TO: <@uunet.uu.net:@vuwcomp.ac.nz:user@someothersite.ac.nz> and that totally fried things for us. (At the time the NZ mail was sent via uucp and internet source routes do not easily map into uucp addresses!) All we really wanted (or needed) was: RCPT TO: My basic claim is that if an MX record says that some site can handle the address, let them. Dont try and help them out by adding routing information. Let them do the end routing. ---rick  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 13:23:00 EDT Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa00531; 28 Jun 89 13:16 EDT Received: by INFOODS id <00001139062@INFOODS.MIT.EDU> ; Wed, 28 Jun 89 13:09:58 EDT Date: Wed, 28 Jun 89 12:44:07 EDT From: John C Klensin Subject: re: Brad Allen's comments on Rick's comments on source routes To: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu X-VMS-Mail-To: EXOS%"<@mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu>" Message-ID: <890628124407.00001139062@INFOODS.MIT.EDU> Unfortunately, while I agree with Brad's main point, some of his examples and comments add strength to Rick's complaints. Specifically, the reason why I prefer source routes to the %-kludge when there is a choice is that the syntax and semantics of source routes--since they are part of the protocol--are, or can be made, unambiguous, while the %-kludge, by definition, is strictly a local-part, up to gateway interpretation. On the other hand, if we can't all manage to read things closely enough to take advantage of that syntax and semantics, source routes are just so much more clutter. >Network problems are many -- bad packet routing; one out of a collection >of links in the network go down, and source route will help route around >it Maybe in UUCP-land. But, in the internet, source routes do nothing for bad packet routing or dead links, except possibly make those conditions worse by trying to force routes through bad paths. For those readers not on the Internet or used to its structure, e-mail is normally transmitted over virtual circuit connections between originating and target hosts. There is no reason for intermediate target hosts, and store-and-forward activities (and packet routing) take place down in, roughly, the network layer, not in explicit "I give it to you, you give it to him, and he gives it to..." action between hosts. Source routing forces applications-level store and forward as well as particular paths, and is, conceptually, a bad idea in the Internet. >; bad UUCP Map stuff (this is not really relevant to Internet proper >but serves as a good example). Actually it is a good example of why we shouldn't pretend that UUCP nodes are part of the Internet, shouldn't assign MX addresses to them, and should force use of various types of creativity in the local-part when mailing to them from the Internet. I don't believe that either, but let's not confuse the issues. >mist.aptos.ca.us preference = 10, mail exchanger = SSYX.UCSC.EDU >Mail to user@mist.aptos.ca.us gets sent to SSYX.UCSC.EDU. Yep, that is how it is supposed to work. >When SSYX receives this piece of mail, it looks the address of this >up in the UUCP Map pathalias output, finds this line: >mist.aptos.ca.us splat!mist!%s >and sends the mail off to UUCP host splat. I hope something like that happens. However, as an Internet site, all I need or want to know is that SSYX.UCSC.EDU accepts mail for a host that I prefer to know (because it is MX-registered and, hence, a legal domain name) as "mist.aptos.ca.us". If it has other identities or routes, I really don't want to know, and, if I do want to know, the issue does not involve source routes once the crossover into UUCP is made. I think that is, more or less, the source of Rick's argument. >Well, SSYX could just as easily have used source routing, converting >mist.aptos.ca.us -> @splat.uucp:user@mist.aptos.ca.us Aha. But here, SSYX is already in the business of being an Internet->UUCP gateway, not a forwarded/router. As an Internet source route/address, @splat.uucp:user... is illegal, since "splat.uucp" is not a valid domain name. If you folks want to make something like that work intra-UUCP, that would be dandy, but (a) it shouldn't appear on the Internet and (b) it is not an argument for or against Internet source routing. >or even (preferably if the mailer could handle it) >mist.aptos.ca.us -> @splat.aptos.ca.us:user@mist.aptos.ca.us This is conceivably a valid Internet address, but then Rick would claim that you would not need it, and I might agree. > since @something1:something3@something2 is RFC822 >whereas something1!something2!something3 is not. Aha again. something!something2!something3@foo is, however, valid RFC822. You can put whatever you like into the local-part, as long as it looks like a "phrase". If something3%something2%something is valid, than the bang-path is also. The problem is that the Internet rules (including RFC822) gives @ absolute precedence, and what is on its right (a required domain name) is fundamentally different from what is on its left. >I haven't studied RFC822 that much and often wonder how it is expected >that @domain1,@domian2:mailbox@domain3 >is supposed to be distinguished from two distinct recipients >(@domain1 and @domain2:mailbox@domain3)? I can see that >looking INTO the address @domain1 reveals a missing mailbox, ... *Flame on* (abusive comments deleted). Source-route syntax REQUIRES the mail address be in pointed brackets, i.e., you can say foo@bar or Joe Smith but, for source routes, you must say Joe Smith <@somewhere:foo@bar> The "requirements for internet hosts" document proposes to make the above legal without the 'Joe Smith' part, but the brackets need to be there. Now, by examination of your question, and reverse reasoning, you know why. Please try to read and study the protocols before commenting on them or how they should be used. *flame off*  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 14:16:41 EDT Received: from SH.CS.NET by mintaka.lcs.mit.edu id aa26440; 28 Jun 89 14:09 EDT To: Rick Adams cc: eric@icsib.berkeley.edu, header-people@mc.lcs.mit.edu, wunder@sde.hp.com, techies@sh.cs.net Subject: Re: RFC-822 'phrase' question In-reply-to: Your message of Wed, 28 Jun 89 13:06:47 -0400. <8906281706.AA25873@uunet.uu.net> Date: Wed, 28 Jun 89 13:45:14 -0400 From: Daniel Long Message-ID: <8906281409.aa26440@mintaka.lcs.mit.edu> Say, for example, I'm a csnet site and I send mail to user@site.oz.au csnet relay properly goes and finds the MX record that says ship it to uunet. uunet gets a RCTP TO: line that looks like: RCPT TO: <@uunet.uu.net:user@site.oz.au> I object to the gratuitious addition of the @uunet.uu.net. Hmmm. MMDF doesn't do that as a result of MX records. For example, I just sent a message to ladc.bull.com, which I know has an MX to UUNET. This is the SMTP dialog: connecting to [192.48.96.2]... open. <-(220 uunet.uu.net Sendmail 5.61/1.14 ready at Wed, 28 Jun 89 13:20:51 -0400) ->(HELO RELAY.CS.NET) <-(250 uunet.uu.net Hello RELAY.CS.NET, pleased to meet you) ->(MAIL FROM:) <-(250 ... Sender ok) ->(RCPT TO:) <-(250 ... Recipient ok) address ok ->(DATA) <-(354 Enter mail, end with "." on a line by itself) sending...:.. ->(.) <-(250 Ok) sent ->(QUIT) <-(221 uunet.uu.net closing connection) There was also a truly horrible problem with routing for .NZ that I can't remember the exact nature of. We were getting things like: RCPT TO: <@uunet.uu.net:@vuwcomp.ac.nz:user@someothersite.ac.nz> and that totally fried things for us. (At the time the NZ mail was sent via uucp and internet source routes do not easily map into uucp addresses!) (I imagine you meant there was a comma in the source route since MMDF doesn't generate it the other way: RCPT TO: <@uunet.uu.net,@vuwcomp.ac.nz:user@someothersite.ac.nz>) MMDF can generate the kind of RCPT TO you are complaining about, however. This happens when a manual route is specified in the MMDF domain-mapping table. This might happen if, for example, relay.cs.net were the MX recipient for all of .nz but needed to forward one specific host back to UUNET. Of course, this is better handled with an MX but I do recall cases where this happened. All we really wanted (or needed) was: RCPT TO: I agree that this would be preferable. If, for some reason, an MX is not appropriate, there is a way to achieve this (by creating a separate channel for a specific destination such as uunet and listing those domains that should be manually forwarded within that channel as opposed to via the normal SMTP channel). Is it hard to strip off your own name with Sendmail? (Just curious--I'm not a Sendmail hacker.) If so, I'll ask the relay staff to use that method in the future. Currently we don't have any such manual routes in place to UUNET so if you are seeing this type of address arrive now, then something else must be wrong and I'd be happy to try to track it down. Let me know. Regards, Dan  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 16:49:37 EDT Received: from GAAK.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa14201; 28 Jun 89 16:46 EDT Received: by gaak.LCS.MIT.EDU id AA04139; Wed, 28 Jun 89 16:44:53 EDT Date: Wed, 28 Jun 89 16:44:53 EDT Message-Id: <8906282044.AA04139@gaak.LCS.MIT.EDU> To: KLENSIN@infoods.mit.edu Cc: header-people@mc.lcs.mit.edu In-Reply-To: John C Klensin's message of Wed, 28 Jun 89 12:44:07 EDT <890628124407.00001139062@INFOODS.MIT.EDU> Subject: Further use of source routing From: "Michael A. Patton" Sender: map@gaak.lcs.mit.edu >Network problems are many -- bad packet routing; one out of a collection >of links in the network go down, and source route will help route around >it Maybe in UUCP-land. But, in the internet, source routes do nothing for bad packet routing or dead links, except possibly make those conditions worse by trying to force routes through bad paths. For those readers not on the Internet or used to its structure, e-mail is normally transmitted over virtual circuit connections between originating and target hosts. There is no reason for intermediate target hosts, and store-and-forward activities (and packet routing) take place down in, roughly, the network layer, not in explicit "I give it to you, you give it to him, and he gives it to..." action between hosts. Source routing forces applications-level store and forward as well as particular paths, and is, conceptually, a bad idea in the Internet. WRONG! I frequently find as a network manager (and PostMaster) that I need to make use of source routing of mail to get around network problems in the Internet. I discover a bunch of mail backed up in the queues and upon investigation discover (or more likely deduce) that some remote site has bad routing back to net 18 (that's us John :-). Well, what should I do? Obviously, I send mail to the responsible person at that site, right? Oops, that won't work because I can't get an SMTP session open with no packets coming back. The answer is, I find a host we both CAN talk to and source route through it. The mail gets through, the other guy knows what I found from my end and away we go. If I'm really anxious, I can edit the control files for those backed up messages and source route them, too. ---------------------------------------------------------------- Now to go back and add my two cents to the original discussion. The original question was not source routing or no source routing but a question of the syntax and semantics to use for source routing. All of the methods talked about, the %-hack, foo!bar@mumble, and @mumble:bar@foo, are ALL source routing. Some kind of source routing is definitely required today, and will probably always have a use (well, maybe if absolutely nothing ever went wrong we wouldn't need it, but ... :-). The real problem today is all the different techniques and implementations which don't arrange to be interoperable. This is a hard problem to solve, you need to get everyone to agree (and when everyone means every little UNIX box, that's a hard task). My comment on the forms to use are that only one of the three forms mentioned above is truly unambiguous in ALL cases, but it's not implemented at all in exactly those places where the others break down. Bangs are really bad. The %-hack comes real close, but I have seen it break. The RFC822/823 source route is unambiguous, but unfortunately suffers from OVER-specification (e.g. all names must be registered). The problem isn't to decide on "the one true mail routing scheme", but rather to design schemes for each realm that are complete, unambiguous and allow for arbitrary external connections WITHIN the framework. Then a gateway between two such realms can uniquely and unambiguously translate addresses. Further I expect that there is developing some problem in this discussion because of people not making the distinction between addressing and routing. These really should be seperate, but most existing specs/systems don't. This happens in the real world, you use the same address (from anywhere in the world) to reach me whether you send by USPS, UPS, FedEx, or Joe's Courier Service, but these would (probably) use dramatically different routing. In fact it's conceivable that Joe would actually put the message (with others) in a package and send it via one of the other carriers to a friend in Boston who would open this up and deliver it, this is source routing done as it should be INSIDE the delivery system completely transparent to the end user. Note reletive to this discussion, in my original example I am inside the system, I'm acting as PostMaster. I think the development that can help us at this time is a "one true addressing" scheme, and I think this IS starting to develop although a little too slowly for my taste. Then let the mail systems and/or PostMasters have some kind of source routing for dealing with intractable problems. I note that this developing discussion is very similar to the discussions of naming, addressing, and routing that went on in the early days of IP concerning the lower layers. I think there is a lot to be learned from what went before (if you're interested try RFC814, IEN179, IEN156, and others). __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 16:55:00 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa23119; 28 Jun 89 16:50 EDT Received: by uunet.uu.net (5.61/1.14) id AA18176; Wed, 28 Jun 89 16:46:03 -0400 Date: Wed, 28 Jun 89 16:46:03 -0400 From: Rick Adams Message-Id: <8906282046.AA18176@uunet.uu.net> To: ARIEL@en-c06.prime.com Subject: Re: RFC-822 'phrase' question Cc: header-people@mc.lcs.mit.edu, long@sh.cs.net I always object to redundancy and unnecessary crap. Thats why I started this whole discussion about rfc822 source routing being unnecessary. When you start to pass 30,000 messages per day, the time wasted on extraneous header parsing is real. Would you object if I routed all uunet mail through your system? I can format the headers so that the addresses are legal and get delivered to the correct destination address. If your mailer can't handle it, its broken. If it can handle it, why do you care? (Oh you dont have unlimited computing resources to waste? Gee, what a cooincidence)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 19:54:44 EDT Received: from arpa.att.com by mintaka.lcs.mit.edu id aa24273; 28 Jun 89 19:47 EDT From: smb@ulysses.att.com Date: Wed, 28 Jun 89 18:29:12 EDT Message-Id: <8906282229.AA00384@hector.homer.nj.att.com> Received: by hector.homer.nj.att.com id AA00384; Wed, 28 Jun 89 18:29:13 EDT To: John C Klensin Cc: header-people@mc.lcs.mit.edu Subject: Re: Brad Allen's comments on Rick's comments on source routes Maybe in UUCP-land. But, in the internet, source routes do nothing for bad packet routing or dead links, except possibly make those conditions worse by trying to force routes through bad paths. For those readers not on the Internet or used to its structure, e-mail is normally transmitted over virtual circuit connections between originating and target hosts. There is no reason for intermediate target hosts, and store-and-forward activities (and packet routing) take place down in, roughly, the network layer, not in explicit "I give it to you, you give it to him, and he gives it to..." action between hosts. Source routing forces applications-level store and forward as well as particular paths, and is, conceptually, a bad idea in the Internet. Unfortunately, while this has been true, it is becoming less and less so. The point was made repeatedly at the INARC workshop that universal interconnectivity on the Internet no longer exists, and cannot be presumed to exist in the immediate future. What with the demise of the ARPANET, there is no central routing core. Things are usually functioning reasonably well, but not always. And when policy routing comes about, matters may get worse.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 00:59:50 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07794; 29 Jun 89 0:58 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 29 Jun 89 00:37:32 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 29 Jun 89 04:26:02 GMT From: Dan Heller Organization: University of California, Berkeley Subject: Re: "Status" header Message-Id: <15051@pasteur.Berkeley.EDU> References: <1322@uceng.UC.EDU>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In reponse to someone's question about what the Status: header is for, karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes: > That's being done by Berkeley Mail. If you have source, see > ucb/Mail/send.c. Gross. Pick another MUA. This header is modified by Mail (or sokme UA) to remember that the message has been Read, Unread-but-old, or other information about the message. Karl feels that this is "gross". I'd love to hear suggestions about how to retain the "status" of a message without losing "state" and not storing the information in the actual message. The status header is common among most Mail-based UA's (I don't know about MH). The "state" I was referring to is the state of integrity that the information about the message remains accurate even tho there may be different users/processes accessing the same file. The state isn't completely conserved, but it is much more efficient than using a separate state file. I don't know how MH manages to remember the status of messages if it doesn't store such information in the message (file) itself. I am guessing that Karl is using MH or something other than Mail, Elm or Mush. So, Karl, I ask how one would save the fact that a message has been saved, printed, forwarded, read/unread, replied-to... Mush uses the status: header to save all this information about each message. Dan Heller  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 08:03:57 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa20288; 29 Jun 89 7:59 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 29 Jun 89 07:37:54 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 29 Jun 89 05:19:23 GMT From: Bill Wisner Organization: Verrifast Plaine Co Ltd Subject: Re: "Status" header Message-Id: References: <1322@uceng.UC.EDU>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu MH can be instructed to keep track of messages that have not been seen by putting them into an "unseen" sequence. It never touches the actual messages to do this. MH can also be instructed to keep track of when a message is replied, forwarded, or whatever. It does not use the utterly bogus and highly ugly Status: header. It inserts two header lines at the very top of the message (thus making them very easy to edit out) along the lines of: Replied: Tue, 27 Jun 89 12:59:17 PDT Replied: Martin Hanley (Look, Martin! Your name in lights!) Note that MH does none of these things unless explicitly told to. w  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 10:45:10 EDT Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa11648; 29 Jun 89 10:42 EDT Received: by INFOODS id <00001022064@INFOODS.MIT.EDU> ; Thu, 29 Jun 89 10:34:40 EDT Date: Thu, 29 Jun 89 10:24:45 EDT From: John C Klensin Subject: RE: Re: "Status" header To: Dan Heller X-VMS-Mail-To: EXOS%"Dan Heller " Message-ID: <890629102445.00001022064@INFOODS.MIT.EDU> cc: header-people <@mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu> Dan, I'm not sure you really want the answer, but... You organize your mail system so that you store envelope information and message information separately. You might even separate message header information from message information with appropriate data structuring. You might consider status-of-reading information to be part of the (stored, and highly canonicalized) envelope information. And you might canonicalize the required/important header fields, too. Once you get the envelope and selected header fields stored into a canonical form (read "a 'binary' data-structure" if you like), then you can put status flags, or whatever, anywhere there and, in no case, does it become part of the message. Now, how this is displayed to the user is a slightly different issue: the most convenient approach might be to have it appear as if it were a header field (although some BITNET systems show envelope information as a *footer* field). Logically separating envelope, header, and message provides an additional useful capability, which is that, on a system with any sort of security or access-restriction provisions, you can arrange different levels thereof and, in particular, give a "postmaster" sufficient access to alter envelopes and return or reroute mail, without giving him or her sufficient access to read message text, even by accident. That is a nice feature, if you think about it. New idea? Nope, something that Multics has done for years. And not something that I had anything to do with inventing, although I wish I had. John Klensin, MIT Klensin@INFOODS.MIT.EDU  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 23:34:55 EDT Received: from cory.Berkeley.EDU by mintaka.lcs.mit.edu id aa26233; 29 Jun 89 23:32 EDT Received: by cory.Berkeley.EDU (5.59/1.28) id AA19957; Thu, 29 Jun 89 20:31:17 PDT Message-Id: <8906300331.AA19957@cory.Berkeley.EDU> From: Dan Heller Date: Thu, 29 Jun 89 20:31:14 PDT In-Reply-To: John C Klensin's 48-line message on Jun 29, 10:24am Phones: Home: (415) 479-4838 Work: 491-1000 X-Mailer: Mail User's Shell (6.5.4 6/12/89) To: John C Klensin Subject: RE: Re: "Status" header Cc: header-people , Bart Schaefer I'm including Bart on the Cc list so I'm going to include your whole message.. > On Jun 29, 10:24am, John C Klensin said this about: > "RE: Re: "Status" header" > > Dan, > I'm not sure you really want the answer, but... > > You organize your mail system so that you store envelope information > and message information separately. You might even separate message > header information from message information with appropriate data > structuring. You might consider status-of-reading information to be > part of the (stored, and highly canonicalized) envelope information. > And you might canonicalize the required/important header fields, too. > Once you get the envelope and selected header fields stored into a > canonical form (read "a 'binary' data-structure" if you like), then you > can put status flags, or whatever, anywhere there and, in no case, does > it become part of the message. > Now, how this is displayed to the user is a slightly different issue: > the most convenient approach might be to have it appear as if it were a > header field (although some BITNET systems show envelope information as > a *footer* field). > Logically separating envelope, header, and message provides an > additional useful capability, which is that, on a system with any sort > of security or access-restriction provisions, you can arrange different > levels thereof and, in particular, give a "postmaster" sufficient access > to alter envelopes and return or reroute mail, without giving him or her > sufficient access to read message text, even by accident. That is a > nice feature, if you think about it. > > New idea? Nope, something that Multics has done for years. And not > something that I had anything to do with inventing, although I wish I > had. > John Klensin, MIT > Klensin@INFOODS.MIT.EDU Basically, I disagree with this method for several reasons -- In no particular order... Portability. "Binary" format is really a bad idea because different computers store binary data differently. In a heterogeneous environment where several architectures share the same "data" filesystems (such as /usr/spool/mail or home directories, for example) then any data stored in a binary format will be sure to fail if the same program compiled for a different architecture were to read/write it. I first encountered this problem at Island (where I work) where we used to store desk top publishing data files in pseudo-binary format. Once you split the message headers from the text of the message, you have completely eliminated any chance for the message to be either read or "maintained" by any other program. One thing people like to do is have the option to use different programs for their data. I like the fact that I can use "vi" on files and my co-workers can use "emacs" to edit the same files. Since the office place today uses email as its primary source of communication between workers (the larger the company, the more apparent this is), having common places where mail messages are stored and read by many users is a luxury people have come to appreciate. Having a mail UA do with messages as you described means that users now only have one program they can use to read their mail. If I want to move my mail around, I have to be sure to bring the whole thing with me wherever I go -- moving folders becomes a royal pain. The reason that this method works for mail *delivery* schemes (such as uucp, sendmail, etc..) is because thiere *is* one program and one program only on the system to handle this level of message storage. It need not be interactive with the user and it doesn't worry about interferring with anyone else. In this case, your "postmaster" can still handle everything correctly. --dan  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 10:58:14 EDT Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa02536; 30 Jun 89 10:52 EDT Received: by INFOODS id <00001271062@INFOODS.MIT.EDU> ; Fri, 30 Jun 89 10:47:06 EDT Date: Fri, 30 Jun 89 09:34:57 EDT From: John C Klensin Subject: Re: Dan Heller's long reply to my longer message about Status fields To: Header People List <@mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu> X-VMS-Mail-To: EXOS%"Header People List <@mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu>" Message-ID: <890630093457.00001271062@INFOODS.MIT.EDU> Dan, I agree with your initial assumptions about what is desirable, but disagree profoundly with the reasoning, final conclusion, and some of the associated inferences. Because it may be of general interest (although I doubt it), let me identify where I think we disagree and why. Then, since this discussion is not really about headers, and because I don't have time, let's drop it or take it offline. 1) The Multics environment, for better or worse, was motivated in part by some real security/privacy concerns, and keeping users (even "postmaster" users and "super" users) out of each other's mail is considered desirable (to say the least). One can disagree or agree with that philosophy, but agreeing makes putting up with some slight inconvenience desirable. This is not, to any degree the only argument here, just something that colors the others a bit. >Portability. "Binary" format is really a bad idea because different >computers store binary data differently. In a heterogeneous environment >where several architectures share the same "data" filesystems (such as >/usr/spool/mail or home directories, for example) then any data stored >in a binary format will be sure to fail if the same program compiled for >a different architecture were to read/write it. I first encountered >this problem at Island (where I work) where we used to store desk top >publishing data files in pseudo-binary format. Either I was not sufficiently clear about the requirement/strategy (which is probably) or your argument is a red herring (which is also possible). The reason why I put "binary" in quotes was to avoid the problems you identify here. What I might, equivalently, have said was "carefully structured format". If that format needs to be machine-independent, there is no problem with that. It probably does not, for the reasons discussed below. And there is no problem with *code* portability, again for the reasons discussed below. >Once you split the message headers from the text of the message, you >have completely eliminated any chance for the message to be either >read or "maintained" by any other program. One thing people like to >do is have the option to use different programs for their data. I like >the fact that I can use "vi" on files and my co-workers can use "emacs" >to edit the same files. On the other hand, data-[structure-]hiding and a certain amount of functional isolation are fundamental principles in software engineering today, and for good reasons. There is a wrong way to do this, and that wrong way is what you, apparently, assume. For example, in VMS, the internal formats of mail are "proprietary", and may change from one operating system release to the next. People who wish to manipulate mail with private tools have to decode the format, and then be prepared to decode again with each system change. There are many terms to describe that strategy, let me try "plain dumb" for public circulation. But let's assume that you equip the mail system, as Multics has, not only with an internal mechanism for storing mail-objects, but with a full set of proper subroutines and functions for accessing and manipulating those objects. And let's further assume that you guarantee those interfaces across not only operating system releases, but across different mail processing mechanisms. If your abstractions are right, you can switch from RFC733 to RFC821, or from SMTP to X.400 without any change to user-level mail processing programs: the user code continues to "see" the same abstractions. >Having a mail UA do with messages as you described means that users now >only have one program they can use to read their mail. Just not true. Mail-reading programs only have to use the proper system primitives for accessing messages and queues. And message-accessing gets you back one or more structured objects. We had several mail-reading programs on Multics, only one or two of which were system supplied, and they couldn't do anything the others couldn't do, since they were constrained to use the same mechanisms. Note that, on Multics, the fact that mail objects are inner-ring objects makes the object-hiding mechanisms and functions non-bypassable. By anything. > If I want to move my mail around, I have to be sure to bring the whole >thing with me wherever I go -- moving folders becomes a royal pain. Nope. If this is a socially desirable activity, then the right primitives can be defined. Since I don't know what would be meant by "move my mail around" or "move folders" in a protected mail environment abstracted from U**X, I can't comment on its social desirability. But having a user-level program to which you can say "take everything of the following description and forward it over there" is very easy. Multics has the facility built into one of the system-provided user-level mail reading commands. >The reason that this method works for mail *delivery* schemes (such as >uucp, sendmail, etc..) is because thiere *is* one program and one program >only on the system to handle this level of message storage. It need not >be interactive with the user and it doesn't worry about interferring with >anyone else. Yeah. And in the Multics model, the "user" can't mess with the programs or their mechanisms, and the postmaster can be somewhat constrained if that is desirable. For emergencies, adequate access to fuss with the queues and objects themselves can be available, but that is not needed for "ordinary" postmaster functions, e.g., mail re-routing and address correction, and, possibly, should not be available. > In this case, your "postmaster" can still handle everything >correctly. Ah, but, if a postmaster is accused of tampering with the content of someone else's mail, she or he has no systems defense. In the Multics model, the postmaster *cannot* access the mail text. The object-hiding of the Multics model also permits some other functions in the validation and authentication area that are important or useful in some contexts. For example, if I get a message from Doe and forward it to Jones, Jones would really like to know that what I've claimed Doe said is what Doe said. In the postal mail system, I do this best by putting Doe's original message, complete with unopened envelope, in another envelope, possibly with my cover note and sending it on. The second-best involves forwarding Doe's orginal letter, in his handwriting, with my cover note in the same envelope. Ever wonder, when something says "original message follows", or ">", if that is *really* the original text? Well, with the Multics UA (which is not the user-level mail reading/writing program but down with the data-hiding primitives) when I instruct the system to "forward" a message, I don't have access to modify its text, and the system guarantees authenticity. If I want to annotate a message, as I am doing with yours, I make a system call that transfers a canonicalized copy of it to me in an ASCII form that resembles what you think of as RFC822, I edit it to my heart's content with the editor of my choice, and I then tell the system where to send it as a *new* or *altered* message. But then it is isn't authenticated forwarding any more. The system can also provide you the ability to delete a message you have sent to me, but without letting you look at messages others have sent. Or can enforce a "delete only if not inspected" rule. In both cases, these functions are accessed by calls to the object primitives from applications code. And, because it can keep records of what calls were made, the system can *know*, not rely on applications to tell the truth. Summary: The following are GOOD THINGS - being able to formulate and manipulate mail using tools of the user's choice, with a variety of such tools coexisting. - providing a high degree of data structure isolation and hiding for data in the formats received over the various networks so that the user abstraction of what mail looks like is independent of the formats and protocol requirements of multiple networks. Such hiding can also provide different mail abstractions to different users and programs: as things evolve, newer programs can use newer interfaces that deliver more or different information; older programs can continue to use older interfaces which, while less informative, keep those programs working. - system management of mail-objects, accessed through data-hiding functions, permits system responsibility for authentication and the maintenance of flags in an fashion independent of end-user application software. This means, among other things, that if you can convince the system that status flags should be part of the mail-object, then all user-level software can manipulate those flags without knowledge of each other. On the other hand, if you cannot, or, more generally, want to maintain a different mail-management abstraction, *your* software can maintain its own tables that map your abstraction into system mail identifiers. This approach has two known major drawbacks: (1) Someone has to make a serious investment in the design of the abstractions that user codes will see and the functions used to access them. Design of the [hidden] mail objects themselves is less important, since they can be changed without user-level code noticing. See any OOP paper for a more elaborate form of this principle. But the investment is serious, taking implementation of a mail system out of the scale of an afternoon exercise. I've seen some "afternoon exercises", and prefer the serious design efforts (e.g., sendmail, etc.), but I suppose this is a matter of taste. (2) Because the management of real (e.g., RFC822) headers, as distinct from their abstractions, is part of the mail-object, a high degree of header integrity and validation can be guaranteed. User-supplied codes cannot include "Longitude" or "Grandfathers-birth-date" headers in messages because there is no way to pass that information through the abstractions into the mail objects. Seems to me that this is an asset, but I'm a known fuddy-duddy who hates seeing messages cluttered with non-standard, cutsy, header fields. john  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 17:32:29 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07093; 30 Jun 89 17:29 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 30 Jun 89 17:19:04 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 30 Jun 89 18:07:08 GMT From: "gregg.g.wonderly" Organization: AT&T Bell Laboratories Subject: MH verses the "all in one file" MUAs Message-Id: <1508@cbnewsc.ATT.COM> References: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu From article , by wisner@mica.Berkeley.EDU (Bill Wisner): > MH can be instructed to keep track of messages that have not been seen by > putting them into an "unseen" sequence. It never touches the actual messages > to do this. > > ... > > Note that MH does none of these things unless explicitly told to. And most of us use the appropriate MHL formats and filters to have them stripped later. Note that MHs repl(1) command (for replying to a message) will allow you to reply multiple times. The Replied headers are stripped from the resulting message by the time you see it in the editor to add your reply. Just a note... It has been said many times before... Those who ignore the past are doomed to repeat it in the future. In other words, those people who continue to implement MUAs that use a single file for storing all messages seem to continue to replicate all the things that we hate about those programs. MH is so elegant and flexible. It pains me to see all the work people are doing just to duplicate what has already been done. ----- gregg.g.wonderly@att.com (AT&T bell laboratories) -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 20:30:29 EDT Received: from hanna.cac.washington.edu by mintaka.lcs.mit.edu id aa05830; 30 Jun 89 20:28 EDT Received: from tomobiki-cho.cac.washington.edu by hanna.cac.washington.edu (5.61/UW-NDC Revision: 1.108 ) id AA15121; Fri, 30 Jun 89 17:27:55 -0700 Date: Fri, 30 Jun 1989 16:50:19 PDT From: Mark Crispin Sender: mrc@tomobiki-cho.cac.washington.edu Subject: Re: "Status" header Cc: header-people@mc.lcs.mit.edu In-Reply-To: <15051@pasteur.Berkeley.EDU> Message-Id: The grossness is in the entire format of /usr/spool/mail. Not all Unix- based mail readers use /usr/spool/mail format. MM and the IMAP server use "mtxt" format, basically a clone of the TOPS-20 MAIL.TXT format. mtxt format has an exact byte count of the message (no need to insert ">" in front of lines that accidentally being with the word "from"), a message write date, and a field of flags (36 in all - surprise!). There are other schemes as well. It just requires breaking away from a format of mail that should have been considered obsolete 10 years ago. mtxt format is certainly not the most wonderful ever invented, but it is much better than /usr/spool/mail format. -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jul 89 05:35:14 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02921; 1 Jul 89 5:30 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 1 Jul 89 05:26:52 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Jul 89 03:38:39 GMT From: Dan Heller Subject: Re: MH verses the "all in one file" MUAs Message-Id: <113463@sun.Eng.Sun.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I meant to proofread this, but apparently, I missed something... > If you think that > MH's "features" are a result of the fact that it's folder storage method > is attributed to the fact that it stored messages on a file-per-message > format, you are mistaken. I meant to say : If you think that MH's great features is attributable to its method for folder storage, you are mistaken. My intent was to point out the fact that a good UA should do the "right thing" regardless of how that UA stores its messages. Two "correct" UAs --each which stores files using the Mail and the MH method-- should do the same thing when it comes to replies, etc... dan  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jul 89 05:35:23 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02932; 1 Jul 89 5:30 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 1 Jul 89 05:25:40 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Jul 89 03:31:33 GMT From: Dan Heller Subject: Re: MH verses the "all in one file" MUAs Message-Id: <113461@sun.Eng.Sun.COM> References: , <1508@cbnewsc.ATT.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > From article by wisner@mica.Berkeley.EDU (Bill Wisner): > > MH can be instructed to keep track of messages that have not been seen by > > putting them into an "unseen" sequence. It never touches the actual messages > > to do this. > > Note that MH does none of these things unless explicitly told to. > > And most of us use the appropriate MHL formats and filters to have them > stripped later. Note that MHs repl(1) command (for replying to a message) > will allow you to reply multiple times. The Replied headers are stripped > from the resulting message by the time you see it in the editor to add > your reply. No one said MH was stupid. There -are- other stupid UA's out there that don't do the right thing (what you described is the right thing). But, that has nothing to do at all with how a mail folder is stored. It is incorrect to make the following statement: > people who continue to implement MUAs that use a single file for > storing all messages seem to continue to replicate all the things that > we hate about those programs. The reason this is incorrect is because your assumption is that it is the single-file-folder "feature" that makes the program "bad." A well written/designed UA should [try to] make it as transparent as possible about the method for how mail is stored. You are making a grave mistake by attributing the storage method utilized by a UA to the bugs or implementation (design) features of that UA. If you think that MH's "features" are a result of the fact that it's folder storage method is attributed to the fact that it stored messages on a file-per-message format, you are mistaken. Believe it or not, I don't advocate using the folder-in-a-file method any more than MH's method; there are good reasons for doing it both ways. I hesitate to start yet another religious war about whether or not the Mail-method or the MH-method is better, but I almost feel compelled to do so anyway because of the misconceptions about UA's as described in the previous text above. If the time has come yet again to resurrect the war on MH vs. Mail folder formats, let's have it. I'm prepared. I'm always looking for good suggestions for improving mush (oh, if I only had the time), and in fact Bart and I have a long list of things to do for the future if the future ever arrives. We're all working together on this; I don't feel as if I'm competing with MH. > gregg.g.wonderly@att.com (AT&T bell laboratories) dan  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jul 89 21:52:14 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa09775; 1 Jul 89 21:51 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8635; Sat, 01 Jul 89 21:50:48 EDT Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 9753; Sat, 01 Jul 89 21:50:47 EDT Date: Sat, 01 Jul 89 18:48 PDT To: header-people From: Leonard D Woren Subject: Re: "Status" header Message-ID: <8907012151.aa09775@mintaka.lcs.mit.edu> There isn't really anything wrong with a UA adding its own header lines to save info. What *is* wrong is that UA not removing those added lines when forwarding mail. Of course, one obvious problem is what happens when it's forwarded with a different UA that doesn't know about those headers? Then the USER should edit the message and delete the garbage. Not doing so is tacky. Why is this the user's responsibility in this case? Well, he's the one using 2 different, incompatible UAs. Lessee now... Header-People discusses headers. Ok, anyone want to propose adding a new field to the standard, to allow UAs to store info there? The definition should include a rule that a UA make that line disappear when the message is forwarded, etc. Can there be a generic header line defined? X-UA-uaxxx: info for ua xxx X-UA-uayyy: info for ua yyy Of course, realistically, we all know by now that it's essentially impossible to get new headers defined and even harder to get them widely implemented. Another sigh. /Leonard  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jul 89 23:34:02 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10447; 1 Jul 89 23:29 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 1 Jul 89 23:18:16 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Jul 89 03:13:25 GMT From: Christopher Davis Organization: Boston University School of Management Subject: Re: What *should* an MUA do? (was MH verses the "all in one file" MUAs) Message-Id: <2730@bucsb.UUCP> References: <113463@sun.Eng.Sun.COM>, <2729@bucsb.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu OOOOOOOOOOOoooooooooooops! I mucked up the followup-to line in that last. Followups should go to comp.mail.misc (or to me if you think it's not something worthy/appropriate for comp.mail.misc). --ckd -- /\ | / |\ @bu-pub.bu.edu | Christopher K. Davis, BU SMG '90 / |/ | \ %bu-pub.bu.edu@bu-it.bu.edu | uses standardDisclaimer; \ |\ | / | BITNET: smghy6c@buacca \/ | \ |/ @bucsb.UUCP or ...!bu-cs!bucsb!ckd if you gotta. --"Ignore the man behind the curtain and the address in the header." --ckd--  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jul 89 23:34:10 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10449; 1 Jul 89 23:29 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 1 Jul 89 23:13:28 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Jul 89 03:10:58 GMT From: Christopher Davis Organization: Boston University School of Management Subject: What *should* an MUA do? (was MH verses the "all in one file" MUAs) Message-Id: <2729@bucsb.UUCP> References: <113463@sun.Eng.Sun.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <113463@sun.Eng.Sun.COM> argv%eureka@Sun.COM (Dan Heller) writes: - [...] My intent was to point out the - fact that a good UA should do the "right thing" regardless of how that - UA stores its messages. Two "correct" UAs --each which stores files - using the Mail and the MH method-- should do the same thing when it - comes to replies, etc... I'm going to go *way* off on a tangent here... I'm working on (well, writing specs for, at the moment) an MUA for our Incredibly Big Machine. I'm interested in finding out what people feel the "right thing" is for replies (as here) or other aspects of an MUA. Limitations of the thing: it will be written in REXX and use XEDIT. It's *not* a CMS site, so I don't know at present what limitations that interface will have (if they're really bad the whole project will just go down the tubes). The programming team is completely unofficial and is a management undergrad in Boston and an engineering student in NJ. [If any of you think we can even get this thing DONE based on all that, let us know what you think... :-] Pie in the sky "this is what I'd really like if you could ever do it" comments will be always accepted, occasionally implemented, definitely appreciated. Ye Olde Hacker Spirit and all that. Followups to comp.mail.misc which I think is the best place to go... Oh, and no flames, please? I want suggestions, not "my MUA is better than yours, my way is better than yours, etc." "My MUA does this and I like it" is more the sort of thing I'm looking for. --ckd -- /\ | / |\ @bu-pub.bu.edu | Christopher K. Davis, BU SMG '90 / |/ | \ %bu-pub.bu.edu@bu-it.bu.edu | uses standardDisclaimer; \ |\ | / | BITNET: smghy6c@buacca \/ | \ |/ @bucsb.UUCP or ...!bu-cs!bucsb!ckd if you gotta. --"Ignore the man behind the curtain and the address in the header." --ckd--  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Jul 89 21:03:32 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19535; 2 Jul 89 20:59 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 2 Jul 89 20:46:02 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Jul 89 22:41:19 GMT From: "gregg.g.wonderly" Organization: AT&T Bell Laboratories Subject: Re: MH verses the "all in one file" MUAs Message-Id: <1518@cbnewsc.ATT.COM> References: <113461@sun.Eng.Sun.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu From article <113461@sun.Eng.Sun.COM>, by argv%eureka@Sun.COM (Dan Heller): > In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: >> >> And most of us use the appropriate MHL formats and filters to have them >> stripped later. Note that MHs repl(1) command (for replying to a message) >> will allow you to reply multiple times. The Replied headers are stripped >> from the resulting message by the time you see it in the editor to add >> your reply. > > No one said MH was stupid. There -are- other stupid UA's out there that > don't do the right thing (what you described is the right thing). But, > that has nothing to do at all with how a mail folder is stored. It is > incorrect to make the following statement: > >> people who continue to implement MUAs that use a single file for >> storing all messages seem to continue to replicate all the things that note that I said SEEM...^^^^ >> we hate about those programs. > > The reason this is incorrect is because your assumption is that it is > the single-file-folder "feature" that makes the program "bad." > A well written/designed UA should [try to] make it as transparent as > possible about the method for how mail is stored. You are making a > grave mistake by attributing the storage method utilized by a UA to the > bugs or implementation (design) features of that UA. If you think that > MH's "features" are a result of the fact that it's folder storage method > is attributed to the fact that it stored messages on a file-per-message > format, you are mistaken. I did not say anything about the merits of either method. What I said was that I have yet to see a "all messages in the same file" UA that does anything but what the others from the past do. People are spending a lot of time reproducing PD replacements for MUAs that don't do anything really that different and useful. > Believe it or not, I don't advocate using the folder-in-a-file method > any more than MH's method; there are good reasons for doing it both ways. > I hesitate to start yet another religious war about whether or not the > Mail-method or the MH-method is better, but I almost feel compelled to > do so anyway because of the misconceptions about UA's as described in > the previous text above. If the time has come yet again to resurrect > the war on MH vs. Mail folder formats, let's have it. I'm prepared. > I'm always looking for good suggestions for improving mush (oh, if I > only had the time), and in fact Bart and I have a long list of things > to do for the future if the future ever arrives. We're all working > together on this; I don't feel as if I'm competing with MH. Okay, here's some questions to think about. What does mush/elm/mail/whatever not do that MH already does? How much effort will it take to add those features (if they are desireable)? By the time you have done that, what will have been added to MH that the other MUAs then won't have? I don't mean to start any wars on MUAs. I am just trying to see if the individuals doing the work are thinking about were they are going. It is a real waste of talent to continually play catchup, always adding the feature that you don't have yet. I had a personal reply from my original article that stated this >And MH is huge, and chews up disk space and inodes, and hard to learn, and >slow to use. There are several parts to this statement that should be thought about. MH is VERY large in source and executables. Mostly because it has a lot of duplicated code to provide the shell parameter parsing for each command, plus the copy of the libraries that rides with each executable (50 some odd executables exist). That, I cannot dispute. However, I take up the argument that this is not a problem, but rather a feature. If you have ever written an MH tool (I have written 4 to date), then you know how powerful and easy to use the library routines are. The INODE issue is a UN*X deficency, not am MH issue. Hard to learn is a perception, not a fact. Most people that I have introduced a tool to tell me it is easy when they have some experience with something similiar. MH is not like any other MUA that I am familiar with (I have exclusivly used MH for 5 years, so that leaves me mostly biased, although I have had the necessity to use others from time to time). However, much of MH's perceived difficulty is do to lack of coherent documentation. There are not any manual pages which provide a nice tutorial on where to start with MH, so the user is stuck with the command manual pages. Putting this aside, if you can type the strings inc scan unseen (or scan unread) show rmm refile you can use MH without any real difficulty. Now for the 'slow to use' part. The fact of the matter is that most people using MH at universities are not going to have high speed CPUs. MH's executables average about 200-300K here, and I imagine they are similar in size elsewhere. This being the case, MH can be slow on a machine with limited resources. But so is every other largish program I have seen. Very few features of a program come free. There are design issues that can govern the relative order of complexity of an operation based on the underlying algorithym. I don't think that MH is perfect, there are a lont of linear algorithyms in it. The point is that certain things cost compute time. Some features of programs can be added in such a way that they always impact the application, even when the feature is not being used. The converse is also true (MH has such features like the 'previous' profile component). Give MH a try. If you hate it, throw it away (or even burn the tape in effigy). But at least try it. MUAs are really a religous issue, so I will not press any harder. I just needed to make some arguments against some of the bad things that people are saying about MH. ----- gregg.g.wonderly@att.com (AT&T bell laboratories) -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 03:18:56 EDT Received: from cs.ucl.ac.uk by mintaka.lcs.mit.edu id aa22346; 3 Jul 89 3:16 EDT To: Daniel Long cc: Rick Adams , eric@icsib.berkeley.edu, header-people@mc.lcs.mit.edu, wunder@sde.hp.com, techies@sh.cs.net Subject: Re: RFC-822 'phrase' question Phone: +44-1-380-7294 In-reply-to: Your message of Wed, 28 Jun 89 13:45:14 -0400. <8906281409.aa26440@mintaka.lcs.mit.edu> Date: Mon, 03 Jul 89 08:10:58 +0100 Message-ID: <653.615453058@UK.AC.UCL.CS> From: Steve Kille Source-Info: lion.cs.ucl.ac.uk Rick et al, > RCPT TO: <@uunet.uu.net:user@site.oz.au> > I object to the gratuitious addition of the @uunet.uu.net. Nonsense. This is doing exactly what SMTP recommends. (P 14. RFC 821, "...the first host in the forward-path should be the host receiving the SMTP commands"). I would also argue that this is good protocol design - verification of who you are talking to explictly. Steve ------- End of Forwarded Message  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 04:32:28 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa23071; 3 Jul 89 4:29 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Jul 89 04:07:07 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Jul 89 04:27:48 GMT From: Dan Heller Subject: Re: MH verses the "all in one file" MUAs Message-Id: <113567@sun.Eng.Sun.COM> References: <113461@sun.Eng.Sun.COM>, <1518@cbnewsc.ATT.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am moving this discussion to comp.mail.misc because it doesn't have anything to do with headers anymore. The reason this all started was that someone took notice of the Status: header present in Mail-based MUA's. Mail, Elm (I guess), Mush, mailx, ... all do this: use the Status: header to save information about whether the message is new, unread.. Mush also uses the status header to store info about whether the message has been saved, replied to, and so on. Greg points out that MH saves this info as well, but not in a header which is visible to the user -- MH apparently filters this information out when the message is displayed. The first part of this message contains the preliminary discussion between us. The latter part of the message actually discusses the drawbacks of MH and a few comments about Mush. People who are interested in continuing a discussion about good MUA development as well as hardline MH users are encouraged to read this message and participate in the discussion. Sorry if the preliminary dialog is hard to follow -- I edited it to make it clear about the direction the discussion is going. In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > From article <113461@sun.Eng.Sun.COM>, by argv%eureka@Sun.COM (Dan Heller): > > In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > >> And most of us use the appropriate MHL formats and filters to have them > >> stripped later. Note that MHs repl(1) command (for replying to a message) > >> will allow you to reply multiple times. The Replied headers are stripped > >> from the resulting message by the time you see it in the editor to add > >> your reply. > > > > There -are- other stupid UA's out there that > > don't do the right thing [referencing how mail is replied to]. But, > > that has nothing to do at all with how a mail folder is stored. It is > > incorrect to make the following statement: > > > >> people who continue to implement MUAs that use a single file for > >> storing all messages seem to continue to replicate all the things that > > note that I said SEEM...^^^^ Yes, you said "seem", but the implication is clear :-). Nevertheless, I'm willing to let it go. > > The reason [your statement] is incorrect is because your assumption is that it is > > the single-file-folder "feature" that makes the program "bad." > > A well written/designed UA should [try to] make it as transparent as > > possible about the method for how mail is stored. You are making a > > grave mistake by attributing the storage method utilized by a UA to the > > bugs or implementation (design) features of that UA. If you think that > > MH's "features" are a result of the fact that it's folder storage method > > is attributed to the fact that it stored messages on a file-per-message > > format, you are mistaken. > > I did not say anything about the merits of either method. What I said > was that I have yet to see a "all messages in the same file" UA that > does anything but what the others from the past do. People are > spending a lot of time reproducing PD replacements for MUAs that don't > do anything really that different and useful. You later admit that you haven't used anything else but MH for the past 5 years, so this statement doesn't carry much weight. Nevertheless, your observation is somewhat accurate: Most UAs developed today are limited in either functionality (feature-list) or tend to be ill-designed and are desitined to make the same mistakes as those that preceded them. With these problems in mind, I designed Mush for the purpose of avoiding these problems while taking advantage of other issues (described later). > Okay, here's some questions to think about. What does > mush/elm/mail/whatever not do that MH already does? How much effort will > it take to add those features (if they are desireable)? By the time > you have done that, what will have been added to MH that the other MUAs > then won't have? I don't want to discuss the entire feature list of Mush; the man page is 50 pages long. But, Mush does provide similar features like "pick" and other functions that MH provides. It does provide "piping" of commands, sorting of messages, etc.. The point is that these features can be provided regardless of the storage method of folders. The fact that many of the features of MH happen to be replicated (there are some very good ones), is a side effect of good design. However, MH has some poor design schemes that warrant the writing of a new MUA. So, I'm not reinventing the wheel with writing Mush, but instead I hope to provide a "new and improved" model. > I don't mean to start any wars on MUAs. I am just trying to see if the > individuals doing the work are thinking about were they are going. It > is a real waste of talent to continually play catchup, always adding the > feature that you don't have yet. Believe me, we are aware of what we're doing and are continuing in a well defined direction. There are definite problems with using a Mail-method folder format, but there are an equal number of problems with using the MH-method. One of the major advantages to using the Mail-based folder storage method is that it is backwards compatible with [most] other Mail applications (I address this issue again later). > I had a personal reply from my original article that stated this > >And MH is huge, and chews up disk space and inodes, and hard to learn, and > >slow to use. There are many things wrong with MH in this respect. Not only is it huge, but it *really is* hard to learn. I remember when I first went to SRI, I was set up with MH by default. I spent hours reading all sorts of doc and experimenting with commands and so on... I was really put off by the fact that all my mail was moved and split up. I struggled with it for a while, but was further put off by the fact that it was so slow. But what really took the cake for me was the fact that if your mail is configured for MH, there's no other UA you can use-- you are stuck with MH. What if I told you I had an editor I'd like you to try but told you that if you used this editor, you can't use any other editor on files you edit using that editor. This is how I see MH's folder format. What saves MH is the fact that there is no "standard" (even proposed standards or RFCs) which discuss folder formats or anything similar. Upon further investigation, I learned that MH wasn't portable to any other unix besides BSD systems. This may have changed lately -- I don't keep up with MH that much (my loss, I guess). Is it true that MH still only talks to sendmail as its sole MTA? > That, I cannot dispute. However, I take up the argument > that this is not a problem, but rather a feature. If you have ever written > an MH tool (I have written 4 to date), then you know how powerful and easy > to use the library routines are. Bad excuse. A good application (regardless of functionality; here we happen to be talking about MUAs) should have a "core" layer which makes the program function _independently_ of its user interface. MH solved the problem by making each MH function a separate shell command. Oy vey... You have to start a new process (fork!?), set up pipes, parse command line options, read init files (dot-files) and everything *for each MH command*. MH isn't a "library" as you described, but rather a set of commands. You build a "tool" in front of MH by doing a bunch of popen() calls, or system() calls, or whatever... Don't you think that's rather inefficient/expensive? Mush hasn't quite been set up to be totally independent of its user inter- face, but it is so close that it took me effectively two weeks to build the curses interface on it. It also has a suntools interface and a tty (csh-like) shell interface. Building a new front end of Mush is in fact very easy -- it'll even be easier once the implementation of its final design has been completed. The point is, Mush is a library of function calls, not a set of unix commands. > Putting this > aside, if you can type the strings > > inc > scan unseen (or scan unread) > show > rmm > refile > > you can use MH without any real difficulty. In mush, if you can type "help", you've got it just about licked.. Of course, if you know how to hit "?" that works, too. As simple as you seem to think it is to type "inc", etc..., I never knew to do that when I first learned MH. Despite the doc! > Now for the 'slow to use' part. The fact of the matter is that most people > using MH at universities are not going to have high speed CPUs. MH's > executables average about 200-300K here, and I imagine they are similar > in size elsewhere. This being the case, MH can be slow on a machine with > limited resources. But so is every other largish program I have seen. Mush averages about 100K and provides many features that MH has "as it turns out." That is, I didn't design mush to be MH compatible, it just so happened that some commands and features are very similar. With suntools, the binary is bigger -- about 1 MEG or so depending on the version of sunview or sunwindows you compile with. Without the curses interface, it's smaller. Mush runs on a 80286 running xenix or a ATT PC and more -- can MH? Mush outperforms MH dramatically on large files. For example, finding all messages from a particular author, that has a particular subject, that was sent (or delivered) between two dates from a folder with 500 messages takes about 6-10 seconds. Or, deleting all messages that have been saved takes about 1 second. > Give MH a try. If you hate it, throw it away (or even burn the tape in I'd love to look at it again... But where does one get it? Don't tell me I have to buy it :-). Actually, there's nothing wrong with selling MH (or software, for that matter -- sorry, rms :-), it just means that I won't buy it due to my limited personal financial resources. > But at least try it. MUAs are really a religous issue, so I will > not press any harder. I just needed to make some arguments against some > of the bad things that people are saying about MH. As I said, there are good things about MH (altho I didn't get into them here, just note that I recognize them), but I feel that all the good things about MH can be dupicated more efficiently in a different way. Future plans for Mush include supporting MH style folders, news, several inter- face enhancments (more csh-like features) and performance modifications. As you said, MUAs are as religious as using different editors -- you're never going to convince an emacs user to use vi, and chances are unlikely that you're going to convert an MH user to use Mush (altho there are some cases where this has happened :-). > gregg.g.wonderly@att.com (AT&T bell laboratories) dan ----- My postings reflect my opinion only -- When on the net, I speak for no company.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 09:50:56 EDT Received: from rice.edu by mintaka.lcs.mit.edu id aa25307; 3 Jul 89 9:48 EDT Received: from icsa.rice.edu by rice.edu (AA19891); Mon, 3 Jul 89 08:48:09 CDT Message-Id: <8907031348.AA19891@rice.edu> Received: from ICSA.RICE.EDU by icsa.rice.edu (IBM VM SMTP R1.2.1) with BSMTP id 9510; Mon, 03 Jul 89 08:47:58 CDT Received: by RICE (Mailer R2.04) id 9509; Mon, 03 Jul 89 08:47:52 CDT Date: Mon, 03 Jul 89 08:45:03 CDT From: "Mark R. Williamson" Subject: Re: MH verses the "all in one file" MUAs To: HEADER-PEOPLE@mc.lcs.mit.edu In-Reply-To: Message of Sun, 2 Jul 89 22:41:19 GMT from On Sun, 2 Jul 89 22:41:19 GMT gregg.g.wonderly said: >The INODE issue is a UN*X deficency, not am MH issue. Fair enough. What system besides UN*X can MH run on?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 11:21:46 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa26037; 3 Jul 89 11:15 EDT Received: by uunet.uu.net (5.61/1.14) id AA09128; Mon, 3 Jul 89 11:05:21 -0400 Date: Mon, 3 Jul 89 11:05:21 -0400 From: Rick Adams Message-Id: <8907031505.AA09128@uunet.uu.net> To: S.Kille@cs.ucl.ac.uk, long@sh.cs.net Subject: Re: RFC-822 'phrase' question Cc: eric@icsib.berkeley.edu, header-people@mc.lcs.mit.edu, techies@sh.cs.net, wunder@sde.hp.com Lets ignore what the RFC says. I claim the RFC is wrong and should be updated. It is gratuitous because it servers no useful purpose. You can tell where it came from via the Received lines (required in the hosts-requirements rf) Besides, it is NOT VERIFICATION. The calling machine is telling you who it is and you're believing it. Thats not verification in my book. The Received lines that have an ip address mapped into a hostname are verification, but the SMTP source routes are just useless filler.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 14:04:07 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27486; 3 Jul 89 14:00 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Jul 89 13:32:38 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Jul 89 17:20:51 GMT From: vax5!ut6y@cu-arpa.cs.cornell.edu Organization: Not in my apartment, there isn't. Subject: Re: MH verses the "all in one file" MUAs Message-Id: <18916@vax5.CIT.CORNELL.EDU> References: <113461@sun.Eng.Sun.COM>, <1518@cbnewsc.ATT.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu My $.02 cents... The main thing I find ELM (for example) has over MH, both of which I have, in my time, installed and used extensively, is speed. Elm2.2 is considerably faster on our little Vax 750 (Vax1.cit.cornell.edu) than MH6.6. Both, I find, provide a great number of features that I like, and in general, balance out in every other way. The other advantage to ELM is that you don't have to go through EMACS to get a really good screen interface. The final advantage is simply that it is compatible with normal Berkley Mail. This may not seem important until you realize that there are times when one has to, for whatever reason, resort to old Mail/Mailx. MHMail requires a format conversion in order to integrate whatever you did under Mail. Elm does not. Unc ,  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 15:03:50 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28037; 3 Jul 89 14:59 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Jul 89 14:53:37 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Jul 89 18:50:10 GMT From: Bill Wisner Organization: Verrifast Plaine Co Ltd Subject: Re: MH verses the "all in one file" MUAs Message-Id: References: <113461@sun.Eng.Sun.COM>, <1518@cbnewsc.ATT.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <18916@vax5.CIT.CORNELL.EDU> ut6y@vax5.CIT.CORNELL.EDU writes: >This may not seem important until you realize that there are times when one >has to, for whatever reason, resort to old Mail/Mailx. HAH! Bill Wisner wisner@mica.berkeley.edu ucbvax!mica!wisner I'm not the NRA either.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 18:36:54 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29920; 3 Jul 89 18:35 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Jul 89 18:27:14 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Jul 89 22:13:58 GMT From: Curt Stevens Organization: University of Colorado, Boulder Subject: Re: "Status" header Message-Id: <9838@boulder.Colorado.EDU> References: <1322@uceng.UC.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <1322@uceng.UC.EDU> kamat@uceng.UC.EDU (Govind N. Kamat) writes: >I keep noticing a header called "Status" in certain mail, with field >values like "R" and "OR". > >What is this header supposed to represent? It doesn't seem to be part >of RFC822. I assume that RFC822 describes the vanilla email header??? Could someone please tell me where I can get this via anonymous ftp? Thanks a bunch... =============================================================================== |Curt Stevens (303)492-1218 | / |arpa: stevens@boulder.colorado.edu| |University of Colorado at Boulder | o o |uucp:{ncar|nbires}!boulder!stevens| |Computer Science Department | | |----------------------------------| |Campus Box 430 | \_/ |Its a dog eat dog world & Im wear-| |Boulder, Colorado 80309 | |ing milkbone underwear.Norm@Cheers| =============================================================================== ======== | Curt | ========  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 19:08:14 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00419; 3 Jul 89 19:04 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Jul 89 18:52:11 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Jul 89 22:47:32 GMT From: Bill Wisner Organization: Verrifast Plaine Co Ltd Subject: Re: "Status" header Message-Id: References: <1322@uceng.UC.EDU>, <9838@boulder.Colorado.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu RFC822 describes the standard format for messages on the Internet. The UNIX mail format is not quite RFC822, although it does make an effort to conform. Bill Wisner wisner@mica.berkeley.edu ucbvax!mica!wisner I'm not the NRA either.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 19:39:16 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00877; 3 Jul 89 19:37 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Jul 89 19:27:56 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Jul 89 16:19:19 GMT From: "p.a.davis" Organization: AT&T, Middletown NJ Subject: DEC Mail-11 & headers Message-Id: <5217@mtgzz.att.com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Are there any opinions, informed or otherwise, concerning DEC's Mail-11 protocol and its refusal to handle non-VMSmail headers ? I find it infuriating to have mail with a reply-to routed through a VAX running a Mail-11 gateway system, only to hear from the recipient that the reply-to has been "excised" from the header, and now, as far as RFC???-compliant mailers are concerned, is actually part of the message ? Does anyone know if DEC plan to do anything about this appallingly parochial approach before X.400 ? Paul Davis Internet: davis@mtgzz.att.com Bitnet: bartonb@duvm Voice1: 201-957-5569 (day) Voice2: 215-981-0614 (night) "All opinions are my own, which may or may not increase their value." "To shatter tradition makes us feel free, But tradition is a static defence against a chaotic community ... " Annette Peacock, 1981  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Jul 89 20:41:18 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa01540; 3 Jul 89 20:36 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 3 Jul 89 20:04:11 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Jul 89 22:35:26 GMT From: "Brandon S. Allbery" Organization: Cleveland Public Access UN*X, Cleveland, Oh Subject: Re: "Status" header Message-Id: <13784@ncoast.ORG> References: <1322@uceng.UC.EDU>, , <15051@pasteur.Berkeley.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu As quoted from <15051@pasteur.Berkeley.EDU> by dheller@cory.Berkeley.EDU (Dan Heller): +--------------- | In reponse to someone's question about what the Status: header is for, | karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes: | | > That's being done by Berkeley Mail. If you have source, see | > ucb/Mail/send.c. Gross. Pick another MUA. | | This header is modified by Mail (or sokme UA) to remember that the | message has been Read, Unread-but-old, or other information about | the message. | | Karl feels that this is "gross". I'd love to hear suggestions about | how to retain the "status" of a message without losing "state" and | not storing the information in the actual message. The status header | is common among most Mail-based UA's (I don't know about MH). +--------------- MH *does* use such headers. However, the format is quite different: Replied: Sat, 01 Jul 89 10:43:08 -0400 However, you can give MH commands a flag (-noannotate) to turn this off. Presumably, Karl does this (assuming that he uses MH); I, personally, prefer to know about it. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@ NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 4 Jul 89 10:36:45 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa07941; 4 Jul 89 10:31 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0741; Tue, 04 Jul 89 10:30:17 EDT Received: from IRLEARN.UCD.IE by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 8693; Tue, 04 Jul 89 10:30:17 EDT Received: by IRLEARN (Mailer R2.03B) id 1023; Tue, 04 Jul 89 15:13:38 GMT Date: Tue, 04 Jul 89 14:59:24 GMT From: "Niall O'Reilly (NOREILLY@IRLEARN.UCD.IE)" Subject: Re: DEC Mail-11 & headers To: HEADER-PEOPLE@MC.lcs.mit.edu In-Reply-To: Message of Mon, 3 Jul 89 16:19:19 GMT from Message-ID: <8907041031.aa07941@mintaka.lcs.mit.edu> My partly-informed and strongly-held opinion is that if mail passing through a VMS VAX must be mangled at all, then that VAX ought to be running PMDF (or better, but I don't know any better: I'm just partly- informed). Mail-11 doesn't support more than three or four of the header elements of RFC822, and supports very restricted addressing. A variety of ad-hoc extensions offer some relief, but too often result in messagesfor which the REPLY command does not work. I'm not quite sure what you mean by 'Mail-11 gateway'. My notion of a gateway is something which comprehends more than Mail-11 ... Niall  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 4 Jul 89 10:36:51 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07946; 4 Jul 89 10:33 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 4 Jul 89 10:06:02 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 4 Jul 89 13:39:01 GMT From: Larry Campbell Organization: The Boston Software Works, Inc. Subject: Re: DEC Mail-11 & headers Message-Id: <797@redsox.bsw.com> References: <5217@mtgzz.att.com> Sender: header-people-request@MC.lcs.mit.edu To: header-people@MC.lcs.mit.edu DEC will never "fix" the Mail-11 protocol. It is not too far from the truth to say that Mail-11 is braindamaged on purpose -- DEC's attitude is that if you want "real" mail, you buy Mailbus products. -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 4 Jul 89 19:12:06 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa11315; 4 Jul 89 19:04 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 4 Jul 89 18:37:56 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 4 Jul 89 22:10:39 GMT From: Keith Moore Organization: CS Dept -- University of TN, Knoxville Subject: Re: DEC Mail-11 & headers Message-Id: <979@utkcs2.cs.utk.edu> References: <5217@mtgzz.att.com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <5217@mtgzz.att.com> davis@mtgzz.UUCP (p.a.davis) writes: >Are there any opinions, informed or otherwise, concerning DEC's >Mail-11 protocol and its refusal to handle non-VMSmail headers ? Mail-11 and VMS MAIL are toys. It's a royal pain to have to translate from MAIL-11 to "real" mail protocols, but this is because VMS MAIL was never designed to talk to anything but other VMS MAIL (or very similar) programs. >I find it infuriating to have mail with a reply-to routed through >a VAX running a Mail-11 gateway system, only to hear from the >recipient that the reply-to has been "excised" from the header, >and now, as far as RFC???-compliant mailers are concerned, is >actually part of the message ? Some SMTP-to-MAIL-11 gateway programs scan the RFC822 headers to determine the "best" reply-to address, and insert that address in the MAIL-11 "From" line, so replies go to the correct addresss. (PMDF does this, and so does my mail-11 gateway for UNIX systems.) >Does anyone know if DEC plan to >do anything about this appallingly parochial approach before X.400 ? I'm sure your DEC customer relations person will tell you that they have done something about the problem, and it's called "Mailbus". -- Keith Moore Internet: moore@utkcs2.cs.utk.edu University of Tenn. CS Dept. BITNET: moore@utkvx 107 Ayres Hall, UT Campus UT Decnet: utkcs2::moore Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Jul 89 17:12:04 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12467; 9 Jul 89 17:10 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 9 Jul 89 16:07:30 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Jul 89 14:20:31 GMT From: "Nicholas J. Simicich" Organization: Nick Simicich, Peekskill, NY Subject: Re: MH verses the "all in one file" MUAs Message-Id: <682@scifi.UUCP> References: <113461@sun.Eng.Sun.COM>, <1518@cbnewsc.ATT.COM>, <18916@vax5.CIT.CORNELL.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <18916@vax5.CIT.CORNELL.EDU> ut6y@vax5.cit.cornell.edu (The Dread Pirate Mikey (Mike Shappe)) writes: >The final advantage is simply that it is compatible with normal Berkley Mail. >This may not seem important until you realize that there are times when one >has to, for whatever reason, resort to old Mail/Mailx. I think that I can say that this isn't true in my case. And I know many other people who do all of their mailing on Unix (AIX) who use mh-mode in GNUemacs, rmail mode in GNUemacs, or XMH, and who never use the Berkley mail command. Me? I like RMAIL mode.... -- Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 22:45:53 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27056; 12 Jul 89 22:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 12 Jul 89 22:23:23 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Jul 89 00:51:26 GMT From: Geoff Goodfellow Organization: Anterior Technology, Menlo Park, CA USA Subject: Assumptions & Rules for Transiting UUCP/SMTP Messages. Message-Id: <1368@fernwood.MPK.CA.US> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [The following blurb is the result of an ~11pm-1am fueling at The Oasis (a local burger/pizza/beer garden) between Geoff Goodfellow & Paul Vixie. Comments?] ASSUMPTIONS & RULES FOR TRANSITING UUCP/SMTP MESSAGES Assumptions: 1. UUCP(!) style addresses are not guaranteed to always be unique and/or registered in the uucp maps. 2. SMTP(@) rfqdm style address are unique and registered in the DNS. 3. The envelope of a UUCP message is always touched as a message transits a system, by prepending the transited systems name to the front. Header Treatment Rules: 1. Headers are treated the same regardless of transport. 2. Headers should not be touched as messages transit systems UNLESS the message is transiting from the UUCP(!) to the SMTP(@) environment. 3. While transiting a message from the UUCP(!) to the SMTP(@) environment, 3a. IF the header contains an (@) style address with a rfqdm address on the right of it THEN do not touch it; 3b. IF the header contains an (@) style address with a non-rfqdm address on the right of it THEN do some type of %ification to the non-rfqdm address and append the rfqdm (@) address of the transited system; 3c. IF the header does not contain an (@) style address THEN replace the header "From:" address with envelope "From " address and append the rfqdm (@) address of the transited system. Notes: DNS = Internet Domain Name System. rfqdm = Registered Fully Qualified Domain address in the DNS. An (@) style address is an address with an @-sign in it. You cannot assume an (@) style address is a rfqdm name without checking its validity with the DNS when transiting messages from UUCP -> SMTP, as there are hosts which will assign themselves a DNS style name without registering it in a DNS server connected to the Internet. (Use of the PSEUDODOMAIN function in IDA Sendmail permits bypassing DNS lookups on bogus top-level domains such as .uucp, .bitnet, .janet, et al and then proceed directly to rule 3b). Some systems prepend their name to headers as a message transits them (in violation of rule 2). This inconsistiency is fixed by copying the envelope "From ", which is always augmented as a message transits a system (assumption 3) into the "From:" header field (rule 3c). There is no attempt to fix or clean-up bad/invalid headers or short-circuit routing. garbage in ==> garbage out (with the exception for rule 3c's handeling of "From:" when transiting a message from !-land into @-land). Some Rule Examples (fernwood.mpk.ca.us is the UUCP -> SMTP gateway host) 2. z!foo --> z!foo x!y!z!foo --> x!y!z!foo x!y!z.com!foo --> x!y!z.com!foo 3a. foo@z.com --> foo@z.com 3b. foo@z.uucp --> foo%z.uucp@fernwood.mpk.ca.us bar@z.bitnet --> bar%z.bitnet@fernwood.mpk.ca.us foo@z --> foo%z@fernwood.mpk.ca.us foo@bogus.com --> foo%bogus.com@fernwood.mpk.ca.us 3c. Envelope: x!y!z!foo Header: x!z!foo --> x!y!z!foo@fernwood.mpk.ca.us Envelope: x.com!y!z!foo Header: x.com!y!z!foo --> x.com!y!z!foo@fernwood.mpk.ca.us