Date: Mon, 23 Jan 84 10:38:40 PST From: Rich Wales To: Header-People@MIT-MC Subject: Funny headers from LBL-CSAM For some time now, whenever someone at LBL-CSAM has made a contribution to the UNIX-Wizards mailing list, the "From" line of the header has been munged. Here is a recent example (note particularly the lines I have indicated with arrows on the left): Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Jan 84 12:55 EST Received: From Lbl-Csam.ARPA by BRL via smtp; 22 Jan 84 12:44 EST Return-Path: Received: by lbl-csam.ARPA ; Sun, 22 Jan 84 09:45:37 pst Date: Sun, 22 Jan 84 09:45:37 pst ==> From: Mike O'Dell@BRL-VGR.ARPA, mo@lbl-csam ==> MMDF-Warning: Parse error in preceeding line at BRL-VGR.ARPA Message-Id: <8401221745.AA21328@lbl-csam.ARPA> To: unix-wizards@brl Subject: NULL pointers Note that the "From" line in the above header is invalid according to RFC822, since the first address (Mike O'Dell@BRL-VGR.ARPA) contains a space in its "local-part". Further, of course, this first address is incorrect, since Mike O'Dell is in fact not at BRL. I assume the munging in question is probably taking place at BRL-VGR (based on the "MMDF-Warning" line). I know it is not happening here at UCLA-LOCUS, since we do not use MMDF and our mail handler does not modify "From" lines of incoming ARPANET mail in any way. On several occasions, I have asked various people at LBL-CSAM to send me test messages so that I could see what their "From" lines looked like (again, hoping to take advantage of the fact that my system's mailer doesn't munge "From" lines). I have never succeeded in getting any reply. I don't know whether this is because the people I have asked thought I was a busybody or a crackpot, or because my messages simply never arrived. Can someone (at BRL and/or at LBL) explain and/or fix this problem? -- Rich P.S. to MMDF gurus: "Preceeding" is a misspelling. It should be "preceding", since the base form of the word is "precede".  Date: Wed, 25 Jan 84 20:36:35 PST From: Rich Wales To: Header-People@MIT-MC Subject: What time zone is Alaska in? A few weeks ago, I thought I heard a fleeting news item on the radio to the effect that Alaska was changing its time zone. Rather than continue to be split across three zones (Yukon, Alaska/Hawaii, and Bering) -- so the story went -- all parts of Alaska would henceforth keep Yukon time (GMT-9; GMT-8 in summer). Is the above actually the case, or was I suffering from a sophisticated aural hallucination? If this is true, then I suppose the long-standing confusion between BST (Bering Standard Time) and BST (British Summer Time) no longer exists. I wonder whether the Alaska Legislature contains any mail hackers. -- Rich  Date: 26 Jan 1984 0102-EST From: John R. Covert To: v.wales at UCLA-LOCUS, Header-People at MIT-MC ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" Usenet-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" Subject: Re: What time zone is Alaska in? Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11986600382.12.132.8699 at DEC-MARLBORO> Regarding: Message from Rich Wales of 25-Jan-84 2343-EST What you heard on the radio is almost true. Alaska used to have FOUR time zones: Bering for the Aleutian Islands and the mainland points along the Bering Sea and Strait, Alaska for most of the state, Yukon for ONLY Yakutat, and Pacific for the area around Juneau. Now there are two. All the mainland points (including Juneau!) have moved to Yukon time (UCT-9). The Aleutians are now on what used to be Alaska time (UCT-10) -- the same as Hawaii time. But the people at the Weather Station at Shemya don't know what the name of their timezone is. Since this was done on the day they would have otherwise dropped from BDT back to BST, they think they're still on Bering Time (since they didn't change time). --------  Date: Thu, 26 Jan 84 12:57:32 EST From: BRINT To: header-people@mit-mc Subject: [Makey.DODCSC: Faster-Than-Light Travel Demonstrated] ----- Forwarded message # 1: Received: From Brl.ARPA by BRL-BMD via smtp; 26 Jan 84 3:57 EST Received: From Sri-Unix.ARPA by BRL via smtp; 26 Jan 84 4:06 EST Received: from Mit-Multics.arpa by sri-unix.arpa with TCP; 25 Jan 84 7:48-PST Date: 25 January 1984 10:41 est From: Makey.DODCSC@mit-multics Subject: Faster-Than-Light Travel Demonstrated To: Physics@sri-unix (enter Sarcasm mode) >>> Subject: Question about Helmut Schmidt's PSI experiment >>> Date: Sunday, 29 January 1984 21:26 est >>> From: ihnp4!ihuxr!lew at UCB-VAX >>> To: physics at SRI-UNIX >>> Article-I.d.: ihuxr.855 At last! The above is conclusive evidence that faster-than-light travel is possible. The message with the above header was received more than four days *BEFORE* it was sent. The only way this could conceiveably have happened is if the message traveled faster than light from ihuxr to SRI-UNIX. (If there were only some way to get this kind of network thruput on a regular basis!) This is the kind of scoop that the National Inquirer pays big bucks for, but you saw it first on net.physics! :: Jeff Makey ----- End of forwarded messages  Date: Sat, 28 Jan 84 01:24:39 PST From: Rich Wales To: Header-People@MIT-MC Subject: Several questions/comments on time zones Here are several questions/comments on time zone abbreviations and usages. I am including all of this in one message for the sake of con- venience. Please feel free to comment on only some of what I say below, even if you don't have anything to say about all my points. Also, I would especially like some feedback from the people who live (or have lived) in the areas involved, and who therefore have first- hand knowledge. Some of this material may seem out of place, given that we haven't been arguing these issues lately. However, I hope that whoever out there is planning possible future revisions of mail standards will take note of this message and any authoritative answers it generates. (1) It has been suggested a few times that time stamps be expressed either in UTC or as the number of seconds past a given starting point. I feel, however, that such an approach would be less than ideal, because the sender's local time of day may be a useful piece of information for the recipient to have. For example, suppose all "Date" lines had to show time in UTC. If I were to send a message between 1600 and midnight (according to my local time, PST), the "Date" line would indicate the next day, since 1600 PST = 0000 UTC. If my message's body contained a "relative" time expression such as "today", the recipient might be confused as to which day I meant unless he knew my physical location (and thus my local time zone). (Admittedly, this same problem could occur today, in cases where a user and his computer are widely separated. However, I would assume that the local time of the user and the computer are the same more often than not.) (2) People have discussed which term is "most" correct for the standard time zone around the prime meridian -- UTC, UT, or GMT. (a) What do the British, Irish, and whoever else falls in this time zone call their time? (Judging from "Date" lines in messages from UCL-CS, I would assume the answer to my question is "GMT"; however, could someone from the UK or Ireland speak up and say definitively?) (b) Assuming that "Date" lines are to reflect the sender's local time, it seems wrong to make the British and Irish say "UT" or "UTC" if their local custom is to say "GMT". If other people somewhere want to use "UT" or "UTC", maybe the only equitable solution is to give all three abbreviations equal status. (c) This entire discussion becomes moot, of course, if we all end up using numeric offsets instead of time-zone abbreviations. (3) Would some Canadian on this list confirm or correct the following time zone abbreviations: NST/NDT (Newfoundland); AST/ADT (Atlan- tic); and YST/YDT (Yukon)? Also, am I correct in assuming that the Alaskans too use YST/YDT for Yukon time? (4) Does Hawaii use the abbreviations HST and HDT? For that matter, do they even have daylight savings time in Hawaii? (Hawaii's close enough to the equator that I suppose it might not make sense for them to use daylight savings time.) (5) According to John Covert at DEC-Marlboro (message of 26 Jan 84), Alaska is down to two time zones now (UTC-10 for the Aleutians and UTC-9 for the rest of the state). Are the people in the Aleutians going to end up calling their time zone HST/HDT (since it's the same as Hawaii time)? Or will they use AHST/AHDT ("Alaska/Hawaii")? Or even AST/ADT ("Alaska", or "Aleutian")? If they decide to call it AST/ADT (and thus create a conflict with Atlantic time), I say forget it -- the Atlantic time zone has first dibs on the abbreviation (and more people, too!), and the Aleutians can use a numeric offset if they don't like HST/HDT. -- Rich  Date: 29 Jan 1984 0018-EST From: John R. Covert To: header-people at MC cc: v.wales at UCLA-LOCUS ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" Usenet-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" Subject: Time Zones Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11987378875.24.132.12239 at DEC-MARLBORO> I would strongly support use of the ISO standard with local time and a numeric offset. As Rich says, the local time is an important piece of mail context. The offset allows it to be easily compared to the recipient's local time or any other time. I'd like to see the name of the zone as well (as a comment, like John Covert is a comment in the From: header). We can't expect standardi- zation of time zone names, because you aren't going to get people in Paris and Munich to agree on only one of HEC and MEZ. The German abbreviation in the summer is MESZ; I don't remember the French. As an aside, remember that all locations that use Daylight Savings time do not switch on the same date. Hawaii does not observe Daylight Savings time. Note that the historical information I've provided on time zones in the North American integrated telepone numbering zone comes from the V&H tape. Since I don't have a new tape yet, my info on Alaska came from making several phone calls to police and weather stations. Prior to the switch in Alaska, there were only THREE locations with dial telephones on Yukon time (one in Alaska and two in the Yukon Territory) and twelve more ringdown call boxes in the Yukon Territory. Whitehorse, YT is on Pacific time. --------  Date: 29 Jan 84 0035 EST From: Rudy.Nedved@CMU-CS-A To: Rich Wales Subject: Re: Several questions/comments on time zones CC: Header-People@MIT-MC In-Reply-To: "Rich Wales's message of 28 Jan 84 04:24-EST" Message-Id: <29Jan84.003557.EN0C@CMU-CS-A> Rich, I have two views of mail: 1) What you see on your screen is what is actually sent. Therefore the time zone is that time zone that you are in including daylight savings problems. If you send to another zone, you may or may not have problems but I don't see any simple solution because I feel the philosphy used by the composer and delivery agents is wrong... 2) What you see on your screen is encoded into a recusive data structure that is handled a specified way at each interface but the representation can be changed as it is moved until it reaches another software interface. The time zone should be displayed as the local time zone but stored in the encoded version as an absolute offset of GMT time. When it is displayed in the new zone, you get the readers time zone instead of the senders time zone information. The senders time zone information (offset) should be included so that some set of users can change the "local time zone" and see what time the sender sent the mail at (in case you want to know if the guy was working late before giving him a call). The RFC822/RFC733 is mostly of philosphy (1) even though I and other people at CMU wish it was different. There are just too many mail systems out in the internet that have simple/trivial mail composers/readers. I don't expect this to change given there is no motivating force that if people don't add code things do not work. I am waiting for multimedia mail and therefore philosphy (2) to happen. There however is some confusion in the world that I wish DCA or DARPA would clear up: Which multimedia specification should people follow?? I hear of one being created by DARPA, one at NBS and one at CCITT. If the issue every comes up around CMU...I am pushing for the CCITT one since Xerox has picked it and it is a more complete specification then the NBS one. -Rudy  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA08870; Sat, 28 Jan 84 21:15:46 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.13/4.11) id AA21448; Sat, 28 Jan 84 21:10:09 pst Received: by ucbopal.CC.Berkeley.ARPA (4.13/4.11) id AA03216; Sat, 28 Jan 84 21:01:58 pst Date: Sat, 28 Jan 84 21:01:58 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8401290501.AA03216@ucbopal.CC.Berkeley.ARPA> To: Header-People@MIT-MC, v.wales@UCLA-LOCUS Subject: Re: Several questions/comments on time zones On zero time zone designators: In addition to UT, UTC, Z, and GMT, I have also heard of GCT (C for Civil). Z ("Zulu" or "Zero" time zone) is the military term. As far as US Armed Forces is concerned, it is the time transmitted by the Dept. of Commerce radios stations WWV and WWVH (hope I got the call signs correct). WWV previously transmitted GMT time, but since the early/mid 70's has been transmitting Coordinated Universal Time(UTC). Perhaps someone can give us some history of the name change. GMT, GCT, PST/PDT, etc. are local Civil time designators. UT and UTC maybe defined by international treaty/agreement (anybody know?). I also suspect that UTC is not the same as GMT (seconds apart?). Does any one have the name of time used by the "star gazers"? On date/time stamping of message: Things would be a lot easier if messages on the network would be dated and time stamped with UTC (or "Z") time. If you want local time and date presented/used by your users, convert the time and date in your presentation (user interface) program(s). The military, and I think, most international communications companies use only one time zone to identify messages. Why can't we? On converting UTC to/from local time: 01:00:01 01 Jan 84 UTC is 17:00:01 31 Dec 83 PST Note the day and year difference. When converting local time to UTC, the day and year must be converted as well. It's not hard to do. For PST, the rule is to add 8 hours to the current time (since the sun comes up 8 hours earlier in England than it does on the U.S. West Coast). If the resulting hour is greater that 24, subtract 24 hours from the hours and add 01 to the day (and add 1 to the year if the original day is 31 Dec). (For PDT add 7 instead of 8 hours to get UTC). I will let you figure out how to convert the other way. New subject: When does the day change? Or is 00:00:00 today, really 24:00:00 yesterday? I think the military avoids the issue by never using 00:00 or 24:00 (hours and minutes) to identify messages. Bill Wells wcwells@Berkeley.ARPA  Date: 29 Jan 1984 0138-EST From: John R. Covert To: header-people at MC ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" Usenet-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" Subject: GMT vs UCT Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11987393385.24.132.7490 at DEC-MARLBORO> Greenwich Mean Time is solar time at the the Greenwich Meridian; it varies with the variations in the rotation of the the earth. Coordinated Universal Time is an absolute time which can differ from GMT by almost a second. Leap seconds are inserted when convenient to keep UTC within one second of GMT. UTC is easier to track at independent locations on earth because all you need is the proper oscillator (I think the element used recently changed). To track GMT, you need an observatory. I've never heard GCT used related to time (I always thought it was Grand Central Terminal :-) --------  Date: Sun, 29 Jan 84 08:35:43 cst From: solomon@wisc-crys (Marvin Solomon) Message-Id: <8401291435.AA00179@wisc-crys.ARPA> Received: by wisc-crys.ARPA (4.22/3.7) id AA00179; Sun, 29 Jan 84 08:35:43 cst To: header-people@mit-mc Subject: Re: Several questions/comments on time zones This is another example of the pitfalls of confusing an interchange standard with a user-interface standard. Users would prefer to see dates in local-time format, but interchange programs would prefer something a bit more uniform and structured. If RFC 733 (and its successor, 822) had not made the mistake of defining a mail header in such a way as to make it appear to be designed to be read, the header could encode dates in any form convenient for exchange (some encoding of UT), and users who wanted to read or send mail would be FORCED to write or have written a program to translate to/from local time. (You may interpret this as a plug for the new NBS standard). By the way, in most cases, the "local time" the user would prefer to see in messages is his OWN local time. For example, when I'm reading a message from somebody and want to know whether he wrote it before or after some particular event (for example, I want to know whether he wrote it early enough that it's likely he saw a particular message from me), I'd rather see the Date line expressed in my own local time. Whenever I have to look at Received lines, I find that even to sort them in chronlogical order, I have to mentally convert to local time (or some other fixed time zone). Offhand, I cannot think of any situation where I want to see the Date line in the sender's local time, and I would argue that NOBODY wants to see maintenance timestamps (such as Received) expressed in the time zone where they were inserted.  Date: Sun, 29 Jan 84 10:03 EST From: "Benson I. Margulies" Subject: Re: Several questions/comments on time zones To: header-people@MIT-MC.ARPA In-Reply-To: Message of 29 Jan 84 09:35 EST from "solomon at WISC-CRYS (Marvin Solomon)" Message-ID: <840129150352.738172@MIT-MULTICS.ARPA> I find it helpful to get a hint of where in the world a correspondant is. The time zone does that. Further, I confess that the precise time of a message is a much better indicator of the prospective state of mind of the sender than it is anything else. I like to know that it was 9am from the senders point of view and not, for example, midnight. Finally, I think your argument is moot. pseudo-readable or not, 733 date-times are quite definitely parsable. Your user interface program is welcome to digest them and re-present hem in local time. rfc733 times are no more or less "standard", iff a reasonable set of zone appreviations is in use.  Date: 29-Jan-84 11:14 PST From: Rich Zellich Subject: Re: Sender's time zone To: Header-People@MIT-MC Message-ID: <[OFFICE-3]GVT-RICH-408G1> I, too, sometimes use the sender's date/time field to get an idea of when the author sent the message, but you must remember that it can't be relied upon because of networking. I, for instance, am in St. Louis on CST but the host I usually send mail from is in Cupertino, CA and is on PST; you will therefore see PST time-stamps on some messages I send (and CST on others, because one of my mail systems allows me to specify which time-zone to use). Seeing PST time stamps on my messages won't much help anyone tell when I sent it (if they want to know if it's too early/late to phone me, or something like tht). -Rich  Date: Sun 29 Jan 84 13:26:36-PST From: David Roode Subject: Re: Sender's time zone To: RICH.GVT@OFFICE-3, Header-People@MIT-MC In-Reply-To: Message from "Rich Zellich " of Sun 29 Jan 84 11:14:00-PST Location: EJ286 Phone: (415) 859-2774 I think that a user's time zone should be settable, at least for message timestamps, on a system which serves more than one zone. Thus he should be able to insure that messages will be stamped with the time he was experiencing as he set them. Failing that, maybe the system in Cupertino could keep Eastern time. I know of one information retrieval utility that uses Eastern time on its system (for everyone) allthough it is located in the Pacific time zone. -------  Received: by RICE (AA22355); Sun, 29 Jan 84 17:06:09 cst Received: by RICE-JANUS (AA00566); Sun, 29 Jan 84 16:56:29 cst Date: Sun, 29 Jan 84 16:39:59 CST From: Paul Milazzo Subject: Re: Several questions/comments on time zones To: solomon@wisc-crys (Marvin Solomon) Cc: header-people@mit-mc Message-Id: <1984.01.29.16.39.59.630.00537@Rice-vms.rice> In-Reply-To: a message from Marvin Solomon dated Sun, 29 Jan 84 08:35:43 cst "If RFC 733 (and its successor, 822) had not made the mistake of defining a mail header in such a way as to make it appear to be designed to be read, the header could encode dates in any form convenient for exchange (some encoding of UT) [...]." It is my understanding that RFC 733 did not invent the contents of a mail header; similar formats had been in use for some time. RFC 733 simply tried to make known (and perhaps official) the various de facto standards which had sprung up in the Internet community. Thus it became a sort of "conglomerate standard". I consider this effort a noble one, if perhaps incompletely successful. Paul G. Milazzo Dept. of Mathematical Sciences Rice University, Houston, TX  Date: Mon, 30 Jan 84 11:08:26 EST From: BRINT To: header-people@mit-mc Subject: Sender's Time Zone For what it's worth, I use the sender's date/time field for nearly all the reasons mentioned by others. The application most-often invoked, however, seems to be to identify duplicate messages (suspected) when reading mail. Brint  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA25935; Mon, 30 Jan 84 16:06:35 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.13/4.11) id AA13154; Mon, 30 Jan 84 15:56:58 pst Received: by ucbopal.CC.Berkeley.ARPA (4.13/4.11) id AA09824; Mon, 30 Jan 84 15:40:24 pst Date: Mon, 30 Jan 84 15:40:24 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8401302340.AA09824@ucbopal.CC.Berkeley.ARPA> To: header-people@MIT-MC.ARPA Subject: Re: Several questions/comments on time zones I believe we need to have two types of date-time stamps: UTC (or Z) and local. Machine readable date-time fields of messages in transit should be in UTC to make programming easier for mail transport programs. The senders local time stamp could be added as a comment when message is transmitted. Simple mailers could be required to use UTC, more complex mail programs could do local time conversion. Here is an example of how dates could be changed when displayed to the user and when passed to the mail transport system: a. Mailer/Mail composition program using local date displays: Date: Sun, 29 Jan 84 10:03 EST or Date: Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST) (I prefer the latter) but transmits: Date: Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST) to the mail transport system. b. Relaying and receiving hosts would use only UTC at the mail transport level. Thus with a "received" field added the header might become: Date: Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST) Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA00611; Sun, 29 Jan 84 17:53:41 utc c. The receiver (addressee) of the message should have the option of displaying "Date" and "Resent-Date" in either the transmittted mail transport form: Date: Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST) Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA00611; Sun, 29 Jan 84 17:53:41 utc or with the UTC part of the "Date" and "Resent-Date" changed to the receiver's local time: Date: Sun, 29 Jan 84 07:03 PST (Sun, 29 Jan 84 10:03 EST) Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA00611; Sun, 29 Jan 84 17:53:41 utc (Note that the "received" field date-time remains in UTC. The message should be stored in its "mail transport form".) d. Referencing of the received message would use the full date-time field: In-Reply-To: Message of Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST) from "Benson I. Margulies" The nice thing about the above scheme is that only one time zone is used at the mail transport level and we do not have to change RFC822 to implement the above since a () comment field maybe used now with any header field. Bill Wells wcwells@Berkeley.ARPA  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA26612; Mon, 30 Jan 84 16:58:12 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.13/4.11) id AA13388; Mon, 30 Jan 84 16:37:42 pst Received: by ucbopal.CC.Berkeley.ARPA (4.13/4.11) id AA10569; Mon, 30 Jan 84 16:26:51 pst Date: Mon, 30 Jan 84 16:26:51 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8401310026.AA10569@ucbopal.CC.Berkeley.ARPA> To: header-people@MIT-MC.ARPA Subject: Re: Several questions/comments on time zones It looks like UT (or maybe UTC) = GMT = GCT = Z. Here is a reply I received from David J. Bryant via Mark Horton : ------- Date: Sun, 29 Jan 84 18:56:43 est; From: mark@cbosgd.UUCP (Mark Horton) To: wcwells@ucbopal; Subject: star gazers time Here is an answer to your star gazers questions Date: Sun, 29 Jan 84 18:21:08 est; From: djb (David J. Bryant) To: mark; Subject: Re: can you please answer the "star gazers" question in this? Astronomers time stamp observations and events according to Universal Time (abbreviated UT). This is based on atomic clocks and mathematical standards according to definition of the International Astromical Union (I.A.U.). Further, Greenwich Mean Time (GMT) is defined to be the same as UT, and applies to the standard meridian (longitude 0 degrees). Greenwich Civil Time (GCT) is synonymous with GMT. WWV and WBS (in England) broadcast UT (which is therefore also GMT, and for the military, Z ("Zulu") time. This is a worldwide standard reference, and probably the best for your purposes. (Elaine says that CompuServe used UT for ALL their record keeping, login accounting, etc.) There are other time schemes as follows: Apparent Time - The time indicated by a sundial. Because the Sun's speed across the sky is not uniform, this varies throughout the year, and is useless for time reckoning. Mean Time - To avoid the non-uniformities of Apparent Time, a fictitious "mean sun" is invoked; this moves across the sky at a constant rate throughout the year. Mean Time, like Apparent Time, is purely a function of your longitude, and so is too variable for much civil use. Civil Time - This is what the clock on the wall is set to. It is based on the concept of Time Zones, Daylight Saving Time, etc. Each time zone is homed on a central meridian, and the mean time for that meridian is used as the civil time throughout the time zone. Other adjustments (Daylight Saving Time) apply as required. Sideral Time - Unlike all the above, which is based on the 24 hour solar day, Sideral Time is based on the 23h 56min "star" day. There are numerous flavors of Sideral Time that compensate for variations, but I don't see any real reason to go into much detail. This is not a time scheme you want to use. Interestingly, all time schemes can be converted to any other time scheme, provided you specify latitude, date, etc. If you would like a more thorough, informative description of these (and other) time systems, let me know. I think this should be enough to answer your question about "star gazing" time. Personally, I encourage you to use UT, and to follow other standard astronomical (I.A.U.) conventions to deal with issues associated with time/date stamping, since astronomers have already worked out these problems. David ------- Now why UT and UTC? I suspect that UT is the time based on the atomic clock from a specific point in time and that UTC is UT which has been leap second adjusted. Bill Wells wcwells@Berkeley.ARPA  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA12643; Tue, 31 Jan 84 11:10:52 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.13/4.11) id AA01413; Tue, 31 Jan 84 11:09:20 pst Received: by ucbopal.CC.Berkeley.ARPA (4.13/4.11) id AA20314; Tue, 31 Jan 84 11:05:36 pst Date: Tue, 31 Jan 84 11:05:36 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8401311905.AA20314@ucbopal.CC.Berkeley.ARPA> To: Margulies@MIT-MULTICS.ARPA, header-people@MIT-MC.ARPA Subject: From Where ? In reply to: Date: Sun, 29 Jan 84 10:03 EST From: "Benson I. Margulies" I find it helpful to get a hint of where in the world a correspondant is. The time zone does that. I think "where" should be in the address, but since Internet mail box addresses are relatively long (with Agent Names), perhaps we should have a "From-Location:" header field with a geographical location. For example: From: "William C Wells" From-Location: Berkeley CA USA Bill Wells wcwells@Berkeley.ARPA  Date: Tuesday, 31 Jan 1984 12:11-PST To: "Benson I. Margulies" Cc: header-people@MIT-MC Subject: Re: Re: Several questions/comments on time zones In-reply-to: Your message of Sun, 29 Jan 84 10:03 EST. <840129150352.738172@MIT-MULTICS.ARPA> From: greep@SU-DSN The time zone may indicate where the machine is, but that isn't necessarily the same as where the user is. For example, there is someone in Australia who uses a machine in California to send mail. More commonly, a lot of people in Washington seem to use machines at ISI to send mail. What's going to happen to time zones when we have people sending messages from Mars or manned space stations? Will they use the time zone of their country's capital?  Date: Tue, 31 Jan 84 13:19:48 PST From: David Alpern Return-Path: Subject: UTC Time stamping To: Header-People@Mit-Mc Via: IBM-SJ; 31 Jan 84 16:16-PST Pardon me, but I think we have a while before we have to worry about how people on Mars would timestamp their messages. Like Benson, I as well use the zone in the timestamp to get an idea of the location of the sender. Sure, it's not 100% accurate, and maybe it'd be nice if a user could specify the zone that would be best to use on messages he's sending. This is something we might consider when writing mail sending programs. No change to any of the "standards" is involved here. However, I somehow missed hearing about the problem that the use of zones other than UTC leads to. Was there one? If so, someone please resend a copy of the original message to me. If not: Many of the mailers around are used more for internal (within some school or company) than external mailing. If I'm on MIT-EECS, and get a message from someone on MIT-ML, I care how recently he sent the message (local time) more than I do what Universal Time it was. RFC 822 does specify a human readable header, and not a machine readable one, in general. For example, consider the usefulness of the "name:;" nomenclature for a distribution list to any program without access to the original list file. I would much prefer if any program that tried to deal with the time for some reason (does anyone???) had to convert than that the mail sending program and mail reading program had to convert at either end for human use. Again, I'd be interested in hearing why this discussion seems important, i.e. what we're trying to prevent or solve. So many mailers aren't even 822 compatible when it comes to dates that I would think the zone issue would be rather minor. With apologies for flaming, Dave  Date: Wed, 1 Feb 84 19:44 EST From: "Benson I. Margulies" Subject: Re: UTC Time stamping Reply-To: bim@MIT-MULTICS.ARPA To: David Alpern cc: header-people@MIT-MC.ARPA In-Reply-To: Message of 31 Jan 84 16:19 EST from "David Alpern" Message-ID: <840202004417.738587@CISL-SERVICE-MULTICS.ARPA> The problem is that we do not have an agreed upon unique list of time zone identifiers. Thus the ISO date standard calls for both the zone abbreviation and its offset from UTC. I still do not see why that is not an adequate solution, though.  Date: 1 Feb 84 2128 EST (Wednesday) From: Richard H. Gumpertz To: Header-People@MIT-MC Subject: Re: Several questions/comments on time zones In-Reply-To: "Rich Wales's message of 28 Jan 84 04:24-EST" Message-Id: <01Feb84.212859.RG02@CMU-CS-A> Parsing time zones is not hard for a computer to do. Let's not waste time on this area that works fine; instead let's fix the things that aren't easy!  Date: 1 Feb 1984 18:59:44 PST From: POSTEL@USC-ISIF Subject: Re: UTC Time stamping To: bim@MIT-MULTICS, Alpern.Ibm-Sj@RAND-RELAY cc: header-people@MIT-MC, POSTEL@USC-ISIF In response to the message sent Wed, 1 Feb 84 19:44 EST from bim@MIT-MULTICS.ARPA I don't think i have ever seen a list of international standard time zone designators from ISO or CCITT or any standards organization. I think the only official international standard way to indicate a time zone is by a numeric offset. --jon. -------  Date: 1 Feb 84 2221 EST (Wednesday) From: Richard H. Gumpertz To: POSTEL@USC-ISIF Subject: Re: UTC Time stamping CC: header-people@MIT-MC, POSTEL@USC-ISIF In-Reply-To: "POSTEL@USC-ISIF's message of 1 Feb 84 21:59-EST" Message-Id: <01Feb84.222129.RG02@CMU-CS-A> So we use ANSI (because we are Americans, mostly) for American time zones in alphanumeric and other time zones in numeric. As I recall, this is a superset of the ISO standard but conveys more information (CDT differs from EST but are numerically equal).  Via: unknown-host; (pss/csmail/listen); to 44d.Ucl-Cs.AC.UK over PSS with NIFTP; 2 Feb 84 12:32 GMT Date: 2 February 1984 12:21 gmt From: "Neil Davies%aucc"@ucl-cs.arpa Subject: Re: UTC Time stamping Sender: DaviesNJ.SysMaint%aucc@ucl-cs.arpa To: POSTEL@usc-isif.arpa cc: header-people@mit-mc.arpa In-Reply-To: Message of 2 February 1984 02:59 gmt from POSTEL Date: 1 Feb 1984 18:59:44 PST From: POSTEL@arpa.usc-isif Subject: Re: UTC Time stamping In response to the message sent Wed, 1 Feb 84 19:44 EST from bim@MIT-MULTICS.ARPA I don't think i have ever seen a list of international standard time zone designators from ISO or CCITT or any standards organization. I think the only official international standard way to indicate a time zone is by a numeric offset. --jon. ------- Jumping ot the filling cabinet. He gets out X.409 CCITT Message handling systems presentaion Trasfer syntax and Notation) or at least a draft of it. One of the sections refers to "UTC", and the presentation layer representation of it. In the references section there are three ISO refernces namely: ISO 2014, Writing Calendar dates in all-numeric form. ISO 3307, Information interchange- representation of time of the day. ISO 4031, Information interchange- representation of local time differentials. also one to B.11, Legal time; use of the term UTC (don't know who origniated that one). 'Fraid I don't happen to have copies of those standards. Neil Davies.  Date: 2 Feb 1984 09:32:31 PST From: POSTEL@USC-ISIF Subject: re: UTC time stamping & time zone designators To: header-people@MIT-MC Neil Davies: Great citations. But no time zone designators (e.g., BST) in them only numeric offsets from UCT. --jon. -------  Date: 2 Feb 1984 1438-EST From: John R. Covert To: POSTEL at USC-ISIF, header-people at MIT-MC ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" Usenet-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" Subject: re: UTC time stamping & time zone designators Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11988583907.27.132.15425 at DEC-MARLBORO> Regarding: Message from POSTEL@USC-ISIF of 2-Feb-84 0932-EST I wouldn't expect to find time zone designators in an ISO standard. ISO rarely resolves issues as complex as whether to call the time zone used in continental Europe HEC or MEZ. When dealing with an issue as close to the heart as the native tongue of the ISO member nations, only numbers can win the votes necessary to pass. We can banty this around forever without getting anywhere. Based on the inputs we have heard local time is the only thing we can be guaranteed will be put into a header because many machines and interfaces are purposefully simple to allow them access to the market and the net. A qualification by zone name is only useful visually since the zone names are not standardized. But this visual identification is useful to the reader. A qualification by UTC offset is nice and is an ISO standard. Since we aren't going to get every mailer to conform, we should state levels of conformance. At the lowest level, simply local time is provided. At the next level, local time is qualified by the UTC offset in the ISO format. At either level a text time zone identification can be added with the understanding that it has purely the effect of a comment and may not be parsed. --------  Date: Thu, 2 Feb 84 12:58 EST From: "Benson I. Margulies" Subject: reams and reams of failed mail notifications To: header-people@MIT-MC.ARPA Message-ID: <840202175812.997294@MIT-MULTICS.ARPA> Whenever I send a message to header-people, I get about a dozen messages from various mailers about their inability to forwward the message someplace. Woundn't they be better directed at the list administrator?  Date: 2 Feb 84 1938 EST (Thursday) From: Richard H. Gumpertz To: "Neil Davies%aucc"@UCL-CS Subject: Re: UTC Time stamping CC: header-people@MIT-MC In-Reply-To: "\"Neil Davies%aucc\"@ucl-cs.arpa's message of 2 Feb 84 07:21-EST" Message-Id: <02Feb84.193839.RG02@CMU-CS-A> The relevant ANSI standard (which we ought to use in America) DOES specify standard alphabetic time zone designations for the USA. I forget the standard number, but it is either X3.30-1971 or X3.51-1975. The other number is for the date standard.  Received: by YALE-BULLDOG via CHAOS; Mon, 6 Feb 84 15:23:07 EST Received: from YALE-RING by YALE-RES via CHAOS; Mon, 6 Feb 84 15:18:57 EST Subject: "Return-Path" vs. "From" Date: Mon, 6 Feb 84 15:19:01 EST From: Nathaniel Mishkin to: header-people@MIT-MC.ARPA cc: Ellis@YALE.ARPA Flame on: I just saw a message that had the following 2 header lines in it: Return-Path: From: Elaine.Newborn@CMU-CS-A.ARPA The "Return-Path" is being generated from data passed in the envelope (SMTP "MAIL FROM"). It seems to me that it's not unreasonable for the "Return-Path" to bear some resemblance to the "From", no? It's bad enough that the two addresses are sometimes trivially different: I've seen mail from many sites in which the case differs (I'm not advocating case sensitivity in user IDs, but some sites DO rely on it). But the case above seems pretty extreme. Which address am I supposed to reply to? If the answer is "either works", why can't the software arrange to give the more sensible one (I'll give you a hint about which I think is the more sensible one: it doesn't have numbers in it; bonus points: why is it ER90 instead of EN90?). -- Nat  Date: Mon 6 Feb 84 13:35:15-PST From: Mark Crispin Subject: Re: "Return-Path" vs. "From" To: Mishkin@YALE.ARPA cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA In-Reply-To: Message from "Nathaniel Mishkin " of Mon 6 Feb 84 12:36:45-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have seen the question of replying to the Return-Path come up zillions of times. Why won't people read RFC 821 and 822 instead of asking this question (or complaining about software which does not reply to the Return-Path)? You *never* reply to the Return-Path. The Return-Path is merely the "return address" for a message if it is undeliverable. It may be the sender of the message. It may be the author of the message. It may be the reply address of the message. It may be the mailer process at the sending site. It may be null. It may be none of these. There is NO relationship between the Return-Path and any reply address. The fact that actual usage patterns very often establish such a relationship is irrelevant. -- Mark -- -------  Date: Mon, 6 Feb 84 22:56:28 EST From: Ron Natalie To: Nathaniel Mishkin cc: header-people@mit-mc.arpa, Ellis@yale.arpa Subject: Re: "Return-Path" vs. "From" Answer "FROM". The SMTP "MAIL FROM" is for ERRORS! -Ron  Date: 7 Feb 84 0049 EST From: Rudy.Nedved@CMU-CS-A To: Nathaniel Mishkin Subject: Re: "Return-Path" vs. "From" CC: header-people@MIT-MC In-Reply-To: "Nathaniel Mishkin's message of 6 Feb 84 15:19-EST" Message-Id: <07Feb84.004916.EN0C@CMU-CS-A> Nat, The return path is the route the mail message took including getting bounced off mars, jupiter and venus. It is not what a mail composer uses to for a return path....it is also quite possible that the reverse path is slower. The return path is only for mail delivery errors. The mail composers should "reply" or "answer" based on the From, Sender and Reply-To fields as specified in RFC822. Admittedly, it is bizzarre that the return-path mailbox specifier is different from the from mailbox specifier but there isn't a quick fix that will 1) get what you want and 2) generate a valid return path. I have plans to fix it but I don't expect it fixed for at least a couple of months. At that point, CMU should have a global distributed name datanase so that anyone on any of our hosts can just say "mail rudy nedved" and it will get to the right mail box. It is all a matter of priorities. -Rudy  Received: by YALE-BULLDOG via CHAOS; Tue, 7 Feb 84 06:39:14 EST Received: from YALE-RING by YALE-RES via CHAOS; Mon, 6 Feb 84 23:05:25 EST Subject: Re: "Return-Path" vs. "From" Date: Mon, 6 Feb 84 23:05:26 EST From: Nathaniel Mishkin To: Mark Crispin cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA In-Reply-To: Mark Crispin , Mon 6 Feb 84 13:35:15-PST I have seen the question of replying to the Return-Path come up zillions of times. Why won't people read RFC 821 and 822 instead of asking this question (or complaining about software which does not reply to the Return-Path)? I am perfectly well aware of the fact that the Return-Path CAN be different from the From and that there are good reasons why it sometimes is. And I'm not talking about what address should be used for replies. What I want to know is WHY in the obvious cases (like the one I showed) IS it different. Given that the sender of a message generally does not (manually) specify the contents of either the Return-Path or From, why do the two fields end up being different in the way they are in the example I gave? I am hardpressed to believe that it is a desirable, intentional, or rational feature that the 2 should be different in the trivial case. I find it hard to believe that whoever wrote the software that caused the behavior I saw considers the difference anything less than a misfeature, if not an outright bug. What I'm really talking about here is the confusion factor: seeing a Return-Path and From that do not agree might lead one to believe that there is some significance in the difference -- otherwise, why would they be presented differently?  From: Christopher A Kent Message-Id: <8402071306.AA15144@merlin.ARPA> Received: by merlin.ARPA; Tue, 7 Feb 84 08:06:17 est Date: 7 Feb 1984 0806-EST (Tuesday) To: Rudy.Nedved@CMU-CS-A.ARPA Cc: header-people@MIT-MC.ARPA Subject: Re: "Return-Path" vs. "From" In-Reply-To: Your message of 7 Feb 84 0049 EST. <07Feb84.004916.EN0C@CMU-CS-A> Would someone please grab Eric Allman, give him a swift kick, and point him at this dialogue? His sendmail program insists on using the string supplied in the SMTP MAIL FROM:<> command as the "Unix-style" from line, which most Unix mail readers pay attention to in preference to the RFC822 From: line when generating a reply address. It is a completely different bogosity that the situation with Unix mail readers comes up at all, but that is a historical dreg and not Eric's fault. But the fact that he ignores it is incomprehensible. Cheers, chris ----------  Date: Tue, 7 Feb 84 10:37:43 EST From: Ron Natalie To: Nathaniel Mishkin cc: Mark Crispin , header-people@mit-mc.arpa, Ellis@yale.arpa Subject: Re: "Return-Path" vs. "From" The confusion factor is minimized by not looking at RETURN-PATH. If you must, configure your mail reader such that the RETURN-PATH lines are deleted. The reason in you case (although I am not certain) is probably one of human engineering. At BRL, for the sake of user friendliness, a user is allowed to specify any return address in his FROM or SENDER line that will legally get the letter back to him (the validation on this is interesting but too lengthy to discuss here). However, the return path is always set to the address that the system determines is the mail invoker really is associated with. This also allows getting around the multiple FROM list problem. For example: I can send a letter with "FROM: Ronald.Natalie@BRL" but the mail system recognizes me as the "ron" user on the BRL-VGR host and my return path gets marked as "ron@Brl-Vgr". RETURN-PATH should probably not be in the header at all, except that mail does get out of the SMTP environment and it's nice to propagate the information along to the non-SMTP environments. The other major use (other than setting return path to null to avoid error messages entirely) is with large mailing lists. If you look carefully at the large lists maintained at BRL (INFO-{MICRO,UNIX,CPM,APPLE}, UNIX-WIZARDS, MSGGROUP). You will find that although these appear to be simple mail exploders (an incoming letter immediately gets turned around and sent out to the list), a transformation occurs. The RETURN-PATH is changed from what it was to the appropriate -REQUEST list. This keeps the list submitters from seeing errors that are beyond their control to fix and forwards them to the people who might be able to fix them who would ordinarily have seen them. -Ron  Date: Tue, 7 Feb 84 12:10:46 cst From: solomon@wisc-crys (Marvin Solomon) Message-Id: <8402071810.AA14416@wisc-crys.ARPA> Received: by wisc-crys.ARPA (4.22/3.7) id AA14416; Tue, 7 Feb 84 12:10:46 cst To: milazzo@RICE-JANUS Subject: Re: Several questions/comments on time zones Cc: header-people@mit-mc, solomon@wisc-crys Re: Date: Sun, 29 Jan 84 16:39:59 CST From: Paul Milazzo Subject: Re: Several questions/comments on time zones To: solomon@wisc-crys (Marvin Solomon) Cc: header-people@mit-mc Message-Id: <1984.01.29.16.39.59.630.00537@Rice-vms.rice> "If RFC 733 (and its successor, 822) had not made the mistake of defining a mail header in such a way as to make it appear to be designed to be read, the header could encode dates in any form convenient for exchange (some encoding of UT) [...]." It is my understanding that RFC 733 did not invent the contents of a mail header; similar formats had been in use for some time. RFC 733 simply tried to make known (and perhaps official) the various de facto standards which had sprung up in the Internet community. Thus it became a sort of "conglomerate standard". I consider this effort a noble one, if perhaps incompletely successful. Paul G. Milazzo Dept. of Mathematical Sciences Rice University, Houston, TX Several people have misuderstood various aspects of this comment, so I must have not made myself clear. First, I do understand the history of 733. One reason standards are hard to write it that you must make a choice between two unpleasent courses: On one hand you can wait until there are (incompatible) implementations and then try to come up with some sort of compromise that won't break too many existing programs. On the other hand you can try to write a spec for something that doesn't exist yet and run the risk of specifying something that is unimplementable. Perhaps I should have said that the choice of making headers human-readable was "unfortunate" rather than "a mistake". Several people have pointed out that while non-human-readable (binary) headers can only be read by programs, human-readable (text) headers can be read by both humans AND programs (using a little compiler technology) and thus would appear to be preferable. My point wasn't that parsing text headers is too hard, but rather that reading text headers is too easy, so that people tend to write mail-reading programs that simply show the headers to users. From time to time, someone flames that "you wouldn't have [whatever your favorite problem is] if you had a decent mail-reading program". If binary headers were the standard, there would be no question but that a reasonable mail-reading program was required, and there would be much less confusion between trans-port level information (in both the envelope and header) and end-user information.  Date: 7 Feb 84 1400 EST (Tuesday) From: Craig Everhart@CMU-CS-A To: Nathaniel Mishkin Subject: Re: "Return-Path" vs. "From" CC: Header-People@MIT-MC Reply-To: Rdmail@CMU-CS-A In-Reply-To: "Nathaniel Mishkin's message of 6 Feb 84 15:19-EST" Message-Id: <07Feb84.140020.RD00@CMU-CS-A> It just doesn't matter, period, that the two are different. I don't care what you think of the aesthetics of each individual field--whether it was a design choice that those two fields look as they do, or (as is the case) that their current appearance is an accident of history. That's none of your business! Obviously, your mailer should NEVER use the Return-Path: field in composing replies (except for error notification). Both addresses work. I could even argue that using a Return-Path identifier that doesn't look like a name is a good idea, precisely to discourage people from using it for ordinary replies. A local (CMU-CS-A) mail system user might have some cause to complain about the aesthetics of the outgoing fields. However, you aren't such, and have no business making that complaint. Craig Everhart  Date: Tue 7 Feb 84 12:29:30-PST From: Mark Crispin Subject: Re: "Return-Path" vs. "From" To: Mishkin@YALE.ARPA cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA In-Reply-To: Message from "Nathaniel Mishkin " of Tue 7 Feb 84 03:45:41-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It isn't totally unreasonable for the From or Reply fields to be a "meaningful" address, such as "Mark.Crispin@Stanford" (which we fully intend to support in the near future) while the "Return-Path" would be a "machine" address incorporating a login name and physical machine, such as "MRC@SU-SCORE". CMU TOPS-10 has particularly nasty usernames; I'm MC0R@CMU-CS-A but anybody seriously sending mail to me there would use "Mark.Crispin@CMU-CS-A". -------  Date: 8 Feb 1984 09:20-EST Sender: MOOERS@BBNA Subject: Re: "Return-Path" vs. "From" From: MOOERS@BBNA To: MRC@SU-SCORE Cc: header-people@MIT-MC, cic@CSNET-CIC, Mooers@BBNA Message-ID: <[BBNA] 8-Feb-84 09:20:34.MOOERS> In-Reply-To: The message of Tue 7 Feb 84 12:29:30-PST from Mark Crispin From: Mark Crispin ... It isn't totally unreasonable for the From or Reply fields to be a "meaningful" address, such as "Mark.Crispin@Stanford" (which we fully intend to support in the near future) ... -------------------- How soon do you expect to support such an address? Is this "institutional" host-alias name, "Stanford", likely to become a sub-domain in a reasonable length of time? How many other institutions have, or are planning, the same kind of host-aliases? (We have two at BBN -- BBN, for the TENEX/TOPS-20 hosts and BBN-UNIX. There is also "OFFICE" at TYMSHARE.) ---Charlotte  Date: Wed 8 Feb 84 22:00:30-PST From: Mark Crispin Subject: Re: "Return-Path" vs. "From" To: MOOERS@BBNA.ARPA cc: header-people@MIT-MC.ARPA, cic@CSNET-CIC.ARPA In-Reply-To: Message from "MOOERS@BBNA" of Wed 8 Feb 84 06:20:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It's our intention to have a single contact point for mail directed to all individuals at Stanford. It'll probably be a dedicated VAX. I'm not sure how it will come about yet; probably it will start as a host named "STANFORD" and eventually it'll be a sub-domain. -------  Received: by YALE-BULLDOG via CHAOS; Thu, 9 Feb 84 10:28:37 EST Received: from YALE-RING by YALE-RES via CHAOS; Thu, 9 Feb 84 10:25:59 EST Subject: Re: "Return-Path" vs. "From" Date: Thu, 9 Feb 84 10:26:04 EST From: Nathaniel Mishkin To: Mark Crispin cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA In-Reply-To: Mark Crispin , Tue 7 Feb 84 12:29:30-PST It isn't totally unreasonable for the From or Reply fields to be a "meaningful" address, such as "Mark.Crispin@Stanford" (which we fully intend to support in the near future) while the "Return-Path" would be a "machine" address incorporating a login name and physical machine, such as "MRC@SU-SCORE". I completely agree with the goal of using "logical" names. However, this doesn't make a virtue out of the strangeness of the "Return-Path". If you want the functionality you say (i.e. that the recipient can see both the user ID and the logical name of the sender), it seems like you should use a "Sender" line and not rely on the behavior of the "Return-Path" (whose contents are presumably not under the control of the person/mailsystem that decides that presenting both the user ID and the logical name is a good idea).  Date: Thu 9 Feb 84 11:51:55-PST From: Mark Crispin Subject: Re: "Return-Path" vs. "From" To: Mishkin@YALE.ARPA cc: header-people@MIT-MC.ARPA, Ellis@YALE.ARPA In-Reply-To: Message from "Nathaniel Mishkin " of Thu 9 Feb 84 07:30:50-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Your message implies that for some reason you actually care what is in the Return-Path header line. You shouldn't. I can put whatever I damn well please in there. If it pleases me to put in the physical login-id/host-name in there, that's my business not yours. Any presumption on your part that there is any relation between the Return-Path and any other header line (including Sender!) is faulty. It can also be argued that your mail reader is faulty for even presenting the Return-Path information to the user. Return-Path is in the header only to assist mail transports which don't have the concept of out-of-band envelopes. Since you're on ARPANET, it's irrelevant. -------  Received: by YALE-BULLDOG via CHAOS; Thu, 9 Feb 84 15:15:29 EST Date: Thu, 9 Feb 84 15:16:25 EST From: John R Ellis Subject: Re: "Return-Path" vs. "From" To: Mark Crispin Cc: Mishkin@YALE.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Mark Crispin , Thu 9 Feb 84 11:51:55-PST It can also be argued that your mail reader is faulty for even presenting the Return-Path information to the user. Return-Path is in the header only to assist mail transports which don't have the concept of out-of-band envelopes. Since you're on ARPANET, it's irrelevant. If only it were irrelevant. Unfortunately, we get a fair amount of mail forwarded from other APRANET hosts (maybe a few messages a week) in which the From address is unrepliable but for which the Return-Path is correct (or at least useable). E.g. Return-Path: From: joe blow Sometimes we get mail with no From/Sender/Reply-To at all. As long as we continue to receive mail in which the 822 text doesn't contain a correct reply address, it is necessary for users to see the STMP Return-Path so that they can attempt replies to such mail. -------  Date: Thu 9 Feb 84 12:34:40-PST From: Mark Crispin Subject: Re: "Return-Path" vs. "From" To: Ellis@YALE.ARPA cc: Mishkin@YALE.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Message from "John R Ellis " of Thu 9 Feb 84 12:17:26-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) John - Good point. However, it does not mean that it is correct for a mailsystem's Reply command to use the Return-Path. The correct behavior is to give an error message, and let the human user figure out that maybe the information in the Return-Path is useful. I am sick and tired of people claiming it should be done automatically - all that would accomplish is an ad hoc modification to the standard. That'll make the standard even more worthless than it already is. -- Mark -- -------  Received: by YALE-BULLDOG via CHAOS; Thu, 9 Feb 84 16:09:39 EST Date: Thu, 9 Feb 84 16:09:20 EST From: John R Ellis Subject: Re: "Return-Path" vs. "From" To: Mark Crispin Cc: Mishkin@YALE.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Mark Crispin , Thu 9 Feb 84 12:34:40-PST However, it does not mean that it is correct for a mailsystem's Reply command to use the Return-Path. In this discussion, no one, including Mishkin, has argued for this. -------  Date: Thu, 9 Feb 84 15:12:54 PST From: David Alpern Return-Path: Subject: Re: "Return-Path" vs. "From" To: Header-People@Mit-Mc In-Reply-To: Message of Thu, 9 Feb 84 15:16:25 EST from John R Ellis Via: IBM-SJ; 9 Feb 84 16:29-PST If only it were irrelevant. Unfortunately, we get a fair amount of mail forwarded from other APRANET hosts (maybe a few messages a week) in which the From address is unrepliable but for which the Return-Path is correct (or at least useable). Which strikes me as exactly the best reason for the Return-Path to specify a physical mailbox, rather than a logical username. This secures the same "realness" on the local part as the host name has. John, it seems you have provided the best answer yet to your and Nathanial Mishkin's original question. - Dave  Received: by RICE (AA11064); Fri, 10 Feb 84 02:58:36 cst Date: Fri, 10 Feb 84 02:33:10 CST From: Scott Alexander Subject: Re: "Return-Path" vs. "From" To: Header-People@Mit-Mc Message-Id: <301.salex.dione@rice> In-Reply-To: a message from David Alpern dated Thu, 9 Feb 84 15:12:54 PST From RFC822 Section 4.3.1 RETURN-PATH: 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. Note: The "Reply-To" field is added by the originator and serves to direct replies, whereas the "Return-Path" field is used to identify a path back to the origina- tor. While the syntax indicates that a route specification is optional, every attempt should be made to provide that infor- mation in this field. Section 4.4.3 REPLY-TO...: Note: The "Return-Path" field is added by the mail transport service, at the time of final deliver. It is intended to identify a path back to the orginator of the mes- sage. The "Reply-To" field is added by the message originator and is intended to direct replies. It would seem fairly clear that this field can have any sort of bogosity in it that the final mailer decides to put into it to give a "definitive" information. It would seem equally clear that there is NO mention here of to what use return-path is to be put. In Section 6.2.2, it does state that return-path may be useful for finding out the proper place to reply to if a message has crossed domain barriers without proper expansion of addresses. Scott Alexander Rice University salex@rice lbl-csam!rice!salex  Date: Fri, 10 Feb 84 09:45 EST From: "Jeffrey I. Schiller" Subject: Re: "Return-Path" vs. "From" To: Header-People@MIT-MC.ARPA cc: Rudy.Nedved@CMU-CS-A.ARPA In-Reply-To: Message of 7 Feb 84 00:49 EST from "Rudy.Nedved at CMU-CS-A" Message-ID: <840210144557.064505@MIT-MULTICS.ARPA> Why is there a problem here? Answer: We don't yet have DOMAINS. It would be pretty clear to me that you have to use the "From" field when replying to mail, however there is one major problem, namely the host in the "From" field may not be in your local system's host table. This can happen due to a number of reasons (non-Internet hosts, slow updating of the NIC host table, slow updating of the local host table). When faced with this situation what I personally do is look at the "Return-Path" and try sending a reply back thataway. It is the best that I can do under the circumstances. Imagine the Internet that didn't have a gateway table, but every datagram had a source route. The same heuristic would begin to develope in people's Internet implementation (and in fac the Multics Internet implementation will soon have this feature, namely the use of the source route in incoming datagrams if no better way can be used to determine where to send a datagram). If DOMAINS worked, then when faced with an unknown host in a "from" field users/host software would have an alternative to peeking at the "Return-path" field, namely querying the appropriate DOMAIN's name server. -Jeff  Date: Sat, 11 Feb 84 13:41 EST From: "Benson I. Margulies" Subject: return-path versus reply-to/from To: header-people@MIT-MC.ARPA Message-ID: <840211184108.489092@MIT-MULTICS.ARPA> How about the following observation: Reply-to and From are what gets filled in when the sender fo the mail indicates where replies are to go. They are most likely the addresses relative to the sending host. Rather than assume a bunch of clutter of the form of changing the reply-to and from fields as messages pass through various domains, why not perserve them as is? If a replying host does not understand a name in a from or reply to, she can always send it back along the return path, and assume that the originating host will be willing to send it along. After all, most froms and return-tos are the user that sent the mail, and them that ain't are usually (though not always) at the same host. This should make the uucp-jockeys happy, since the return path is the only way to find an arbitrarily hidden uucp host. On the internet, return paths are generally trivial. IP gateways do not play with mail headers. Only mail gateways do. Generally, then, an IP host would want to use the "send it back down the return path" trich whenver the name in the from/reply-to could not be resolved via whatever domain name scheme we have going. Remember, the mail-catanet has ALWAYS been much larger than the ARPA/IP-datagram-catanet. The Domain scheme does not claim to cover the entire mail-catanet, just deal much better with the IP-catanet (and possibly some other parts of the world). I guess I could summarize my position by: Return paths are concerned with hosts and gateways, NOT users. The user to be replied to should always be a part of the from/reply-to address. The Return-path is available to aid a mail agent in responding to mail that does not come from its host-name universe.  Date: 11 Feb 84 15:24 EST From: Stephen Tihor To: header-people@MIT-MC.ARPA Subject: return-path versus repl-to/from Message-ID: <4254996F.012E0021.1984@CMCL1.NYU-CMCL1.ARPA> I have been following this discussion with some interest and while I personally am an advocate having the domain-catenet over the mail-catenet (even if much of this is implemented by mail-gateways that convert 822 letters into uucp/NBS/DEC mail/arbitrary local mail system protocol letters) I am surprised that no one mentions the scheme that the NYU mailer uses to make a stab at replying to message which arrive on an 822 mail path with a bad "reply address" ( by which I mean whichever header [from, reply-to, etc.] applies under 822 for a letter with that combination of headers). It then looks at the RETURN-PATH and makes the assumption that the "reply address" is some address in a local non-internet but in.ternet-like domain, and replaces the final mail box in the Return-Path, which as people have pointed out COULD be anything from the bit bucket to the mail system maintainer, with the "reply address" to produce a <@X,@Y,@Z:reply address> source routing path. Shudder, but this seems to have handled a few strange cases we got from "alternet" internets early in RFC822's reign. -------  Date: Sat 11 Feb 84 13:26:13-PST From: Mark Crispin Subject: return path To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Once upon a time, there was From. Then came Reply, which parsed From to send an answer back. And the world saw that it was good. But then it was seen that it needed to be possible to reply to a different address than the From, and that people with secretaries may have their secretaries do the actual sending. So Sender and Reply-To were invented. And the world saw that it was complicated. Then came the realization that it wasn't always clear where to send error reports to, and that the Sender was not always the right place. So Return-Path came into being. And the world became hopelessly confused. Whither now, SMTP? I must say, everything up to now has seemed necessary to add necessary functionality to Internet mail. But I fail to see why Internet mail must be made unimplementable to support non-Internet mail. It seems to me that the non-Internet networks should conform to Internet mailing conventions and not the other way around. The right fix is to remove "From", "Sender", and "Reply-To" from the message header and put it in the envelope. -------  Date: Sat, 11 Feb 84 19:18 EST From: "Jeffrey I. Schiller" Subject: Re: return path To: Mark Crispin cc: Header-People@MIT-MC.ARPA In-Reply-To: Message of 11 Feb 84 16:26 EST from "Mark Crispin" Message-ID: <840212001844.303119@MIT-MULTICS.ARPA> Now now, Mark, network chauvinism is not the answer. Maybe the Internet should be forced to adopt uucp style mail names, they certainly work better given that they sort of work in a non-host-table environment. And although the Internet does have a host table, it doesn't tend to be very accurate. You also left out in your "history of mail" the fact that in the beginning there were very few hosts, and they were connected to the relatively homogeneous ArapNet. Today things are more complicated simply because there is more out there to talk to, and not all of it connected together in an ideal fashion (1200 or 300 baud phone lines on UUCP networks). -Jeff  Date: Sun 12 Feb 84 19:02:36-PST From: Mark Crispin Subject: Re: return path To: Schiller@MIT-MULTICS.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from ""Jeffrey I. Schiller" " of Sat 11 Feb 84 16:24:17-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Network chauvinism has nothing to do with it. We ARE supposed to get Internet mail - domains and all - working. This includes the migration to a world where a monolithic Internet host table no longer exists: a world of name servers. It seems awfully presumptious for individuals in other worlds to dictate to us what Internet standards or implementations should look like, especially when accompanied with vieled (sometimes no so vieled) threats that if we don't do as they please, "the world will pass [us] by." It is my contention that nobody has the complete understanding, much less a monopoly on such understanding, what a "WorldNet" of electronic mail will look like. I think we (the Internet community) try. We try to understand, and we try to strike a balance between global connectivity and a set of de facto "non-standards" which are difficult if not impossible to document, much less implement. There's nothing wonderful about UUCP "!" syntax. It does pretty much the same thing as "." with MMDF or "%" with TOPS-20 and other systems. UUCP just replaces the "@" as well and has the names in reverse order. I thought we were above talking about trite syntax details anyway. -------  Date: Mon, 13 Feb 84 15:22 EST From: "Benson I. Margulies" Subject: header reply fields To: header-people@MIT-MC.ARPA Message-ID: <840213202228.415255@CISL-SERVICE-MULTICS.ARPA> Mark, I think you berate the UUCP dept. without good reason. There are implementation reasons why participation in the domain mail system may be impractical for many itty-bitty hosts. That protocol is HAIR. It requires a database, someplace, to list everyone. (That it, everyone has to be in one or another domain database RR record). It seems to me that if there is a simple, clear, set of header fields (envelope, message, or stamp) that allow non-IP-universe mail players to function well, then we should go for it. If return-path was invented for error replies, then I humbly suggest that it was misnamed. Call that field "error-reply-to" or "responable-mailer-maintainer". Use return-path as I and the person from NY described -- as a hop-hop description to be used when the from/reply-to information is not usuable.  Date: Mon 13 Feb 84 14:09:18-PST From: Mark Crispin Subject: Re: header reply fields To: header-people@MIT-MC.ARPA In-Reply-To: Message from ""Benson I. Margulies" " of Mon 13 Feb 84 12:41:29-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) RFC 821 and RFC 822 both define what the "return path" is quite specifically. I refuse to argue about whether or not the name is a good one; I personally detest "resent-from". However, this shouldn't matter. As several people repeatedly point out, what is in the header isn't necessarily what should be presented to the user. The whole purpose of domains is to make it easier for small hosts, by providing a distributed database of host names. At no single point is "everyone" listed. Nor is it the intention of domains to have validation at the sending end. A message crossing complex domain boundaries may not have its full domain path validated until final delivery. Consider mail to MRC@Score.Stanford.ARPA - this is a fully qualified domain address (although "Mark Crispin"@Stanford would probably be the preferred mailing address). If the Stanford name server is down or temporarily inaccessible, there would be no way to validate the existance of Score from the sending end. That does not mean the message should be rejected. The ARPA name server should validate whether or not Stanford is a valid name. An itty-bitty host can win by passing on all host names to a more intelligent agent. For example, a very simple mailing strategy would be to send all mail to the nearest name server (or even to the root name server). In my example, the sending host could perhaps trace all the way down to Score, but it doesn't have to. It could stop at Stanford and deliver it there. It could stop at ARPA and deliver it there. Or, if it was external to ARPA, it could deliver it to some agent which is in some way closer to delivering to ARPA. The point is, you don't need to implement the full domain protocol to use domains. You merely need to know somebody who does, or rather does so more than you do. I am quite opposed to adding yet another header field to reply to. From and Reply-to are quite enough. If you want to have a reply address which is maintained by the transport mechanism, put it in the envelope (the way Return-Path is) where it belongs. -- Mark -- -------  Date: Mon, 13 Feb 84 18:41 EST From: "Benson I. Margulies" Subject: return path etc. To: header-people@MIT-MC.ARPA Message-ID: <840213234100.476146@CISL-SERVICE-MULTICS.ARPA> What does envelope-ness have to do with this? A PC with a single 300 baud modem is not going to be pleased to have to go calling up name servers for each address it wants to send mail to. Period. I just checked, and the Multics mailer in fact implements my proposed use of return-path -- as a way to send a reply back if the available name resolving services don't make it. Thus there seems to be a non-problem here. The envelope contains return-path, which is one way to get back to the source host of the mail. All that I (and some others, it seems) are asking is for the RFC's to say explicitly that if a host puts some other hostname in a from or reply-to field, that it better be prepared to act as a mail gateway to that host. Return-path is already defined as the path back to the source, so no change in its definition is needed. From/Reply to should have a user name and a host, and trust to the domain services and the return path to allow mail agentas to reply. A mail agent that really wants to be verbose could show the user the return path, but probably don't want to. The issue of "what mailbox at the source host to send errors to" as opposed to "how did this mail get here" seems to deserve a seperate field, probably in the envelope. The name return-path certainly suggests my interpretation.  Date: 13 Feb 84 19:46 EST From: Stephen Tihor To: Margulies@CISL-SERVICE-MULTICS.ARPA Subject: RE: return path etc. Cc: header-people@MIT-MC.ARPA Message-ID: <446C83C0.000E0021.1984@CMCL1.NYU-CMCL1.ARPA> In-Reply-To: <840213234100.476146@CISL-SERVICE-MULTICS.ARPA> ; Message of 13-FEB-1984 19:02 from "Benson I. Margulies" To: header-people@MIT-MC.ARPA In-Reply-To: Mark Crispin , Mon 13 Feb 84 14:09:18-PST The point is, you don't need to implement the full domain protocol to use domains. You merely need to know somebody who does, or rather does so more than you do. Amazingly enough, there is already a model for this kind of service. It is called the U.S. Postal Service. It seems to work tolerably well (and presumably better than a scheme in which I have to know the name and route of every mailman from here to California). I am quite concerned by the prospect of the non-Internet world and the Internet world having a large enough "paradigm split" so as to preclude anything better than almost completely awful solutions to the mail delivery problem. The microworld has to get away from explicit routing and the Internet world has to get away from the notion that everyone can always connect to (almost) anyone else. A fleshed out notion of a delivery hierarchy (where to send mail to when I can't understand the address) and its relationship (if any) to a naming hierarchy seems like a good idea: it would tend to engage both the "microworld" and the Internet world in a mutually beneficial discussion. The problem with a delivery hierarchy is that some machines have to be willing to do work for others. Who pays and how? Which will come first: our solution to these problems or AT&T's (or the USPS's or whoever's)? Do we care? Sorry if this is too much "Worldnetbabble". I just find the prospect of all the good work and thought about mail going down the tubes to be depressing. -- Nat  Date: Mon 13 Feb 84 23:51:34-EST From: Greg Skinner Subject: Re: header reply fields To: Margulies@CISL-SERVICE-MULTICS.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from ""Benson I. Margulies" " of Mon 13 Feb 84 16:32:16-EST I noticed in the conversion tables for domain-style to Arpa-style host identifications a number of conventions for an MIT Chaos host to be converted to an ARPA-style looking host. For example, if I sent a message to you from MIT-OZ (the mailsystem where I saw this), I'd be creating an MIT Chaos From: address that looked like: From: GDS@MIT-OZ.#Chaos whereas when it actually leaves the Chaosnet to the ARPANet it is transformed to From: GDS%MIT-OZ@MIT-MC.ARPA Wouldn't it be feasible for non-Internet hosts to do some sort of conversion from non-Internet to Internet syntax as they cross their mail gateways into the Internet? -------  From: vortex!lauren at RAND-UNIX Date: Mon, 13-Feb-84 18:54:49-PST Sender: Lauren Weinstein Subject: return paths and small machines Message-ID: <8402131854.9111.0.VT2.2@vortex.UUCP> To: header-people@MIT-MC I hate to tell you this friends, but within the next few months I'm going to let my MSDOS UUCP and related mail programs out of the bag, and indications are strong that there could be MANY, MANY machines running this code very quickly. The decisions I make RIGHT NOW regarding domain handling and the like will probably affect more machines than everything else put together for quite some time. I feel VERY strongly that absolute routing must always be available when DESIRED or MOST ECONOMICAL/FASTEST -- not just in "emergencies". Masses of little machines trying to concentrate mail into a relatively few "smart" gateway hosts would quickly swamp those systems and also result in much longer mail delivery times in many cases. These systems will have a very limited ability to hold large (or even small) databases, but will NOT be willing to forward all their mail through inefficient paths just for the sake of naming, especially in those cases where many fast direct or semi-direct routes are available (very often the case with UUCP routings). Once these programs are out the door, I have no way to force everyone to get updates later -- so before long there could be many 1000's of these things floating around that will depend on absolute routing for many situations and have only limited (or no) domain knowledge. You can try ignore them if you wish, but judging from the organizations that are screaming at me to release these programs, many of you will end up ignoring yourselves! Let's try for a compromise. I can't hold this stuff back much longer, and any decisions must be made right now or it'll be too late as far as the 10's of 1000's of smaller machines are concerned. --Lauren--  Date: 13-Feb-84 22:27 PST From: Rich Zellich Subject: Re: return paths and small machines To: header-people@MIT-MC Message-ID: <[OFFICE-3]GVT-RICH-442TE> In-reply-to: <8402131854.9111.0.VT2.2@vortex.UUCP> As far as I can see, there is no reason to try to stamp out uucp "routing" addresses, because to the non-uucp Internet, one of those long strings with all the !s in it is just a mailbox name at some host in some domain. As long as that host can recognize that it is receiving a uucp route/address and can appropriately route it via uucp instead of Internet SMTP or whatever, who cares? (At least as long as messages coming OUT of the uucp context get properly transformed so the DCA-specification Internet programs can understand the return addresses.) -Rich Zellich  Date: Tue, 14 Feb 84 10:26 EST From: "Benson I. Margulies" Subject: lauren's manifesto To: header-people@MIT-MC.ARPA Message-ID: <840214152600.810167@CISL-SERVICE-MULTICS.ARPA> Lauren -- I may be confused --- Could UUCP do all its !'ing in the return path instead of the From/Reply-to/To field? That way, any individual little beastie that could be found via the domain system would be, but the little beasties and the big beasties could still communicate via the complete route in the return path. I.E., move the path information to the envelope.  Received: by YALE-BULLDOG via CHAOS; Tue, 14 Feb 84 16:40:04 EST Received: from YALE-RING by YALE-RES via CHAOS; Tue, 14 Feb 84 16:40:18 EST Subject: Re: return paths and small machines Date: Tue, 14 Feb 84 16:40:21 EST From: Nathaniel Mishkin To: vortex!lauren@RAND-UNIX.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: vortex!lauren at RAND-UNIX, Mon, 13-Feb-84 18:54:49-PST I hate to tell you this friends, but within the next few months I'm going to let my MSDOS UUCP and related mail programs out of the bag, and indications are strong that there could be MANY, MANY machines running this code very quickly. The decisions I make RIGHT NOW regarding domain handling and the like will probably affect more machines than everything else put together for quite some time. I feel VERY strongly that absolute routing must always be available when DESIRED or MOST ECONOMICAL/FASTEST -- not just in "emergencies". ... I'm glad that you're worried about the issues. The problem I have with UUCP is not so much that absolute routing is evil, but that everything in the present UUCP systems I've seen seems so ad hoc. Ad hoc names, ad hoc routing, ad hoc "parsers". I think the most important aspect of any mail system that is distributed to the masses is that it doesn't forclose future possibilities. If your version handles names up to only 10 characters, that's what we'll be stuck with forever. If your version picks one of the 2 possible interpretations of "a!b!c@x" (i.e. "a!b!c" at "x", or "a!b" ! "c@x") instead of defining some reasonable syntax to determine which you mean, then we'll be stuck with that. Masses of little machines trying to concentrate mail into a relatively few "smart" gateway hosts would quickly swamp those systems and also result in much longer mail delivery times in many cases. These systems will have a very limited ability to hold large (or even small) databases, but will NOT be willing to forward all their mail through inefficient paths just for the sake of naming, especially in those cases where many fast direct or semi-direct routes are available (very often the case with UUCP routings). In the short run, this all is quite true. In the long run, clearly it can't be or the whole thing will collapse. The time will come when people will choose reliability and ease of use over direct manual routing and speed. They'll make that choice even if they have to PAY for that less speedy system. People don't (by and large) put up their own satellite dishes -- they pay a cable TV company to do it. The problem is to design the system now so that the transition to the inevitable will be as painless as possible. Perhaps it's not do-able. -- Nat  Date: 14 February 1984 18:50 est From: DBrown.TSDC at HI-MULTICS Subject: Re: Return path and small machines To: HEADER-PEOPLE at MIT-MC cc: DSullivan.CSC_SDO at HI-MULTICS, Winterton.HISCAN at HIS-PHOENIX-MULTICS, Stachour.CSCswtec at HI-MULTICS Well, it does look like something of an "envelope" issue. On one of the systems I'm familiar with there is a small host-table which takes a fully specified domain name and returns a best way to get there. Since the system in question only *has* about three ways of getting mail out, it tends to be rather trivial. The envelope gets marked "send via HI-MULTICS.ARPA" most of the time, and presumably the path it followed to get wherever it was goung reflects this, despite the fact that my real address is "Dave Brown"@CCSC-SDO.Minneapolis.Honeywell, and gets put in as "who I am". It strike me that the algorithm the oracle (which owns the host table) was published here about six months ago. By Bill Wells, maybe? In any case, it was and is a trivial name server, necessary and sufficent to get a message out on the most suitable path to a particular sub-domain. --dave DBrown.TSDC @ HI-MULTICS.ARPA watbun!drbrown @ watmath.UUCP "Dave Brown" @ CCSC-SDO.Minneapolis.Honeywell(. maybe ARPA someday)  Date: Tue 14 Feb 84 19:49:05-PST From: Mark Crispin Subject: Re: return path etc. To: Margulies@CISL-SERVICE-MULTICS.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from ""Benson I. Margulies" " of Mon 13 Feb 84 15:57:52-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) From: "Benson I. Margulies" Subject: return path etc. What does envelope-ness have to do with this? Simple. Concepts such as the "origin address", the "composer address", the "reply address", and the "return address [as distinct from reply address]" should be specified in the message envelope. At present SMTP only puts the "return address" and the "destination address" in the envelope. The Return-Path header line is generated by whatever process finally delivers the message to the destination user (often the SMTP server but not necessarily; in TOPS-20 it's the mailer), solely for the benefit of other networks which don't have envelopes and depend upon the header for everything. A PC with a single 300 baud modem is not going to be pleased to have to go calling up name servers for each address it wants to send mail to. Of course not. But it is going to have to call up somebody to start the message on its way. That somebody could also be the name server. I'd rather have my PC calling up an intelligent delivery agent that knows what I'm talking about than some stupid forwarder that insists that I tell it everything. I just checked, and the Multics mailer in fact implements my proposed use of return-path -- as a way to send a reply back if the available name resolving services don't make it. Multics is not the specification. RFC's 821 and 822 are the specification. All you've said is that the Multics mailer has a bug that some individuals perceive as a feature. Past archives of Header-People will document bugs in the TOPS-20 mailer that I would protest is a feature. The issue of "what mailbox at the source host to send errors to" as opposed to "how did this mail get here" seems to deserve a seperate field, probably in the envelope. The name return-path certainly suggests my interpretation. I'm afraid that RFC's 821 and 822 use Return-Path to mean the former. And a non-trivial amount of software on a non-trivial number of hosts implement it as this. I'll tell you what. I'll agree to lobby with you to change the meaning of Return-Path if you lobby to get the syntax of dates to not require a comma after the day or week and to require a hyphen before the time zone. It may sound silly to you, but it means a good deal to TOPS-20. Needless to say, both ideas probably would be rejected - and should be. -------  From: vortex!lauren at RAND-UNIX Date: Wed, 15-Feb-84 00:22:21-PST Sender: Lauren Weinstein Subject: manifesto Message-ID: <8402150022.11658.0.VT2.2@vortex.UUCP> To: header-people@MC No manifesto intended! I'm just desperate for a reasonable solution that will be acceptable to everyone involved. The little machines are going to (apparently) be used heavily by corporate and other large entities who will be communicating with sites scattered across the world, and will (for speed and money reasons) want to route mail via the overall "best" route, taking full advantage of the high interconnectivity of the Internet. Would you really expect someone to send their mail to a "smart" name server, perhaps knowing that the server is topologically far away from the desired destination, if the sender knows of a more or less direct route that it can use easily? I just don't think that the concentration required by the forced use of name servers is practical or desirable. You might argue that uucp sites can do what they want and should leave everyone else alone. I would claim that is impossible. There are gateways springing up everywhere, and any attempt to "control" their use would just result in more "unofficial" hacks appearing to replace them. There's going to be one hell of a lot of traffic between the uucp net and everything else! One thing about the return path -- it is useful for addressing information only as a last resort in many cases. Especially for mail routed through centralized machines, the return path may well indicate a route that is far more costly (in terms of time and money) than many other (topologically shorter) routes. This really is a desperate situation. We probably have no more than a couple of months before I'll have to start releasing the package, and my time for major code modifications at this point is quite small. Can't we come up with something that we can all live with and that has a reasonable chance of working when scaled up pretty massively? Thanks much, all. --Lauren--  Date: Wed, 15 Feb 84 09:34 EST From: "Benson I. Margulies" Subject: Definition of Return-Path To: header-people@MIT-MC.ARPA Message-ID: <840215143408.115972@CISL-SERVICE-MULTICS.ARPA> I think there is a compatable re-definition of the return path. Define the user-name/mailbox part of the return path to be, indeed, the correct destination of error messages. Not wonderful, but effective. The rest of the return path is still a way back to some host that is guaranteed to be will ing to act as a mail gateway to the host names in the from and/or reply-to fields.  Date: 15 Feb 84 1251 EST (Wednesday) From: don.provan@CMU-CS-A To: vortex!lauren@RAND-UNIX Subject: Re: manifesto CC: header-people@MIT-MC, In-Reply-To: <8402150022.11658.0.VT2.2@vortex.UUCP> Message-Id: <15Feb84.125107.DP0N@CMU-CS-A> but it's the corporations and other large entities that i would expect to go out and buy a name server/best route finder to plug into their local net. you make it sound as if they'll have to route mail through sri-nic. if a site needs effecient routing and can afford it, it should buy it. if it doesn't need it or can't afford it, it may send some mail via a non-optimal path. what's so bad about that? what is it that uucp people feel smtp is lacking? i don't see that the path back to the originator really solves any uucp problems. there no reason to think that the sending site knows any more about the best route than the replying site does. you may increase ineffeciency by encouraging software to use longer than necessary routes just because that's the way the mail came in. maybe the problem is that us arpa types (well, this arpa type, anyway) don't understand enough about how uucp works to understand the problem. there's no doubt that there are serious routing problems when each link runs at a different speed, has a different amount of traffic, and is up for different periods in a day. i don't see how making changes in the mail delivery scheme lessens those problems. no matter how many hooks you put in, SOMEBODY has to know that his link is only up for 10 minutes a week and runs at 300 baud or that this link is no longer available. your PC isn't going to. is your PC going to come up with the route, or is the user responsible for that? how did either of them discover the route. i, for one, am so baffled by these questions that i can't hope to understand what you think a mail delivery scheme can have to make these problems go away. i don't think the two sides swatting at each other is going to get us very far. maybe a few lessons will help. don  Date: 15 Feb 84 14:18 EST From: Stephen Tihor To: <@MIT-MC:vortex!lauren@RAND-UNIX> Subject: RE: manifesto Cc: header-people@MIT-MC.ARPA Message-ID: <464E7CA5.008A0022.1984@CMCL1.NYU-CMCL1.ARPA> In-Reply-To: <8402150022.11658.0.VT2.2@vortex.UUCP> ; Message of 15-FEB-1984 04:24 from vortex!lauren@RAND-UNIX I am not quite sure what the problem is, exactly. It sounds like Lauren is wants to know where in an RFC822 mail file he should put the cached routing information from the envelope of the incomming message that is being replied to. Conceptually RFC822 didn't need to include any envelope information, but a few fields were copied in simplify life for people converting 733 mailers (sort of, I guess, although I was never really clear on this even when people were discussing it.) But the envelope infomation mat need to be kept somewhere and could be used to update a reverse path routing database for UUCP style delivery agents. Such a database really doesn't take up too much room since you eliminate the path information from the message and just leave the alsolute address, the added cost should be on the close order of the size of the absolute address even in a naive implementation. Is the propblem that you want equal shot at putting stuff into the 822 mail format to make this implementation easier? Or that you don't want to added an envelope section to the users mail file? Or that you don't want to write the trivial name server to cache this infomation on the PC? {Sigh I can see it now RFC987: Trivial Name Server Implementation.} -------  Date: Wed, 15 Feb 84 12:24:27 pst To: vortex!lauren@RAND-UNIX Cc: header-people@MC Subject: Re: manifesto In-Reply-To: Your message of Wed, 15-Feb-84 00:22:21-PST. <8402150022.11658.0.VT2.2@vortex.UUCP> From: Tim Mann The idea of a domain name server is to make life easier, not harder. If you don't know how to get to some site, you can ask a name server. There is no reason not to cache knowledge of how to get to certain sites on your own machine. Roughly speaking, I think the new Internet RFC's are basically intended to formalize this notion. The major problem here is that non-Internet mailers have to worry about routing to the destination, not just addressing it. Nevertheless, I think it's possible to use the Internet scheme in a non-fully-connected network by using source routing (Internet syntax, not ...!...!...) when you know or can construct a good path to the destination, otherwise sending the mail on to a "smarter" host which runs the software to do the job. The step of constructing a route should be done by the mail software, not the user, whenever possible, using whatever information is available. One source of information could be a nearby host running a full-blown name server -- if there is no such host nearby, or it doesn't make sense to query it rather than just sending the mail to it (perhaps because the information would only be used once), the mailer would fall back on the second approach, forwarding the mail to someone smarter. I'm assuming here that there are roughtly 3 classes of machines involved -- small personal computers, which are not necessarily up all the time and don't have much disk space or processor power, but nonetheless want to participate; larger computers that are up fairly reliably, have dialins and dialouts but are not on the ARPA Internet; and Internet machines. The first class is, I think, what your software is directed toward, while the second class is the sort of machine that's on the uucp net now. --Tim  Date: Wed, 15 Feb 84 12:25:49 PST From: David Alpern Return-Path: Subject: What am I missing? (Domains vs. Return-path discussion) To: Header-People@Mit-Mc Via: IBM-SJ; 15 Feb 84 15:18-PST Ok, somewhere I missed something. I thought the idea behind domains was to make all Internet addressing absolute, and remove the need to specify routes to a host that knows of the host you really wish to address. The use of the host portion of return-path, which is frequently a non-822 compatible multiple '@' form, as a route to a gateway as something to try when all else fails seems reasonable to me only when all else fails. Where I'm lost is how the two combine. When domains happen, won't the problem of unknown hosts in a FROM go away, unless a mailer is really broken or does something weird at a gateway? I thought all FROMs, etc., were supposed to be qualified so that at least the domain specified would be known to all recipients.  From: vortex!lauren at RAND-UNIX Date: Wed, 15-Feb-84 16:30:46-PST Sender: Lauren Weinstein Subject: Re: manifesto Message-ID: <8402151630.13019.1.VT2.2@vortex.UUCP> To: mann@diablo CC: header-people@MC In-Reply-To: Your message of Wed, 15 Feb 84 12:24:27 pst I'm afraid that a lot of people are going to be using PC's as class (2) machines -- up all the time for mail and servicing a fairly large number of class (3) machines (and other class (2) machines). In any case, these PC's will all be running my software, and I doubt very much if all of the name server issues could possibly be worked out and implemented before the software hits the street. Therefore, I'm looking for a "fallback" solution that will be practical. --Lauren--  From: vortex!lauren at RAND-UNIX Date: Wed, 15-Feb-84 16:23:55-PST Sender: Lauren Weinstein Subject: uucp Message-ID: <8402151623.13001.1.VT2.2@vortex.UUCP> To: don.provan@CMU-CS-A CC: header-people@MC In-Reply-To: Your message of 15 Feb 84 1251 EST (Wednesday) The issues are complex. I'm not sure that this is the right place for a uucp tutorial, even if I had the time to write one at this point. There is plenty of arguing going on over on uucp as well about handling growth WITHIN the uucp network itself. A couple of points though. First of all, your expectation that large entities will make the investment in name servers and such assumes more organization that these people usually have in this area. They just want to get a WHOLE BUNCH of PC's talking to each other and the Internet as quickly as possible. Maybe someday they'll want to make bigger investments in more sophisticated hardware/software, but for now they want quick and easy access to the nets. Anything more than that requires bigger initial investments and is harder for them to justify since they want to "build up" to a big operation after a period of time. My point is that the software I give them NOW for their immediate needs is going to probably be running for a long time, so I want to make sure that it's as reasonable as possible. Your model of 300 baud systems only up 10 minutes a day is inaccurate. Most systems run at 1200 baud and will be up 24 hours a day in some mode or another. Some PC's will be mail-only machines of a sort for local areas and will do nothing else. But they STILL will have limited capabilities compared with a 780 running sendmail. This does NOT mean that they might not be in contact with dozens of major hosts via dialed-in or dialed-out calls, and have access to a vast number of direct and indirect routing choices, that could allow speedy mail delivery. Given that some uucp sites only talk to each other once a day, knowing the most direct path to a site can make the difference between getting a message through in 24 hours vs. getting it through in a week. The degree of centralization encouraged by the name server sort of scenario would tend to add more hops to the average message, and could slow delivery to an extent as to make it pretty much useless. By the way, are we sure that we're arguing about the same thing? --Lauren--  Date: Wed, 15 Feb 84 20:46 EST From: "Benson I. Margulies" Subject: Alpern's and Lauren's last notes To: header-people@MIT-MC.ARPA Message-ID: <840216014632.516417@CISL-SERVICE-MULTICS.ARPA> It is not clear that we are arguing about the same thing. Try these cases: 1) PC originating new mail to host, someplace. Lauren, now do you imagine that it figures out how to send it? Does the user inform the program? 2) PC replying to mail that came it. I don't see why the return-path should be so substantially non-optimal. Or these questions: Do UUCP hosts (PC's expecially) typically store a bunch of !-ity-! routes to popular destinations, so the user don't have to type them? Where do they keep this database?  Date: Wed, 15 Feb 84 20:47 EST From: "Benson I. Margulies" Subject: envelopes versus messages To: header-people@MIT-MC.ARPA Message-ID: <840216014745.993851@CISL-SERVICE-MULTICS.ARPA> It seems to me that some of the cross purposes of this discussion relate to the role of envelopes. I always have assumed that the content of the envelope is available to the mail agent (mail reading program, if you like) of the recipient. Am I out-to-lunch on that?  Date: 16 Feb 84 0021 EST (Thursday) From: don.provan@CMU-CS-A To: vortex!lauren@RAND-UNIX Subject: Re: uucp CC: header-people@MIT-MC In-Reply-To: <8402151623.13001.1.VT2.2@vortex.UUCP> Message-Id: <16Feb84.002138.DP0N@CMU-CS-A> i guess that's my problem: i don't really understand what we're arguing about, and it feels like i'm not the only arpa type that doesn't. i thought your point was that return-path needs to get messages back to the originator for uucp type network. am i crossing arguments?  Date: 16 Feb 1984 1228-EST From: John R. Covert To: namedroppers at SRI-NIC, header-people at MIT-MC ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" Subject: Addressing in international environments Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11992230303.17.132.27001 at DEC-MARLBORO> Unfortunately, due to CCITT recommendations dealing with carrying traffic for "others," top-level domains do not provide enough information to route messages in the international environment (or even the national environment within some countries). For example, let's assume that someone at UCL-CS.ARPA wants to send a message to a user on ZAPHOD.DIGITAL (assuming the top-level domain DIGITAL is established). If UCL-CS believes that the correct method for sending to domain DIGITAL is to establish a PSS call to a DIGITAL host which is located in the U.K. and is capable of accepting mail, everything is ok in this case, since ZAPHOD is located in Reading, Berks. If the same person also wants to send to someone at VORTEX.DIGITAL, located in Nashua, New Hampshire, the same route may or may not be legal, depending on British regulations. It may also be permitted to send the message via the ARPAnet to a gateway in the U.S. However, if the same person at UCL wants to send to a user on MUN02.DIGITAL, neither of the above routes are permitted. The UCL sender must send to MUN02 directly (or at least to a host located in the same building as MUN02); since Germany strictly interprets the CCITT reccomendations prohibiting the use of private data networks for carrying traffic to or from an outside entity. This could be interpreted as requiring top-level domains to not extend past the boundaries recognized by PTTs. The extent of a top-level domain would vary from country to country. In the U.S., DIGITAL-US could cover the whole country. In Germany, a domain would have to be established for each separate piece of property. If MUN02 is not to be further qualified than with the domain DIGITAL, then UCL-CS (or any other mail originator, e.g. a CSNET host, a PC running Lauren's UUCP software) has to be able to do one of the following: 1. Contact a name server to find out the correct gateway to use to reach MUN02.DIGITAL. or 2. Require (or allow) the user to specify an explicit path. The restrictions placed on interconnection of public and private networks in some countries may seem bizarre to those of us in the U.S., but they are based upon CCITT recommendations. Though we can take the attitude that "these countries will suffer the economic consequences of restrictive regulations as businesses relocate to other countries" this attitude is not conducive to the success of electronic mail. --------  Date: 16 Feb 1984 13:26-EST Sender: DDEUTSCH@BBNA Subject: Re: Addressing in international environments From: DDEUTSCH@BBNA To: decwrl!rhea!castor!covert@SHASTA, RSX-DEV@DEC-MARLBORO(Attn: Covert) Cc: namedroppers@SRI-NIC, header-people@MIT-MC, DDeutsch@BBNA Message-ID: <[BBNA]16-Feb-84 13:26:04.DDEUTSCH> In-Reply-To: <"MS10(2124)+GLXLIB1(1136)" 11992230303.17.132.27001 at DEC-MARLBORO> To which CCITT recommendations do you refer? Normally CCITT recommendations are not concerned with the operation of private networks, though they do regulate the connection of private networks to public networks. As you noted, individual countries take differing approaches towards internal telecommunications regulations. Also, the draft CCITT recommendations on message handling systems (the X.400 series) put countries at the top level of the addressing hierarchy. The draft recommendations do not constrain the routing of messages between countries. They do say, however, that a private management domain (i.e. a message-relaying system, possibly spanning many nodes, controlled by a private organization) cannot be used to link two public management domains. This is regardless of whether the private management domain is built upon a public or private data network. Your message raises some deeper questions. Given a hierarchical naming/addressing scheme, how closely should that scheme follow the network architecture? Should it always be possible to directly derive the route from the name? It is my contention that no matter how arbitrarily telecommunications regulations may interfere with routing, naming should be sufficiently orthogonal to routing in order to allow a reasonable naming hierarchy (i.e. DIGITAL-GERMANY, or even DIGITAL-WORLD). Debbie Deutsch  Date: 16 Feb 1984 12:57 MST (Thu) Message-ID: From: "Frank J. Wancho" To: Header-People@MC Subject: Does Guinness accept these? Return-Path: <@COLUMBIA-20.ARPA:pourne@Mit-Mc.ARPA> Received: from COLUMBIA-20.ARPA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 12:42:34-MST Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Thu 16 Feb 84 13:20:25-EST Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 16 Feb 84 18:16 GMT Via: UCL-CS; Date: Wednesday, 15-Feb-84 16:28:40-GMT Received: from Usc-Isid by 44d.Ucl-Cs.AC.UK via Satnet with SMTP; 15 Feb 84 13:17 GMT Received: FROM MIT-MC BY USC-ISID.ARPA WITH TCP ; 15 Feb 84 01:04:49 PST Date: 15 February 1984 04:06 EST From: "Jerry E. Pournelle" Subject: Let's spread the good news! To: Per_Lindberg_QZ , KERMIT_implementation_and_experience cc: info-kermit In-reply-to: Msg of 13 Feb 84 13:29 +0100 from Per_Lindberg_QZ%qzcom at ucl-cs.arpa Sender: POURNE what's that supposed to mean? I do not know anything about KERMIT either. How should I? There have been drearily long expositions on the net at 300 baud; I have yet to see anything in print or in my mail. If Kermit is available for any machine I know of, I'd like to see it run. can it work on a Compupro? Z-80 or Dual Processor? Ot what does it take to make it run? Is there a way I can get a copy mailed to J E Pournelle BYTe POB 372 Hancock NH 03449 Or at least some description of what it is? Date: 13 Feb 84 13:29 +0100 From: Per_Lindberg_QZ%qzcom at ucl-cs.arpa Reply-To: Per_Lindberg_QZ%qzcom at ucl-cs.arpa, KERMIT_implementation_and_experience%qzcom at ucl-cs.arpa To: KERMIT_implementation_and_experience%qzcom at ucl-cs.arpa, info-kermit Re: Let's spread the good news! Remailed-From: Billy Remailed-To: pourne@MIT-MC It seems to me that there is a lot of people with personal computers Out There who has never heard of KERMIT, and probably would be very happy to. And I think KERMIT deserves more publicity. So, who writes an article in BYTE? - Per Lindberg, QZ - (Text 41569)------------------------------  Date: Thu, 16 Feb 84 16:14:46 est From: Mark Shoemaker Message-Id: <8402162114.AA17984@mordred.ARPA> Received: by mordred.ARPA; Thu, 16 Feb 84 16:14:46 est To: header-people@mit-mc.ARPA Subject: PC node names Cc: vortex!lauren@rand-unix.ARPA When the hords of PC's (that Lauren will be providing software for) come on-line, how will they be addressed? Perhaps I'm paranoid, but as the UUCP network has been having site (node?) name conflict problems for some time now, what's going to happen when Lauren's (or someone else's) clever comm. software is made available and everyone with a moderately powerful micro wants to be networked? So far, the discussion has concerned reasonable ways for them to send mail (or whatever) out to the rest of the world; how will the inverse work? shoe  Date: Thu, 16 Feb 84 13:40 EST From: Barry Margolin Subject: Re: Addressing in international environments To: Charles Hedrick cc: RSX-DEV@DEC-MARLBORO.ARPA, namedroppers@SRI-NIC.ARPA, header-people@MIT-MC.ARPA In-Reply-To: Message of 16 Feb 84 13:16 EST from "Charles Hedrick" Message-ID: <840216184025.532046@MIT-MULTICS.ARPA> From: Charles Hedrick The only regulations that would make Arpanet domains illegal would be a regulation that prevents DEC from having a single nameserver that gives out routings to all of its machines. Surely even Europe won't do that. Even that isn't a real problem, as a domain may have more than one name server. Indeed, for purposes of reliability and reduction of network congestion, large domains SHOULD have more than one. barmar  Date: 16 Feb 1984 14:04-PST Sender: GEOFF@SRI-CSL Subject: glop. From: the tty of Geoffrey S. Goodfellow To: Header-People@MC Message-ID: <[SRI-CSL]16-Feb-84 14:04:44.GEOFF> I've seen a lot of these type of addresses recently. Dose anyone have any ideas where they come from and what they mean? In the egregious case (below) I have no idea where the username ends and the host address begins! What would someone do if they needed to reply to this person? P.S. What about all this "(Text 41915)-------------------------......" bad breath we are starting to see at the end of messages emitting from Xerox recently? It looks like header field pollution has become contagious, moved down and invaded the message body. Received: from SU-SCORE by SRI-CSL via DDN; 16 Feb 84 13:47:37-PST from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Feb 84 13:10:42-PST from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2623256738786884@MIT-MULTICS.ARPA>; 16 Feb 1984 13:25:38 est Date: 15 Feb 84 01:46 +0100 From: KPJ_Jaakkola_QZ@QZCOM Subject: interrupt at 20? To: TOPS-10/20_SIG@QZCOM Cc: tops-20 In-Reply-To: <41882@QZCOM> Top fork stops at address 20, either due to a HALTF% or an error. Job lacks privileges, monitor Mini-EXEC (MEXEC) displays the message, and logs out the job. (Text 41915)------------------------------ -------  Date: Thu, 16 Feb 84 18:23 EST From: "Benson I. Margulies" Subject: Is someone trying to prove a point? To: header-people@MIT-MC.ARPA Message-ID: <840216232352.436538@CISL-SERVICE-MULTICS.ARPA> I have gotten several messages from person_%_arpa.Mit-Xx.ARPA%yorkcom at UCL-CS that were copies of mail sent to header people. Now, that set of % will produce a pretty indirect route to begin with. But worse yet, the mail from me seems to be sent from UCL-CS to something.UK over SATNET! Is this an exercise in pessimal routing of mail? A demonstration of the return-path problem? ???  From: DonWinter.pasa@PARC-MAXC.ARPA Date: 16 Feb 84 16:02:48 PST Subject: Re: glop. In-reply-to: GEOFF@SRI-CSL.ARPA's message of 16 Feb 84 14:04 PST, <[SRI-CSL]16-Feb-84 14:04:44.GEOFF> To: GEOFF@SRI-CSL.ARPA cc: Header-People@MC.ARPA Just exactly what leads you to associate the (Text 41915) tag with XEROX? The message you forwarded did not emanate from within Xerox. Does THIS message have such a tag on it? (I will see when it gets back to me.)  Date: 16 Feb 84 1926 EST From: Rudy.Nedved@CMU-CS-A To: the tty of Geoffrey S. Goodfellow Subject: Re: glop. CC: Header-People@MIT-MC In-Reply-To: <[SRI-CSL]16-Feb-84 14:04:44.GEOFF> Message-Id: <16Feb84.192639.EN0C@CMU-CS-A> I suspect it is MAILNET software. I started seeing this stuff come out of MIT's mailnet connection a few months ago. -Rudy  Date: Thu 16 Feb 84 19:51:37-PST From: Mark Crispin Subject: Re: Is someone trying to prove a point? To: Margulies@CISL-SERVICE-MULTICS.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from ""Benson I. Margulies" " of Thu 16 Feb 84 15:44:20-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It's a great example of why domains are a good idea and why using the return-path or other relative routes is a bad idea. Domains or any other absolute addressing system would have optimized the delivery route. You can't optimize relative routes, because there is absolutely no guarantee that the FOOBAR host at one part in the route equals the FOOBAR host on some other portion of the route. -------  From: vortex!lauren at RAND-UNIX Date: Thu, 16-Feb-84 22:18:49-PST Sender: Lauren Weinstein Subject: Re: PC node names Message-ID: <8402162218.2113.1.VT2.2@vortex.UUCP> To: mas@Purdue.ARPA CC: header-people@MC In-Reply-To: Your message of Thu, 16 Feb 84 16:14:46 est Well, as a practical matter, there is no way to totally FORCE someone to not pick a name already in use. However, it is quite possible to refuse to deal with such a site -- thusly effectively isolating it from the rest of the network. As it happens, I will shortly be announcing the Global UUCP Sitename Registry, which will perform verification and basic registration of UUCP sitenames. This work will be done by myself in conjunction with other persons who are handling the nitty-gritty of maintaining UUCP map/routing databases. Hopefully this will all help keep the situation under control. It will still be tricky, however, and will have to be watched carefully... --Lauren--  Date: Fri, 17 Feb 84 11:10:03 GMT From: Steve Kille To: "Benson I. Margulies" cc: header-people@mit-mc.arpa Subject: Re: Is someone trying to prove a point? As there have been several comments on this, let me explain a little of what is going on. The critical system involved is COM, a conferencing system developed by Jacb Palme in Stockholm. There are two instantiations of this, which interact with the Arpanet: one at York, UK (yorkcom) which will send and receive using UCL as a relay; and one at QZ, Stockhom, Sweden (qzcom / oden.mailnet), which is a mailnet host using mit-multics as a relay. Both UCL and MIT use the '%' notation to hide non-arpa domains/hosts. There are some relevant points: 1) COM adds the _____(text123456) which Geoff noted. The number refers to the COM entry. 2) COM usernames have spaces. Palme found that simply quoting these caused a lot of problems with many Arpa sites (!!). Thus he chose to map spaces into underscores. Unfortuantely, the software is not perfect, and often lexical separators, as well as spaces embedded in usernames get mapped. This may be fixed at qz, but certainly not at york. 3) When generating reply addresses, the full trace information associated with the message is used to generate a humongous source route (which will get worse when a message is repeatedly answered). Attempts are then made to eliminate redundant components. (As can be seen from the phrasing of this, I believe it to be an inappropriate approach). 4) There is a bug/configuration problem at Yrokcom, which can cause cause strange messages to be sent to an address approximately relating to recipients in the message to: list. If this is not fixed soon, the York header-people entry will be removed from the UCL list expansion. Steve  Date: Fri, 17 Feb 84 08:34 EST From: "Benson I. Margulies" Subject: Re: Is someone trying to prove a point? Reply-To: header-people@MIT-MC.ARPA To: header-people@MIT-MC.ARPA In-Reply-To: Message of 16 Feb 84 22:51 EST from "Mark Crispin" Message-ID: <840217133410.140836@CISL-SERVICE-MULTICS.ARPA> Mark, I agree. What I am still perplexed about is (1) why all that crap couldn't continue to stick around, quietly, in the envelope (and in a much more compact form) (2) if its in the envelope, why it is evil for not-very-clever hosts to use it if they are unwilling or unable to do better. --benson  Date: 16 February 1984 17:01 est From: DBrown.TSDC at HI-MULTICS Subject: Re: Addressing in international environments To: John R. Covert cc: Header-People at MIT-MC, namedroppers at SRI-NIC In-Reply-To: Message of 16 February 1984 12:28 est from John R. Covert With respect, I disagree. My understanding of the domain/nameserver scheme is that Vortex's machine sends to a machine which knows about the domain "DEC", (hopefully almost anyone), and that machine, if it does not *itself* know how to reach the DEC net, passes it on to a host which it has listed in its' local name server as accepting responsability for mail to all of DECNET. That machine, presumably a DEC mail gateway, then has the responsability of forwarding (or refusing) the mail to the proper site in the proper country, obeying all the trans-border data-flow regulations then in force. So Lauren's machine (and my baby bun) need not know any explicit paths or mailing heuristics because of the "domain of responsability" design of the ARPA Internet. --dave (why should *i* understand DECNET?) brown  Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA06274; Thu, 16 Feb 84 17:04:50 pst Received: by ucbarpa.ARPA (4.22/4.22) id AA05640; Thu, 16 Feb 84 17:05:25 pst From: eric%ucbarpa@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 16 Feb 1984 1705-PST (Thursday) Message-Id: <5638.31.445827921@ucbarpa> To: Christopher A Kent Cc: header-people@MIT-MC.ARPA Subject: Re: "Return-Path" vs. "From" In-Reply-To: Your message of 7 Feb 1984 0806-EST (Tuesday). <8402071306.AA15144@merlin.ARPA> Fcc: mail Gosh Chris, I'm awfully sorry that I have tried to do the right thing instead of perpetuating the insanity that has characterized (and sadly, continues to characterize) the UNIX mail system. Sendmail passes the information it gets from the received envelope into the transmitted envelope. If the mailer is a program rather than an SMTP channel, the "envelope" consists of the command line arguments. The version of Mail that comes with sendmail works, as does MH. This seems to cover 90% of the 4.2 users. eric  Received: from EDUCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2623342751739532@MIT-MULTICS.ARPA>; 17 Feb 1984 13:19:11 est Date: 17-FEB-1984 11:15 EST From: OBERST%EDUCOM.MAILNET@MIT-MULTICS To: HEADER-PEOPLE@MIT-MC.ARPA Subject: RE: glop. I've seen a lot of these type of addresses recently. ... Received: from SU-SCORE by SRI-CSL via DDN; 16 Feb 84 13:47:37-PST from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Feb 84 13:10:42-PST from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2623256738786884@MIT-MULTICS.ARPA>; 16 Feb 1984 13:25:38 est Date: 15 Feb 84 01:46 +0100 From: KPJ_Jaakkola_QZ@QZCOM The message presented came from the QZ Computing Centre in Stockholm. If "these type of addresses" refers to the use of underscores in the local-part of the mailbox, they are being generated by QZ in place of blanks, since MIT-MULTICS (which relays QZ's messages to a number of MAILNET and other sites) had not been able to properly handle quoted strings in SMTP paths. For consistency, they made both the SMTP and the 822-header local-parts translate blanks to underscores. In any case the @ is the delimiter separating local-part ('user-name') and domain ('host'). As for the "(Text 41915)-------------------------", QZ's local mail system is actually a conferencing system, which associates a numeric ID with all 'text'--as opposed to messages which can contain text(s)--and thus tags each text with the offending 'breath.' QZ converts their 'headers' into RFC822 format in messages that get sent out, but since the Text ID can refer to part(s) of the message they decided to keep it in the text/message-body part of the message. Apologies to Xerox for having been named as co-polluters. Some Background: MAILNET uses the Phonenet strategy of autocall modems over phone lines (and outbound Telenet/TYMNET) to connect to remote hosts for the pick-up and delivery of electronic mail. MIT-MULTICS is the 'hub', and there are currently 15 universities so connected (including the U of Stockholm's QZ). We have a gateway under development to BITNET and several universities accept and forward mail to/from other networks that they are connected to. For telephone dial-up sites we run the mmdf link-level protocol (Phonenet's) and X.25 as llp for most of the Telenet sites. We have adopted to use SMTP for mail transfer and attempt to use RFC822 for message format. We have attempted to act as if DOMAINS existed, but use the % routing convention whenever sites send messages to non-MAILNET sites. Thus most sites append '.MAILNET' to their site-name, but we encourage/require routing information for messages that go beyond MAILNET sites. (Thus in this message, the OBERST%EDUCOM.MAILNET@MIT-MULTICS should allow ARPA readers to reply in the absence of a MAILNET domain name-server). There has been reluctance in some quarters to implementing temporary hacks (like %'s) with the result that most sites have half-implemented temporary hacks. I have followed the domain/reverse-path/RFC733-still-lives-on-with-% discussions on Header-People, and would be happy to hear other suggestions about what to do while we wait for DOMAINS and name-servers to appear. Dan Oberst MAILNET Director  Date: Fri, 17 Feb 84 15:37 EST From: "Benson I. Margulies" Subject: return-path To: header-people@MIT-MC.ARPA Message-ID: <840217203723.729084@CISL-SERVICE-MULTICS.ARPA> Well, if the return path is supposed to be where errors end up, could someone please fix the tops-20 mailer so that the return path for all mail to tcp-ip at NIC would be tcp-ip-request at NIC, and not the originator of the mail?  Date: 17 February 1984 1338-pst From: Jerry Bakin Subject: Overloading the UUCP network. (Keep this message away from flammables.) To: HEADER-PEOPLE @ MIT-MC Am I alone, or have other people experienced: o Mail lost in UUCP. o Mail successfully transmitted but received too late to be of use. (One week or more delay interval between sending and receiving) o A from path which is useless (no pun intended) as a reply path, and no reply path explicitly given. o No idea of a path from host A to host 2, much less knowledge of an optimal route between the two. o A previously known host in a path between two hosts going down for an unknown amount of time forcing a completely new path to be worked out. o A previously known gateway between two networks going down for an unknown amount of time forcing completely new paths to be figured out. o The name of a host in a path changing. It is my understanding UUCP was intended to be used on the very low scale. Now, what is already an overloaded net is threatened to be completely inundated by the release (neither good nor bad) of a version of UUCP for the PC. Am I to believe that industry, faced with KNOWLEDGE of the above problems, and needing a mail which is reliable, is screaming for Lauren to release his PC UUCP? Yes, I do believe they are screaming, but for two reasons: I) They have no knowledge of the problems, II) Cheap is CHEAP. However, with the possible trebling of the load on the UUCP net due to commercial use, can we expect intolerable problems? Perhaps such sites as Berkeley, a taxpayer funded gateway, will stop being a gateway, because there is only so much subsizing of a commercial net their administration will allow (not to mention the possible trebling costs)? Or, other gateway sites which are already commercial, but support CS use, will stop being allowed to be used as gates due to increased costs and loads on their systems. Lauren, we all want to become rich and help mankind, let me make a suggestion that you design a net which runs on phone lines at 1200 baud, is domain like in its addresses, dynamically rerouting based upon cost, and speed, delivers mail, registered mail, and secure mail, (all with acknowledgement of receipt available.) Start it for the PC, (call it Personnel Computer Protocal -- PCP), design it so anyone can adopt it, and market this. Businesses will pay the added phone costs in much the same way that they pay for business calls now, so the cost of calling cross country via cross town will not be as important as getting the mail there this hour versus this month. In the mean time, UUCP will not become anymore bogged down than it is, nor will I or any of us have to subsidize Charlie Chaplan's Hat Business anymore than we currently do. And if you really want to become rich, you'll lease own cross country lines, (They're only 3K a month) and run your net yourself at higher speeds and charging people by the message. Jerry.  Date: Fri, 17 Feb 84 19:57 EST From: "Benson I. Margulies" Subject: PCP proposal To: header-people@MIT-MC.ARPA Message-ID: <840218005705.697379@CISL-SERVICE-MULTICS.ARPA> It exists. Its called MCI-Mail. If businesses want reliable, cheap, addressed delivery to PCs they just buy MCI Mail advanced service for each one and MCI endeavours to disambiguat the names. No domains yet, but I bet they could be convinced ...  Return-Path: Received: by seismo.ARPA ; Fri, 17 Feb 84 20:21:34 est Date: Fri, 17 Feb 84 20:21:34 est From: harpo!hou3c!ka@SEISMO Message-Id: <8402180121.AA08809@seismo.ARPA> To: MRC@SU-SCORE.ARPA Cc: header-people@mit-mc.ARPA Subject: Paths vs. Domains In-Reply-To: Your letter of Thu, 16-Feb-84 22:51:37 EST This actually covers several different issues. First, relative naming vs. each machine having a unique name. Second, the specification of routes vs. the specification final destination only. Finally, if you have routes, the use of a host specific syntax vs. a single route syntax. I agree that machine names should be unique. The domain scheme pro- vides a way to do this. One problem with the scheme is that it was designed to handle naming on the Internet. Thus last I heard the plan was to have DARPA register register domains that met certain require- ments (including having two nameservers on the Internet). The result has been that people have gone ahead and announced the existance of domains like MAILNET and UUCP which are not registered anywhere, so name conflicts are possible. I also agree that it would be better if users did not have to specify routes, but it is difficult to avoid the necessity. What is worse is that the routes are currently buried into the domain specific string in many cases. For example, mail from CSNET has a return addresses like "spaf.gatech@CSNet-Relay.ARPA". My mailer will use an efficient route to reply to this, but only because of a hack I put in my mailer to rewrite this address as "spaf@gatech.csnet". Recently CSNet has been replacing the dot with a percent sign so that the code I wrote no longer works. I don't think that the necessity for providing explicit routes will disappear any time soon. There are lots of problems, depending on the domain (including, as I mentioned, the lack of even a registery of top level domains that don't talk to the Internet.) What I do hope is achievable in the relatively near term is the use of explicit routes as opposed to placing routing information in the domain specific string. With the former a mailer approach it is easy to determine the original address; with the latter it is necessary to know the peculiarities of particular hosts. Kenneth Almquist  Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 18 Feb 84 1:00 GMT Via: UCL-CS.; Date: Saturday, 18-Feb-84 00:57:34-GMT Date: 18-Feb-84 00:25-BST From: vortex!lauren_ Reply-to: vortex!lauren_ , ARPA_Header-People%yorkcom@ucl-cs.arpa To: ARPA_Header-People%yorkcom@ucl-cs.arpa, header-people , vortex!lauren Subject: manifesto Message-ID: <3649@YORKCOM> Transfer file: DSKA:PST011.COM[3,5] Via: UCL-C ; 1984-02-18 00:24:12-BST Date: Friday, 17-Feb-84 19:35:47-GMT Received: from Ucl-Cs.AC.UK by 44d.Ucl-Cs.AC.UK via List-Channel; 15 Feb 84 16:06 GMT Received: from Usc-Isid by 44d.Ucl-Cs.AC.UK via Satnet with SMTP; 15 Feb 84 13:18 GMT Received: FROM MIT-MC BY USC-ISID.ARPA WITH TCP ; 15 Feb 84 01:23:58 PST From: vortex!lauren at RAND-UNIX Date: Wed, 15-Feb-84 00:22:21-PST Original-Sender: Lauren Weinstein Subject: manifesto Message-ID: <8402150022.11658.0.VT2.2@vortex.UUCP> To: header-people@MC Sender: header-people-request@ucl-cs No manifesto intended! I'm just desperate for a reasonable solution that will be acceptable to everyone involved. The little machines are going to (apparently) be used heavily by corporate and other large entities who will be communicating with sites scattered across the world, and will (for speed and money reasons) want to route mail via the overall "best" route, taking full advantage of the high interconnectivity of the Internet. Would you really expect someone to send their mail to a "smart" name server, perhaps knowing that the server is topologically far away from the desired destination, if the sender knows of a more or less direct route that it can use easily? I just don't think that the concentration required by the forced use of name servers is practical or desirable. You might argue that uucp sites can do what they want and should leave everyone else alone. I would claim that is impossible. There are gateways springing up everywhere, and any attempt to "control" their use would just result in more "unofficial" hacks appearing to replace them. There's going to be one hell of a lot of traffic between the uucp net and everything else! One thing about the return path -- it is useful for addressing information only as a last resort in many cases. Especially for mail routed through centralized machines, the return path may well indicate a route that is far more costly (in terms of time and money) than many other (topologically shorter) routes. This really is a desperate situation. We probably have no more than a couple of months before I'll have to start releasing the package, and my time for major code modifications at this point is quite small. Can't we come up with something that we can all live with and that has a reasonable chance of working when scaled up pretty massively? Thanks much, all. --Lauren-- (Text 3649)------------------------------  From: vortex!lauren at RAND-UNIX Date: Fri, 17-Feb-84 18:22:51-PST Sender: Lauren Weinstein Subject: It's coming. Message-ID: <8402171822.3626.1.VT2.2@vortex.UUCP> To: Bakin@HI-MULTICS CC: header-people@MC Sorry Jerry, but you lose. Most of the problems with UUCP aren't really with UUCP at all, but with other software (mail delivery software, for example) which in many cases didn't have the facilities for properly handling exception conditions. This is certainly getting better rapidly. In any case, 90%+ of the 1000's of Unix boxes being sold now have UUCP capability. This makes it pretty much a universal, for better or worse. I'm not interested at this time in trying to force through some- thing new -- I want to give people something that they can plug in and use, right now, to communicate with the most other people possible. This means UUCP. You might be interested to know that 99% of the businesses that want my UUCP are already involved in UUCP in one respect or another and are fully aware of both the positive and negative benefits. People don't want to be restricted to a subset of sites running some new software -- they want to communicate with the 1000's of sites that exist now. You might as well resign yourself to the fact that it's coming, 'cause it is! As an aside, I think I've worked out a reasonable solution to the domain handling for my related mail software, and that will hopefully help to keep things under control. --Lauren-- P.S. Keep in mind that I straddle both sides of the fence. I've been an ARPANET user for far longer than the vast majority of others on the net, and I also am heavily involved in Usenet activities. This allows me to see both sides of the issue, though I can't claim to have magic wands for every situation. --LW--  From: Christopher A Kent Message-Id: <8402180354.AA03461@merlin.ARPA> Received: by merlin.ARPA; Fri, 17 Feb 84 22:54:43 est Date: 17 Feb 1984 2254-EST (Friday) To: "Benson I. Margulies" Cc: header-people@MIT-MC.ARPA Subject: Re: PCP proposal In-Reply-To: Your message of Fri, 17 Feb 84 19:57 EST. <840218005705.697379@CISL-SERVICE-MULTICS.ARPA> Ugh. At $1/message, it's hard for me to think of MCI Mail as cheap... chris ----------  From: vortex!lauren at RAND-UNIX Date: Fri, 17-Feb-84 18:34:47-PST Sender: Lauren Weinstein Subject: Swedish mail loop? Message-ID: <8402171834.3661.0.VT2.2@vortex.UUCP> To: header-people@MC I just saw one of my messages from a few days ago come bouncing back into header-people through that (mailnet?) gateway (in Sweden?) Can someone in charge of that thing please try to avoid this? Thanks. --Lauren--  From: vortex!lauren at RAND-UNIX Date: Fri, 17-Feb-84 21:10:22-PST Sender: Lauren Weinstein Subject: $1/message Message-ID: <8402172110.3840.0.VT2.2@vortex.UUCP> To: header-people@MC Or to put it another way, would you be willing to subscribe to HEADER-PEOPLE if you had to put a dollar into your terminal for each message received? --Lauren--  Date: Sat 18 Feb 84 01:18:39-PST From: David Roode Subject: Re: $1/message To: vortex!lauren@RAND-UNIX, header-people@MIT-MC In-Reply-To: Message from "vortex!lauren at RAND-UNIX" of Fri 17 Feb 84 22:51:43-PST Location: EJ286 Phone: (415) 859-2774 I think that bulk mailing lists could be argued to be cheaper, so I think a comparable rate would be $.60 to receive Header-people. I think that MCI Mail is probably already entertaining the notion of providing an interface to a processor of some sort at the user's modem, but I have no specific knowledge. If this service is offered, it should likewise be cheaper. -------  Date: Sat, 18 Feb 84 09:52 EST From: "Benson I. Margulies" Subject: More spacewarp from York To: header-people@MIT-MC.ARPA Message-ID: <840218145247.590195@CISL-SERVICE-MULTICS.ARPA> Why do extra copies of Lauren's mail come back to haunt us days later courtesy of YorkCOM? --benson  Date: Sat, 18 Feb 84 09:56 EST From: "Benson I. Margulies" Subject: COM versus Case Sensitivity To: header-people@MIT-MC.ARPA Message-ID: <840218145631.915725@CISL-SERVICE-MULTICS.ARPA> Folks, We here in Multics have always wanted to see a rule that hostnames may be translated to upper case, but that the original case be preserved if possible. We are good losers, though, so the tendency to uppercase everything don't bother us too much. The random initial capitalization intruduced by, for example, YorkCOM, is a bit too much. Mit-Xx? Someone has got to be joshing me. Either we allow case of names of people and hosts to be meaningful, or not. If the answer is no, this pseudo-heuristic is pretty silly. --benson  Date: Sat, 18 Feb 84 17:23 EST From: "Benson I. Margulies" Subject: my note on MCI mail To: header-people@MIT-MC.ARPA Message-ID: <840218222344.582791@MIT-MULTICS.ARPA> It occurs to me that I was at least half serious. Note: I. The argument from Political Economics We are told that large corporate organizations want to use PC sized machines to store and process data. We are told that these organizations want to interchange information amongst widely seperated examples of these machines. We know that a large corporation will have very little tolerance for insecurity, unreliability, and general flakeyness. THEREFORE, we conclude that large organizations will have little use for UUCP as we know it today. We know that corporations have money to spend to soolve their problems. They bought the PC's. They buy federal express packets for big bucks. We know that where there is a demand for a service, and money to pay (generously) for it, that the service will usually spring up, unless trampled by state intervention. THEREFORE, we expect some large organization to offer a means by which an organization with many scattered machines can reliably and securely deliver information amongst them. Is it any surprise that MCI mail already is claiming to offer this service, even if it isn't all there yet? II. An argument about "randoms" Now, what about the intrepid explorers? Today, the intrepid explorers use UUCP and phone-net and friends. What choice have they? Given a nice, reliable, organized alternative, will they use it? If its cheap enough they sure will. Phone calls ain't free either. Why should I leave my PC sitting around dialing the phone like a little "daemon" if I could hand the delivery problem off to someone else? III. But still, we have to design ... Of course, a system like MCI, let alone a bunch of competing systems like MCI, will need to deal with name resolution and all those wonders. The domain scheme is a pretty reasonable approach. Let's hope that the commercial entities buy in before the chaos gets out of hand. But I think that the scenerio of 47million PC all tryping to figure out what phone number to call to reach each other is silly. They will call up MCI, or SPC, or the PostalService, and let it worry, for a fee. So to get really contentious: UUCP will die under its own weight, and be replaced by commercial carriers who have the resources to apply Internet/CCITT style solutions to naming and routing problems.  Date: 18 Feb 1984 17:05-PST Sender: GEOFF@SRI-CSL Subject: Re: $1/message From: the tty of Geoffrey S. Goodfellow To: vortex!lauren@RAND-UNIX Cc: header-people@MC Message-ID: <[SRI-CSL]18-Feb-84 17:05:24.GEOFF> In-Reply-To: <8402172110.3840.0.VT2.2@vortex.UUCP> Received: from MIT-MC by SRI-CSL via DDN; 18 Feb 84 16:51:20-PST Date: Fri, 17-Feb-84 21:10:22-PST From: vortex!lauren at RAND-UNIX Subject: $1/message To: header-people@MC Or to put it another way, would you be willing to subscribe to HEADER-PEOPLE if you had to put a dollar into your terminal for each message received? --Lauren-- That's cheating, Lauren, since on MCI Mail it costs nothing to receive a message (nor for that matter to compose one, login, check for mail, etc), it only costs money when you actually SEND something. At that price, I think it's pretty cheap, especially when you consider ancillary benefits like being able to receive TELEX and TWX's at no cost. g  From: vortex!lauren at RAND-UNIX Date: Sun, 19-Feb-84 00:15:11-PST Sender: Lauren Weinstein Subject: Re: my note on MCI mail Message-ID: <8402190015.6178.1.VT2.2@vortex.UUCP> To: Margulies@MIT-MULTICS.ARPA CC: header-people@MC In-Reply-To: Your message of Sat, 18 Feb 84 17:23 EST The flaw in your argument is assuming that "corporate"-type entities demand that ALL of their communications be super reliable and secure. In fact, what many of them want is to be able to carry on much the same sorts of "non-critical" applications that we currently base on ARPANET, UUCP, etc. They want to chat among themselves, "talk" informally with researchers at other locations, tell jokes, and otherwise do the sorts of things the rest of us do now. For these sorts of applications, security and reliability are not critical, nor are such communications worth a lot of money. Force people to pay more than a very modest amount for such services, and they won't participate at all, or only participate for very "high-value" type communications. It's specifically the "lower-value", more informal sorts of communications that I consider to be of importance and that I'm trying to promote. Most businesses are not yet willing to entrust important communications to electronic mail (for a number of technical and legal reasons -- have you read MCI's disclaimer for MCI mail?) and I don't intend to try change their mind at this point. Nor am I offering a UUCP electronic funds transfer service... so don't panic! --Lauren--  From: vortex!lauren at RAND-UNIX Date: Sun, 19-Feb-84 00:26:02-PST Sender: Lauren Weinstein Subject: Re: $1/message Message-ID: <8402190026.6184.1.VT2.2@vortex.UUCP> To: Geoff@SRI-CSL CC: header-people@MC In-Reply-To: Your message of 18 Feb 1984 17:05-PST Well, I can put it another way, would you be willing to SEND a message to header-people if you had to pay $1 for each person who would be RECEIVING it? This is even worse! How likely would people be to contribute their expertise on various subjects if they had to PAY to send that information to the people who would benefit? Few of our large mailing lists would survive under such a scheme. Two specific points about MCI Mail: 1) Their technique of forcing you to use inane and time-consuming menus UNLESS you're willing to pay them money is pretty low are far as I'm concerned. 2) I am convinced that their "free access" policy will not last. I'd be happy to give odds that somewhere not too far down the line, all "free" users will receive a notice telling them that if they want to keep their access, they will have to start paying a monthly fee and/or pay minimum amounts per month. Clearly MCI has the right to do this, but the people who think the service is going to stay free forever are kidding themselves, I suspect. --Lauren--  Date: Sun, 19 Feb 84 10:14:35 EST From: Dave Farber To: vortex!lauren@rand-unix.arpa cc: Geoff@sri-csl.arpa, header-people@mit-mc.arpa Subject: Re: $1/message While I hate to get involved but ... I have been using a package called TRANSEND for my IBM PC. It allows a reasonable PC-PC mail transefer with "attachments" that can be com files etc. It used the modem7 protocol. Its human interface is very nice and easily learned by simple managers. It can also relay mail though mail systems like the the SOURCE and Ontyme . So I can compose a lot of mail on my PC send some of it via pc-pc communications and some via the source etc. While the mail part is not up to arpanet standards (by a long shot) you would be surprised at how useful it is. Clearly as soon as MCI gets their protocol public, it too will be a vehicle for this type of usage with a lot more flexibilty since I can telex etc. Dave  Date: Mon 20 Feb 84 03:31:03-PST From: David Roode Subject: envelope information To: Header-People@MIT-MC Location: EJ286 Phone: (415) 859-2774 I sometimes wish the so-called envelope information on an SMTP transaction coming into my host were retained once the message was delivered to its appropriate mailbox. The motivation is that there are multiple names by which my mailbox may be refered to. Sometimes it would be useful to be able to identify which was used for a particular message, but that information is not listed in the standard headers. This would be the case for example when an alias had been placed on a mailing list at another site. The complete distribution is not shown in the message body because it is too long. I mention this because some people seem to feel that the user wishes to be saved from ever seeing the envelope, which is currently generally only partially available (in the form of the return path). I contend that full retention of envelope information is necessary for the user agent to function fully. -------  Date: Mon, 20 Feb 84 9:43:22 GMT From: Steve Kille To: "Benson I. Margulies" cc: header-people@mit-mc.arpa Subject: Re: More spacewarp from York The relevant implementor knows. I have broken the loop by removing an entry from my sublist expansion. Steve Kille  Date: Mon 20 Feb 84 07:02:32-PST From: Mark Crispin Subject: Re: envelope information To: ROODE@SRI-NIC.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "David Roode " of Mon 20 Feb 84 03:38:14-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) You cannot retain all the envelope information in a user-accessible place, because this would defeat the purpose of bcc's. -------  Date: Mon, 20 Feb 84 12:43 EST From: "Benson I. Margulies" Subject: security of envelopes To: header-people@MIT-MC.ARPA Message-ID: <840220174339.717329@CISL-SERVICE-MULTICS.ARPA> No PC (or anything else) is secure. If you really believe in the security of BCC, the information had better never leave the sending host in envelope or message..  Date: 20 Feb 1984 18:12:28-EST From: eagle!hou3c!ka at mit-vax Posting-Version: version B 2.10.1 6/24/83; site dartvax.UUCP Path: hou3c!burl!clyde!floyd!harpo!decvax!dartvax!davidk From: davidk@dartvax.UUCP (David C. Kovar) Comments: The real from line reads From: davidk@dartvax.UUCP (David C. Kovar) Do not accept an substitutes. Resent-From: ka@hou3c.UUCP To: Header-People@MIT-MC.ARPA Subject: Re: Overloading the UUCP network. (Keep this message away from flammables.) Message-ID: <742@dartvax.UUCP> Date: Sat, 18-Feb-84 15:18:44 EST Received: by hou3c.UUCP; Sat, 18-Feb-84 21:45:38 EST References: <290@hou3c.UUCP> Organization: Dartmouth College Lines: 59 You suggest that Lauren go off and start up his own PCP network so that UUCP will not become anymore bogged down than it is. You also state that most of your problems with UUCP involve hosts going down, causing you to reroute via other sites or networks. No where do you mention that the problems with UUCP involve overuse. Now I agree that UUCP handles one hell of a lot of traffic, and I also agree that adding PC sites will add more of a load to the net, but I fail to agree that switching the PC's to another net will solve the problem. First off, I am going to send news and mail even if I do not have UUCP running on my IBM XT. With it, I can compose on my own system and free ports up on the colleges system. Without it, I will be composing and thinking on the college's VAX and tying up their resources. Either way, that article/mail is going out on the net. So in this case, I see a PLUS in releasing UUCP for the PC, not a minus. The net load stays about the same and my host system gets me off on my own. Secondly, the only people who can tie into an existing nodes will have to request permission to do so from that site. Same process that you have to go through for an account. This means that every PC owner and their brother will not go out an join the net, they can't get at it. They will all be paying for their own phone calls, not the rest of the network. (I already ventured that their postings to the net would stay the same, keeping that cost to the net even.) Now each site might not want 40 PC UUCP sites calling in, but they can deal with that on their own, that will not affect the net as a whole. But, we will have a large number of new site names, and that must be dealt with. And I also would not want to route my mail/news through a PC site. To this end, we might add a 'pc' to the site name, indicating that it was a leaf and should not be included in internal paths. This would also help keep the site names unique. I wrap this up with one question: Who owns the net? If you do not want to subsidize IBM, do not permit PC UUCP's at your site. Each particular 'you' out there can refuse to subsidize in this way but I would be rather upset if you decided to prevent me from posting just because I own a IBM and you get paid $30K a year to hack UNIX. If worst comes to worst, I'll go buy PC/IX and then be a 'real' site. And by damned, if you do not like that, I can probably manage to trade my car in on a MicroVax. If you want to keep VAX sites off of the net, I wish you luck. Sorry about the flame, all. -- David C. Kovar Usenet: {linus | decvax | cornell}!dartvax!davidk ARPA: kovar@MIT-ML (Infrequent) U.S. Snail HB 3140 Dartmouth College Hanover NH 03755 "The difficult we did yesterday, the impossible we are doing now."  Return-Path: Received: by seismo.ARPA ; Tue, 21 Feb 84 00:01:03 est To: Header-People@MIT-MC.ARPA From: hou3c!ka@SEISMO (Kenneth Almquist) Subject: Re: envelope information Message-Id: <313@hou3c.UUCP> Date: Mon, 20-Feb-84 23:49:37 EST References: <308@hou3c.UUCP> Organization: Bell Labs, Holmdel, NJ It seems to me that the controversy over what belongs in the envelope and stuff that "has to be in the header for the benefit of networks that don't have any concept of 'envelope' information" is due to confusion over what RFC 822 is attempting to define. If RFC 822 is supposed to define a general purpose, network independent standard for mail transfer, then it should be complete. This implies that a "Currently-To:" field should be added to it so that a piece of mail can be sent to another system without providing a destination separately. A lower level protocal must be used underneath RFC 822 to actually transfer the mail. In the case of the ARPANET, that lower level transport could remove the "Return-Path:" and "Currently-To:" fields from the header and transmit them in the envelope. The receiving process would then restore the values to the header. Is there any explanation (other than confusion on the part of the writers about what they were trying to do) why RFC 822 contains "Return-Path:" but not "Currently-To:"? Kenneth Almquist  From: vortex!lauren at RAND-UNIX Date: Mon, 20-Feb-84 17:00:36-PST Sender: Lauren Weinstein Subject: PC UUCP Message-ID: <8402201700.1851.0.VT2.2@vortex.UUCP> To: header-people@MC By the way, my current code has full capabilities for forwarding mail through to other sites in the typical UUCP manner -- in fact, vortex handles quite a bit of West Coast traffic right now without any problems at all. The capacity for a PC to act as a mail server seems to be quite high. On the other hand, my current netnews handling code is designed NOT to allow forwarding of Usenet netnews articles. This was a conscious decision on my part based on the assumption that few PC's would have enough disk space to handle such a potentially voluminous task. --Lauren--  Date: Tue, 21 Feb 84 15:30:21 EST From: Ron Natalie To: Mark Crispin cc: ROODE@sri-nic.arpa, Header-People@mit-mc.arpa Subject: Re: envelope information I endorse the Currently-To: idea. It can be done without destroying the BCC protection for example it could be intermixed with the Recieved lines. Delivering-To: ron@Brl-Vgr Received: From BRL.ARPA by BRL-VGR via smtp; 20 Feb 84 21:38 EST Delivering-To: info-unix@Brl-Vgr Received: From Brl-Vld.ARPA by BRL via smtp; 20 Feb 84 21:30 EST Date: Mon, 20 Feb 84 21:29:06 EST From: Doug Gwyn (VLD/VMB) To: hnij@bnl cc: info-unix@brl Subject: Re: file descriptors --> filenames In the above example the letter was Recieved on BRL from the user on the host BRL-VLD. INFO-UNIX@BRL routes to INFO-UNIX@BRL-VGR. It is the received there. INFO-UNIX is expanded and in turn delivered to me (RON@BRL-VGR). Our mail system, as well as others tries to keep the number of copies of a message down, this might be circumvented by adding these extra lines which make several slightly subtle changes. -Ron  Date: 21 Feb 1984 23:09:47-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Subject: Strange Message Posting-Version: version B 2.10.1 6/24/83; site sjuvax.UUCP Path: hou3c!burl!clyde!akgua!sb1!sb6!bpa!burdvax!sjuvax!bbanerje Comments: Beware of wolves in sheep's clothing; the real "From:" line reads From: bbanerje@sjuvax.UUCP From: bbanerje@sjuvax.UUCP Resent-From: ka@hou3c.UUCP Resent-Date: Tue, 21-Feb-84 22:05:03 EST Message-ID: <170@sjuvax.UUCP> Date: Mon, 20-Feb-84 17:44:51 EST Received: by hou3c.UUCP; Tue, 21-Feb-84 18:30:51 EST Distribution: net Organization: Saint Josephs Univ. Phila., Pa. My apologies if this is in the wrong Newsgroup. Anyhow, the following in its entirety is a message I received in the Mail. Apparently a message I had posted to net.unix didn't make the jump over to the ARPA-NET. QUESTIONS - Is this due to one of the Hosts being dead, or is this a usual occurence? I'm only on the UUCP network. - The body of my article didn't come back with the header. Does this mean that it didn't make it out? Or does this mean that the software only mails back Headers. Any and all answers gratefully received. Binayak Banerjee { allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje ******************************************************************** >From burdvax!bpa!sb1!burl!Mailer@CMU-CS-C.ARPA Thu Feb 16 14:52:17 1984 Received: by sjuvax.UUCP (4.12/4.7) id AA11419; Thu, 16 Feb 84 14:52:08 est Via: ulysses!mhuxl!eagle!harpo!ucbvax Received: by ulysses.UUCP (4.12/4.7) id AA00975; Thu, 16 Feb 84 13:01:21 est Received: from CMU-CS-C.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA01766; Wed, 15 Feb 84 13:27:26 pst Message-Id: <8402152127.AA01766@UCB-VAX.ARPA> Date: Tue 14 Feb 84 08:20:05-EST From: The Mailer Daemon To: harpo!eagle!mhuxl!ulysses!burl!clyde!akgua!psuvax!burdvax!sjuvax!bbanerje@BERKELEY.ARPA Subject: Message of 14-Feb-84 08:19:35 Status: RO Message undelivered after 0 days -- will try for another 0 days: BBoard.Unix-Wizard@Tartan.TARTAN: Cannot connect to host. ------------ Received: from BRL-VGR by CMU-CS-C with TCP; Tue 14 Feb 84 08:19:38-EST Received: From Sri-Unix.ARPA by BRL-VGR via smtp; 9 Feb 84 8:48 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Feb 84 5:41-PST Date: 6 Feb 84 17:05:26-PST (Mon) To: info-unix@brl-vgr From: harpo!eagle!mhuxl!ulysses!burl!clyde!akgua!psuvax!burdvax!sjuvax!bbanerje@ucb-vax Subject: Re: Area-code as uucp domains Article-I.D.: sjuvax.143 In-Reply-To: Article <458@houxe.UUCP> <1062@utah-gr.UUCP> <325@hogpc.UUCP> <173@lzmi.UUCP>, <247@dual.UUCP> ------- -- Binayak Banerjee {allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje  Date: 21 Feb 84 2327 EST From: Rudy.Nedved@CMU-CS-A To: eagle!hou3c!ka%mit-vax@mit-mc Subject: Re: Strange Message CC: Header-People@MIT-MC In-Reply-To: <170@sjuvax.UUCP> Message-Id: <21Feb84.232723.MA1L@CMU-CS-A> It is a warning message from CMU-CS-C trying to send mail off of the ARPANET to a host on a serial line called TARTAN. The warning messages about unable to deliver mail contains ONLY the header and not the body of the message. The message has either been delivered or is still pending to be delivered. I would think it would be better to send a message to Postmaster@BRL thru some common uucp address then it would be to broadcast this type of thing to the entire header-people mailing list. Rudy Nedved A CMU Postmaster  Date: Tue 21 Feb 84 20:45:23-PST From: Mark Crispin Subject: "Unable to deliver after 0 days" To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The particular strangeness about the message (that is, it is unable to deliver after no time at all) is due to a fencepost error in older versions of the TOPS-20 mailer. It was fixed a while ago -- it now tries for at least a day before reporting an error -- but the distribution of the new software is quite irregular. -------  Received: by UCB-VAX.ARPA (4.22/4.22) id AA14399; Tue, 21 Feb 84 22:35:17 pst Date: Tue, 21 Feb 84 22:43:48 est From: cbosgd!mark@Berkeley (Mark Horton) Message-Id: <8402220343.AA11347@cbosgd.UUCP> Received: by cbosgd.UUCP (4.12/3.7) id AA11347; Tue, 21 Feb 84 22:43:48 est To: header-people@mit-mc.ARPA Subject: Re: envelope information If we're going to go this far: Delivering-To: ron@Brl-Vgr Received: From BRL.ARPA by BRL-VGR via smtp; 20 Feb 84 21:38 EST Delivering-To: info-unix@Brl-Vgr Received: From Brl-Vld.ARPA by BRL via smtp; 20 Feb 84 21:30 EST why not just use the existing "for" subfield of Received, as provided in RFC822: Received: From BRL.ARPA by BRL-VGR for ron@Brl-Bgr via smtp; 20 Feb 84 21:38 EST Received: From Brl-Vld.ARPA by BRL for info-unix@Brl-Vgr via smtp; 20 Feb 84 21:30 EST By the way, this DOES seem like a good idea. Mark  From: Christopher A Kent Message-Id: <8402231923.AA01007@merlin.ARPA> Received: by merlin.ARPA; Thu, 23 Feb 84 14:23:55 est Date: 23 Feb 1984 1423-EST (Thursday) To: eric%ucbarpa@Berkeley.ARPA (Eric Allman) Cc: header-people@MIT-MC.ARPA Subject: Re: "Return-Path" vs. "From" In-Reply-To: Your message of 16 Feb 1984 1705-PST (Thursday). <5638.31.445827921@ucbarpa> Eric, I stand only mildly rebuked. I agree that it is a bad thing to perpetuate the insanity that is Unix mail. (Unix vendors could note that they would do well to concentrate on developing a totally new mail system -- grad student hacking doesn't seem to be enough.) Unfortunately, the envelope information that you pass around is misleading to the many other programs that parse Unix mailboxes. It would have been simple to just use the true From address, rather than the SMTP sender information, which is of little use to 90% of the users. Programs which filter incoming mail (like msgs) present confusing return/from addresses. It seems like the whole thing could have been solved/avoided by fixing sendmail rather than having to hack on each of the programs that gets confused. chris ----------  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA08239; Thu, 23 Feb 84 23:52:33 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14/4.13.1) id AA08448; Thu, 23 Feb 84 23:42:31 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.13.1) id AA16931; Thu, 23 Feb 84 23:35:49 pst Date: Thu, 23 Feb 84 23:35:49 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8402240735.AA16931@ucbopal.CC.Berkeley.ARPA> To: header-people@mit-mc Subject: Re: envelope information Since D.Brown has dropped by name into the pot, I guess it is time to dust off my "Basic Message Format" again. The "Currently-to" concept is the about the same as the "Relay-to" header field in my basic message format. I prefer "Relay-to" since it is already defined for military messages. For those that have not kept a copy of my basic message format header fields, here is a summary of the header fields. The "envelope information" is contained in the postal heading. ----- Basic Message Format - 2 - "Heading Components" Version 3 - 23 Feb 84 1. Basic Message Structure: Parts: Sub-parts: HEADING Transmission Heading Batch Heading Postal Heading Message Heading TEXT Message Text (Body of Message) ENDING Message Ending Postal Ending Batch Ending Transmission Ending The Internet text message format as defined by the "Standard for the Format of ARPA Internet Text Messages" (RFC 822) has a heading and a text. No ending is defined. Basic message format classifies header fields into two groups, Message Heading and Postal Heading fields. In addition to RFC 822 header fields there are additional header for use in the Postal Heading. No attempt has been made to define "Batch" or "Transmission" fields since these are more the concern of the network and the transport system being used. "Classification", "Precedence" and "Resent-Precedence" have been added to the Message Heading to permit user definition of these fields. 2. Basic Message Format Header Fields by Sub-Part and Component. POSTAL HEADING SUB-PART COMPONENT FIELD _____________________________________________________ Postal Postmark Posted-Date: Heading Posted-From: Post-ID: Postmaster: Return Field Return-Path: Relay Instructions Relay-To: Do-Not-Relay-To: Trace Fields Received: _____________________________________________________ MESSAGE HEADING SUB-PART COMPONENT FIELD _____________________________________________________ Readdressal Date-Time Resent-Date: Message Heading(s) Originator's Resent-From: Address Resent-Sender: Resent-Reply-To: Originator's Resent-Message-ID: Message ID. Precedence Resent-Precedence: Receiver's Resent-To: Address Resent-cc: Resent-bcc: Resent-Exempt: _____________________________________________________ Original Date-Time Date: Message Heading Originator's From: Address Sender: Reply-To: Originator's Message-ID: Message ID. Precedence Precedence: Receiver's To: Address cc: bcc: Exempt: Security Classification: Classification Content Subject: Information Keywords: In-Reply-To: References: Encryption Encrypted: Field _____________________________________________________ Heading Comments Comments: Comments Field _____________________________________________________ Notes: (a) Fields not defined in RFC 822 are: Posted-Date, Posted-From, Post-ID, Postmaster, Relay-To, Do-Not-Relay-To, Resent-Precedence, Precedence, Resent-Exempt, Exempt, Classification. The order of sub- parts differs from RFC 822 Article 4.1 in that "source" is defined as: source = [trace] [resent] originator (b) Each sub-part of the heading begins with its corresponding date- time field. Fields pertaining to one sub-part may not be placed in another sub-part. With the exception of the date-time field which begins the sub-part, the order of fields within the sub-part is not defined. However the above order is recommended. (c) There may be none, one or more "readdressal message heading" sub- parts in the message heading. If there is more than one "readdressal message heading" the later ones precede the earlier ones. (d) "Relay-To" fields may be deleted by relaying hosts (Mail Transport Agent programs) when delivery has been made (or protected) by that host (MTA). (e) Relaying hosts (MTA's) will not make changes to the Message Heading within an mail system using basic message format. Gateways to non-basic message format mail systems, may translate header fields into other formats. However, if the other mail system's format is incompatible with the basic message format, the message should be quoted in the text of the other systems message. The same applies to incompatible messages being entered into an a basic message format mail system. (f) There may be only one "Date:", "From:", "Sender:" and "Message- ID:" field per original message. Relaying hosts may not add or change the "Message-ID" field. (g) "Exempt" and "Resent-Exempt" fields are optional user fields that may be used with collective addresses to indicate that the drafter (or user resending the message) does not want the message sent to one or more addressees in the collective address. Syntax is same as "To": exempt = "Exempt" ":" 1#address resent-exempt = "Resent-Exempt" ":" 1#address ----- Comments? Bill Wells, RMC, USNR-R wcwells@BERKELEY.ARPA ucbvax!wcwells Computing Services, 297 Evans Hall, University of California, Berkeley CA 94720  Date: 24 Feb 1984 1315-EST From: John R. Covert To: Header-People at MIT-MC ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" Subject: Domains, PTTs, Lauren's PC/UUCP, and the WorldNet Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11994335995.26.132.97343 at DEC-MARLBORO> It is clear that the domain mechanism is the right mechanism for solving the addressing problem in a world internet. My earlier message on "addressing in the international environment" was misunderstood by many, though I did get quite a few useful responses. I wrote the message primarily in response to Lauren's message asking for an interim mechanism for dealing with domains and name servers in an environment where lots of UUCP(Lauren) systems are originating mail. Though many of these systems may be PCs, many more of them may be larger timesharing machines with hundreds of users. Lauren is correct in stating that once his software hits the streets, it will become a defacto standard. His implementation needs to be either sufficiently general to solve the whole problem or must be guaranteed to be upgraded at a future time. Guaranteeing upgrade is probably not realistic. Producing sufficient generality is also unlikely, so maybe all that can be hoped for is that we understand the problems in the international market. The international market has some special requirements caused by the fact that in most of the rest of the world (outside the U.S.) there is a monopoly on communications. All communications. One of the flaming responses I received asked "Why should I have to understand DECNET?" I went back and re-read the message I had sent, and nowhere had I even mentioned DECNET. Regardless of the protocol used, the rules for getting from point A to point B (if one of those points is in a country which does not permit the unrestricted interconnection of communications networks) can not permit a host to simply dump the message on another host and expect it to take care of all the PTT requirements, when a basic requirement is that no one may carry someone else's traffic. By carrying someone else's traffic, the monopoly of the PTT on message transport (whether the message is voice, data, or paper -- yes, I can't even legally hand carry someone else's letter part of the way towards its destination) has been damaged. For example, if machine X, located in country Y, wants to send a message to SRI-NIC.ARPA and UCL-CS.ARPA, country Y may require that the message be routed differently for each destination. Country Y may not permit messages to the U.S. to be routed via the U.K., or messages to the U.K. to be routed via the U.S. I'm not confusing domains with routing. Both of the names in the example above contain enough information to allow the host in country Y to do the right thing. But only after the names are further resolved. The machine in country Y cannot send the mail to a single known system which handles all mail to any ARPA host. The names have to somehow be resolved by a name server which is able to tell machine X the correct route for mail to each of the machines based on the location of machine X and the locations of SRI-NIC.ARPA and UCL-CS.ARPA. The domain system can handle this. Referencing both of these hosts with just ".ARPA" is a valid interim solution as we migrate to the domain structure. Eventually, just .ARPA is not enough to allow the host in country Y to deal with its PTT regulations. Within the ARPAnet we may want to be able to always specify just .ARPA and not be required to specify .ARPA.USA and .ARPA.GB (for example). Software which creates the headers in a message may have to be able to add country designators so that a "Reply all" command issued by a machine in country Y can function without involving name servers. Though there is little relationship between what goes on within the ARPAnet and what CCITT bodies do (since the ARPAnet is a research network), as the connections between the ARPAnet and external networks become common, the creators of these connections have to be sure that international agreements allowing the ARPAnet to extend beyond the boundaries of the U.S. are not violated. The ARPAnet is not the only network which is international in scope. DEC, IBM, and many other companies have built such networks. PTTs are within the rights granted to them by their monopoly status to refuse to allow any host on a private network to be connected to the public network unless the software in use on those hosts is demonstrated to obey the rules imposed by the monopoly. A UUCP host might, for example, be required to demonstrate to the PTT, before a modem could be connected to it, that it will only forward messages which originated within the organization owning the machine. Descriptions of the protocol to be used may be required to be submitted with the application for a modem connection license. As a final note, I should state that most of my experience has come from studying the requirements in Germany, primarily dealing with the interconnection of public and private networks. Remember that a network is a private network even if it operates only over public network facilities. It is private if the switching function is provided by a private entity. All of this discussion took place prior to the completion of the recommendations in the X.400 series. How the X.400 series will affect the environment in Germany is at the moment unknown. One of the more interesting requirements under the German Telecommunications Law is that if a new public service becomes available, private networks which provide the equivalent service must be taken out of service. As of last year, the DBP seemed to consider the Teletex service (which is an upgraded version of Telex with a larger character set and higher speed data transmission) as the service which would meet the electronic message needs of the future. They insisted that the service was a point-to-point service, i.e. a Teletex line could not be connected to a data processing system to allow distribution of messages within an organization. Other countries may have less restrictive, some may have similar, and some may have more restrictive regulations than Germany. And Lauren may have no plans for his product to be used outside the U.S. Be glad these problems don't exist in the U.S. --------  Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA22044; Fri, 24 Feb 84 11:30:51 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbarpa.ARPA (4.22/4.22) id AA22377; Fri, 24 Feb 84 11:31:54 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.13.1) id AA20770; Fri, 24 Feb 84 11:30:26 pst Date: Fri, 24 Feb 84 11:30:26 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8402241930.AA20770@ucbopal.CC.Berkeley.ARPA> To: header-people@mit-mc.ARPA Subject: Re: envelope information Envelope Information - 1.1 Now that I have sent out my summary of basic message format header fields I would like to limit the discussion to "envelope information" (ie. my "postal heading" fields) in this discussion group (header-people@mit-mc/net.mail.headers). Discussion of the format in general and other headings should be in the "MsgGroup@brl/ net.mail.msggroup" where basic message format was discussed last year. To forestall some comments: Yes, I know that "stacked" Resent headings are incompatible with RFC 822. Now back to "envelope information". In defining the "postal heading" I was concerned with making a distinction between mail transport agent functions and user agent functions (a distinction that is not clear in RFC 822). At the time I was aware that the mail formatting/generation program could be different from the mail transport program(s) and that the mail formatting/generating program might be spooling output to the mail transport program for posting. I was thinking of the programs being on the same host, but the introduction of smart workstations (and personal microcomputers [pc]) adds a new twist to the problem. That is, how to identify mail transmissions and handle error messages when the user originates the message on a work station or pc and the mail transport agent (ie. "post office") is on another host. I do not think this latest twist is a problem if we make a clear distinction between mail transport agent header fields and user agent header fields. We will also have fewer problems if the fields that are allowed to be changed by the mail transport agent are limited. (Note: header munging or refiling messages across mail system gateways is a separate issue.) I think my postal heading fields can solve a number of these problems. In my postal heading I have defined the following fields: SUB-PART COMPONENT FIELD _____________________________________________________ Postal Postmark Posted-Date: Heading Posted-From: Post-ID: Postmaster: Return Field Return-Path: Relay Instructions Relay-To: Do-Not-Relay-To: Trace Fields Received: _____________________________________________________ The "Postmark" fields serve to identify each message transmission. --- My assumption is that a unique message identified by "Date" "From" and "Message-ID" (fields added by the user agent mail formatting/generation program) might be retransmitted to one or more addresses of the original message (for example, when the original message was returned to sender due to a host being down). The "Postmaster" field serves to identify the Postmaster of the of the originating mail transport agent. This is needed where one mail transport agent is serving several hosts, workstations and microcomputers. (This should handle the case where the originator of a message is not in the same mail domain as the Postmaster of the originating mail transport agent.) "Return-path" - same as RFC 822, with one note: In addition to the last mail transport agent adding this field, I think "gateway" mail transport agents should also add/modify this field.  Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA25582; Fri, 24 Feb 84 15:10:11 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbarpa.ARPA (4.22/4.25) id AA03091; Fri, 24 Feb 84 15:11:13 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.13.1) id AA24196; Fri, 24 Feb 84 15:09:49 pst Date: Fri, 24 Feb 84 15:09:49 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8402242309.AA24196@ucbopal.CC.Berkeley.ARPA> To: header-people@MIT-MC.ARPA Subject: Re: envelopes versus messages In reply to: Date: Wed, 15 Feb 84 20:47 EST From: "Benson I. Margulies" Subject: envelopes versus messages To: header-people@MIT-MC.ARPA Message-Id: <840216014745.993851@CISL-SERVICE-MULTICS.ARPA> It seems to me that some of the cross purposes of this discussion relate to the role of envelopes. I always have assumed that the content of the envelope is available to the mail agent (mail reading program, if you like) of the recipient. Am I out-to-lunch on that? There is a problem with the definition of envelope. We each seem to have our own definition. "envelope" information, that is information used or added by the mail transport agents, should be passed on to the addressees of a message, but may not be. The mail transport agents job ends when the message has been spooled to (placed in) the addressees mail box. Certain information available to the mail transport agent may not be added to the heading of the message prior to being delivered to the mail box. Trace information and other information added by the mail transport agents should be available to the receiving user agent, though not necessarily displayed by default. In the case of SMTP, much of the SMTP envelope information may also need to be passed on to a non-SMTP mail transport programs in the heading of the message. The information also needs to flow in the opposite direction, from the user agent (the mail formatting/generation program) to the mail transport agent, and in some cases even down to lower levels. For example, the "precedence" and "classification" of a government message is defined by the user agent, but does not look like the RFC 822 or SMTP provides for precedence or classification information to be passed from the user agent down to the IP Header "Type of Service" Precedence bit and the Security field of the IP Header "Security" Option (see RFC 791 section 3.1). Bill Wells wcwells@Berkeley.ARPA ucbvax!wcwells  Date: 24 Feb 1984 18:28:00-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83 SMI; site sun.uucp Path: hou3c!burl!ulysses!harpo!decvax!decwrl!sun!gnu From: gnu@sun.uucp (John Gilmore) Subject: Re: "From " vs. "From:" in Sendmail Message-ID: <450@sun.uucp> Date: Thu, 23-Feb-84 21:39:17 EST References: <5638.31.445827921@ucbarpa> In-Reply-To: <5638.31.445827921@ucbarpa> Organization: Sun Microsystems, Inc. From: eric%ucbarpa@Berkeley.ARPA (Eric Allman) Subject: Re: "Return-Path" vs. "From" Gosh Chris, I'm awfully sorry that I have tried to do the right thing instead of perpetuating the insanity that has characterized (and sadly, continues to characterize) the UNIX mail system. Sendmail passes the information it gets from the received envelope into the transmitted envelope. If the mailer is a program rather than an SMTP channel, the "envelope" consists of the command line arguments. Unfortunately the information provided by uucp in the "envelope" is often wrong. This causes the "From " line and the "From:" line to differ, which is very confusing to the end-users, mail-readers, etc. For mail generated on the Arpanet and relayed to Sun via uucp, the From: line is right (or at least can be munged to be right, by adding ".arpa"), but the "From " line often claims the message is from "daemon" or "uucp" or whatever user happened to do something that started this uucp connection. E.g.: From uucp Thu Feb 23 00:27:47 1984 From: Ed Pattermann To: "sun!gnu@shasta"@SUMEX-AIM.ARPA For mail which has been passed solely thru uucp sites, the "From " line is clearly correct, since the "From:" line has not been maintained at (all) intermediate sites. E.g.: From dual!allegra!cbosgd!fair Thu Feb 23 17:01:34 1984 From: dual!cbosgd!fair The win would have been to make the envelope right for all uucp traffic, (which it already was for strictly-uucp traffic) and have sendmail fix the From: line to match the "From " line. This has not been done -- yet. Is there a uucp/mail expert in the house who can tell us WHY the envelope is "uucp" or some user, instead of the right thing?  Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA02070; Fri, 24 Feb 84 18:29:44 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbarpa.ARPA (4.22/4.25) id AA07483; Fri, 24 Feb 84 18:30:40 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.13.1) id AA27344; Fri, 24 Feb 84 18:29:18 pst Date: Fri, 24 Feb 84 18:29:18 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8402250229.AA27344@ucbopal.CC.Berkeley.ARPA> To: header-people@mit-mc.ARPA Subject: Re: envelope information Envelope Information - 1.1 correction Oh joy. My last message: Date: Fri, 24 Feb 84 11:30:26 pst From: wcwells@ucbopal (William C. Wells) Message-Id: <8402241930.AA20770@ucbopal.CC.Berkeley.ARPA> Subject: Re: envelope information was truncated when it was transmitted locally. Here is the bottom part again. Sorry for the repeat. ---- SUB-PART COMPONENT FIELD _____________________________________________________ Postal Postmark Posted-Date: Heading Posted-From: Post-ID: Postmaster: Return Field Return-Path: Relay Instructions Relay-To: Do-Not-Relay-To: Trace Fields Received: _____________________________________________________ The "Postmark" fields serve to identify each message transmission. --- My assumption is that a unique message identified by "Date" "From" and "Message-ID" (fields added by the user agent mail formatting/generation program) might be retransmitted to one or more addresses of the original message (for example, when the original message was returned to sender due to a host being down). The "Postmaster" field serves to identify the Postmaster of the of the originating mail transport agent. This is needed where one mail transport agent is serving several hosts, workstations and microcomputers. (This should handle the case where the originator of a message is not in the same mail domain as the Postmaster of the originating mail transport agent.) "Return-path" - same as RFC 822, with one note: In addition to the last mail transport agent adding(/modifying?) this field, I think "gateway" mail transport agents should also add/modify this field. The "Relay-to" field tells the receiving mail transport agent that he(/she?) is responsible only for forwarding the message to a specific list of addressee (not all addressee in the message heading). It takes precedence over addresses in the message heading. It may be used by either the mail transport agent or the user agent. One example of user agent use would be in the retransmission of a message which was returned to the sender, and the sender does not want to retransmit to all addressees but only to the addressee that did not get the message. The "Do-not-relay-to" field is intended to be used with collective addresses where mail transport agent has or is making delivery to specific member(s) of the collective address via other means (for example via an alternate mail system). This assumes the mail transport agent applying this field knows the composition of the collective address. "header-people@mit-mc.ARPA" is an example of a collective addresss. "Received" - same as RFC 822. Bill Wells, U.C. Berkeley wcwells@Berkeley.ARPA or ucbvax!wcwells  Date: 27 Feb 1984 18:23:15-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site ucbvax.UUCP Path: hou3c!burl!ulysses!harpo!decvax!ucbvax!fair From: fair@ucbvax.UUCP (Erik E. Fair) Reply-To: fair@Berkeley.ARPA (Erik E. Fair) Subject: Re: my note on MCI mail Message-ID: <110@ucbvax.UUCP> Date: Sun, 19-Feb-84 23:48:16 EST References: <840218222344.582791@MIT-MULTICS.ARPA> In-Reply-To: <840218222344.582791@MIT-MULTICS.ARPA> Organization: U.C. Berkeley This is a refutation to the notion that UUCP/USENET will collapse, contained in the conclusion of the referenced news article. In brief: 1. Assume that all UUCP/USENET sites must do computation that is useful to the owners of said site, in addition to the UUCP/USENET traffic that they carry. 2. Given 1., when traffic increases to a point where the `useful' work is not being done, excess traffic will be offloaded or cut off by the owners of the site. 3. Given 2., how & when does UUCP/USENET collapse? Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA  Date: 27 Feb 1984 18:23:29-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site ucbvax.UUCP Path: hou3c!burl!ulysses!mhuxl!ihnp4!harpo!idi!ios!qubix!sun!decwrl!decvax!ucbvax!fair From: fair@ucbvax.UUCP Subject: Re: "From " vs. "From:" in Sendmail Message-ID: <163@ucbvax.UUCP> Date: Sat, 25-Feb-84 16:26:05 EST Received: by hou3c.UUCP; Sun, 26-Feb-84 05:31:20 EST References: <450@sun.uucp> In-Reply-To: <450@sun.uucp> Organization: U.C. Berkeley Uh, I have a small nit to pick with John Gilmore. The example he used for showing the proper interpretation of `correct' mail headers from the UUCP land was wrong: >>For mail which has been passed solely thru uucp sites, the "From " line >>is clearly correct, since the "From:" line has not been maintained at >>(all) intermediate sites. E.g.: >> From dual!allegra!cbosgd!fair Thu Feb 23 17:01:34 1984 >> From: dual!cbosgd!fair >> >>The win would have been to make the envelope right for all uucp >>traffic, (which it already was for strictly-uucp traffic) and have >>sendmail fix the From: line to match the "From " line. This has not >>been done -- yet. Is there a uucp/mail expert in the house who can tell >>us WHY the envelope is "uucp" or some user, instead of the right thing? I have been many things in my time, but never have I been cbosgd!fair. I'm dual!fair or ucbvax!fair or fair@ucb-arpa.ARPA. The problem is that some 4.2 BSD sites out there are running bogus versions of sendmail which puts out the return address in the envelope in domain format. It gets worse when the letter passes through a working sendmail sites, because they try and undo the damage, and only succeed in hiding it. That letter there started life From dual!fair cbosgd changed that to From cbosgd!fair@dual.UUCP and allegra changed that to From dual!allegra!cbosgd!fair It gets really fun when someone tries to reply to that. This bug has been fixed by steve@nbires.UUCP, tjt@masscomp.UUCP, postmaster@uwisc-rsch.ARPA, and eric@BERKELEY.ARPA Some by my prodding them, some not. If you spot one of these, complain until it gets fixed, because all mail passing through the suspect site will have bogus return addreses, and only the silly people who keep the entire routing map in their heads (like me) will be able to get anything through the Emails. (Mark Horton, are you listening? Do I have to beat this to death?) Please, Help Stamp Out Sendmail Errors by sending your tax deductible contributions to Save the Network Box 10.2.0.78 Berkeley, California 94720 Thank you. Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA P.S. For those on USENET: 10.2.0.78 is ucbvax's ARPANET address. :-)  Date: 27 Feb 1984 21:53:09-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP Path: hou3c!burl!ulysses!harpo!decvax!genrad!grkermit!masscomp!kobold!tjt From: tjt@kobold.UUCP Reply-To: eagle!masscomp!kobold!tjt%mit-vax@mit-mc (hopefully works) Subject: Re: "From " vs. "From:" in Sendmail Message-ID: <277@kobold.UUCP> Date: Mon, 27-Feb-84 00:46:45 EST Received: by hou3c.UUCP; Mon, 27-Feb-84 15:47:46 EST References: <450@sun.uucp> <163@ucbvax.UUCP> In-Reply-To: <163@ucbvax.UUCP> Organization: Masscomp, Westford, MA For anyone who is interested: I fixed the sendmail bug described by Erik Fair (sending out domain based address in the unix-style "From " line) by switching from the 4.1c version of sendmail to the 4.2 version. Looking at the Version.c file indicated that this was explicitly fixed and is not an artifact of an aberrant configuration file. -- Tom Teixeira, Massachusetts Computer Corporation. Westford MA ...!{ihnp4,harpo,decvax}!masscomp!tjt (617) 692-6200 x275  Sender: Hamilton.ES@PARC-MAXC.ARPA Date: 27 Feb 84 20:05:41 PST (Monday) Subject: Bogus "Arpanet hosts" To: Header-People@mit-mc.ARPA cc: Hamilton.ES@PARC-MAXC.ARPA From: Bruce Hamilton Reply-To: Hamilton.ES@PARC-MAXC.ARPA It seems like every few days lately I try to reply to somebody, and the address on their "From" or "Reply-To" is phony. Maybe we have no right to expect usable return addresses from Usenet and CSNet (although I would contest even that premise), but certainly places like Columbia and CMU (to name two places where this has happened to me) ought to be able to munge any headers they fling out onto the Arpanet to reflect a valid Arpanet address, and NOT some bogus internal network address. Xerox's Grapevine software is very clever this way, so that insiders don't have to wade through @PARC-MAXC.ARPA, but outsiders do. Below is an example of the sort of thing I'm talking about: --Bruce ---------------------------------------------------------------- The message sent by Hamilton.ES at 27-Feb-84 14:53:47 PST could not be delivered to the following recipients because they were rejected by the MTP server "Maxc". The reason given was: Sorry, I never heard of an ARPA domain named "cmu-psy-a" shrager@cmu-psy-a.ARPA Original msg header being replied to: Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 27 FEB 84 13:50:19 PST Return-path: <@SUMEX-AIM.ARPA:shrager@cmu-psy-a> Redistributed: Xerox1100UsersGroup^.PA Received: from CMU-CS-PT by SUMEX-AIM.ARPA with TCP; Mon 27 Feb 84 13:26:07-PST Received: from CMU-PSY-A by CMU-CS-PT with CMUFTP; 27 Feb 84 16:20:59 EST Date: Mon, 27 Feb 84 16:15:52 EST From: shrager@cmu-psy-a.ARPA Subject: Touch Screen To: 1100users@sumex.ARPA ----------------------------------------------------------------  Date: 27 Feb 1984 23:18:51-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp4.UUCP Path: hou3c!burl!ulysses!mhuxl!ihnp4!gjm From: gjm@ihnp4.UUCP (Gary J. Murakami) Reply-To: gjm%ihnp4.UUCP@Berkeley (Gary J. Murakami) Subject: Re: "From " vs. "From:" in Sendmail Message-ID: <555@ihnp4.UUCP> Date: Mon, 27-Feb-84 20:24:48 EST Received: by hou3c.UUCP; Mon, 27-Feb-84 22:21:09 EST References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP> In-Reply-To: <277@kobold.UUCP> Organization: AT&T Bell Labs, Naperville, IL Last time I looked at cbosgd's config file, my analysis agreed with Erik Fair's analysis of the situation. Empirical evidence seems to point out that the path reversal problem still exists at more than one host. Part of the problem stems from the inconsistent treatment of a!b@c. Unfortunately the 4.2 distribution contains config files that do a considerable amount of header munging, and more hacking will probably make matters worse. Sendmail is still a mixed blessing, however some of us hope to eventually fix the (few) cursed parts. Gary Murakami AT&T Bell Laboratories ihnp4!gjm  Date: Mon, 27 Feb 84 23:26:56 EST From: Daniel Long Subject: Re: Bogus "Arpanet hosts" In-Reply-To: Your message of 27 Feb 84 20:05:41 PST (Monday) To: Hamilton.ES@PARC-MAXC.ARPA Cc: Header-People@mit-mc, long@BBN-UNIX Bruce, You have every right to expect usable return addresses from CSNET. If you can find any examples of un-replyable CSNET messages, we would be very interested in seeing the headers so we can correct the problem. CSNET problems/inquiries may be directed to CIC@CSNET-SH. Thanks, Dan Long Technical Liaison CSNET Coordination and Information Center  Date: Mon 27 Feb 84 21:22:48-PST From: Mark Crispin Subject: Re: Bogus "Arpanet hosts" To: Hamilton.ES@PARC-MAXC.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "Bruce Hamilton " of Mon 27 Feb 84 20:05:41-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Bruce - The TOPS-20 mailer, by deliberate design, does not perform any relay services beyond that of a bridge. CMU and Columbia both run this software (although your example involved CMU-CS-PT, a Unix system). Unlike the UUCP world, I consider store-and-forward relaying and relative addressing to be temporary measures pending the adoption of a universal standard for electronic mail addressing. It's too bad that so many people confuse "where" the person is with the "way to get there." I also have substantial reservations about the entire philsophy of header-munging. All too often I have seen my message headers transmogrified into invalid headers by a well-meaning, but incorrect, header modifier. Several delivery problems, especially in the early days of SMTP, proved to be undebuggable because a header modifier succeeded in destroying the information needed to figure out what happened. Worse is the habit of MMDF and certain other header modifiers to make a message header "cute" by applying certain rules of case modification; I'm really tired of seeing crap such as "Mit-Xx", "Su-Ai", or - the worst insult of all - "Mrc". I feel that a host using the services of a bridge should be willing to generate a message header that is valid at the other side of the bridge. It isn't difficult to do, especially if both sides of the bridge are willing to recognize Internet addresses. -- Mark -- -------  Date: Tue, 28 Feb 84 10:38 EST From: Steven Schwartz Subject: Diseased mail headers To: <@MIT-MC.ARPA:eagle!hou3c!ka@MIT-VAX>, postmaster@MIT-MC.ARPA, <@MIT-MC.ARPA:postmaster@MIT-VAX>, gjm%ihnp4.UUCP@UCB-VAX.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message of 28 Feb 84 00:56 EST from "Network_Server.Daemon (eagle!hou3c!ka@MIT-VAX@MIT-MC)" Message-ID: <840228153852.194555@MIT-MULTICS.ARPA> I have lately been receiving mail with headers like the following: Return-Path: <@MIT-MULTICS.ARPA,@MIT-MC:eagle!hou3c!ka@MIT-VAX> Received: from MIT-MC by MIT-MULTICS.ARPA TCP; 28-Feb-1984 00:56:12-est Date: 27 Feb 1984 23:18:51-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp4.UUCP Path: hou3c!burl!ulysses!mhuxl!ihnp4!gjm From: gjm@ihnp4.UUCP (Gary J. Murakami) Reply-To: gjm%ihnp4.UUCP@Berkeley (Gary J. Murakami) Subject: Re: "From " vs. "From:" in Sendmail Message-ID: <555@ihnp4.UUCP> Date: Mon, 27-Feb-84 20:24:48 EST Received: by hou3c.UUCP; Mon, 27-Feb-84 22:21:09 EST References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP> In-Reply-To: <277@kobold.UUCP> Organization: AT&T Bell Labs, Naperville, IL Somewhere along the line, someone's mail server is adding a second From: field. I'm certain it isn't the fault of the message sender(s?), but I have little idea of why this message is traveling between Berkeley (an ARPA site) and MIT-MC (also ARPA) via MIT-VAX. Anyone have any clues? Steve Schwartz SSchwartz at MIT-Multics  Date: Tue, 28 Feb 84 7:46:23 EST From: G B Reilly To: Mark Crispin cc: Header-People@mit-mc.arpa Subject: Re: Bogus "Arpanet hosts" MMDF does generate a header that is readable on both sides of a bridge. As for CSNet, for example, all messages that travel from a CSNet host to the ARPA have their addresses modified so that they end with "@CSNET-RELAY.ARPA". Hence, according to the RFC 822 standard, those messages can be replied to. Brendan Reilly  Date: 28 Feb 1984 18:22:55-EST From: eagle!hou3c!ka at mit-vax To: SSchwartz@MIT-MULTICS.ARPA, postmaster@MIT-MC.ARPA, postmaster@mit-vax, gjm@ihnp4.UUCP@UCB-VAX.ARPA Cc: header-people@MIT-MC.ARPA In-Reply-To: <840228153852.194555@MIT-MULTICS.ARPA> Subject: Re: Diseased mail headers The message originated on the USENET and was forwarded to the mailing list, which explains the route. The extra "From:" line is a gift of the code on mit-vax to convert from UUCP mail to RFC 822 mail. The first "From:" lines should really be a "Sender:" line. Eventually Berkeley will take over the gateway since they have direct access to the ARPANET. Kenneth Almquist ka@hou3c.UUCP ealge!hou3c!ka@mit-vax ihnp4!hou3c!ka@Berkeley harpo!hou3c!ka@seismo P.S. If people on this list prefer not to see the stuff from USENET, I can stop gatewaying it. I can also (to a limited extent) weed out specific topics if that is desired.  Date: 28 Feb 1984 18:23:11-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP Path: hou3c!burl!ulysses!harpo!seismo!rlgvax!cvl!umcp-cs!chris From: chris@umcp-cs.UUCP Subject: Re: "From " vs. "From:" in Sendmail Message-ID: <5472@umcp-cs.UUCP> Date: Sun, 26-Feb-84 19:53:12 EST Received: by hou3c.UUCP; Tue, 28-Feb-84 16:53:17 EST References: <5638.31.445827921@ucbarpa> <450@sun.uucp> In-Reply-To: <450@sun.uucp> Organization: Univ. of Maryland, Computer Science Dept. Well, on our system the uucp "envelope" info is usually wrong because uux uses getpwuid(getuid())->pw_name, but it is invoked on behalf of the fake user "mmdf" when MMDF dequeues UUCP channel mail. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relay  Date: 28 Feb 1984 18:23:18-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Path: hou3c!burl!ulysses!allegra!alice!research!dmr From: dmr@research.UUCP Subject: addressing follies Message-ID: <1023@research.UUCP> Date: Tue, 28-Feb-84 02:41:37 EST Received: by hou3c.UUCP; Tue, 28-Feb-84 05:00:29 EST Here, for your enjoyment, is the first line of the last 12 uucp letters received by research from ucbvax. I'm especially fond of the first one. Too bad it doesn't have a % to make it perfect. From @Ucl-Cs.ARPA:@Caga.AC.UK:@Ucl-Cs.ARPA:lcp@Camsteve.AC.UK From @SU-SCORE.ARPA:@SU-AI:MACKAY@WASHINGTON From @SU-SCORE.ARPA:@SU-AI:greep@SU-DSN From @SU-SCORE.ARPA:@SU-AI:phil@RICE From @SU-SCORE.ARPA:@SU-AI:sdcarl!rusty@Berkeley From @SU-SCORE.ARPA:DRF@SU-AI From @SU-SCORE.ARPA:gwyn@brl-vld From @SU-SCORE.ARPA:phil@RICE From Ellis@YALE.ARPA From fateman@ucbdali.Berkeley.ARPA From kahn@UCLA-CS.ARPA From lbl-csam!FURUTA@WASHINGTON.ARPA  Date: Tue 28 Feb 84 16:33:44-PST From: Mark Crispin Subject: Re: addressing follies To: Header-People@MIT-MC.ARPA In-Reply-To: Message from "eagle!hou3c!ka at mit-vax" of Tue 28 Feb 84 15:23:18-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Some of those addresses are perfectly valid, in particular: @SU-SCORE.ARPA:DRF@SU-AI @SU-SCORE.ARPA:gwyn@brl-vld @SU-SCORE.ARPA:phil@RICE Ellis@YALE.ARPA kahn@UCLA-CS.ARPA The following addresses are bogus because ":" is used in the source path multiple times. Score's software has always done the right thing in the past; unless there was a bug suddently introduced I believe that somebody in the mail chain after Score (probably some Unix someplace) bogotified it. @SU-SCORE.ARPA:@SU-AI:MACKAY@WASHINGTON @SU-SCORE.ARPA:@SU-AI:greep@SU-DSN @SU-SCORE.ARPA:@SU-AI:phil@RICE @SU-SCORE.ARPA:@SU-AI:sdcarl!rusty@Berkeley ^-- these addresses would be valid if this colon was a comma instead. The following address is bogus because "Caga.AC.UK" and "Camsteve.AC.UK" are not valid in the Internet domain yet. Note that the excessive colons appear here as well, bolstering my contention that somebody is incorrectly converting commas to colons at the Internet/UUCP bridge. @Ucl-Cs.ARPA:@Caga.AC.UK:@Ucl-Cs.ARPA:lcp@Camsteve.AC.UK The following address is bogus because "ucbdali.Berkeley.ARPA" is not valid in the Internet domain yet. fateman@ucbdali.Berkeley.ARPA The following address is bogus in the Internet world due to the presence of UUCP syntax. WASHINGTON.ARPA is a TOPS-20 site and does not use UUCP syntax. Somebody obviously thought it does, probably in the UUCP world. lbl-csam!FURUTA@WASHINGTON.ARPA -------  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA22845; Tue, 28 Feb 84 10:52:27 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14/4.14.2) id AA00386; Tue, 28 Feb 84 10:52:37 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.13.2) id AA01592; Tue, 28 Feb 84 10:25:51 pst Date: Tue, 28 Feb 84 10:25:51 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8402281825.AA01592@ucbopal.CC.Berkeley.ARPA> To: SSchwartz@MIT-MULTICS.ARPA Subject: Re: Diseased mail headers Cc: ihnp4!gjm@Berkeley, header-people@MIT-MC.ARPA, cbosgd!mark@Berkeley, postmaster@MIT-MC.ARPA, postmaster@MIT-VAX.ARPA, postmaster@Berkeley In reply to: Date: Tue, 28 Feb 84 10:38 EST From: Steven Schwartz Subject: Diseased mail headers To: <@MIT-MC.ARPA:eagle!hou3c!ka@MIT-VAX>, postmaster@MIT-MC.ARPA, <@MIT-MC.ARPA:postmaster@MIT-VAX>, gjm@ihnp4.UUCP Cc: header-people@MIT-MC.ARPA In-Reply-To: Message of 28 Feb 84 00:56 EST from "Network_Server.Daemon (eagle!hou3c!ka@MIT-VAX@MIT-MC)" Message-Id: <840228153852.194555@MIT-MULTICS.ARPA> I have lately been receiving mail with headers like the following: Return-Path: <@MIT-MULTICS.ARPA,@MIT-MC:eagle!hou3c!ka@MIT-VAX> Received: from MIT-MC by MIT-MULTICS.ARPA TCP; 28-Feb-1984 00:56:12-est Date: 27 Feb 1984 23:18:51-EST From: eagle!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp4.UUCP Path: hou3c!burl!ulysses!mhuxl!ihnp4!gjm From: gjm@ihnp4.UUCP (Gary J. Murakami) Reply-To: gjm%ihnp4.UUCP@Berkeley (Gary J. Murakami) Subject: Re: "From " vs. "From:" in Sendmail Message-ID: <555@ihnp4.UUCP> Date: Mon, 27-Feb-84 20:24:48 EST Received: by hou3c.UUCP; Mon, 27-Feb-84 22:21:09 EST References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP> In-Reply-To: <277@kobold.UUCP> Organization: AT&T Bell Labs, Naperville, IL Somewhere along the line, someone's mail server is adding a second From: field. I'm certain it isn't the fault of the message sender(s?), but I have little idea of why this message is traveling between Berkeley (an ARPA site) and MIT-MC (also ARPA) via MIT-VAX. Anyone have any clues? Steve Schwartz SSchwartz at MIT-Multics ------ It looks like a USENET news article was introduced directly into the mail system at MIT-VAX without a mail header or without a null line (end of header indicator) between the mail header and the news article header. Or somewhere along the mail relay path, the null line between the mail header and news article header was lost. The following headings in the message above appear to be USENET news article header fields (some of which have be modified in the mail system): Date: 27 Feb 1984 23:18:51-EST Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp4.UUCP Path: hou3c!burl!ulysses!mhuxl!ihnp4!gjm From: gjm@ihnp4.UUCP (Gary J. Murakami) Reply-To: gjm%ihnp4.UUCP@Berkeley (Gary J. Murakami) Subject: Re: "From " vs. "From:" in Sendmail Message-ID: <555@ihnp4.UUCP> Date: Mon, 27-Feb-84 20:24:48 EST Received: by hou3c.UUCP; Mon, 27-Feb-84 22:21:09 EST References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP> In-Reply-To: <277@kobold.UUCP> Organization: AT&T Bell Labs, Naperville, IL The "Reply-To:" with the "@Berkeley" was probably added by MIT-VAX. The message did not go through Berkeley. (sendmail on UCBVAX generates full domain names, eg. @Berkeley.ARPA, and Received fields) Bill Wells, Computing Services, U.C. Berkeley wcwells@Berkeley.ARPA or ucbvax!wcwells  Date: Tue, 28 Feb 84 23:30:00 EST From: Doug Kingston To: Header-People@MIT-MC Reply-To: DPK@BRL-VGR, Reilly@UDEL-RELAY, Steve@UCL-CS Subject: User selectable mailboxes We have decided that we would like to add a facility to the MMDF local channel, to allow users to have mail delivered to a file other than there regular mailbox simply by having the mail addressed with a slightly different "mailid". We already have the facility for have mail delivered to arbitrary files and processes, but due to the security implications, this kind of delivery is under the control of the system management. This new facility should be one that can be invoked by the user without bothering the management. It must also be sufficiently restricted that outside users cannot create random files or destroy same. Our strawman proposal for implementing this facility calls for they following syntax to be recognized: "user" deliver to user's regular mailbox (/disk/user/mailbox) "user=h-p" deliver to alternate mailbox hp (/disk/user/mailbox=h-p) We chose "=" as the magic character to trigger this, since it did not appear to have any magic properties anywhere else we could think of. Can anyone think of any problems this would cause, and if so, what suggestions do you have for altering the syntax to be more useable? We are not wedded to = or even the precise syntax used here. We would be interested in hearing what other systems may have implemented such a facility and what syntax they have used. Fighting the 150 message a day habit, -Doug-  Date: Wed, 29 Feb 84 07:06 EST From: "Robert W. Kerns" Subject: User selectable mailboxes To: DPK@BRL-VGR.ARPA, Reilly@UDEL-RELAY.ARPA, Steve@UCL-CS.ARPA Cc: Header-People@MIT-MC.ARPA In-reply-to: The message of 28 Feb 84 23:30-EST from Doug Kingston I don't understand. This seems to be purely an internal issue between your system management and the users you want to restrict to creating mailboxes with only certain names. Any system I've had much truck with has always let people create mailboxes under any name whatsoever. Why do we need a convention for the sake of sites that want to be restrictive? Anyone sending to this user's special mailbox has to know the name of the special-purpose mailbox anyway, and agree to use that name. Presumably he has to be told anyway. People do this all the time with mass-mailing lists, with names like SMITH-JUNK, etc.  Date: Wed, 29 Feb 84 07:06 EST From: "Robert W. Kerns" Subject: User selectable mailboxes To: DPK@BRL-VGR.ARPA, Reilly@UDEL-RELAY.ARPA, Steve@UCL-CS.ARPA Cc: Header-People@MIT-MC.ARPA In-reply-to: The message of 28 Feb 84 23:30-EST from Doug Kingston I don't understand. This seems to be purely an internal issue between your system management and the users you want to restrict to creating mailboxes with only certain names. Any system I've had much truck with has always let people create mailboxes under any name whatsoever. Why do we need a convention for the sake of sites that want to be restrictive? Anyone sending to this user's special mailbox has to know the name of the special-purpose mailbox anyway, and agree to use that name. Presumably he has to be told anyway. People do this all the time with mass-mailing lists, with names like SMITH-JUNK, etc.  Date: Wednesday, 29 Feb 1984 09:01-PST To: DPK@BRL-VGR, Reilly@UDEL-RELAY, Steve@UCL-CS Cc: Header-People@MIT-MC Subject: Re: User selectable mailboxes In-reply-to: Your message of Tue, 28 Feb 84 23:30:00 EST. From: greep@SU-DSN I modified the delivery part of Rand MH to do something similar, although I used "." instead of "=", e.g. "greep.foomail" means user greep, mailbox foomail. What then happens is that if the recipient has specified his own program to handle his incoming mail (this was already part of MH), one of the arguments that is passed to that program is the mailbox, in this case "foomail". The program can do whatever it wants with the message. If the address consists of a user name with no mailbox, then the argument defaults to "inbox". If the user does not have his own program to handle incoming mail, then the part after the period is ignored and the mail all goes in one place. This is how we handle bboards. For example, "dsn-WorkS" is aliased to "news.works". There is a fake user called "news" which has a shell file to handle incoming mail. The shell program makes sure that the mailbox specified exists and then puts the message in it. If the mailbox isn't valid, the program returns a non-zero return code which tells the mailer to notify the sender of the error by sending back a message, which will include any error messages that were output by the program.  Date: 1 Mar 1984 12:55:00 PST From: POSTEL@USC-ISIF Subject: dead hosts ? To: header-people@MIT-MC I recently sent out an RFC announcement to a long mailing list, and as expected received numerous messages from various mailers daemons about things that did not work. The largest group of these messages were from the mailer on my home system complaining that a few destination hosts were down every time it tried to deliver the mail for three days. The people who have mailboxes on these hosts might consider moving to more reliable hosts. This time the hosts in question were: MIT-ML, SRI-UNIX, AMES-TSS, and LL. --jon. -------  Date: 1 March 1984 13:37 pst From: Bakin.SSID at HI-MULTICS Subject: RESENT field :) To: HEADER-PEOPLE at MIT-MC Acknowledge-To: Bakin.SSID at HI-MULTICS I recently received a message with two fields I had never seen before: RESENT-(FROM TO) I took offense at the person listed as resent from, I don't know him, why should he resent me! I was pleased that the mailer told me that guy resents me, I'll never send him mail again, but how did the mailer figure it out? YES, it was me he resents, because I was listed as the RESENT-TO! But this jerk also resents an entire mailing list, because they were in there too. Does some RFC exist specifying fields such as this? Is there a FLAMING-DEATH-TO field? or maybe a VOTE-FOR field? I was aware of such fields as SENDER:, FROM:, and I had thought something like Redistributed-By, and maybe Redistributed-To:, but I really think we should leave such personal fields as RESENTMENT out headers entirely! Jerry. P.S. Maybe this should be RE-SENT-(FROM TO)?  Received: by YALE-BULLDOG via CHAOS; Thu, 1 Mar 84 17:38:59 EST Date: Thu, 1 Mar 84 17:34:59 EST From: John R Ellis Subject: Re: RESENT field :) To: Bakin.SSID@HI-MULTICS.ARPA Cc: HEADER-PEOPLE@MIT-MC.ARPA In-Reply-To: Bakin.SSID at HI-MULTICS, 1 March 1984 13:37 pst RESENT-(FROM TO) ... Does some RFC exist specifying fields such as this? Read RFC 822. P.S. Maybe this should be RE-SENT-(FROM TO)? My Random House College Dictionary (1975), admittedly not the best dictionary, has the following definition for "resend": resend, ... resent, resending. 1. to send again. 2. to send back. So "Resent-From" is hyphenated correctly. -------  Date: 1 Mar 1984 22:06:04-EST From: allegra!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP Path: hou3c!burl!ulysses!harpo!decvax!genrad!grkermit!masscomp!kobold!tjt From: tjt@kobold.UUCP Reply-To: ucbcad!masscomp!kobold!tjt@Berkeley.ARPA (hopefully) Subject: Re: "From " vs. "From:" in Sendmail Message-ID: <279@kobold.UUCP> Date: Wed, 29-Feb-84 09:13:57 EST Received: by hou3c.UUCP; Thu, 1-Mar-84 02:49:46 EST References: <450@sun.uucp> <163@ucbvax.UUCP> <277@kobold.UUCP> <555@ihnp4.UUCP> In-Reply-To: <555@ihnp4.UUCP> Organization: Masscomp, Westford, MA Although I missed Rob Pike's "cat -v considered harmful" talk at the Toronto USENIX conference, I understood he mentioned that the current trend in arcane command switches would no double lead to an extension language for cat. It occurred to me the other day after wrestling with configuration files that sendmail must be the aforementioned extension language (where is TECO now that we need you?). -- Tom Teixeira, Massachusetts Computer Corporation. Westford MA ...!{ihnp4,harpo,decvax}!masscomp!tjt (617) 692-6200 x275  Date: 1 Mar 1984 22:06:12-EST From: allegra!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 5/3/83; site ukc.UUCP Path: hou3c!burl!ulysses!harpo!seismo!hao!hplabs!zehntel!tektronix!uw-beaver!cornell!vax135!ukc!mjb From: mjb@ukc.UUCP (M.J.Bayliss) Subject: Re: Strange From headers Message-ID: <4097@ukc.UUCP> Date: Thu, 16-Feb-84 06:45:03 EST Received: by hou3c.UUCP; Thu, 1-Mar-84 18:58:40 EST References: <215@heurikon.UUCP> In-Reply-To: <215@heurikon.UUCP> Organization: Computing Lab. Kent University, England This is a sendmail problem and it's not just restricted to the sites named in the original article (ukc also generates the same problem). What happens (as far as i can work out) is: sendmail generates an UGLYUUCP from line to find the sitename to put in the "remote from...." it takes the first component of the $g macro but... $g is not always correct! Sites that cause this problem are not adding their own sitename onto the sender's address at the right place. I've spent two days examining trace output from sendmail and as far as i can tell $g is continually reset as the sender address is modified (rulesets 3, 1, 4 and the uucp mailer sender ruleset). This should be an easy bug to fix but... When I wrote my sendmail.cf I found I had to use the uucp ruleset to put "ukc!" on the front of the sender's name, if I didn't sendmail complained because there was no "!" in the sender. Following the same logic I should just need to put "ukc!" at the start of every sender's name that goes through the uucp ruleset. However, this doesn't work and $g does not include the "ukc!", but does contain the full uucp route upto and including the sender's site. I suspect it's because we're all trying to be too clever, and getting carried away converting everything in sight into "user@site.net" triples. Are there any sendmail experts out there? Is Eric Allman reading this? I for one would appreciate help just to stop sites adjacent to me complaining. mike bayliss University of Kent. ...!{vax135,mcvax}!ukc!mjb P.S. no flames telling me I should use standard configuration files, I'm trying to cope with a local network of 8 systems (2 different mail protocols) and two wide area networks (2 different mail protocols and 2 different naming conventions).  Date: 1 Mar 1984 22:06:21-EST From: allegra!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP Path: hou3c!burl!ulysses!mhuxl!ihnp4!dual!fair From: fair@dual.UUCP (Erik E. Fair) Subject: Re: addressing follies Message-ID: <320@dual.UUCP> Date: Wed, 7-Mar-84 02:40:18 EST Received: by hou3c.UUCP; Thu, 1-Mar-84 18:52:45 EST References: <1023@research.UUCP> In-Reply-To: <1023@research.UUCP> Organization: Dual Systems, Berkeley, CA If anyone is curious for a translation of those mysterious address, you may inquire at one of the addresses below: Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA dual!fair@BERKELEY.ARPA {ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair Dual Systems Corporation, Berkeley, California  Date: Fri, 2 Mar 84 00:43 EST From: "Robert W. Kerns" Subject: RESENT field :-<:) To: Bakin.SSID@HI-MULTICS.ARPA Cc: HEADER-PEOPLE@MIT-MC.ARPA In-reply-to: The message of 1 Mar 84 16:37-EST from Bakin.SSID at HI-MULTICS Date: 1 March 1984 13:37 pst From: Bakin.SSID at HI-MULTICS Does some RFC exist specifying fields such as this? Is there a FLAMING-DEATH-TO field? or maybe a VOTE-FOR field? Yeah, RFC822, I believe. You're no longer allowed to REDISTRIBUTE mail, and this has caused a notable increase in user RESENTment. It also subjects us to a lot of chatter between mailers about who got what from whom and other interbeing private topics that really shouldn't be told in public. I've taken to censoring my headers! If you don't wish to cause RESENTment, you can always be straight FORWARD! Unfortunately, the response does not always go as you'd like.  Date: 2 Mar 84 1144 EST From: Rudy.Nedved@CMU-CS-A To: POSTEL@USC-ISIF Subject: Re: dead hosts ? CC: header-people@MIT-MC In-Reply-To: "POSTEL@USC-ISIF's message of 1 Mar 84 15:55-EST" Message-Id: <02Mar84.114453.EN0C@CMU-CS-A> SRI-Unix seems to be answering for SRI-SPRM for some reason. I have sent there system (by hand) mail about the problem per our users complaints (since we have users getting mail from them...) and we have a policy now of depending on NIC to have the correct information about hosts. -Rudy  Date: 2 Mar 1984 10:08-EST Sender: MOOERS@BBNA Subject: Re: RESENT field :) From: MOOERS@BBNA To: Bakin.SSID@HI-MULTICS Cc: HEADER-PEOPLE@MIT-MC Cc: Mooers@BBNA Message-ID: <[BBNA] 2-Mar-84 10:08:58.MOOERS> In-Reply-To: The message of 1 March 1984 13:37 pst from Bakin.SSID at HI-MULTICS I agree completely that "RESENT" is an unfortunate choice. I was told that Dave Crocker thought it was cute. At the time that RFC822 was written, HERMES and MSG used "REDISTRIBUTED" and MM used "REMAILED". I don't know that anyone was using "RESENT". HERMES spells the fields "ReSent". What else can you do? ---Charlotte  Date: 2 Mar 1984 10:52-PST Sender: BILLW@SRI-KL Subject: Re: dead hosts ? From: BILLW@SRI-KL To: Rudy.Nedved@CMU-CS-A Cc: POSTEL@USC-ISIF, header-people@MIT-MC Message-ID: <[SRI-KL] 2-Mar-84 10:52:56.BILLW> In-Reply-To: <02Mar84.114453.EN0C@CMU-CS-A> SRI-UNIX's Imp port is broken, and it is temporaryilly using the port assigned to sprm. We hope the change is not long-lived enough to announce to any but the most prolific of those sending mail to SRI-UNIX. Since they are the primary gateway from usenet, its nic to have them up somewahere... BillW, Postmaster, SRI  Date: 2 Mar 1984 18:58:04-EST From: allegra!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site vax135.UUCP Path: hou3c!hocda!houxm!vax135!martin From: martin@vax135.UUCP (Martin Levy) Subject: .ARPA hard coded into sendmail/src/daemon.c Message-ID: <638@vax135.UUCP> Date: Thu, 1-Mar-84 20:14:07 EST Received: by hou3c.UUCP; Thu, 1-Mar-84 22:00:34 EST Organization: AT&T Bell Labs, Holmdel, NJ when using sendmail around a local ethernet and or thru any other media where sendmail (in daemon mode) get's it's mail via sockets, it will set up the Received header line like this:- Received: from vax135.UUCP (vax135.ARPA) by marvin.UUCP (4.12/4.7) id AA03076; Thu, 1 Mar 84 19:58:24 est now, we are not on the ARPANET, and hence the .ARPA is not correct. this is very hard coded in, and only happens when the HELO argument (SMTP RFC???) does not match gethostbyaddr() of the socket. now, i pass vax135.UUCP over as the HELO arg, and the output of gethostaddr() is "vax135", ok so whats up?, i think i should just send over "HELO vax135", but the default sendmail scripts use vax135.UUCP. a simple fix is to put .ether instead of .ARPA in the name, but that's even worse!!. whats the correct fix while still leaving things 'configurable' by sendmail.cf?. martin levy.  Date: 4 Mar 84 2143 EST From: Rudy.Nedved@CMU-CS-A To: Header-People@MIT-MC Subject: smtp, errors and delivery Message-Id: <04Mar84.214333.EN0C@CMU-CS-A> A large number of sites seem to handle "mail from:" command errors by issuing the command "mail from:<>" as the next command. Considering that alot of mail is forwarded and that any mail with a null return is "droppable" if an error occurs, I don't think this is a wise way of handling "mail from" errors for the user will not get an error message. The following is an example of this code: 220 CMU-CS-A.ARPA TOPS-10 SMTP server ready 1C(50)-2 HELO bazola 250 CMU-CS-A.ARPA MAIL FROM: 500 malformed local host name 'bonzo_land', for line 'MAIL FROM:'. MAIL FROM:<> 250 Mail okay. RCPT TO: 250 Rcpt okay. DATA 354 Ready for mail. 250 Mail completed. QUIT 221 CMU-CS-A.ARPA TOPS-10 SMTP service terminating I can understand that the code was probably installed duringthe tcp transition days when alot of smtp servers were still "buggy" but I can not see a reason for it now. Is there some other reason or should I send mail to sites that have this "old code" installed? Thanks, -Rudy  Date: Mon 5 Mar 84 01:09:03-PST From: Mark Crispin Subject: Re: smtp, errors and delivery To: Rudy.Nedved@CMU-CS-A.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Sun 4 Mar 84 21:43:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Rudy - The TOPS-20 SMTP sender (part of MMailr) is one of those SMTP senders who will send a MAIL FROM: with a null argument if the SMTP server rejects the command. This is to maximize what chance the message has of getting through. I think that this is completely within reasonable fault-tolerance procedures. I will resist any pressure to change it, until and unless CMU is willing to undertake the responsibility of reliably delivering any and all mail originating from any and all TOPS-20 systems on the Internet. -- Mark -- -------  Date: Mon, 5 Mar 84 10:13:30 GMT From: Hsmith@ucl-cs.arpa To: msggroup@brl.arpa, header-people@mit-mc.arpa Subject: CBMS 84 International Federation for Information Processing IFIP WG 6.5 International Working Conference on COMPUTER-BASED MESSAGE SERVICES Nottingham, UK 1-4th May 1984 Final Announcement Conference Sessions include: Message Architecture & Multimedia Systems Naming/Addressing and Directory Services User Interface Architecture Services and Cost/Benefit Issues Regulatory and Security Considerations Conference and Message System Interconnection Message Server Implementations Teletex Systems Panel I - International CBMS Standards Activities:Overview Panel II - International CBMS Standards Activities: The Commercial View Panel III - Intermediate Term Interconnection Strategies Working Group Sessions The objective of this conference is to promote the interchange of information and discussion about national and international computer-based message services. Because many service and inter- connection requirements remain to be established for these emerg- ing systems, the conference includes a number of working ses- sions. Issues to be discussed in the working sessions include both technical and economic/political aspects of message ser- vices. The conference brings together 27 speakers from eight countries to present papers on computer-based messaging systems and ser- vices. There are no parallel paper sessions in order to allow delegates to attend all presentations. In addition to the papers, three panels serve to review progress and issues in; standards activity, commercial developments, and intermediate term interconnection requirements. The final day and a half is devoted to working sessions which will develop the issues raised by the panels and address a number of application topics. The application topics will include multimedia systems, directory service standards, conferencing system requirements, user environment services, and facilities for impaired communities. Venue The conference will be held in the Albany Hotel situated in the centre of Nottingham, UK. The City is approximately two hours by train from London. Air Travellers arriving at Heathrow or Gatwick may also reach the city via a shuttle flight to East Midlands Airport. The City is some twenty minutes taxi ride from the airport. Further information will be sent with registration details. Registration The Conference registration fee is #90 (90 pounds UK sterling). This includes a copy of the proceedings, a conference dinner on May 2nd, and refreshments during the sessions. Address for Further Details: CBMS '84 Human Computer Interaction Group Nottingham University Nottingham NG7 2RD England Arpa: hsmith@ucl-cs.isid Telephone: (+44) 602 506101 Ext: 3587 Telex: 37346 UNINOT G Programme Committee G. Antoni, Italy J. Palme, Sweden A. Danthine, Belgium S. Ramani, India P. Kirstein, UK P. Schicker, Switzerland J. Garcia-Luna, USA K. Smaaland, Norway R. Miller, USA L. Tarouco, Brazil N. Naffah, France J. White, USA G. Neufeld, Canada K. Wimmer, German Federal Republic Organising Committee H.T. Smith, Nottingham University, UK W. Dzida, GMD Bonn, German Federal Republic R. Uhlig, Bell Northern Research, Canada  Date: 5 Mar 84 1116 EST From: Rudy.Nedved@CMU-CS-A To: Mark Crispin Subject: Re: smtp, errors and delivery CC: Header-People@MIT-MC In-Reply-To: "Mark Crispin's message of 5 Mar 84 04:09-EST" Message-Id: <05Mar84.111651.EN0C@CMU-CS-A> Mark, I didn't even know that TOPS-20 was in the crowd of people doing this way of handling rejected "mail from" commands. It looks like it is a defacto standard then since Unix, ITS and TOPS-20 do it. I don't understand why people use this mechanism if they want their users to have their mail delivered or get an error message back. I consider the risk too high to take the chance with using a null-return or no-return path....sigh. Maybe it is the case that these same systems parse the headers if they don't have a return-path and try to use the address?? If so the picture doesn't seem so bleak afterall. Well back to work....I not going to bug anyone except for people around CMU. -Rudy  Date: 5 Mar 84 1250 EST (Monday) From: don.provan@CMU-CS-A To: Rudy.Nedved@CMU-CS-A Subject: Re: smtp, errors and delivery CC: Mark Crispin , Header-People@MIT-MC In-Reply-To: <05Mar84.111651.EN0C@CMU-CS-A> Message-Id: <05Mar84.125014.DP0N@CMU-CS-A> Rudy, Look at your example: your mailer is all set to reject the mail altogether because it doesn't like "bonzo_land". How can you be upset about the remote mailer sending you a blank field? Its first priority is to get the mail delivered. If you're going to reject the only from address it has, what else can it do? You aren't going to return an error message there anyway. I don't really understand why mail receivers are parsing this field so carefully, anyway. I've had several sites i couldn't get mail to because they tried to parse '"Provan Don%c"@LLL-MFE' and couldn't, so they rejected the mail. Its bad enbough that they can't parse it, but to reject some mail because a field that shouldn't ever get used can't be parsed is silly. I wasn't smart enough to think of sending an empty address if it wouldn't take my real address, but now that it's been suggested, I think I'll add it. Frankly, I think the only legal error to a mail command should be "too busy to send mail now." I don't think it makes sense to reject it because of a syntax error.  Date: Mon, 5 Mar 84 11:16:36 PST From: Rich Wales To: Header-People@MIT-MC Subject: Re: "MAIL FROM:<>" in SMTP Instead of using an empty "MAIL FROM:" address if the original return path is rejected for some reason by the receiving site, I would suggest trying a "Postmaster" address, as in the following scenario: 220 FOO.ARPA SMTP Server ready HELO BLAH.ARPA 250 FOO.ARPA MAIL FROM:<"Fred Flintstone"@BLAH.ARPA> 501 Yecch! I don't like <"Fred Flintstone"@BLAH.ARPA> MAIL FROM: 250 OK . . . This way, at least, the delivery-error message (if any) will go some- where and can be dealt with by a (probably already overworked) wizard. If, for some inscrutable reason, the receiving site rejects a "Postmas- ter" return address, THEN go ahead and use an empty address. Whenever a receiving site rejects a valid "MAIL FROM:" address and the mailer has to resort to using "Postmaster", of course, the gurus at the sending site should be notified in some way (e.g., by a note in a log file). This is doubly true in cases where a receiving site rejects a "Postmaster" address -- something that should never, ever happen! -- Rich  Date: Mon 5 Mar 84 13:23:51-PST From: Mark Crispin Subject: Re: smtp, errors and delivery To: Rudy.Nedved@CMU-CS-A.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Mon 5 Mar 84 11:16:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Rudy - The problem is that it is a "de facto standard" to reject MAIL FROM: commands for the slightest bogosity (even if the bogon turns out to be at the SMTP server's end!). A number of SMTP servers reject a-d-l's, for example. Still others reject mail from "unknown hosts" when the problem is that the SMTP server's host table is out of date. Yet another problem is that many (most?) SMTP servers reject bracketed host names. There are a number of "nameless" TOPS-20s which talk TCP/IP and use their bracketed address forms as a name (e.g. [1.2.3.4]). This is valid according to the standard and TOPS-20 fully implements it, but try convincing a large number of SMTP servers of that!! I won't even go into the details of how to reply or return messages in these cases (other than "implement the standard"). -- Mark -- -------  Date: Mon 5 Mar 84 13:30:58-PST From: Mark Crispin Subject: Re: smtp, errors and delivery To: don.provan@CMU-CS-A.ARPA cc: Rudy.Nedved@CMU-CS-A.ARPA, Header-People@MIT-MC.ARPA In-Reply-To: Message from "don.provan@CMU-CS-A" of Mon 5 Mar 84 12:50:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Don - I take the middle ground. I think it is completely alright to reject a MAIL FROM command because of a syntax error PROVIDED that the syntax parser COMPLETELY implements the standard. That includes: . all forms of quoting . source path route lists . bracketed or #'d host addresses in lieu of host names Very few SMTP servers do. I believe TOPS-20's SMTP server does (if it doesn't, it's a bug because all the code is there). I don't think an SMTP server should try to validate a host name in a MAIL FROM command other than checking it for syntactical validity. RCPT TO: is a different matter entirely. -- Mark -- -------  Date: Mon, 5 Mar 84 17:07:15 cst From: solomon@wisc-crys (Marvin Solomon) Message-Id: <8403052307.AA04439@wisc-crys.ARPA> Received: by wisc-crys.ARPA (4.22/3.7) id AA04439; Mon, 5 Mar 84 17:07:15 cst To: Header-People@mit-mc.ARPA Subject: Re: smtp, errors and delivery I can't resist putting in my two bits. An important principle in mail systems is the notion of responsibility. If we want reliable mail systems, then we should design them so that throughout a message's lifetime, there is always some module responsible for it. When a server SMTP accepts a message, it is taking responsibility for that message. If for some reason it can't deliver the message to the recipient, it has the responsibility to return it to the sender. If it has reason to believe that it is being asked to accept a piece of mail that will be unreturnable, it has every right (indeed duty) to reject it. Otherwise, it may end up with no alternative but to drop the message on the floor--the very worst thing to do in any mail systems. The old BBN SMTP server (used with many Berkeley 4.1 UNIX systems) got a lot of flack (righly) for being too promiscuous in what it would accept; it would take just about anything, and figure out later what to do about it: MAIL FROM: !random@@garbage? 250 Fine and dandy RCPT TO: >you got to be kidding> 250 You betcha DATA blah blah blah . 250 Yes sir boss! I would much rather see mail bounce back to the sender if something goes wrong, than to have it flush down a black hole. If the server doesn't like the MAIL FROM address, the sender should take the rejection gracefully, and inform the sender that something is wrong. The sender (if he is a naive user) will yell at his mail system maintainer, who will see what's wrong and fix it. The idea of substituting "Postmaster" has a lot to recommend it, but if that's rejected (perhaps because it's the host name, not the local part, that's at issue), the sender shouldn't cram the mail down the receiver's throat. Null return addresses should only be used for the error messages themselves. If many (most?) SMTP servers are broken, they should be fixed, not coded around by breaking the senders as well.  Date: 5 Mar 84 2058 EST (Monday) From: don.provan@CMU-CS-A To: Mark Crispin Subject: Re: smtp, errors and delivery CC: Header-People@mit-mc In-Reply-To: "Mark Crispin's message of 5 Mar 84 16:30-EST" Message-Id: <05Mar84.205835.DP0N@CMU-CS-A> Mark, Why should you ever reject it because of a bogus Mail From field? All you do by that is make sure the receiver doesn't get the mail. Of all the parties involved, the receiver is the one that can't possibly be at fault, so why limit the sevice you provide him? I agree that bells and wistles should go off all over the place, but not at the expense of delivery.  Date: Mon, 5 Mar 84 23:07:22 EST From: Doug Kingston To: don.provan@cmu-cs-a cc: Rudy.Nedved@cmu-cs-a, Mark Crispin , Header-People@mit-mc Subject: Re: smtp, errors and delivery There are two different philosophies being used here. One says "Deliver the message at all costs", while the other says "Make a reliable deliver, or return it". The first is the method used by people that will give you a null return addresss (MAIL FROM:<>) while the second is the more conservative stratagy and gives you a better guarantee that you will know that the message was delivered (or not). MMDF (the system I maintain) is a more conservative mailer. We rigorously adhere to the transfer of responsibility model and we always give a return address (even it is the postmaster address). We do not attempt to supply alternate MAIL FROM addresses, and as it turns out we now almost never get rejections based on the MAIL FROM address. This was not true when the net first changed protocols though. Mark and others are not wrong in what they are doing, it just shows a difference in priorities. Cheers, -Doug-  Date: 5 Mar 1984 18:49:54-EST From: allegra!hou3c!ka at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site cornell.UUCP Path: hou3c!hocda!houxm!ihnp4!harpo!ulysses!burl!clyde!floyd!vax135!cornell!bill From: bill@cornell.UUCP (Bill Nesheim) Subject: Re: .ARPA hard coded into sendmail/src/daemon.c Message-ID: <6741@cornell.UUCP> Date: Mon, 5-Mar-84 10:05:09 EST Received: by hou3c.UUCP; Mon, 5-Mar-84 17:05:36 EST References: <638@vax135.UUCP> In-Reply-To: <638@vax135.UUCP> Organization: Cornell Univ. CS Dept. Wouldn't it be better to use the localnet name, instead of .ARPA or .ether? We have several localnets here, and it sure would be nice to see the localnet name put in where the .ARPA is hard coded now. Opinions? -- Bill Nesheim Cornell U. Dept of Computer Science {vax135,uw-beaver}!cornell!bill bill@cornell bill@CRNLCS.BITNET  Date: 6 Mar 84 0146 EST From: Rudy.Nedved@CMU-CS-A To: don.provan@CMU-CS-A Subject: Re: smtp, errors and delivery CC: Header-People@MIT-MC In-Reply-To: <05Mar84.125014.DP0N@CMU-CS-A> Message-Id: <06Mar84.014615.EN0C@CMU-CS-A> don, The problem is that large number of sites including CMU's Unix machines relay mail to another site and do not include their name in the return path. In the example I gave the sender was something like "bazola" and it was NOT in the mail from: line. The return path of "@bazola:@bonzo_land" will work in the CMU-CS-A server (independent of whether it is in the host table) and so will "@[78.7.8.9]:@bonzo_land" but since my mail system knows that hosts that are in the local domain have names that contain the character set A-Z and period it rejects the mail. The reason behind this was I was getting some real bizarre garbage host names that sometimes look like data or internal queueing data from the remote host. I suspect that a large chunk of mail systems can not handle funny characters that "happen" to be the queue file delimiter....like our Unix machines using colons can not simply insert the return path into the queue file...some conversion has to be done. The other problem I have seen is that if I add the connected site name to the return path if it is not there then when the mail is rejected, the site I did this service for rejects the error notifcation. I think what I will do now is change the mail server so that it adds the connecting site host name (or address) and if an error occurs it tries to send it back to the correct address and if that fails it replaces the address with Postmaster@. As Doug Kingston has pointed out...we have two design philosphys in the mail world....I didn't realize this before and I am glad I sent mail asking before starting to shoot at sites that are different. My apology for the length of this message. -Rudy  Date: Mon 5 Mar 84 23:19:46-PST From: Mark Crispin Subject: Re: smtp, errors and delivery To: don.provan@CMU-CS-A.ARPA cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "don.provan@CMU-CS-A" of Mon 5 Mar 84 20:58:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) That's easy. Most syntactically invalid MAIL FROM commands are from people who are debugging SMTP senders. I said that the TOPS-20 SMTP server completely implements the standard, so no correct SMTP sender should encounter an error. The TOPS-20 SMTP server will accept any return-path for the MAIL FROM argument as long as it is syntactically valid. It won't barf mail just because the host isn't in some host table! -------  Date: 5-Mar-84 23:34 PST From: Rich Zellich Subject: Re: smtp, errors and delivery To: Header-People@MIT-MC Message-ID: <[OFFICE-3]GVT-RICH-489L3> Re the mention of two different philosophies: Remember, please, that there is an authentication issue involved, too. Perhaps the "deliver at all costs" philosophy should quietly begin disappearing (at least in the MilNet environment), since there is a very large, and growing, community of users using mail for business purposes as well as the older uses for technical (and social) purposes. -Rich  Date: Tue, 6 Mar 84 9:20:47 EST From: Stephen Wolff To: Rich Zellich cc: Header-People@mit-mc Subject: Re: smtp, errors and delivery > Perhaps the "deliver at all costs" philosophy should quietly begin > disappearing (at least in the MilNet environment) ......... Why the (apparent) double standard? MILNET people don't NEED reliable mail service? Or at least not if `business' (commercially) related? Can you explain, please? I'm puzzled. -steve  Date: Tue, 6 Mar 84 11:42:08 EST From: Dave Farber To: Stephen Wolff cc: Rich Zellich , Header-People@mit-mc.arpa Subject: Re: smtp, errors and delivery As some one who has run an experimental mail relay for the Military for many years (!!), let me assure all that they NEED reliable mail and deliver at any cost. You every see a red faced 4 star? Dave ps Steve, I know you know. It should be to: Rich, copy you.  Date: Tue, 6 Mar 84 12:02 EST From: "Benson I. Margulies" Subject: Mailing lists that "take responsability" To: header-people@MIT-MC.ARPA Message-ID: <840306170219.672347@CISL-SERVICE-MULTICS.ARPA> I want to make a plea for some of the big mailing list servers to start putting themselves in as the return path, instead of the person who submitted the transaction to the list. I am tired of the volume (and I mean VOLUME) of failed mail notification that I get every time I send to this (and several other) lists. What is needed is for the home system of HEADER-PEOPLE or whatever to make header-people-request the target of the return path, instead of me. Further, if the SMTP server involved implements EXPN, then it should NOT expand header people.  Date: 06-Mar-84 16:45:11-UT From: gross@dcn7 Subject: RE: smtp, errors and delivery To: rich.gvt@office-3 cc: header-people@mit-mc I'm also in favor of phasing out the 'deliver at all costs' philosophy since it can cause as many problems as it solves. Are there any counterbalancing arguments out there? Why leave Milnet out? Phill -------  Date: 6 Mar 1984 12:03-EST From: Dan Hoey Subject: Re: smtp, errors, and delivery To: header-people at MIT-MC I know I'll regret this, but I think some of these ideas need straightening out, so I'll try. The return-path is, I am told, supposed to be the address of the sender of the message, routed in reverse order of the message's delivery. Many uses have been inferred for it, but in this pragmatic world I can tell you what it's used for (and if I've left your favorite use out, I'd like to hear it): 1. An address to send delivery errors back to. This saves the rfc-writers from having to document an ``Errors-to'' header field. 2. A fallback reply address. If the ``From'' or ``Reply-to'' field is garbage--some of them get typoed by hand, you know--the return path is sometimes usable. 3. A quick index to the ``Received'' lines, useful when those lines are out of order or missing. This can be useful in diagnosing mail problems. 4. A testament by the systems involved as to the actual origin of the message, useful when the mail is somehow unlawful and the malefactors are being rounded up. It should be noted that (1) is somewhat in conflict with (2) through (4), but since (1) is an important and routine function that hasn't otherwise been provided for we live with it. Incidentally, I imagine (4) is what Rich Zellich is talking about becoming more important with Milnet, but I'm not sure. The ``deliver-at-all-costs'' philosophy might better be stated as ``deliver even if you can't get back from here.'' When such a philosophy is taken, all the benefits of 1-4 are lost. The loss of (1) and (2) means that the message could get to a point where even with human intervention, there's no way of telling who the message is for or from, an uncomfortable situation for us dead-letter-office personnel. Loss of (3) could lead to not being able to figure out why we get into all these uncomfortable situations. And loss of (4) could prevent us from calling a halt to the chain letters, cranks, ransom notes, and other Trojan thoughts that we can't deliver, return, or diagnose anyway. Unfortunately, the ``responsibility'' philosophy seems to imply that you can't send mail unless it can be returned. With so many protocols around, one site's mailbox is another site's host name. Rudy's example of "_" in a host name is an example, but I'm aware of various uses of certain other @=." )\!:([%] special characters that might be insufficiently quoted--or quotable--to permit returning of the mail. It seems unfortunate that person A out in funny-character-land should be prohibited from sending his phone number to person B in easy-address-ville because host C in the middle is feeling responsible. I can suggest some more strategies for people who want to sail gracefully between the explosive source and the yawning sink. I'm pretty sure they're orthogonal, and some of them may even be easy. 1. Try to patch the return-path. For instance, put quotes around it? Maybe put parens around it and add "Postmaster"? I don't know if quotes and comments fit the return path syntax, but it's a try. 2. Stuff an error message containing the offending return-path onto the message before sending the message with an empty return-path. 3. Send a notification back along the return-path to warn that delivery errors may happen and the sender may not hear about them. 4. Log it locally so InterNetPol can track it back to its source if necessary. An ideal site might implement them on both sides (server and user). I would be interested in seeing other solutions to the problems of unusable return-paths. Somehow I can't get into this philosophy jazz, though. Dan Hoey  Date: Tue 6 Mar 84 10:58:04-PST From: Mark Crispin Subject: authentication To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The only authentication issue with Internet mail is that there is NO authentication. Let's not introduce this particular red herring. Anybody who thinks that Internet mail is authenticated is fooling himself. -------  Date: 6-Mar-84 13:13 PST From: Rich Zellich Subject: Re: smtp, errors and delivery and authentication To: Header-People@MIT-MC Message-ID: <[OFFICE-3]GVT-RICH-490UQ> Mark Crispin seems to be the only one who understood that the key word in my message was "authentication". Yes, I know that technically mail is not really authenticated (except that it \is/ to a great extent by addition of the Received lines and the Return-path building). The point is, that in an official-business environment, \reliability means not only the ability to deliver the mail, but also to get it there with a reasonable indication of who really sent it/. Getting mail from a host your mail-receiving server can't identify may not be the best idea in the world (and with name servers coming online along with domains, a hosts private name table shouldn't be the cause of wrongly-rejected mail). Sometime in the future, of course, we must add \real/ authentication (and real security, real precedence, ...). Right now, the official policy when sending official direction via netmail is to follow it up with a TWX. In practice, unless it's fairly important, only the net message is used; this is because most of the users don't understand how easily a message can be forged on many systems, and because they haven't yet been bitten by a forged message. -Rich  Date: Tue 6 Mar 84 13:57:15-PST From: Mark Crispin Subject: SMTP and authentication To: Header-People@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) As a taxpaying citizen of the United States of America (and reasonably patriotic, despite certain leftist political views), I strongly object to the idea of having Internet mail used for ANY confidential, official, or any other traffic which in some way involves USA national security. Internet mail is, and should remain, a high-connectivity, high-throughput mail network with reasonable reliability and validation. This is quite suited for the research purposes it is mostly put to. Excessive validation (which tends to affect the HELO command and not the return-path in the MAIL FROM command) will only serve to seriously impact the high connectivity of Internet mail. I am glad to hear the military follows up all official (and unclassified, I hope!) directives sent over Internet with a TWX. My faith in the US military as a viable agency in defending our nation against foreign aggression would be shattered if it relied on Internet mail. What makes this whole discussion silly is that NONE of the hosts on Internet (except perhaps the Multics sites) are secure enough to have authenticated mail in any case. Certainly not any of the Tenex, TOPS-20, or Unix systems. It is only when you can restrict entry into the network (e.g. the secure subnet of Milnet) that there is any authentication at all. Even then all it means is that the mail was not forged outside of the network. Can't we end this once and for all? Authentication does not exist, and cannot exist with the current hosts on the network. -- Mark -- -------  Date: Tue, 6 Mar 84 17:53:43 EST From: Doug Kingston To: Benson I. Margulies cc: header-people@mit-mc.arpa Subject: Re: Mailing lists that "take responsability" I've said this before, but some seemed to have missed it... In the MMDF II software, I have implemented something called the "list channel" which is in fact a "remailing" mechanism which will substitute an alternate return address for original (sender's) address. All the lists handled through BRL hosts are sent through the list channel. As a result, senders to Unix-Wizards, Info-Micro, Info-Cpm, etc. get much less return mail when they submit a message. The list channel inserts Unix-Wizards-Request, and generally *-request as the return address in the MAIL FROM command if that is a valid address on the BRL host. As a result, the failed mail messages go to someone who can actually do something about it, the list manager. Unfortunately, it is not possible to totally eliminate this return trash since some mailers will blindly except the mail and reject it later after throwing away the MAIL FROM address. They still take the return address from the letter. There is nothing we can do to stop this unless we start munging the message, which we are unwilling to do in this case. Stop promiscuous hosts! -Doug- PS. Then there the hosts that return mail unmodified under separate cover... Arrrgggg....  Date: 6 Mar 1984 1907-EST From: John R. Covert To: MRC at SU-SCORE, Header-People at MIT-MC ENET-address: "Castor::Covert" Phone: "(603) 884-8271 or DTN 264-8271" UUCP-address: "{ucbvax,allegra,decvax}!decwrl!rhea!castor!covert" Subject: Re: SMTP and authentication Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11997283717.19.132.6887 at DEC-MARLBORO> Regarding: Message from Mark Crispin of 6-Mar-84 1656-EST Authentication does not exist without encryption (because without encryption you can hack the authentication). I'm amazed that people who are concerned about authentication think that following up a message with a TWX or Telex involves any more authentication! A TWX or Telex can be hacked just as easily as netmail! All it takes is changing the answerback. When people worry about authentication in netmail, my usual reply is "Anyone can throw a letter into the Postal Service with any return address they want, as well as a forged signature." No unencrypted mail system has authentication. /john --------  Date: 6 Mar 84 1757 EST (Tuesday) From: don.provan@CMU-CS-A To: header-people@mit-mc Subject: re: smtp, errors, and delivery Message-Id: <06Mar84.175702.DP0N@CMU-CS-A> what we need is two new types of error messages. one to indicate that the mail may be delivered but errors cannot be returned and another to indicate that the mail will be delivered but there was still something bogus about the return path. this general discussion is fine, but the times i've had mail rejected because of what the server thought was a syntax error in the return path, the mail would have been delivered immediately by the server, so there was no danger of the return path being used, anyway.  Date: Tue, 6 Mar 84 20:04 EST From: "Benson I. Margulies" Subject: return-path To: header-people@MIT-MC.ARPA Message-ID: <840307010402.021078@CISL-SERVICE-MULTICS.ARPA> As Mr. Crispin pointed at length last week, the RFC specifies that RETURN-PATH is explicitly supposed to serve as a target of complaints, and NOT as a reply address or anything else.  Date: Tue, 6 Mar 84 20:07 EST From: "Benson I. Margulies" Subject: Authentication To: header-people@MIT-MC.ARPA Message-ID: <840307010738.841199@CISL-SERVICE-MULTICS.ARPA> I disagree with Mr. Covert. Given the assumption that the net gives me trustworthy informatio on the source host of mail (which the ARPAnet can), and knowledge of the security characteristics of the hosts on the net, authentication is available. Consider two Multics systems on ARPA. The sending system software that installs the source name in the envelope is trusted code. The recieving server can validate that the IMP leader/IP header specify the address of a directly connected trusted mail host, and copy the envelope source user name into the appropriate Sender field. Voila! We maintain the envelope data in trusted code so that even local mail has authenticated sources. Over an unreliable communications medium, where you cannot perform HOST level authentication, mr. covert is correct. only encryption will do.  Date: 6 Mar 84 1849 EST From: Rudy.Nedved@CMU-CS-A To: Mark Crispin Subject: Re: SMTP and authentication CC: Header-People@MIT-MC In-Reply-To: "Mark Crispin's message of 6 Mar 84 16:57-EST" Message-Id: <06Mar84.184902.EN0C@CMU-CS-A> Mark, Can't you use semi-secret "public" key encryption to validate the sender? The semi-secret parts comes from the fact that you can't set up in any enviroment by the points you mentioned (insecure networks and hosts) a authentication server without the potential for forgery of it....but you can have users type in magic numbers at both ends and have the mail authenticated....the magic numbers are sent by "secure" courier...a guy with a handcuffed briefcase. This is one the issues CMU CS/RI systems staff is suppose to solve ASAP....probably after we get the user names and host names "addressing" issues solved. -Rudy  Date: 6 Mar 84 1852 EST From: Rudy.Nedved@CMU-CS-A To: Mark Crispin Subject: Re: SMTP and authentication CC: Header-People@MIT-MC In-Reply-To: "Mark Crispin's message of 6 Mar 84 16:57-EST" Message-Id: <06Mar84.185221.EN0C@CMU-CS-A> Oh. The mail message would be in clear text with a complete business like letter enclosed (duplicating the from:, to:, cc: and subject: fields) and would have at the end a "encrypted checksum" of sorts. -Rudy  Date: 6-Mar-84 17:59 PST From: Rich Zellich Subject: Re: SMTP and authentication To: John R. Covert Cc: Header-People@MIT-MC Message-ID: <[OFFICE-3]GVT-RICH-491AK> In-reply-to: <"MS10(2124)+GLXLIB1(1136)" 11997283717.19.132.6887 at DEC-MARLBORO> Well, the TWXs come through the secure commo centers using the DoD AUTODIN network. Supposedly, the manual channels covering getting the typed original to the comm center for transmission take care of authenticating the Sender/From/Authorized-by/etc. Last I heard, the plan is to use the new MilNet/ARPANET protocols with the security and precedence stuff added to replace the aged AUTODIN. How the AUTODIN-replacement network will be interconnected with the ARPANET, current-version MilNet, or any other part of the internet, I have no idea. -Rich  Date: Tue, 6 Mar 84 23:57:32 EST From: Steve Dyer Subject: please remove me To: header-people@mit-mc Please remove me from your mailing list. Thanks, Steve Dyer sdyer@bbn-unix sdyer@bbncca  Date: Wed, 7 Mar 84 01:11 EST From: "Robert W. Kerns" Subject: Not about SMTP and authentication To: Rudy.Nedved@CMU-CS-A.ARPA Cc: Header-People@MIT-MC.ARPA I'm tired of this topic. Let's talk about your In-Reply-To: header. Received: from MIT-MC by SCRC-YUKON with CHAOS; Tue 6-Mar-84 20:53:07-EST Date: 6 Mar 84 1852 EST From: Rudy.Nedved@CMU-CS-A To: Mark Crispin Subject: Re: SMTP and authentication CC: Header-People@MIT-MC In-Reply-To: "Mark Crispin's message of 6 Mar 84 16:57-EST" Message-Id: <06Mar84.185221.EN0C@CMU-CS-A> It's different; something I hadn't seen before. It would have been useful, except for two things: 1) You use the pretty "Mark Crispin's" personal name instead of (or without including) the actual mailbox name. 2) You turn what would have been a perfectly nice phrase parsable phrase into a single word by quoting it. I just wanted to call your attention to the fact that despite RFC822's lack of any useful advice on the issue, there ARE those of us out here with mail-readers capable of making good use of the In-Reply-To field. Since your mail-sender obviously goes to enough work to generate everything needed, why not include the mailbox-name with the personal name? In my opinion, any In-Reply-To: header which doesn't include Date: and From: mailbox information, or Message-ID: information, is useless fluffery, and cannot be relied on to identify any particular message. This includes constructs like "Your message of", since too often people add and delete recipients. Also, in the interest of standardization, and so we don't need to recognize still another format (although it's not hard), I would recommend the following format. In-Reply-To: The message of 6 Mar 84 16:57-EST from Mark Crispin This format, or something close, is pretty widly used by those who generate the In-Reply-To: header at all when there is no message ID, and our mail-reader is capable of quickly finding the referenced message from this information. Indeed, by tracing forward and backward using this information, I can delete an entire conversation at a single keystroke, which is what I wanted to do with the topic under discussion. I hope any future header-RFC writers include some useful information, and maybe even restrictions, on In-Reply-To next time around. Oh, well. But since this is a different topic, I have carefully deleted my In-Reply-To: header: In-reply-to: <06Mar84.185221.EN0C@CMU-CS-A>  Date: Tue 6 Mar 84 22:27:19-PST From: Mark Crispin Subject: Re: Authentication To: Margulies@CISL-SERVICE-MULTICS.ARPA cc: header-people@MIT-MC.ARPA In-Reply-To: Message from ""Benson I. Margulies" " of Tue 6 Mar 84 17:25:55-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Does Multics prevent users from connecting to the SMTP server port on other systems? If not, your entire previous argument is worthless. -------  Date: 7 Mar 84 0532 EST From: Rudy.Nedved@CMU-CS-A To: "Robert W. Kerns" Subject: Re: Not about SMTP and authentication CC: Header-People@MIT-MC In-Reply-To: "\"Robert W. Kerns\"'s message of 7 Mar 84 01:11-EST" Message-Id: <07Mar84.053239.EN0C@CMU-CS-A> My world does not cover "mail compostion" issues and the people that normally work on RdMail either have left or are extremely busy and can not expend the time to get this kinda of thing fixed. I wish I could help but all I influence is delivering the message rain, sleet, power failure, disk crash (well...) and sunny weather (in Pittsburgh??? ha!). -Rudy  Date: 7-Mar-84 10:30 PST From: Bill Barns Subject: Re: SMTP and authentication To: RICH.GVT@OFFICE-2 Cc: Header-People@MIT-MC Message-ID: <[OFFICE-2]TYM-WWB-492TB> In-reply-to: <[OFFICE-3]GVT-RICH-491AK> Yes, to expand a bit on your discussion: the authentication and security of AUTODIN I are derived from three things: physical security of the terminals and switches, encryption of data, and administrative procedures. If you could connect your terminal or PC into AUTODIN and type away, authentication would be out the window. One of the effects of the AUTODIN admin procedures is that it is generally impossible to get something transmitted without it going through the hands of someone other than the originator. There are exceptions to this, as well as the possibility of admin breakdowns. Message centers are supposed to maintain files of signatures of authorized releasers and all the message forms are supposed to be signed. As to the exceptions, there are a bunch of rules not worth repeating, but basically they are logged in a special way. The idea of using Internet for AUTODIN GENSER type traffic relies heavily on encryption. I haven't heard what the drafter/releaser procedures will be; I suspect no "official" decision has been made. Once you get the data "canned" with the right NSA techniques, there is no problem sending it down any pipe you want - Milnet, Arpanet, direct broadcast satellite, suit yourself. The interesting questions have to do with how you get your can of data sealed. I don't see it working with the style of mail-sending we use now; probably military installations will eventually be set up to let people "draft" items by a procedure similar to Internet "sending", but before being "released" they will have to go through some procedure similar to what is done to declassify a magtape, which basically means somebody else in a secure place will have to poke at it. There is a bunch of work in progress on retinal scanners and other gee whiz stuff, but I don't think you should plan on finding one on your desk any time soon. Back in '77 I was hearing that by 1984 the Pentagon would be full of Secure Office Terminals. It isn't (but yes, there has been some progress). Someday, probably, but not before all the Spectra-70's keel over. I think there will have to be one or more interim solutions. -b  Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA00232; Thu, 8 Mar 84 11:56:40 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.14.2) id AA16452; Thu, 8 Mar 84 11:42:02 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.14) id AA02084; Thu, 8 Mar 84 11:48:17 pst Date: Thu, 8 Mar 84 11:48:17 pst From: wcwells%ucbopal.CC@Berkeley (William C. Wells) Message-Id: <8403081948.AA02084@ucbopal.CC.Berkeley.ARPA> To: Header-People@MIT-MC Subject: Re: smtp, errors and delivery Military message systems operate on three basic principles: reliability, speed, and security. Of the three, "reliability is paramount". I think you will find that an electronic mail system that permits messages to "drop into a black hole" will not be acceptable for Defense Data Network (ie. MILNET) use. Mail transport agents should be responsible for ensuring the FROM in SMTP and the "From" in the mail header are correct both when received and when transmitted. This may require that gateway mail transport agents modify the address when the message is transmitted by a gateway into a different mail domain or mail system. For non-Internet mail addresses, this means transforming the address into an address that is acceptable to the Internet world. It may mean adding the source "route" (eg. @host.domain:) of the gateway mail transport agent to the front of the From address, or changing the address into the form: "off-net-address"@mail-gateway-id.registered-top-domain-name where the address to the right of the "@" sign is a valid Internet mail domain name. Receiving mail transport agents should check the FROM field, if the syntax is correct, but the domain name is not, then they should add the domain name of the sending mail transport agent to the front of the source "route" in the address to ensure a reply path. --- Hmmmm. That would imply the addresses of the form: <@mail-gate.Internet-top-domain:local-address@hostid.non-ARPA-domain-name> for example: <@mail-relay.ARPA:userid@hostid.local-netid> should be legal within the Internet mail world. That is, if the first domain-name in the source "route" is known and valid within the current mail domain, and the syntax of the address is correct, then the address should be accepted by the receiving mail transport agent. Bill Wells, Computing Services, UC Berkeley wcwells@Berkeley.ARPA or ...!ucbvax!wcwells  Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA23963; Sun, 11 Mar 84 14:33:54 pst Received: by ucbarpa.ARPA (4.22/4.25) id AA09682; Sun, 11 Mar 84 14:28:59 pst From: eric%ucbarpa@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 11 Mar 1984 1428-PST (Sunday) Message-Id: <9681.31.447892136@ucbarpa> To: allegra!hou3c!ka@mit-vax, vax135!martin@Berkeley (Martin Levy) Cc: Header-People@MIT-MC.ARPA Subject: Re: .ARPA hard coded into sendmail/src/daemon.c In-Reply-To: Your message of 2 Mar 1984 18:58:04-EST, Thu, 1-Mar-84 20:14:07 EST. <638@vax135.UUCP> Fcc: mail I have modified sendmail on the Berkeley version to have a new configuration option (`N') that specifies the local net name. This defaults to "ARPA" for back compatibility. eric  Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA24288; Sun, 11 Mar 84 15:05:07 pst Received: by ucbarpa.ARPA (4.22/4.25) id AA10286; Sun, 11 Mar 84 15:00:12 pst From: eric%ucbarpa@Berkeley (Eric Allman) Phone: (415) 548-3211 Date: 11 Mar 1984 1500-PST (Sunday) Message-Id: <10285.31.447894010@ucbarpa> To: vax135!ukc!mjb@Berkeley (M.J.Bayliss) Cc: Header-People@MIT-MC.ARPA Subject: Re: Strange From headers In-Reply-To: Your message of 1 Mar 1984 22:06:12-EST, Thu, 16-Feb-84 06:45:03 EST. <4097@ukc.UUCP> I am indeed reading your message.... You have identified the problem correctly -- the UGLYUUCP code is ONLY for cases where you are sticking with the oh-so-ugly technique of stacking UNIX-style from lines, e.g., From uucp .... remote from vax135 >From uucp .... remote from ukc >From mjb .... If you decide to use the ".UUCP" format, you must stop using the stacked "remote from ..." syntax. This can be turned off selectively by having two UUCP mailer definitions, e.g., "olduucp" and "newuucp." eric  Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK with CHAOS; Sun 11-Mar-84 20:32:14-EST Date: Sun, 11 Mar 84 20:30 EST From: Moon@MIT-MC.ARPA Subject: Goodbye To: Header-People@MIT-MC.ARPA I can no longer keep up with this amount of mail. I have deleted 213 unread Header-People messages from my mailbox and removed myself from the list. Goodbye.  Date: 16 Mar 1984 09:19:33-EST From: allegra!hou3c!hocda!houxm!ihnp4!zehntel!dual!unisoft!ed at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site unisoft.UUCP From: ed@unisoft.UUCP (Ed Gould) Subject: Re: .ARPA hard coded into sendmail/src/daemon.c Message-ID: <227@unisoft.UUCP> Date: Wed, 14-Mar-84 02:11:08 EST Received: by hou3c.UUCP; Wed, 14-Mar-84 23:03:14 EST References: <6741@cornell.UUCP> In-Reply-To: <6741@cornell.UUCP> Organization: UniSoft Corp., Berkeley Nothing is hard-coded into sendmail. It all comes from the .cf file. I know they're hard to deal with, but all the flexibility you want is there. -- Ed Gould ucbvax!mtxinu!ed  Date: 16 Mar 1984 09:19:44-EST From: allegra!hou3c!hocda!houxm!ihnp4!harpo!seismo!rick at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site seismo.UUCP From: rick@seismo.ARPA (Rick Adams) Subject: Re: .ARPA hard coded into sendmail/src/daemon.c Message-ID: <703@seismo.UUCP> Date: Thu, 15-Mar-84 12:43:18 EST Received: by hou3c.UUCP; Thu, 15-Mar-84 15:53:43 EST References: <6741@cornell.UUCP> <227@unisoft.UUCP> In-Reply-To: <227@unisoft.UUCP> Organization: Center for Seismic Studies, Arlington, VA Nothing is hard-coded into sendmail. It all comes from the .cf file. I know they're hard to deal with, but all the flexibility you want is there. Funny, this certainly looks hardcoded to me: /* determine host name */ hp = gethostbyaddr(&otherend.sin_addr, sizeof otherend.sin_addr, AF_INET); if (hp != NULL) ---> (void) sprintf(buf, "%s.ARPA", hp->h_name); else /* this should produce a dotted quad */ (void) sprintf(buf, "%lx", otherend.sin_addr.s_addr); RealHostName = newstr(buf); How do you propose I get it to say .UUCP instead of .ARPA? ---rick  Date: 16 Mar 1984 13:23:49-EST From: allegra!hou3c!hocda!houxm!ihnp4!harpo!seismo!rick at mit-vax To: Header-People@MIT-MC.ARPA Posting-Version: version B 2.10.1 6/24/83; site seismo.UUCP From: rick@seismo.ARPA (Rick Adams) Subject: Re: .ARPA hard coded into sendmail/src/daemon.c Message-ID: <704@seismo.UUCP> Date: Thu, 15-Mar-84 13:26:23 EST Received: by hou3c.UUCP; Thu, 15-Mar-84 20:18:25 EST References: <6741@cornell.UUCP> <227@unisoft.UUCP> In-Reply-To: <227@unisoft.UUCP> Organization: Center for Seismic Studies, Arlington, VA Re: Nothing is hard-coded into sendmail. It all comes from the .cf file. I know they're hard to deal with, but all the flexibility you want is there. Funny, this certainly looks hardcoded to me: /* determine host name */ hp = gethostbyaddr(&otherend.sin_addr, sizeof otherend.sin_addr, AF_INET); if (hp != NULL) ---> (void) sprintf(buf, "%s.ARPA", hp->h_name); else /* this should produce a dotted quad */ (void) sprintf(buf, "%lx", otherend.sin_addr.s_addr); RealHostName = newstr(buf); How do you propose I get it to say .UUCP instead of .ARPA? ---rick  Date: 16 Mar 1984 13:13:35 PST From: POSTEL@USC-ISIF.ARPA Subject: .ARPA is coming To: header-people@MIT-MC.ARPA Please note the announcement in DDN MGT Bulletin 22 of the change in the data kept in the HOST.TXT file and made available via the NIC's Host-Name Server. On March 21 (at 8am EST) all the official host names will be changed to have ".ARPA" appended. For example, "USC-ISIF" will become "USC-ISIF.ARPA". This might cause some programs a few minor problems. If you would like to check things prior to the change over you can use the file DHOSTS.TXT from the NIC (pathname=DHOSTS.TXT on SRI-NIC). --jon. -------