Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 OCT 86 19:21:59 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 1 Oct 86 19:20:32 EDT Date: Wed, 1 Oct 1986 16:00 EDT Message-ID: From: Rob Austein To: The lost Bostonian Cc: header-people@MC.LCS.MIT.EDU, tcp-ip@SRI-NIC.ARPA Subject: SMTP, 2600, and the security of mail In-reply-to: Msg of 30 Sep 1986 13:29-EDT from The lost Bostonian Date: Tuesday, 30 September 1986 13:29-EDT From: The lost Bostonian To: header-people@mc.lcs.mit.edu, tcp-ip@sri-nic.arpa If it is true that all IP implementations enable a server program to determine the IP address of its peer, then the HELO command, and its response could be eliminated, which would save us a few bytes. You are assuming that it is always possible to translate addresses to names and vice versa. Unfortunately, there are some people out in the world running domain nameservers who are totally clueless about what they are doing, and there are others who have the misfortune to be stuck behind a losing gateway or otherwise be unreachable much of the time. Do you really want to make it impossible to receive mail from some host because a third party is broken? Or have to put numeric addresses into the Recieved headers? The answer is to fix the silly net, not throw away features to save two IP packets. --Rob  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 14 Oct 86 05:59:42 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2707120512047934@MIT-MULTICS.ARPA>; 14 Oct 1986 05:55:12 edt Date: 05 Oct 86 15:37 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: HEADER-PEOPLE@AI.AI.MIT.EDU Subject: CONFIRM-DELIVERY Message-ID: <206907@QZCOM> In-Reply-To: <860924130255.410923@MIT-MULTICS.ARPA> (a) In the case of receipt confirmation, X.420 says (sectin 4.2.2.3) that this can be implemented in two ways: - Either automatically produce a receipt confirmation when the recipient reads the message, or - ask the recipient, when he has read the message, whether the requested reciept should be sent or not. The latter alternative seems to satisfy you objections. (b) The main reason why I want to implement "CONFIRM-DELIVERY" is not to make the system more X.400-compatible, but because I feel this is an important user service. I have made some small studies of the reliability of the academic nets in transporting messages from ARPANET mailing lists to our computer in Sweden, and found that the failure rate may be higher than 1 %. With such a high failure rate in the academic nets, it seems very important to provide senders with a facility to get a confirmation that the message they sent has reached the mailbox of the recipient. This could also answer your question about how to define "delivery", which in certain local nets could be unclear. In general, it seems better to define delivery as close to the recipient as possible, since the error control will then reach over a larger width of transmissions where a message can be lost. But if the local network within a university is very very reliable, one might envisage to send a delivery notification somewhat earlier. The trade-off, of course, is that if you delay delivery notification to delivery to the user work-station, and if that work-station only occasionally connects to download mail, you will get longer delay before the delivery-notification is sent. But is not that still a safer bet?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 OCT 86 13:13:43 EDT Received: from po3.andrew.cmu.edu by MC.LCS.MIT.EDU 15 Oct 86 13:08:49 EDT Received: by po3.andrew.cmu.edu (4.12/3.15) id ; Wed, 15 Oct 86 12:59:12 edt Received: FROM apollo VIA queuemail ID ; Wed, 15 Oct 86 12:56:49 edt Message-Id: Date: Wed, 15 Oct 86 12:56:29 edt From: cfe@andrew.cmu.edu (Craig F. Everhart) To: header-people@mc.lcs.mit.edu Subject: Re: CONFIRM-DELIVERY Suppose we were building a system where people could request delivery confirmation, and we believed that we had handled the ethical questions. Suppose we said that confirmation messages (of any of a desired set of stages in delivery) were to be sent to a given address. Naively, wouldn't that mean that one would get an awful lot of mail confirming delivery? My point is that the confirmation service should make it easy for the original sender's mail-handling agent to match the confirmation messages to the initial request, and that it's not (yet?) clear to me how this process can be automated. The most I can yet assume about confirmation messages so far is that they are composed with an In-Reply-To: header that matches the Message-ID: of the initial message. But this level of service, by itself, is inadequate, because a person replying to the message would generate a reply message that has exactly this same property. Did I miss some set of proposals that would explain how automatic confirmation might work? Or should I propose something? If the latter, here's a try: A goal of automatically-generated confirmation notices should be to allow mail-handling agents to keep track of the confirmed progress. Thus, if I initiate a piece of mail and ask for confirmation of a given phase of its delivery (say, ``In-Mailbox''), I'd expect that I'd later be able to ask my mail- handler about the status of the piece of mail--that of the N recipients, we had received confirmation from these K, and none yet for the remaining N-K of them. (Yes, we can imagine elaborations of this, where if confirmation lags for some recipients, the handler reminds me of the fact. Subsequent proposals might allow us to ask remote delivery or user agents whether mail was received and the confirmation message simply lost.) Let's say that I want confirmation of In-Mailbox state. My message might include the headers: From: mumble@bar To: a@b, c@d, e@f Confirm-In-Mailbox: mumble@bar Message-ID: The automatically-generated confirmation from c@d might include the headers: From: c@d In-reply-to: Confirmation-In-Mailbox: [token] where the [token] might be ``accepted'' or ``refused'' or some such. The body of the message might be optional human-readable text describing the reasons for refusal, should the refuser decide to offer any. The automatic handler of these things then scans incoming mail for header field names that start with ``Confirmation-'', matches the In-Reply-To: fields against the set of messages for which not all confirmations have been received, and matches the From: (/Sender:?) fields of the confirmation messages against the To: list of the original message. (This latter matching algorithm might be quite complicated, as it's not a trivial task, but it would reside solely in the mail-handler.)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 OCT 86 15:50:54 EDT Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 19 Oct 86 15:49:45 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2707583247563093@MIT-MULTICS.ARPA>; 19 Oct 1986 14:27:27 edt Date: 19 Oct 86 13:43 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, header-people@MC.LCS.MIT.EDU Subject: Re: CONFIRM-DELIVERY Message-ID: <210159@QZCOM> In-Reply-To: The problem of intelligent handling of confirmations can be split into two parts: (a) Formatting the text of the confirmation itself in such a manner that it can be recognized and handled by a computer program. You suggest an alternative for doing this in your message. (b) Programming your local user agent to use this to provide you with various features such as: - Getting yourself reminded if a message has not been delivered within a certain time interval. - Providing you with a summary of the delivery-status of a multi- recipient message when you ask for it, or automatically at a certain future date. (b) is of course a local matter, does not need standardization. (a) does require a standardized format of confirmations. This is already available in X.400. If we do wish to get this also as an extension to RFC822, something like what you propose should be used. One problem is that more and more of messaging will be X.400, and go via X.400<->RFC822 gateways, and the present proposal for such gateways (RFC987) does not propose that confirmation requests and confirmations should be passed across such gateways (since RFC822 does not have a standard for confirmation formatting in computer-readable form).  Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 20 Oct 86 19:30:21 EDT Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2707687635477331@MIT-MULTICS.ARPA>; 20 Oct 1986 19:27:15 edt Date: 20 Oct 86 18:26 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA To: HEADER-PEOPLE@AI.AI.MIT.EDU, MHS_implementation@WISC-RSCH.ARPA Cc: AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA Bcc: "Craig Partridge" Subject: Mailing-list standard proposal Message-ID: <210381@QZCOM> The AMIGO project in Europe has developed a proposal for a standard way of handling mailing-lists. The advantage of having a standard for mailing-list handling is that it is easier to provide nice user services if the way mailing-lists work is standardized. The proposal from AMIGO will also allow lists to be members of each other circularly without looping messages. The AMIGO proposal for mailing-lists is mainly defined in the P2 layer of X.400, but defined in such a way that it can also be used in RFC821/822 based nets, and so that the mailing-list specific information will be conveyed between X.400 and RFC821/822 through gateways according to the RFC987 recommendation for gateways between X.400 and RFC821/822. We are fully aware that CCITT is going to standardize mailing- lists entirely in the P1 layer of X.400, but we believe there will be a need for P2-based mailing-lists because these can be imple- mented (according to our proposal) without any change to the X.400 or RFC821/822 recommendations, while the CCITT recommendation, when it is ready, will require rewriting of not only the message systems handling mailing list expansion, but also all the systems which carry information between two nested lists. The AMIGO proposal contains (a) A recommendation how the header and envelope fields (RFC821/822 information) is to be handled by a mailing-list expander. (b) A standard for remote operations on a mailing list, such as adding yourself or removing yourself from a remote list, getting a list sent to you of the members of a lists, getting a list of all mailing lists at a certain host (all of course subject to access control). These operations are done by specially formatted P2 or RFC822 messages, and do not require any change to the X.400 or RFC message standards. A version of the AMIGO proposal will be available for comment in 2-4 weeks from now, and you can request a copy by writing to AMIGODOC@SEARN.BITNET or AMIGODOC%SEARN.BITNET@WISCVM.ARPA The proposal will be sent to you electronically unless you speci- fically ask for a paper copy and supply your postal address. We will in December 1986 begin pilot implementation of the AMIGO proposal within four different message systems in France, Germany, United Kingdom and Sweden. People outside the AMIGO project are welcome to participate in the pilot implementation of the AMIGO proposal for mailing-lists.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 OCT 86 06:30:15 EST Received: from ucbvax.berkeley.edu (TCP 1200400116) by MC.LCS.MIT.EDU 30 Oct 86 06:19:11 EST Received: by ucbvax.berkeley.edu (5.53/1.18) id AA18472; Wed, 29 Oct 86 09:25:40 PST Date: Wed, 29 Oct 86 09:25:40 PST From: jordan@ucbvax.Berkeley.EDU (Jordan Hayes) Message-Id: <8610291725.AA18472@ucbvax.berkeley.edu> To: header-people@mc.lcs.mit.edu Subject: BITNET mail There are still a lot of people out there on the Internet trying to use ucbvax.Berkeley.EDU as a BITNET gateway ... pretty anti-social, if you ask me. Check your mailing lists and mailer configurations today. Thanks. /jordan  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 OCT 86 09:47:01 EST Received: from csv.rpi.edu (TCP 30003055412) by MC.LCS.MIT.EDU 30 Oct 86 09:45:01 EST Received: by csv.rpi.edu (5.51/1.14) id AA06999; Thu, 30 Oct 86 07:34:15 EST Date: Thu, 30 Oct 86 07:34:15 EST From: schoff@csv.rpi.edu (Martin Schoffstall) Message-Id: <8610301234.AA06999@csv.rpi.edu> To: header-people@mc.lcs.mit.edu, jordan@ucbvax.berkeley.edu Subject: Re: BITNET mail I don't know what INTERNET people use (we use wiscvm.wisc.edu) but I DO see BITNET people use violet.berkeley.edu when they want to mail to the INTERNET. Isn't this antisocial too? Marty  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 NOV 86 16:45:33 EST Received: from rsch.wisc.edu (TCP 30001201001) by MC.LCS.MIT.EDU 1 Nov 86 15:36:46 EST Date: Sat, 1 Nov 86 14:34:22 CST From: lhl@rsch.wisc.edu (L.H. Landweber) Message-Id: <8611012034.AA13562@rsch.wisc.edu> Received: by rsch.wisc.edu; Sat, 1 Nov 86 14:34:22 CST To: schoff@csv.rpi.edu Subject: Re: BITNET mail Cc: header-people@mc.lcs.mit.edu, jordan@ucbvax.berkeley.edu lhl While it may anti-social to use bitnet/internet gateways other than wiscvm, it certainly is rational. Each weekday we fall behind hundreds of messages due to arpanet congestion. (We sit at one end of the most congested line in the Arpanet.) Most of the time these are cleared on the weekend, but if something goes wrong at that time, large numbers of messages may be lost (or returned to sender). This week i will send out an announcement that at some future date we will limit the number of copies of a single message that wiscvm will relay. We will expect list maintainers to contact someone on the other net to set up exploders. We have offers from some to help and details will be forthcoming. At present well over 50% of our traffic is due to mulitple copies from lists on both sides. Hopefully, the above change will fix or at least ease the current problem. Larry Landweber  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 3 NOV 86 16:39:15 EST Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU 3 Nov 86 16:37:08 EST Received: from jade.berkeley.edu by violet.berkeley.edu (5.54 (CFC 4.22.2)/1.16.3) id AA19875; Mon, 3 Nov 86 13:36:16 PST Received: by jade.Berkeley.Edu (5.54 (CFC 4.22.3)/5.7.1) id AA17329; Mon, 3 Nov 86 13:35:56 PST Message-Id: <8611032135.AA17329@jade.Berkeley.Edu> Date: Mon, 03 Nov 86 22:14 CET To: header-people@mc.lcs.mit.edu, jordan@ucbvax.Berkeley.EDU(Jordan Hayes) From: Peter Sylvester +49 228 303245 Subject: Re: BITNET mail > > There are still a lot of people out there on the Internet trying to use > ucbvax.Berkeley.EDU as a BITNET gateway ... pretty anti-social, > if you ask me. Check your mailing lists and mailer configurations > today. Thanks. There are lots of people that use BSMTP at UCBJADE (in BITNET) as a gateway, too. This is a relict of the fact that you sometimes get mail via that gate and can respond only thru that gate. If you use direct most .EDU stuff to WISCVM, you sometimes got non delivery reports that tell you something of unknown hosts. I do not know whether this is still true. Where is the "official announcement" of the WISCVM gateway? > > /jordan >  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 NOV 86 22:53:26 EST Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU 6 Nov 86 22:50:58 EST Received: from jade.berkeley.edu by violet.berkeley.edu (5.54 (CFC 4.22.2)/1.16.3) id AA24525; Thu, 6 Nov 86 19:48:21 PST Received: by jade.Berkeley.Edu (5.54 (CFC 4.22.3)/5.7.1) id AA22149; Thu, 6 Nov 86 19:47:46 PST Date: Thu, 6 Nov 86 19:47:46 PST From: netinfo%jade.Berkeley.EDU@BERKELEY.EDU (Postmaster + BITINFO) Message-Id: <8611070347.AA22149@jade.Berkeley.Edu> To: lhl@rsch.wisc.edu, schoff@csv.rpi.edu Subject: Re: BITNET mail Cc: header-people@mc.lcs.mit.edu, jordan@ucbvax.berkeley.edu.lhl, usenet@ucbvax.Berkeley.EDU One of the things that can be done to reduce the amount of list mail going across the ARPANET/BITNET gateway to get the VM version of USENET news completed and distributed throughout BITNET/EARN/NETNORTH land. This would allow list mail to be reduced to one message going across the gateway. Only one message maximum needs to be sent across the gateway for each news article. Numbers of messages going across the gateway can be further reduced by using the batching feature of USENET news. Postmasters at sites running USENET news may want to take a look at list mail addressed to their site. Many ARPANET mailing lists are relayed into the USENET news system, and users at USENET news sites should not need to receive individual copies in addition to the USENET news copy. We can help reduce much of this extra traffic by identifying the USENET news group name of mailing lists in the INTEREST-GROUPS file(s) so users will know where in USENET news to find there favorite mailing list. Bill Wells  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 8 NOV 86 16:31:51 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 8 Nov 86 15:57:50 EST Received: from UCLASSCF(MAILER) by MITVMA (Mailer X1.23) id 8294; Sat, 08 Nov 86 15:51:27 EST Received: by UCLASSCF (Mailer X1.23) id 3799; Sat, 08 Nov 86 12:48:23 PST Date: Sat, 08 Nov 86 12:47:21 PST From: REMARCK@UCLASSCF (Marc Kriguer) To: header-people@mc.lcs.mit.edu Subject: This account is scheduled to be deleted soon... And to avoid the last-minute rush, I have to start dropping myself from all the mailing lists I am on. Please remove my name from the header-people mailing list. Thank you very much! Marc Kriguer  Received: from grape.ads.ARPA (TCP 1200400070) by AI.AI.MIT.EDU 17 Nov 86 14:13:17 EST Date: Mon, 17 Nov 86 11:07:45 pst From: Scott J. Kramer To: mit-erl!gildea@eddie.mit.edu Cc: bug-gnu-emacs@prep.ai.mit.edu, header-people@ai.ai.mit.edu Reply-To: sjk@ads.arpa In-Reply-To: Stephen Gildea's message of Fri, 14 Nov 86 15:50:38 est <8611162119.AA16365@prep.ai.mit.edu> Subject: rmail-reply-to-sender Speaking of mail replies, there's an annoyance related to using a REPLY-TO field, which I currently use because the host I'm sending from isn't recognized on the Internet. When the recipient responds to a message with a REPLY-TO which also has CC addresses, the CC's are omitted in the reply; only the REPLY-TO address is used. RFC822 isn't specific about this; it just says "if REPLY-TO exists, then the reply should go to the addresses indicated in that field and not to the address(es) indicated in the FROM field." I'm CC'ing Header-People on this since someone there may know of a way to do what I'm trying to do (ie, have CC's get replies if I use REPLY-TO). From what I can tell, the only way is to have a valid FROM field. scott  Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 17 Nov 86 16:00:33 EST Received: from killer-rat by nrtc-gremlin.arpa id a012430; 17 Nov 86 12:53 PST To: sjk@ads.ARPA cc: mit-erl!gildea@mit-eddie.ARPA, bug-gnu-emacs@prep.ai.mit.EDU, header-people@ai.ai.mit.EDU reply-to: header-people@mc.lcs.mit.EDU Subject: Re: rmail-reply-to-sender In-reply-to: Your message of Mon, 17 Nov 86 11:07:45 -0800. Date: Mon, 17 Nov 86 12:53:50 -0800 Message-ID: <3153.532644830@nrtc-gremlin.arpa> From: Marshall Rose Well, only Dave Crocker knows for sure, but I think this interpretation is correct: New message (reply) Old message (being replied to) ------------------ ------------------------------ To: use Reply-To: if present, otherwise use From: if present, otherwise use Sender: if present otherwise use Return-Path: (gag) cc: use To: and cc: if present (including a cc: is at the user's option-- some people prefer to omit the cc:) For an example of the rules that MH uses, look at the standard "replcomps" file distributed with MH. This is a "simple" formatting facility which builds the reply draft for the user. Note that the answer to your "have CC's get replies if I use REPLY-TO" query depends on the recipient of the message, NOT the sender. /mtr  Date: Mon, 17 Nov 86 16:54:34 EST From: David Vinayak Wallace Subject: semantics of Reply-To: To: sjk@ADS.ARPA cc: HEADER-PEOPLE@AI.AI.MIT.EDU, bug-gnu-emacs@PREP.AI.MIT.EDU In-reply-to: Msg of Mon 17 Nov 86 11:07:45 pst from Scott J. Kramer Message-ID: <[AI.AI.MIT.EDU].119419.861117.GUMBY> Date: Mon, 17 Nov 86 11:07:45 pst From: Scott J. Kramer Speaking of mail replies, there's an annoyance related to using a REPLY-TO field, which I currently use because the host I'm sending from isn't recognized on the Internet. When the recipient responds to a message with a REPLY-TO which also has CC addresses, the CC's are omitted in the reply; only the REPLY-TO address is used. RFC822 isn't specific about this; it just says "if REPLY-TO exists, then the reply should go to the addresses indicated in that field and not to the address(es) indicated in the FROM field." I'm CC'ing Header-People on this since someone there may know of a way to do what I'm trying to do (ie, have CC's get replies if I use REPLY-TO). From what I can tell, the only way is to have a valid FROM field. Reply-To: means send replies to this address. If there's no Reply-to: then your mail reader should compose a reply to the union of CC and From. If you're sending from a host which for some reason won't identify itself usefully, specify a From:. Hopefully your mailer will set the Sender: field to be the invalid address, ut preserver the From:. In other words, gnu emacs is doing the right thing; you should use From: where you now use Reply-to:.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 NOV 86 21:51:47 EST Received: from SUMEX-AIM.ARPA (TCP 1200000070) by MC.LCS.MIT.EDU 17 Nov 86 21:47:23 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 17 Nov 86 18:41:02-PST Date: Mon 17 Nov 86 18:25:02-PST From: Mark Crispin Subject: Re: rmail-reply-to-sender To: header-people@MC.LCS.MIT.EDU, mrose@NRTC-GREMLIN.ARPA, sjk@ADS.ARPA cc: mit-erl!gildea@MIT-EDDIE.ARPA, bug-gnu-emacs@PREP.AI.MIT.EDU In-Reply-To: <3153.532644830@nrtc-gremlin.arpa> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12255782689.9.MRC@PANDA> NO!!!!! A mail composition program must NEVER, repeat, NEVER!! generate a reply to a Sender or a Return-Path. A valid From field is required in all Internet messages. The Reply-To field overrides a From for reply purposes, but that does not eliminate the need for a valid From field. Nor does the presence of Sender and Return-Path fields (neither of which have anything to do with a reply address). In this day and age when certain vendors are "certifying" their TCP/IP implementations by testing them against random Unix systems, it is vitally important that implementations which take excessive liberties with the protocols be firmly suppressed. -- Mark -- -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 NOV 86 22:55:20 EST Received: from nrtc-gremlin.arpa (TCP 20030600021) by MC.LCS.MIT.EDU 17 Nov 86 22:52:08 EST Received: from killer-rat by nrtc-gremlin.arpa id a016065; 17 Nov 86 19:48 PST To: Mark Crispin cc: header-people@mc.lcs.mit.EDU, sjk@ads.ARPA, mit-erl!gildea@mit-eddie.ARPA, bug-gnu-emacs@prep.ai.mit.EDU reply-to: header-people@mc.lcs.mit.EDU Subject: Re: rmail-reply-to-sender In-reply-to: Your message of Mon, 17 Nov 86 18:25:02 -0800. <12255782689.9.MRC@PANDA> Date: Mon, 17 Nov 86 19:48:06 -0800 Message-ID: <4904.532669686@nrtc-gremlin.arpa> From: Marshall Rose Mark - there is a difference between working correctly and working. Working correctly is to ignore sender and return-path. However this is not often working. In a perfect world with a diligent protocol police, we would only worry about working correctly. This proceeds from a false assumption: there is neither perfection nor diligence in the Internet. It is better to know that you can fall back on sender and/or return path in case you have to (when working on a poorly constructed message), than to just say "you can't reply to that". /mtr  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86 00:11:18 EST Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 NOV 86 00:08:18 EST Date: Tue, 18 Nov 86 00:10:36 EST From: David Vinayak Wallace Subject: Replying to Sender or (gasp) Return-path To: mrose@NRTC-GREMLIN.ARPA cc: header-people@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 17 Nov 86 19:48:06 -0800 from Marshall Rose Message-ID: <[AI.AI.MIT.EDU].119575.861118.GUMBY> Date: Mon, 17 Nov 86 19:48:06 -0800 From: Marshall Rose there is a difference between working correctly and working. Working correctly is to ignore sender and return-path. However this is not often working...there is neither perfection nor diligence in the Internet. It is better to know that you can fall back on sender and/or return path in case you have to (when working on a poorly constructed message), than to just say "you can't reply to that". There's a difference between DWIM and incorrectness. Your mail handler may reasonably complain "I can't reply to that" and ask the human for help; it can't reasonably figure out which of From, Sender or Return-Path might interest the user (for instance, if I want to send a message to someone who will fix it up I might send a message to the Return-Path, whereas in a legitimate reply I might be able to construct a valid destination address). For purposes of replying there isn't much difference between Return-Path, Sender, and Subject. They all have inappropriate semantics. The machine shouldn't fake out naive users by using random information.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86 00:46:33 EST Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Nov 86 00:36:29 EST Received: from ibm.com by RELAY.CS.NET id aa12754; 17 Nov 86 18:09 EST Date: Mon, 17 Nov 86 13:59:46 PST From: David Alpern To: header-people@MC.LCS.MIT.EDU Subject: Re: rmail-reply-to-sender In-Reply-To: Message of Mon, 17 Nov 86 12:53:50 -0800 from Marshall Rose I don't believe the SENDER field should ever be used when developing the list of addressees for a reply. See RFC822 on this. (Although, I'll agree, there are times.... My own reply code will use the SENDER field only if an explicit option is given by the replying human.) - Dave  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86 03:43:22 EST Received: from nrtc-gremlin.arpa (TCP 20030600021) by MC.LCS.MIT.EDU 18 Nov 86 03:40:17 EST Received: from nrtc-gremlin by nrtc-gremlin.arpa id a018430; 18 Nov 86 0:36 PST To: David Vinayak Wallace cc: header-people@mc.lcs.mit.EDU reply-to: header-people@mc.lcs.mit.EDU Subject: Re: Replying to Sender or (gasp) Return-path In-reply-to: Your message of Tue, 18 Nov 86 00:10:36 -0500. <[AI.AI.MIT.EDU].119575.861118.GUMBY> Date: Tue, 18 Nov 86 00:36:43 -0800 Message-ID: <18426.532687003@nrtc-gremlin.arpa> From: Marshall Rose This is NOT, repeat NOT, a case of DWIM. The issue is simple: mail composers should use "reply-to if" they want to redirect replies that would normally go to the "from" field; mail repliers should honor "reply-to" over "from", but need to be able to do something if neither field is present. This is yet another example of the trite "be conservative in what you send, liberal in what you accept". This emphasizes the key point of my original message: the sender can use "reply-to", but it is upto the receiver to do the right thing. The right thing is to use "reply-to" or "from" for the primary recipient(s) of the reply. There is no concrete right thing for generating the list of secondary recipients (usually to and cc are the right thing, at the user's option). For example, my original message had a "reply-to" of header-people, and my mailbox did NOT appear anywhere in the message except for "from". I assume that Mark explicitly added my address to his reply. In this case the mail composer used "reply-to" to redirect replies, and the mail replier did not honor this protocol. A final note: do not, as your previous message suggests, mistake the operation of replying with other message-handling functions (e.g., forwarding, and so on). If you want to send the message to someone who will fix it up, you are NOT replying to the message. You are sending a message with a different purpose, not a reply to the original! /mtr  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86 11:25:29 EST Received: from SUMEX-AIM.ARPA (TCP 1200000070) by MC.LCS.MIT.EDU 18 Nov 86 11:22:24 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 18 Nov 86 08:16:28-PST Date: Tue 18 Nov 86 07:57:08-PST From: Mark Crispin Subject: Re: Replying to Sender or (gasp) Return-path To: header-people@MC.LCS.MIT.EDU In-Reply-To: <18426.532687003@nrtc-gremlin.arpa> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12255930529.7.MRC@PANDA> Marshall - The Internet mail world is not yet such that it is impossible to use a mail system that obeys RFC 822 when it comes to the semantics of replying. The only reason for adding Return-Path to your mail user agent's REPLY parser is laziness on the part of the mail maintainer -- that is, he is unwilling to handle the problems which occasionally come up and explain the realities of mail to a user who thinks that the reply address is "always" available in a Return-Path. Various vendors then "validate" their mail software against this lazy software, since it's located on a Unix and everybody is running Unix so it must be right... Then the poor maintainers of non-Unix software get long, pendantic complaint letters from the above-mentioned vendors (or their users) stating everything imaginable about the Internet protocols except the facts. Wollongong is a worst case, but not the only case. I don't want to argue English semantics, but "be conservative in what you send" sure means to me that you should be conservative and not send replies to the Return-Path. What's more, replying to the Return-Path is explicitly forbidden by RFC 822. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86 14:21:29 EST Received: from nrtc-gremlin.arpa (TCP 20030600021) by MC.LCS.MIT.EDU 18 Nov 86 14:18:28 EST Received: from killer-rat by nrtc-gremlin.arpa id a020495; 18 Nov 86 11:15 PST To: Mark Crispin cc: header-people@mc.lcs.mit.EDU reply-to: header-people@mc.lcs.mit.EDU Subject: Re: Replying to Sender or (gasp) Return-path In-reply-to: Your message of Tue, 18 Nov 86 07:57:08 -0800. <12255930529.7.MRC@PANDA> Date: Tue, 18 Nov 86 11:15:08 -0800 Message-ID: <6660.532725308@nrtc-gremlin.arpa> From: Marshall Rose Mark: If what we are arguing here is "validation", then I appologize. I am not talking about validation. I agree with your argument that validating against lazy software is wrong. /mtr  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 18 Nov 86 15:06:39 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2710180402874677@MIT-MULTICS.ARPA>; 18 Nov 1986 14:53:22 est Date: 18 Nov 86 18:47 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, mit-erl!gildea@MIT-EDDIE.ARPA, sjk@ADS.ARPA Cc: bug-gnu-emacs@PREP.AI.MIT.EDU, HEADER-PEOPLE@AI.AI.MIT.EDU, AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: reply-to Message-ID: <218147@QZCOM> In-Reply-To: <218025@QZCOM> > FROM: Scott J. Kramer > > When the recipient responds to a message with a REPLY-TO which also > has CC addresses, the CC's are omitted in the reply; only the REPLY-TO > address is used. RFC822 isn't specific about this; it just says "if > REPLY-TO exists, then the reply should go to the addresses indicated > in that field and not to the address(es) indicated in the FROM field." > > I'm CC'ing Header-People on this since someone there may know of a way > to do what I'm trying to do (ie, have CC's get replies if I use > REPLY-TO). From what I can tell, the only way is to have a valid FROM > field. Hear! Hear! The solution to your problem is something I have been arguing for for a long time, but not yet got enough people convinced of. There should be two different "reply-to" fields, with different names, one to serve as a replacement for the originator only, and one to serve as a replacement for all recipients. Thus, if your mail system, as many of them have, has two commands to write replies, one for replies only to the originator, and one for replies to all recipients, then the first command should use the value from one of the two "reply-to" fields, and the other should use the value from the other kind of "reply-to" field. Jacob Palme, QZ Computer Center, Stockholm, Sweden  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 18 Nov 86 19:49:07 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2710197129684579@MIT-MULTICS.ARPA>; 18 Nov 1986 19:32:09 est Date: 18 Nov 86 18:47 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, mit-erl!gildea@MIT-EDDIE.ARPA, sjk@ADS.ARPA Cc: bug-gnu-emacs@PREP.AI.MIT.EDU, HEADER-PEOPLE@AI.AI.MIT.EDU, AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: reply-to Message-ID: <218147@QZCOM> In-Reply-To: <218025@QZCOM> > FROM: Scott J. Kramer > > When the recipient responds to a message with a REPLY-TO which also > has CC addresses, the CC's are omitted in the reply; only the REPLY-TO > address is used. RFC822 isn't specific about this; it just says "if > REPLY-TO exists, then the reply should go to the addresses indicated > in that field and not to the address(es) indicated in the FROM field." > > I'm CC'ing Header-People on this since someone there may know of a way > to do what I'm trying to do (ie, have CC's get replies if I use > REPLY-TO). From what I can tell, the only way is to have a valid FROM > field. Hear! Hear! The solution to your problem is something I have been arguing for for a long time, but not yet got enough people convinced of. There should be two different "reply-to" fields, with different names, one to serve as a replacement for the originator only, and one to serve as a replacement for all recipients. Thus, if your mail system, as many of them have, has two commands to write replies, one for replies only to the originator, and one for replies to all recipients, then the first command should use the value from one of the two "reply-to" fields, and the other should use the value from the other kind of "reply-to" field. Jacob Palme, QZ Computer Center, Stockholm, Sweden  Received: from SRI-NIC.ARPA (TCP 1200000063) by AI.AI.MIT.EDU 18 Nov 86 23:47:48 EST Date: Tue 18 Nov 86 20:21:57-PST From: Ole Jorgen Jacobsen Subject: Re: reply-to To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, mit-erl!gildea@MIT-EDDIE.ARPA, sjk@ADS.ARPA, bug-gnu-emacs@PREP.AI.MIT.EDU, HEADER-PEOPLE@AI.AI.MIT.EDU, AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA, OLE@SRI-NIC.ARPA In-Reply-To: <218147@QZCOM> SRI-International: +1 (415) 859-4536 Home: +1 (415) 325-9427 Message-ID: <12256066120.25.OLE@SRI-NIC.ARPA> Jakob, I'll have to totally disagree with you on this, Scandinavian loyalty or not. The issue of who your reply goes to is a matter of taste and choice depending on the circumstances. I believe it SHOULD NOT be made part of any protocol, but SHOULD be an option in your local User Agent. When I started to reply to your message a couple of minutes ago, my user agent (MM) very cleverly asked me if I wanted to reply to "sender only" or "all". I think this (thanks to Mark Crispin!) is exactly the right thing to do. Why add new fields to RFC 822 when you can have smarter user agents? I assure you that I am not the only person who has been burnt by the "reply" function over the last ten years or so. Sometimes you want your reply to go to "all", while other times you definitely don't. The trouble is that so many user agents decide what "The Right Thing" is for you and don't give you the option. Ole -------  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 19 Nov 86 14:27:13 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2710264711211617@MIT-MULTICS.ARPA>; 19 Nov 1986 14:18:31 est Date: 19 Nov 86 17:27 +0100 From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: HEADER-PEOPLE@AI.AI.MIT.EDU Subject: Reply-to Message-ID: <218423@QZCOM> In-Reply-To: <12256066120.25.OLE@SRI-NIC.ARPA> > FROM: Ole Jorgen Jacobsen > > Jakob, > I'll have to totally disagree with you on this, Scandinavian > loyalty or not. The issue of who your reply goes to is a matter of > taste and choice depending on the circumstances. I believe it SHOULD > NOT be made part of any protocol, but SHOULD be an option in your > local User Agent. When I started to reply to your message a couple of > minutes ago, my user agent (MM) very cleverly asked me if I wanted to > reply to "sender only" or "all". I think this (thanks to Mark > Crispin!) is exactly the right thing to do. Why add new fields to RFC > 822 when you can have smarter user agents? > > I assure you that I am not the only person who has been burnt > by the "reply" function over the last ten years or so. Sometimes you > want your reply to go to "all", while other times you definitely don't. > The trouble is that so many user agents decide what "The Right Thing" > is for you and don't give you the option. Was this a statement of disagreement with anything I wrote? But I agree completely with you that decisions on where to send a reply should be up to the writer of the reply, aided by his user agent. Since two common alternatives is to send a reply to either only the originator, or to all recipients of the commented message, so many systems provide simple commands for those two alternatives which is very good. You are questioning whether the mail protocols should contain any support for this at all. However, there may be cases where the sender or the system of the sender wishes to indicate that replies should be redirected. Examples: (1) Replies to the sender only may be redirected to the secretary of the sender, some special folder for collecting replies to a certain question etc. (2) Replies to all may be redirected to avoid duplicates (do not send me a personal copy, I will get it via the list) or because some CC recipient with only marginal interest does not want to get all the replies. Since there are completely different needs for redirection in case of replies to the originator and replies to the whole group, there is a need for two different kinds of "Reply-to" header fields, one for each kind of reply. It is of course always up to the writer of the reply and his UA to decide to which extent they want to heed the advice in the reply-to fields. No one should be forced to send a reply to any particular address.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 NOV 86 14:24:48 EST Received: from hplabs.HP.COM (TCP 30001235012) by MC.LCS.MIT.EDU 20 Nov 86 14:24:19 EST Received: from hplms1. by hplabs.HP.COM ; Thu, 20 Nov 86 09:04:21 pst Received: from hpldat (hpldat) by hplms1; Tue, 18 Nov 86 09:44:08 pst Return-Path: Received: by hpldat ; Wed, 19 Nov 86 16:58:14 pst Message-Id: <8611200058.AA13911@hpldat> To: Header-People@mit-mc (The Header People Mailing List) Date: Wed, 19 Nov 86 16:58:11 PST From: Dave Taylor Subject: The current Reply-To: discussion Organization: Hewlett-Packard Laboratories, Unix Networking Group Work-Phone-Number: +1 415 857-6887 X-Mailer: Elm [version 1.4] I think we're all missing the point here... there are *two* different things being argued currently - one is a low-level question of how to deal with headers, and the other is a higher-level question of how to present the results of the header parsing/munging to the end user. I think that the low level questions are set out in a reasonably straightforward manner in '822. My personal belief (and "elm" is a result of this) is that the Reply-To: address is a sign of mutual exclusion - if it's present, that's the *only* address you reply to, by default. If you "Group reply" to a message that contains a Reply-To: header, elm will build a return address based on the address in the reply-to field and the To: and Cc: list (stripping out the recipients address, of course). If the Reply-To: isn't present, the program will either use the From: address or the results of its own parsing of the "From_" lines at the top of the message (the results of those dumb AT&T mail transport systems). At the user level, they merely know that if they use "reply" that it will go to the appropriate person, and if they use "group reply" it will be sent to the "reply" address AND the list of people who received the original message. A wrinkle is added when we start to consider the reliability of information in the From: and Reply-To: fields...Any mail not from a "real" internet site has a high likelihood of having an invalid due to omission address. So how to deal with it? I don't think we can assume that we can get the host and login of the ultimate destination machine and route from there (e.g. ignore the path the message took) - therein lies painful death if we have no path, an old path, or, horrors! multiple hosts with the same name. Once we get domains fully implemented I anticipate a lot of this hassle going away, since all addresses will either fully specified by the sending machine (e.g. "To: taylor" would leave my machine as "To: taylor@hpldat.HPL.HP.COM") or by the user (via aliases, I hope!) as in "To: woodward@scfac" -> "To: woodward@scfac.DEC.COM" etc). This also leads to a question of how do we deal with incorrectly specified domains (e.g. "hpldat.HP.COM") but that's a different story entirely!! The way the elm gets around this problem is that the default configuration *ignores* the From: and Reply-To: addresses and simply traces back the sending route. The system administrator, installing the program, has to decide if the addresses contained therein are valid or not (since the program sure can't!!). Anyone have any comments on this user-level .vs. system-level restatement of the problem?? [I *don't* think another header is needed! Gad! We already have enough that it's a bloody pain to figure out the precedence of them all (e.g. From, Sender etc). "Return-Path:" is ignored in elm because I think it's a bogus header...] -- Dave Taylor taylor@hplabs.HP.COM  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 NOV 86 15:16:44 EST Received: from LOKI.BBN.COM (TCP 20026200116) by MC.LCS.MIT.EDU 20 Nov 86 15:10:42 EST To: header-people@mc.lcs.mit.edu Subject: Use of Reply-To Date: Thu, 20 Nov 86 15:08:56 -0500 From: Craig Partridge I do want to point out that the Reply-To can contain multiple addresses. If you wanted to incorporate everyone in your cc list in your Reply-To as well, you are supposed to be able to. Craig Partridge CSNET Technical Staff  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 2 Dec 86 17:06:15 EST Received: from YKTVMX(VICTOR) by MITVMA (Mailer X1.23) id 2725; Tue, 02 Dec 86 17:01:14 EST Date: 2 Dec 1986 16:45:17-EST (Tuesday) From: "Victor S. Miller" To: HEADER-PEOPLE@AI.AI.MIT.EDU Subject: Redistribution lists Recently I became the moderator for TheoryNet (a bulletin board for theoretical computer science). Every time I post a submission, I get a large number of error messages from various mail delivery agents around the world. Most of them concern recipients who are on redistribution lists at various sites. I would think that it would be better for these messages to go to the local postmaster, or maintainer of the list (they can do something about them). How can I arrange that this happens? Another thing that I have noticed, is that quite a large number of the recipients who cause errors are not local recipients. It would be nice if these names weren't on the list to begin with. What I'm leading up to, is that it would be nice if there were some organized way of finding out who is responsible for these mailing lists. At the very least, it would be nice if the error messages indicated the userid of the original recipient, since it is not always easy to figure out who it was. Victor S. Miller  Received: from gjetost.wisc.edu (TCP 30003006041) by AI.AI.MIT.EDU 3 Dec 86 07:22:36 EST Date: Wed, 3 Dec 86 06:21:18 CST From: solomon@gjetost.wisc.edu (Marvin Solomon) Message-Id: <8612031221.AA01360@gjetost.wisc.edu> Received: by gjetost.wisc.edu; Wed, 3 Dec 86 06:21:18 CST To: VICTOR%yktvmx.bitnet@wiscvm.wisc.edu Subject: Re: Redistribution lists Cc: HEADER-PEOPLE@ai.ai.mit.edu With regard to your original question: This subject has been discussed in this forum many times before and the answer is not simple. In your situation, there are three parties of interest: the submitter, the list maintainer, and the maintainer of a redistribution list (e.g. joe@randomsite sends to theorynet@yktvmx which relays to theory-net-local@podunk-u which relays to random-reader@podunk-u; the three people are joe, the maintainer of theorynet, and the maintainer of theory-net-local). Error messages should NEVER go to joe. If theory-net-local is somehow broken, the theorynet maintainer should find out. If ramdom-reader removes his account, the maintainer of theory-net-local should find out. How do you do that? If the theorynet relay is on the Arpa Internet, it is sending its mail via SMTP, which is a dialogue that introduces each message with a MAIL FROM: command. Normally, if the SMTP receiver has problems, it will either reject the message outright, or send back the error message to xxx@yyy.zzz. Note that the same applies to theory-net-local, although the maintainer of theory-net has no way to make the maintainer of theory-net-local do the "right thing". Similar remarks apply to BITNET if BSMTP (batch SMTP) is in use. How do you get the right thing into the SMTP MAIL FROM command? That's highly system-dependent. Talk to your mail guru. (Barry Appleman is a good choice at Yorktown). What about headers? You have a better chance of getting the right results if the message has lines Reply-to: Sender: or Sender: thus, the redistribution software should put the original sender into the Reply-to: field and put the list maintainer in the Sender: field. (A common convention is to give the maintainer of "list" the alias "list-request".) Now for something slightly different. The "From:" address in your question is illegal (as are most of the examples above). Host names should be globally unique, but your "From:" address is . How do you know that there isn't some other "yktvmx" in the universe? The host name "should" be something like "yktvmx.ibm.com" (which would identify it as the unique yktvmx in the unique ibm in the commercial domain). In the current state of affairs, a more practical solution would be for your return address to be Reply-to: which says that you are on the unique yktvmx in bitnet, but since Internet hosts are unlikely to understand that, replies should be sent to wiscvm.wisc.edu for relay into bitnet. Who is at fault? Either the software on yktvmx that you used to create that header in the first place, or the hosts that first transferred the message out of BITNET and into the Internet. From the headers on your message, that would seem to be mitvma.bitnet and/or mit-multics.arpa.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 4 Dec 86 06:16:06 EST Date: Thu, 4 Dec 86 06:15:09 EST From: "Pandora B. Berman" Subject: [Forwarded: AKLOM@BITNIC, Re: Moving ARPAnet SIGS to BITNET.] To: header-mins@MC.LCS.MIT.EDU Message-ID: <126294.861204.CENT@AI.AI.MIT.EDU> Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 2 Dec 86 19:53:44 EST Received: from BITNIC(MAILER) by MITVMA (Mailer X1.23) id 3130; Tue, 02 Dec 86 18:54:11 EST Received: by BITNIC (Mailer X1.23b) id 0487; Tue, 02 Dec 86 18:49:18 EST Date: Tue, 02 Dec 86 18:53:44 EST From: Judith Molka Subject: Moving ARPAnet SIGS to BITNET. To: MICHAEL S. MAITEN , HOBBIT , RICH ZELLICH , JAKE FEINLER , LARRY LANDWEBER , CHARLOTTE MOORE , ALAN BAWDEN , ANDREW GIDEON , ANDREW KNUTSEN , ANDREW MOORE , ANDY CROMARTY , ANN WESTINE , BILL BOGSTAD , BILL MITCHELL , BOB PUYEAR , BRAD SAGARIN , BRIAN KANTOR , BRUCE NEMNICH , CHRIS CONDON , CHRISTOPHER SCHMIDT , CHUQ VON ROSPACH , CLIFFORD NEUMAN , CRAIG ANDERSON , DAVE STEINER , DAVE TAYLOR , DAVID C. PLUMMER , DAVID E. TOWSON , DAVID FUCHS , DICK KOOLISH , DON STONE , DOUG ALAN , DR. KENNETH I. LAWS , ED FOX , EINAR STEFFERUD , ELIOT MOORE , ERIC LAVITSKY , , FRANK J. WANCHO , FRANK WANCHO , FREDERICK S. BRUNDICK , GARY DELP , GEORGE HARTWIG , GEORGE ROBBINS , GERN , GLEN DANIELS , GLENN S. BURKE , GREGOR J. KICZALES , GREGORY G. FINN , HENRY NUSSBACHER , HOWARD WALTER , J.Q. JOHNSON , JACOB PALME , JIM GETTYS , JOHN BRUGGE , JOHN FODERARO , JOHN LEKASHMAN , JOHN MALLERY , JOHN MARK AGOSTA , JOHN MITCHENER , JOHN ROBINSON , JONATHAN REES , JOSEPH GUIRRERI , , KARL A. NYBERG , KEITH A. LANTZ , KEITH PETERSEN , KEN ROSSEN , KEN VAN CAMP , KEN YAP , , LARRY SEWARD , LISTSERV EDITOR , LIUDVIKAS BUKYS , , MARK CRISPIN , MARK PLOTNICK , MARK RICHER , MARK S. DAY , MARK WEISER , MARLA BAER-PECKHAM , MARSHALL T. ROSE , MARVIN M. ZAUDERER , MATT KIMMEL , MATTHEW SAROFF , MEL PLEASANT , MICHAEL A. PATTON , MICHAEL BROWNE , MICHAEL HABERLER , MIKE MEYER , MIKE MUUSS , NATHANIEL MISHKIN , ODED FEINGOLD , OWEN T. ANDERSON , PANDORA B. BERMAN , PAUL POMES , PETER G. NEUMANN , PRAVEEN KUMAR , RALPH G. SBRAGIA , RALPH W. HYRE, JR. , RAMON CURIEL , RICH KULAWIEC , RICHARD ACUFF , RICHARD FURUTA , RICK CONN , ROBERT L. KRAWITZ , RON NATALIE , S. W. GALLEY , SCOTT BRIM , SCOTT CAMPBELL , STEPHEN PAGE , STEVE STRASSMANN , STEW RUBENSTEIN , SUSAN TABRON , TAMIR WEINER , TODD BOOTH , VINCE FULLER , VIVIAN NEOU , WALT The following is a message sent from Larry Landweber, coordinator of the Wisconsin Gateway to ARPAnet and BITNET List Administrators. "Because of Arpanet congestion problems, our WISCVM mail relay is unable to keep up with the quantity of mail sent to it for forwarding. While the problem is particularly acute in the Bitnet to Arpanet direction, the level of traffic in both directions is a problem. A large part of this traffic results from mailing lists. Furthermore, while we are usually only sent a single copy of a list mailing, the recipient list is often very long. A single message may require the sending of over a hundred copies This is a problem for two reasons... Arpanet congesion makes it difficult at times to establish and keep TCP connections and such connections are slow; second, the implementation of the gateway at present makes multiple copies for forwarding (a poor design choice that is being worked on). At present, the first problem is far important. Note that in a about a month we will begin limiting the number of copies we will relay by putting a limit on the number of recipients in RCPT TO lines in SMTP and BSMTP. This limit is likely to be 10. Thanks in advance for your cooperation in this matter. Larry Landweber" The BITNET Network Information Center has been working with Larry Landweber on the problem discussed above. If your Special Interest Group does not have a BITNET site willing to create a sub-list to maintain your BITNET subscribers, then we will assist in finding you a site. If you have found a BITNET site to host your sub-lists, then please send the name of your SIG and the name of the BITNET sub-list to AKLOM@BITNIC. This information is needed by Rich Zellich to update the ARPANET SIGs file. The BITNIC will coordinate the efforts of those on the network who are working on distribution lists. This includes working with Rich Zellich to provide instructions in ARPANET SIGs of where users should subscribe for each list, helping the maintainers of the sub-lists in obtaining existing subscriptions from the ARPAnet coordinators and contacting the SRI-NIC to help us set up lists for the ARPAnet subscribers to BITNET lists. These are the ARPAnet SIGs which we are aware of that have BITNET sub-lists in operation. ARPAnet list BITNET list ---------------------------------- -------------------- INFO-VAX@SRI-KL.ARPA INFO-VAX@UGA INFO-IBMPC@C.ISI.EDU I-IBMPC@UGA INFO-KERMIT@CU20B.COLUMBIA.EDU I-KERMIT@UGA SF-LOVERS@RED.RUTGERS.EDU SFLOVERS@UGA SECURITY@RED.RUTGERS.EDU SECURITY@UGA INFO-HZ100@RADC-TOPS20.ARPA INF-Z100@CLVM UNIX-SOURCES@BRL.ARPA UNIX-SRC@CLVM INFO-NETS%MIT-OZ@MC.LCS.MIT.EDU INFONETS@BITNIC --Judy Molka, BITNET Network Information Center  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 4 Dec 86 08:54:19 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 4 Dec 86 08:52:59 EST Received: from AI.AI.MIT.EDU by MIT-MULTICS.ARPA TCP; 04-Dec-1986 08:52:02-est Date: Thu, 4 Dec 86 06:32:17 EST From: header-people-request@AI.AI.MIT.EDU Sender: CENT@AI.AI.MIT.EDU Subject: 4 POINTS OF ADMINISTRIVIA -- LISTEN UP FOLKS To: HEADER-PEOPLE@AI.AI.MIT.EDU cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, aklom%bitnic%mitvma@MULTICS.MIT.EDU, zellich@SRI-NIC.ARPA, lhl@WISCVM.WISC.EDU, RMXJ%CORNELLC.BITNET@WISCVM.WISC.EDU Message-ID: <126300.861204.CENT@AI.AI.MIT.EDU> 1. Due to the increased usage of MIT-AI, HEADER-PEOPLE, its archives, and its auxiliary -REQUEST list have moved (back) to (the new) MIT-MC. The forwarding pointers on AI are all in place, so this change should be reasonably transparent (1 more Received: line) for people who mail to the old address, but everyone is urged to mail directly to MC in an effort to lighten the total network mail load. All archives, HEADER MINS00 through MINS15 (back to 1977!), as well as the recent mail, HEADER MINS, live on the KSC; directory on MC.LCS.MIT.EDU, and are trivially accessible over the Arpanet via FTP. People on other nets who want to see the archives: well, mostly you should try to get assistance from your friends on net gateway machines to ship these files through. But if you can't find any such acquaintances and are desperate, you can send mail to HEADER-PEOPLE-REQUEST and try to twist my arm. 2. To reiterate: The chief maintainer of HEADER-PEOPLE does not participate in the discussion (I'm otherwise busy), so any add/remove/change requests sent to HEADER-PEOPLE are only an annoyance to other list members. Please send such to HEADER-PEOPLE-REQUEST. HEADER-PEOPLE is maintained but not moderated, and the master list lives on an ITS, so its primary distribution is through COMSAT; this means you, the original msg authors, get all those nasty error reports about non-existent addresses, etc. Sorry. Forward them along to HEADER-PEOPLE-REQUEST and they will get taken care of, quickly -- I know just how much you feel about junk filling your mailbox. 3. There was, briefly, a problem with some list addresses at Berkeley; the list referred to the host as merely BERKELEY, when that nickname had been removed from the relevant host tables. Some well-intentioned soul replaced all occurences of BERKELEY in the list file with BERKELEY.EDU. Thank you, whoever you are, for trying -- but you did it wrong. One address was already a BERKELEY.EDU, so you broke it by adding an extra .EDU; also, you fucked up the history section of the file. And you didn't give anyone any indication that you had done anything to the list. HEADER-PEOPLE-REQUEST does exist for a reason; the next time you feel moved to modify the list, please drop us a line, so we know what's happening and can vet your changes. 4. WISCVM, the chief ARPANET/BITNET gateway, is getting snowed under: Date: 14 November 86 18:33 EST To: ARPANET and BITNET List Administrators From: Larry Landweber Subject: WISCVM Mail Relay Because of Arpanet congestion problems, our WISCVM mail relay is unable to keep up with the quantity of mail sent to it for forwarding. While the problem is particularly acute in the Bitnet to Arpanet direction, the level of traffic in both directions is a problem. A large part of this traffic results from mailing lists. Furthermore, while we are usually only sent a single copy of a list mailing, the recipient list is often very long. A single message may require the sending of over a hundred copies. This is a problem for two reasons... Arpanet congesion makes it difficult at times to establish and keep TCP connections and such connections are slow; second, the implementation of the gateway at present makes multiple copies for forwarding (a poor design choice that is being worked on). At present, the first problem is far important. significant. To alleviate the problems cited above and enable us to provide a reasonable level of service, we are asking Arpanet list maintainers to provide list exploders on Bitnet and vice versa. Your cooperation will be very much appreciated. Note that in a about a month we will begin limiting the number of copies we will relay by putting a limit on the number of recipients in RCPT TO lines in SMTP and BSMTP. This limit is likely to be 10. Thanks in advance for your cooperation in this matter. So we need a volunteer on BITNET to take over the BITNET addresses as a redistribution point. Light work, little acclaim, some harrassment when the more irritable folks have erring mail returned to them -- and if no one does it, the BITNET side of this list will go down the tube. Interested folk are encouraged to apply to (you guessed it) HEADER-PEOPLE-REQUEST; indications of sanity, experience at dealing with mailing lists, sense of humor, etc. will be taken into account in choosing the victim////// noble volunteer. Thank you for your attention to this public service msg..  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 4 Dec 86 10:11:13 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 4 Dec 86 10:10:04 EST Date: Thu, 4 Dec 86 04:41 EST From: John C Klensin Subject: Marvin's redistribution list comments To: VICTOR@YKTVMX.BITNET, Marvin Solomon cc: header-people@AI.AI.MIT.EDU Message-ID: <861204094145.321439@MIT-MULTICS.ARPA> To add two things to this succinct and clear explanation (I am keeping a copy so I can use it to explain this problem locally (which I need to do, again and again)): The offender is mitvma.bitnet and mit-multics.arpa. The two machines have a wire running between them that constitutes a partial BITNET->Internet gateway. One explanation for the problem is that each machine is expecting the other to munge the headers; neither does. Another explanation is that the proper munging of the headers is at the bottom of a hole labelled "we think we found a counterexample that demonstrates at least one case where header-munging fails to produce the correct/anticipated effect, therefore we will do nothing". However, the sending host can overcome a good deal (not all) of the problem with a small, very popular, and only slightly illegal ruse: if the mail leaves yktvmx with the host name 'yktvmx.BITNET' in the header, i.e., using the pseudo-domain 'BITNET', many Internet hosts, including the mit-multics->mitvma offending/offensive pseudo-gateway, will know what to do with it. And, on those hosts that don't, many human beings and mail agents will know enough to look at a "host name" ending in ".BITNET" and say "aha, user%yktvmx.BITNET@WISCVM.WISC.EDU" -- so at least it is possible to get an answer back. In this particular case, the sending host, yktvmx, must route the (RSCS) mail to MAILER@MITMVA on BITNET in order to have it get through thatthe MITVMA->MIT-Multics gateway. MAILER@MITVMA is an MTA, and it, at least, is quite happy to accept From: and Sender: fields in messages that say things like victor%yktvmx.BITNET@WISCVM.WISC.EDU or, to get things back the way they came, victor%yktvmx.BITNET@MIT-Multics.ARPA ...whether it should accept Sender/From addresses that differ, even slightly, from the BSMTP envelope (or what it requires of that envelope) is an open question, but it does. That permits the originating host to fix/avoid the problem itself. And so, the third explanation around here is that neither mit-multics.arpa not mitvma.BITNET should need to do the job, the originating host (yktvmx) should do so. I'm not, personally, real impressed with that story, but, you, Victor, might translate it as "either put together message headers that conform to the idiosyncracies of the unofficial gateways that you use, or use an official gateway (e.g., WISCVM.WISC.EDU) that does the right thing". Disclaimer: While I work for/at MIT, I am not part of the organization that determines whether the situations discussed above are "features" or problems worth fixing .a and whether the word "explanations" used above should be spelled "excuses". In this particular case, perhaps, more's the pity. john  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Dec 86 03:23:09 EST Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 5 Dec 86 03:22:19 EST Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Fri 5 Dec 86 00:18:17-PST Date: Fri 5 Dec 86 00:01:41-PST From: David Roode Subject: Re: Redistribution lists To: Victor%YKTVMX.BITNET@WISCVM.WISC.EDU cc: HEADER-PEOPLE@AI.AI.MIT.EDU In-Reply-To: Message from ""Victor S. Miller" " of Tue 2 Dec 86 13:45:17-PST Phone: (415) 965-5585 Message-ID: <12260300425.19.ROODE@BIONET> You should not have to do anything to have error messages for local exploders route back to the local host. The local host should be building a RETURN PATH that will cause this to happen for all downline messages (until the next local exploder). The problem is incomplete implementations of exploders at sites being used for mail relaying by your mailing list. One alternative is to switch to sites which do implement this in what has become the accepted manner. If you play with the "Sender:" header, or the "Reply-to:" header, you may trick certain mailers which do not otherwise produce the desired RETURN PATH into doing so; you may also cause legitimate replies to the message from humans to go astray. -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 06:44:45 EST Received: from USC-ECLB.ARPA (TCP 3201600101) by AI.AI.MIT.EDU 14 Dec 86 06:44:14 EST Date: Sun 14 Dec 86 03:42:27-PST From: Leonard D. Woren Subject: question on ReSent-To To: header-people@AI.AI.MIT.EDU Message-ID: <12262699910.13.LDW@USC-ECLB.ARPA> A question came up on what it means to if there are multiple ReSent-xxx lines of the same type. RFC 822 seems to ignore this problem. Can anyone tell me what a mailer should do, for example, if it receives a message with multiple ReSent-To: lines??? How would the mailer know which ReSent-To: line to use in delivering the message? The problem appears to exist with many (or all) resent- fields. Suppose there are multiple ReSent-From: lines. How would a mailer or user agent "reply" command know which one to use? If possible, please reply to (or cc:) LDW@USCMVSA.BITNET -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 11:38:06 EST Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 14 Dec 86 11:37:47 EST Received: from nrtc-gremlin by nrtc-gremlin.arpa id a007324; 14 Dec 86 8:35 PST To: "Leonard D. Woren" cc: header-people@ai.ai.mit.EDU, ldw%USCMVSA.BITNET@wiscvm.wisc.EDU reply-to: header-people@ai.ai.mit.EDU Subject: Re: question on ReSent-To In-reply-to: Your message of Sun, 14 Dec 86 03:42:27 -0800. <12262699910.13.LDW@USC-ECLB.ARPA> Date: Sun, 14 Dec 86 08:35:38 -0800 Message-ID: <7322.534962138@nrtc-gremlin.arpa> From: Marshall Rose Having multiple Resent-xxx fields is no worse than having multiple xxx fields (e.g., To: and cc:). There isn't a problem. Programs like "mailers" have two units of information: the envelope and the message. The envelope contains (among other things) the recipients that the mailer is responsible for, the message has whatever the originating user typed in, plus a Received: field for every mailer that it's passed through. If the mailsystem did not separate the envelope and the message, then "accurate" delivery would be impossible as an address could be an alias which gets expanded to other addresses, and so on. Now, for the second part of your question: how does a user agent "reply" command know which one to use. The answer is that it doesn't use Resent-From: for replies, nor does it uses any Resent-xxx: headers. For the purposes of replying, it should ignore all the Resent-xxx: headers and use the usual Reply-To:/From:, To: and cc: fields. The Resent fields are used, by my interpretation, for one thing only: when a user takes a message s/he received and wishes to propagate it in the "mailsystem" to other recipients, the user adds Resent fields and says to send the message. The user agent sees the Resent fields, and then using whatever method it has for talking to its local mailer, it creates an envelope with the contents of the Resent fields. The mailer acts on this information, not on any information in the message. /mtr  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 12:30:57 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 14 Dec 86 12:29:56 EST Date: Sun, 14 Dec 1986 12:27 EST Message-ID: From: Rob Austein To: "Leonard D. Woren" , LDW%USCMVSA.BITNET@WISCVM.WISC.EDU Cc: header-people@AI.AI.MIT.EDU Subject: question on ReSent-To In-reply-to: Msg of 14 Dec 1986 06:42-EST from Leonard D. Woren Date: Sunday, 14 December 1986 06:42-EST From: Leonard D. Woren A question came up on what it means to if there are multiple ReSent-xxx lines of the same type. RFC 822 seems to ignore this problem. Can anyone tell me what a mailer should do, for example, if it receives a message with multiple ReSent-To: lines??? How would the mailer know which ReSent-To: line to use in delivering the message? The problem appears to exist with many (or all) resent- fields. Suppose there are multiple ReSent-From: lines. How would a mailer or user agent "reply" command know which one to use? I think you confusing envelope and contents. RFC822 came out at the same time as RFC821 (SMTP), which is the answer to your question. You aren't supposed to -do- anything based on the Resent-To: lines, you're supposed to be using the SMTP RCPTs. In case you haven't heard of it yet, there's this neat adaptation of SMTP for store-and-forward-file oriented networks (eg, BITNET), called BSMTP. It is a minimal set of additions to SMTP (two new commands, one new reply code) and is a real winner. I can post the spec (it's real short) if there's sufficient interest. I believe that the most common BITNET mailer (Alan Crosswell's MAILER) now uses BSMTP. Among other things, it provides things like SMTP return-path for errors, and a way to work around the 8 character limit on RSCS user-ids (handy if you are using a BITNET machine to relay mail to another machine that isn't an IBM mainframe...). Of late, we have been converting hosts on the MIT Chaosnet to using SMTP instead of the old MAIL protocol (which parses the RFC882 headers). The header parsing was getting too complex and we kept getting screwed by the lack of SMTP return-paths. At this point you shouldn't be writing new code that parses RFC882 headers if there is any way to avoid it. You should put your programer time into implementing the newer mail protocols. SMTP isn't perfect, but a lot of the design decisions in it were based on the failings of the older protocols (ie, it's a second generation mail protocol). Is there some particular environment that you have to work with that requires parsing RFC882 headers? I have heard that the WISCVM gateway is still sending non-BSMTP messages on the BITNET side, even though it insists on BSMTP for messages going the other way. --Rob  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 12:30:57 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 14 Dec 86 12:29:56 EST Date: Sun, 14 Dec 1986 12:27 EST Message-ID: From: Rob Austein To: "Leonard D. Woren" , LDW%USCMVSA.BITNET@WISCVM.WISC.EDU Cc: header-people@AI.AI.MIT.EDU Subject: question on ReSent-To In-reply-to: Msg of 14 Dec 1986 06:42-EST from Leonard D. Woren Date: Sunday, 14 December 1986 06:42-EST From: Leonard D. Woren A question came up on what it means to if there are multiple ReSent-xxx lines of the same type. RFC 822 seems to ignore this problem. Can anyone tell me what a mailer should do, for example, if it receives a message with multiple ReSent-To: lines??? How would the mailer know which ReSent-To: line to use in delivering the message? The problem appears to exist with many (or all) resent- fields. Suppose there are multiple ReSent-From: lines. How would a mailer or user agent "reply" command know which one to use? I think you confusing envelope and contents. RFC822 came out at the same time as RFC821 (SMTP), which is the answer to your question. You aren't supposed to -do- anything based on the Resent-To: lines, you're supposed to be using the SMTP RCPTs. In case you haven't heard of it yet, there's this neat adaptation of SMTP for store-and-forward-file oriented networks (eg, BITNET), called BSMTP. It is a minimal set of additions to SMTP (two new commands, one new reply code) and is a real winner. I can post the spec (it's real short) if there's sufficient interest. I believe that the most common BITNET mailer (Alan Crosswell's MAILER) now uses BSMTP. Among other things, it provides things like SMTP return-path for errors, and a way to work around the 8 character limit on RSCS user-ids (handy if you are using a BITNET machine to relay mail to another machine that isn't an IBM mainframe...). Of late, we have been converting hosts on the MIT Chaosnet to using SMTP instead of the old MAIL protocol (which parses the RFC882 headers). The header parsing was getting too complex and we kept getting screwed by the lack of SMTP return-paths. At this point you shouldn't be writing new code that parses RFC882 headers if there is any way to avoid it. You should put your programer time into implementing the newer mail protocols. SMTP isn't perfect, but a lot of the design decisions in it were based on the failings of the older protocols (ie, it's a second generation mail protocol). Is there some particular environment that you have to work with that requires parsing RFC882 headers? I have heard that the WISCVM gateway is still sending non-BSMTP messages on the BITNET side, even though it insists on BSMTP for messages going the other way. --Rob  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 18:47:59 EST Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 14 Dec 86 15:34:37 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 14 Dec 86 12:28:49-PST Date: Sun 14 Dec 86 11:27:01-PST From: Mark Crispin Subject: Re: question on ReSent-To To: LDW@USC-ECLB.ARPA, LDW%USCMVSA.BITNET@WISCVM.WISC.EDU cc: header-people@AI.AI.MIT.EDU In-Reply-To: <12262699910.13.LDW@USC-ECLB.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12262784482.7.MRC@PANDA> Leonard Woren - The first part of your question is meaningless. The message header is not used by the mailer in determining who the message should go to. That information is stored in the "envelope" of the message, which is transmitted by the SMTP (RFC 821) protocol out of band from the message. There is not necessarily any correlation between the information in the header and what actually exists in the envelope, although generally the header information is a *subset* of the envelope information. Replies are sent to the REPLY-TO address if it exists, else to the FROM address. Replies are never sent to SENDER, RETURN-PATH, or any of the RESENT-xxx lines. If the re-sender had wanted a reply he would have forwarded the message inside his own message instead of resending the original message. -- Mark -- -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 00:13:49 EST Received: from RADC-MULTICS.ARPA (TCP 3200000022) by AI.AI.MIT.EDU 15 Dec 86 00:13:07 EST Date: Mon, 15 Dec 86 00:07 EST From: Rodney Subject: x.25 et al To: header-people@AI.AI.MIT.EDU Message-ID: <861215050735.241268@RADC-MULTICS.ARPA> I'd like to find out about all this networking stuff, is there someplace I can ftp a document explaining X.25 or any of the other nets? -rodney  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 04:08:33 EST Received: from USC-ECLB.ARPA (TCP 3201600101) by AI.AI.MIT.EDU 15 Dec 86 04:05:55 EST Date: Mon 15 Dec 86 01:06:00-PST From: Leonard D. Woren Subject: Resent-xxx, RFC822, BSMTP To: header-people@AI.AI.MIT.EDU Message-ID: <12262933571.33.LDW@USC-ECLB.ARPA> Thanks for the replies. Obviously, I should have included more information. Also obviously, the mailer that I am running has a problem. I have UCLA/Mail running on MVS, and the Crosswell mailer running on VM. UCLA/Mail was written to conform to RFC822. It will handle BSMTP, but not everything sends it. Our VM node is not sending BSMTP to the MVS node. I'll have to get the VM'ers to check out whether we're running the latest version of the Crosswell mailer, or whether there's some definition that needs to be changed to have it send BSMTP to the MVS system. WISCVM and other gateways that will remain nameless often send us mail without BSMTP envelopes, that has bad headers, because they don't mung them going through the gateway, and that mail cannot be delivered by UCLA/Mail. I agree, it appears that I would not be having any problems if *every* mailer sent BSMTP. The reason for my original query is that the author of UCLA/Mail said that one reason he doesn't support a lot of RFC822 fields is that they're not clearly defined. I'll forward my question and all the responses to him. If (B)SMTP is the way to go, why was RFC822 even written? Isn't SMTP defined in RFC821? And, thanks for the offer of posting the BSMTP definition, but I believe that I already have it. -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 10:33:30 EST Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 15 Dec 86 10:32:28 EST Received: from nrtc-gremlin by nrtc-gremlin.arpa id a010353; 15 Dec 86 7:32 PST To: "Leonard D. Woren" cc: header-people@ai.ai.mit.EDU reply-to: header-people@ai.ai.mit.EDU Subject: Re: Resent-xxx, RFC822, BSMTP In-reply-to: Your message of Mon, 15 Dec 86 01:06:00 -0800. <12262933571.33.LDW@USC-ECLB.ARPA> Date: Mon, 15 Dec 86 07:32:07 -0800 Message-ID: <10351.535044727@nrtc-gremlin.arpa> From: Marshall Rose Hopefully you won't get too many flames for your last message "if (B)SMTP is the way to go, why was rfc822 ever written?" The answer is simple: they solve different problems. SMTP is used by mailers to exchange messages in transit. In a correctly managed environment, there is no munging involved! The only thing an SMTP implementation will do to the message it accepts is add a Received: line and update the Return-Path:. It should do nothing more. (The operative term here is "correctly managed".) SMTP should spend most of its time handling envelope stuff. 822 is used by user agents to manage a different type of information. It is 822 which defines the semantics of Reply-To:, Subject:, Date:, To:, and so on. 821/SMTP is totally naive about this kind of stuff. Now, I can tell you from long, bitter experience, and I'm sure other people who've I'd had violent arguments with, like Mark Crispin, will agree with me that: If your "mailer" doesn't deal in envelopes, and instead looks at the headers of the message to figure out what to do, then it is SEVERELY BROKEN and WILL NEVER WORK RIGHT! As far as your friend's claim that "822 isn't specific enough on the meanings of the fields it defines", my claim is that it is a matter of interpretation. I know of 5 independently coded implementations of user agents in the ARPA Internet which all manage work together. While each implementation team might view that only their code conforms to 822 and the other four don't, everything still works. I suspect the best thing to do, is to ask more questions on header-people, and try to resolve any issues you might have. /mtr  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 10:33:30 EST Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 15 Dec 86 10:32:28 EST Received: from nrtc-gremlin by nrtc-gremlin.arpa id a010353; 15 Dec 86 7:32 PST To: "Leonard D. Woren" cc: header-people@ai.ai.mit.EDU reply-to: header-people@ai.ai.mit.EDU Subject: Re: Resent-xxx, RFC822, BSMTP In-reply-to: Your message of Mon, 15 Dec 86 01:06:00 -0800. <12262933571.33.LDW@USC-ECLB.ARPA> Date: Mon, 15 Dec 86 07:32:07 -0800 Message-ID: <10351.535044727@nrtc-gremlin.arpa> From: Marshall Rose Hopefully you won't get too many flames for your last message "if (B)SMTP is the way to go, why was rfc822 ever written?" The answer is simple: they solve different problems. SMTP is used by mailers to exchange messages in transit. In a correctly managed environment, there is no munging involved! The only thing an SMTP implementation will do to the message it accepts is add a Received: line and update the Return-Path:. It should do nothing more. (The operative term here is "correctly managed".) SMTP should spend most of its time handling envelope stuff. 822 is used by user agents to manage a different type of information. It is 822 which defines the semantics of Reply-To:, Subject:, Date:, To:, and so on. 821/SMTP is totally naive about this kind of stuff. Now, I can tell you from long, bitter experience, and I'm sure other people who've I'd had violent arguments with, like Mark Crispin, will agree with me that: If your "mailer" doesn't deal in envelopes, and instead looks at the headers of the message to figure out what to do, then it is SEVERELY BROKEN and WILL NEVER WORK RIGHT! As far as your friend's claim that "822 isn't specific enough on the meanings of the fields it defines", my claim is that it is a matter of interpretation. I know of 5 independently coded implementations of user agents in the ARPA Internet which all manage work together. While each implementation team might view that only their code conforms to 822 and the other four don't, everything still works. I suspect the best thing to do, is to ask more questions on header-people, and try to resolve any issues you might have. /mtr  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 10:33:30 EST Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 15 Dec 86 10:32:28 EST Received: from nrtc-gremlin by nrtc-gremlin.arpa id a010353; 15 Dec 86 7:32 PST To: "Leonard D. Woren" cc: header-people@ai.ai.mit.EDU reply-to: header-people@ai.ai.mit.EDU Subject: Re: Resent-xxx, RFC822, BSMTP In-reply-to: Your message of Mon, 15 Dec 86 01:06:00 -0800. <12262933571.33.LDW@USC-ECLB.ARPA> Date: Mon, 15 Dec 86 07:32:07 -0800 Message-ID: <10351.535044727@nrtc-gremlin.arpa> From: Marshall Rose Hopefully you won't get too many flames for your last message "if (B)SMTP is the way to go, why was rfc822 ever written?" The answer is simple: they solve different problems. SMTP is used by mailers to exchange messages in transit. In a correctly managed environment, there is no munging involved! The only thing an SMTP implementation will do to the message it accepts is add a Received: line and update the Return-Path:. It should do nothing more. (The operative term here is "correctly managed".) SMTP should spend most of its time handling envelope stuff. 822 is used by user agents to manage a different type of information. It is 822 which defines the semantics of Reply-To:, Subject:, Date:, To:, and so on. 821/SMTP is totally naive about this kind of stuff. Now, I can tell you from long, bitter experience, and I'm sure other people who've I'd had violent arguments with, like Mark Crispin, will agree with me that: If your "mailer" doesn't deal in envelopes, and instead looks at the headers of the message to figure out what to do, then it is SEVERELY BROKEN and WILL NEVER WORK RIGHT! As far as your friend's claim that "822 isn't specific enough on the meanings of the fields it defines", my claim is that it is a matter of interpretation. I know of 5 independently coded implementations of user agents in the ARPA Internet which all manage work together. While each implementation team might view that only their code conforms to 822 and the other four don't, everything still works. I suspect the best thing to do, is to ask more questions on header-people, and try to resolve any issues you might have. /mtr  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 12:41:52 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 15 Dec 86 12:41:08 EST Received: from YKTVMX(VICTOR) by MITVMA (Mailer X1.23) id 4008; Mon, 15 Dec 86 12:35:35 EST Date: 15 Dec 1986 12:30:13-EST (Monday) From: "Victor S. Miller" To: header-people@ai.ai.mit.edu Subject: Folding long fields In re-reading rfc822, I find that folding long lines is permitted only where LWSP is permitted. What should one do with some horrendously long addresses one gets from UseNet: in the form a!b!...!z where the total length often is longer than 140 characters? (of course this comes in a header field called Path which isn't in the rfc822 standard -- it should be called X-Path). The character "!" doesn't have any lexically special meaning in rfc822 (neither does %), thus it looks like one can't fold it anywhere. Victor  Received: from po2.andrew.cmu.edu (TCP 20000574551) by MC.LCS.MIT.EDU 15 Dec 86 14:26:50 EST Received: by po2.andrew.cmu.edu (4.12/3.15) id ; Mon, 15 Dec 86 13:49:25 est Received: FROM lititz VIA queuemail ID ; Mon, 15 Dec 86 13:49:03 est Message-Id: Date: Mon, 15 Dec 86 13:48:32 est From: cfe#@andrew.cmu.edu (Craig F. Everhart) To: header-people@mit-mc.arpa Subject: Re: Resent-xxx, RFC822, BSMTP I agree that in the Arpa Internet world nobody should muck with the 822 headers (except for adding Received: and Return-Path: lines. (Headers should be composed properly in the first place, but that's another issue.) In the Bitnet world, mail is much less well specified. There are lots of Bitnet hosts and mailers that don't support the envelope/content distinction that RFC821 provides (that is generally provided by the BSMTP variant of SMTP), and they resort to inspection of the header fields. My belief is that Bitnet mail is (currently, at least) sufficiently different from Arpa Internet mail that mail gateway machines must, in general, rewrite the addresses in the headers. Not that I'm specifying the transformations here!  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 14:52:52 EST Received: from WISCVM.WISC.EDU (TCP 20032201015) by AI.AI.MIT.EDU 15 Dec 86 14:52:13 EST Received: from (MAILER)DBNGMD21.BITNET by WISCVM.WISC.EDU on 12/15/86 at 13:51:28 CST Date: Mon, 15 Dec 86 20:40 CET To: header-people@ai.ai.mit.edu From: Peter Sylvester +49 228 303245 Subject: Re: Folding long fields > From: "Victor S. Miller" .... > one gets from UseNet: in the form a!b!...!z where the total length often > is longer than 140 characters? (of course this comes in a header field You put your finger into one of the wounds of the SMTP interpretation in BITNET (and maybe in other environments, too). In BITNET there is no RFC821/2 mail. It is EBCDIC and CRLF is interpreted a "end of card" (80 columns). Blanks are always inserted and you get either 80 or 79 characters in a "line" (79 if you have to double a dot in col 1). 79/80 is much less than any of the limits that are in RFC821 although it works in 99.9999% of all "texts". Peter  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 19:05:25 EST Received: from BRL-SEM.ARPA (TCP 30001213410) by AI.AI.MIT.EDU 15 Dec 86 16:22:44 EST Date: Mon, 15 Dec 86 16:15:58 EST From: Ron Natalie To: "Victor S. Miller" cc: header-people@ai.ai.mit.EDU Subject: Re: Folding long fields Message-ID: <8612151615.aa04955@SEM.BRL.ARPA> There is no restriction on having a header field called "Path," receiving sites are free to discard it. The "X-" prefix is guaranteed never to be used for anything in the spec so it is available to user implementations. -Ron  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Dec 86 22:26:14 EST Received: from jade.berkeley.edu (TCP 20010104011) by AI.AI.MIT.EDU 19 Dec 86 21:14:44 EST Received: from web.berkeley.edu by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.6) id AA08273; Fri, 19 Dec 86 18:09:09 PST Received: by web.Berkeley.Edu (1.1/SMI-3.0DEV3.4) id AA09711; Fri, 19 Dec 86 18:11:39 PST Date: Fri, 19 Dec 86 18:11:39 PST From: netinfo%web.Berkeley.EDU@BERKELEY.EDU (Postmaster & BITINFO) Message-Id: <8612200211.AA09711@web.Berkeley.Edu> To: header-people@ai.ai.mit.edu, victor@ibm.com Subject: Re: Folding long fields Cc: mark@cbosgd.att.com, usenet@ucbvax.Berkeley.EDU In reply to: Date: 15 Dec 1986 12:30:13-EST (Monday) From: "Victor S. Miller" To: header-people@ai.ai.mit.edu Subject: Folding long fields Status: RO In re-reading rfc822, I find that folding long lines is permitted only where LWSP is permitted. What should one do with some horrendously long addresses one gets from UseNet: in the form a!b!...!z where the total length often is longer than 140 characters? (of course this comes in a header field called Path which isn't in the rfc822 standard -- it should be called X-Path). The character "!" doesn't have any lexically special meaning in rfc822 (neither does %), thus it looks like one can't fold it anywhere. Victor I concur that Path should not be put in RFC822 mail headers when news is gatewayed from USENET news to Internet mail systems. Often Path is not even a mail address. It is actually a list of USENET news site codes that a USENET news article has passed through. Altrough USENET users may thing otherwise, there are many news links that are not UUCP news links. I would be nice if the USENET/mail gateway software programmers would delete the Path when it is transported into the mail system, and optionally use X-Path (if they must) with LWSP between sites instead of exclamation marks. Bill Wells postmaster%web@Berkeley.EDU  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Dec 86 22:26:22 EST Received: from jade.berkeley.edu (TCP 20010104011) by AI.AI.MIT.EDU 19 Dec 86 21:33:19 EST Received: from web.berkeley.edu by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.6) id AA08456; Fri, 19 Dec 86 18:31:51 PST Received: by web.Berkeley.Edu (1.1/SMI-3.0DEV3.4) id AA09755; Fri, 19 Dec 86 18:34:23 PST Date: Fri, 19 Dec 86 18:34:23 PST From: netinfo%web.Berkeley.EDU@BERKELEY.EDU (Postmaster & BITINFO) Message-Id: <8612200234.AA09755@web.Berkeley.Edu> To: GRZ027@DBNGMD21.BITNET, header-people@ai.ai.mit.edu, mail-l@bitnic.BITNET Subject: BITNET mail system In reply to: Date: Mon, 15 Dec 86 20:40 CET From: Peter Sylvester +49 228 303245 ... In BITNET there is no RFC821/2 mail.... Yes there is no interactive RFC821 on BITNET because BITNET/EARN/NETNORTH is a file transfer network. The BSMTP is the non-interactive replacement for SMTP on BITNET in the VM mailer system.. It might be more correct to say that there is an Internet mail transport system (VM Mailer from Columbia University) on BITNET/EARN/NETNORTH, but that many sites with IBM computers do not participate in this mail system because they only want to run IBM supported software. Bill Wells  Received: from po3.andrew.cmu.edu (TCP 20000406037) by MC.LCS.MIT.EDU 7 Jan 87 17:49:28 EST Received: by po3.andrew.cmu.edu (4.12/3.15) id ; Wed, 7 Jan 87 17:44:08 est Received: via switchmail; Wed, 7 Jan 87 17:43:57 est Received: FROM lititz VIA queuemail ID ; Wed, 7 Jan 87 17:42:04 est Message-Id: Date: Wed, 7 Jan 87 17:41:37 est From: cfe#@andrew.cmu.edu (Craig F. Everhart) To: Arpa-MHS@brl.arpa, Header-People@mc.lcs.mit.edu Subject: Unambiguous local addresses Cc: cfe#@andrew.cmu.edu (Craig F. Everhart), jr#@andrew.cmu.edu (Jonathan Rosenberg), nsb#@andrew.cmu.edu (Nathaniel Borenstein) We have a problem; I suspect that others share it. Maybe somebody has found a solution. Here's the problem. If somebody knows that I'm reachable via mail to the domain name andrew.cmu.edu, they could address their mail to ``everhart@andrew.cmu.edu'' or ``craig.everhart@andrew.cmu.edu'' or ``c.f.everhart@andrew.cmu.edu'' and it will get to me just fine, assuming that the name they give isn't ambiguous. (If it's ambiguous, they'll be told.) But we'd like outgoing mail to be stamped in the From: field with an address that will never be ambiguous. In the old days we just used a Unix username for that: mine is ``cfe'', and my mail had a line like From: cfe@andrew.cmu.edu (Craig F. Everhart) So, because we stamp our mail this way, we have to interpret the localparts of mail addresses (here ``cfe'') first as Unix usernames, and if that fails we can try to match it as a surname or whatever. Well, lots of our usernames are things like rt8p or zt55, so you'd never confuse them with a surname or given name. But lots of them (the older ones) are ``brian'' and ``bob'' and ``bond'' and ``crane'' and like that. Suppose Joe Crane's userid is ``crane'' and Sam Crane's is ``sc09''. Somebody tries to send mail to their buddy Sam Crane; they guess that ``crane@andrew.cmu.edu'' will either get to Sam or will be rejected as ambiguous. Well, wrong: we have to consider it an unambiguous specification for Joe Crane. Why? Because mail from Joe Crane has a From: address of ``crane@andrew.cmu.edu'', and replies to that address need to go to Joe without complaint. So what we'd really like is a way to distinguish, lexically, localparts of mail addresses that are Unix usernames from those that are name probes. What we invented was what we call the hash-mark convention: localparts suffixed with a hash-mark (e.g. ``cfe#@andrew.cmu.edu'') would be considered to be a Unix username only, and localparts not suffixed that way would be considered to be name probes. Thus, mail to ``crane@andrew.cmu.edu'' gets rejected as ambiguous; mail from Joe Crane has a From: address of ``crane#@andrew.cmu.edu''; replies to that address (with the hash-mark) are delivered to Joe Crane, username ``crane'', without complaint. We thought that this convention would be the answer. We picked the hash-mark because it needs no quoting to appear in a legal RFC822 address and because we thought that it had no conflicting conventional use. It's close, but once we deployed it we found problems with other sites. In particular, VM hosts (much of Bitnet) cannot deal with this character in addresses; it is conventionally interpreted by low-level VM software as a line-separator or line-terminator character. A widespread user mail agent mis-composes replies if addresses contain that character; users find it difficult to enter that character by hand as part of a canonical mail address. In addition, the hash mark is in ASCII, but it isn't in most international alphabets; people might have a hard time composing properly-addressed mail to us. There are two possibilities that seem open. One is to change our users' Unix usernames so that they're lexically distinct from given names or surnames--for example, so they all begin with letter-letter-digit. This is a major step. The other possibility is to find another way to tag localparts as usernames and not, e.g., surnames. We like the suffix-character solution; we've already grown a system that interprets the localpart A#B as submailbox B of Unix username A's mail. (So, for instance, I would receive mail addressed to cfe#photo and I could put such mail into a separate mail class.) The problem is that lots of the characters already mean something. I did a little research. Given each character, suppose that we started using that character as our special tag: Some characters are widely used for other purposes, so people composing mail addresses might accidentally misuse them: dot (Brian.Reid), underscore (Jakob_Palme), hyphen (John Smith-Corona), percent (foobaz%mit-oz@mit-mc). Some characters are conventionally used by some mailers (well, UUCP, and some UCB Sendmail config files) to indicate an alternate host/user coupling: exclamation (foo!bar!baz!mumble@Berkeley), colon and circumflex and maybe slash and equals (Berknet (?)). Some characters have special interpretations in other computing domains: hash-mark (IBM VM makes it hard to use), slash, equals, hash, underscore (RFC987 suggests another interpretation for them for use on the other side of a gateway to X.400), dollar sign (a disastrous part of an address for standard Berkeley 4.2 Sendmail). International standard alphabets don't include lots of characters: dollar sign, tilde, hash-mark, left and right curly brace, vertical bar (all variable within ISO 646), exclamation, hash-mark, dollar sign, percent, ampersand, asterisk, circumflex, underscore, open quote (not part of basic IA5). This summary leaves us with only the two characters plus sign and question mark. It might be funny for a while if my unambiguous address were ``cfe?@andrew.cmu.edu'', but really!. What I'd like to ask, though, is if my unambiguous address were ``cfe+@andrew.cmu.edu'', what mailers would fall over? What problems might there be? We might have used something like ``Craig.F..Everhart@andrew.cmu.edu'' as our unambiguous mail address, but our system is growing to be very large (3400+ users today, 10000 in a couple of years). Thus, name conflicts are inevitable, even if we try to include people's middle names in their unambiguous addresses. Even in a small domain it's possible to make one user ``smith'' and another one ``rsmith'', but how does the person outside the system, guessing what Rob Smith's mail address is, get the mail to the right person with the greatest probability? Do we have choices other than renaming hundreds of our users' Unix usernames to be lexically distinct, switching to using a plus rather than a hash mark (and running into new and different bugs on widely-scattered mail systems), or inventing some new unambiguous, uncontroversial annotation on Unix usernames so that they can be used and recognized as localparts without hassle? (Any such invention should provide for submailbox notation also, so that the trick is to embed both a Unix userid and an arbitrary submailbox name.) Yes, with 10,000 users, we'll need to provide some mechanism for un-flattening the name space (like offering some way to specify ``the Dr. Smith on the History faculty''@andrew.cmu.edu), but we'll always need to have an unambiguous mail address, regardless of how many Smiths join the History faculty. I apologize for the length of this message. I hope, however, that somebody can offer a solution or advice. Many thanks, Craig Everhart Andrew message group  Received: from BRL-SEM.ARPA (TCP 30001213410) by MC.LCS.MIT.EDU 7 Jan 87 19:37:31 EST Date: Wed, 7 Jan 87 19:31:43 EST From: Doug Kingston To: "Craig F. Everhart" cc: Arpa-MHS@BRL.ARPA, Header-People@mc.lcs.mit.EDU, "Craig F. Everhart" , Jonathan Rosenberg , Nathaniel Borenstein Subject: Re: Unambiguous local addresses Message-ID: <8701071931.aa10738@SEM.BRL.ARPA> The MMDF2 Mail System has been using the equals sign "=" for encoding delivery information in the local part for some time. We have not run into any problems. The notation we use yeilds address such as "dpk=infoterms@vgr.brl.mil". I would avoid "?" at all costs. -Doug-  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Jan 87 11:27:06 EST Received: from ub.com by csnet-relay.csnet id ab02183; 8 Jan 87 11:23 EST Date: Thu, 8 Jan 87 7:50:32 PST From: Dave Crocker To: "Craig F. Everhart" cc: Arpa-MHS@BRL.ARPA, Header-People@MC.LCS.MIT.EDU, "Craig F. Everhart" , Jonathan Rosenberg , Nathaniel Borenstein Subject: Re: Unambiguous local addresses Organization: Ungermann-Bass, Inc. Craig, This is a brief commentary on some choices we made for MCI Mail. Anyone thoroughly familiar with addressing in same may wish to read their next message... "login" vs. "full" names are both allowed for referencing. There is no syntactic distinction made. I do not recall ever hearing of a user problem with this, but there was a major operational difference between MCI Mail, at that time, and your own environment: We were entirely interactive with the data base and the user received a feedback line that specified the addressee's full name, organization, and location. If the reference is ambiguous, the user receives this information about all of the possible choices. With the advent of back-end, protocol-based submission, MCI may be having some of the problem you describe. In general, the philosophy was to give users a way to specify a unique addres, if they insisted, but allow them to hit an unintended recipient, if they were not careful. Login name and Full name were given equal precedence. So, if there are two users with a last name of Crane and a third with a login of Crane, then reference to "crane" is ambiguous. What we did, to provide a guaranteed-unique reference, was to have yet-another reference string for the user, called their MCI ID. (Mine is 1060171. So, you can send to dcrocker, Dave Crocker, Crocker, 1060171 -- only the last of which is guaranteed always to refer to me and only me.) To facilitate resolution, when the id is unknown and the name may be ambiguous, reference to the recipient's organization and/or location also is permitted. E.g., "crocker" may be ambiguous, but "crocker/ungermann/clara" is not. (org and loc may be substrings of Ungermann-Bass and Santa Clara.) Well, it is, now, but my wife used to work there, so ... It is worth noting that the Directory Services work that is going on in the international standards community permits roughly this sort of reference. I guess my suggestion is that you should administratively enforce Unix logins that are cryptic, unique ids and let the Full-Name database handle the "friendly" references. Dave  Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 8 Jan 87 11:59:18 EST Received: from ucl-cs-vax2 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa04498; 8 Jan 87 16:56 WET To: "Craig F. Everhart" cc: Arpa-MHS@brl.arpa, Header-People@mc.lcs.mit.edu, Jonathan Rosenberg , Nathaniel Borenstein , mhs@Cs.Ucl.AC.UK Subject: Re: Unambiguous local addresses Phone: +44-1-380-7294 In-reply-to: Your message of Wed, 07 Jan 87 17:41:37 -0500. Date: Thu, 08 Jan 87 16:45:54 +0000 Message-ID: <4137.537122754@UK.AC.UCL.CS> From: Steve Kille This is a difficult problem, and shared by very many sites (although I suspect that quite a few do not realise it yet). These are my thoughts on how UCL will tackle them. The first thing is to separate the mail id and user id name spaces. These really have different characteristics. The latter usually need only be known by a relatively small number of people, and so can be shorter (and more cryptic). The mapping should be done at message creation/deliver times. As a side effect, this also improves security, as you do not distribute a list of login ids every time you send a message. This does give an extra binding to maintain, but is not that big a deal if you are already managing your namespaces sensibly. We regard the phrase (X.400 free form name) as something the user should specify, and should not be regulated. This work is concerned with what is inside the angle brackets. The form of the local-part (for human users) should be aligned with human usage, and the structure made clear. We will use "." as the preferred separator (e.g. S.Kille). Besides feeling right (at least to me), this structuring will also facilitate usage of X.400. For recipients, matching will be as flexible as possible. The key question is "what to put in the From: line". This must be unique. We will default to Single Initial "." Surname. If this is not unique, more initials will be added, and then expanded. (e.g. S.Kille -> S.E.Kille -> Steve.E.Kille...). The user may chose to use the default, or any other unique variant (e.g. Kille (if I am the only one) or Steve.Kille but not Steve (even if it is unique)). We have decided not to guarantee permanent uniqueness. Thus if Steve.F.Kille gets a job at UCL, S.Kille will become ambiguous (and thus erroneous). Then, my From: line would have to change, and anyone sending messages would need to determine the new value. For "important" people, aliases might be used to override ambiguities (e.g. a student with the same name as a professor). People with exactly the same name will not be given accounts! We regard the "user friendliness" of this approach as overweighing the (rather painful) problems when clashes occur. It is clearly important to make sure that clashes are very rare. This means that the larger the namespace, the more of the name must be used. The suggested UCL CS dept. policy is on the basis of 500-1000 names (we currently have two P.M.Smiths, but they do have different christian names. There are a very small number of clashes with single initial + surname). I would be expecting to find clashes occuring once or twice a year. With andrew.cmu.edu, you appear to be talking about rather more (10 000) users withing the songle domain. If this made the number of clashes too high, you would need to do something to reduce them,. This would imply either having more of the name as default, or breaking the name another level to the domain (e.g. Department in the University). This would be adding an Organisational Unit level in X.400. Steve  Received: from USC-ECLB.ARPA (TCP 3201600101) by MC.LCS.MIT.EDU 8 Jan 87 13:48:27 EST Date: Thu 8 Jan 87 10:47:16-PST From: Bob Larson Subject: Re: Unambiguous local addresses To: steve@CS.UCL.AC.UK cc: header-people@MC.LCS.MIT.EDU, jr#@ANDREW.CMU.EDU, nsb#@ANDREW.CMU.EDU In-Reply-To: <4137.537122754@UK.AC.UCL.CS> Message-ID: <12269330845.37.BLARSON@USC-ECLB.ARPA> People with exactly the same name will not be given accounts?!! A new form of discrimination, I'd like to see you defense when a lawsuit comes up. (It's not discrimination your honor, he can get an account just as soon as he changes his name.) BTW, I did attend the same university at the same time as someone else with exactly the same name. Using addresses that may suddenly become ambiguous as the from addresses is not a good idea, not only because of unreliable replying to your messages. Mailing list maintainers would curse you for it. -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Jan 87 14:53:10 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 8 Jan 87 14:55:41 EST Received: from YKTVMX(VICTOR) by MITVMA (Mailer X1.23) id 9239; Thu, 08 Jan 87 12:46:24 EST Date: 8 Jan 1987 12:43:39-EST (Thursday) From: "Victor S. Miller" To: Craig.F.Everhart@andrew.cmu.edu Cc: header-people@ai.ai.mit.edu Subject: Unique addresses Why not just translate the Unix userid foo into the address foo.unix@andrew.cmu.edu? This would work fine, as long as no one with the last name of `unix' comes along. Victor  Received: from hplabs.HP.COM (TCP 30001235012) by MC.LCS.MIT.EDU 8 Jan 87 19:32:22 EST Received: from hplms1 by hplabs.HP.COM ; Thu, 8 Jan 87 13:40:23 pst Received: from hpldat (hpldat) by hplms1; Thu, 8 Jan 87 13:39:43 pst Return-Path: Received: by hpldat ; Thu, 8 Jan 87 13:40:29 pst From: Dave Taylor Message-Id: <8701082140.AA21067@hpldat> To: @MC.LCS.MIT.EDU@hplabs.HP.COM, %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart), Arpa-MHS@brl.ARPA%MC.LCS.MIT.EDU, %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart), Header-People@mc.lcs.mit.edu%MC.LCS.MIT.EDU, %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart), cfe#@andrew.cmu.edu%MC.LCS.MIT.EDU, %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart), jr#@andrew.cmu.edu%MC.LCS.MIT.EDU, %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart), nsb#@andrew.cmu.edu%MC.LCS.MIT.EDU, %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart) Date: Thu, 8 Jan 87 13:40:25 PST Subject: Re: Unambiguous local addresses In-Reply-To: Message from "Craig F. Everhart" of Jan 7, 87 at 5:41 pm Organization: Hewlett-Packard Laboratories, Unix Networking Group Work-Phone-Number: +1 415 857-6887 X-Mailer: Elm [version 1.5] An interesting problem you bring up, Craig. Oddly, though, no-one has seemed to realize that you're talking about not "how do we use login names as return addresses" but rather "must we use them, and if so, how". I suggest that we consider first whether we need to use login names at all as return addresses.... On a campus network of any reasonable size, indeed ANY network of a reasonable size, there are bound to be name collisions, and there will have to be resolutions arrived at, perhaps as used in MCI mail with the location name, or company name, or some other extended level of information. The key point, though, is that the name resolver is going to be *on-line* during this whole bit, so when a user is given an account initially, the administration group can then assign them a unique identification *based on their name*. This would then go into, say, a file on each host, in the form; userid unique-user-identification-name so that as mail is sent off the machine the program jumps into this file and extracts a *guaranteed unique* name for the person. As new users are added to the system, the administration group would see the name conflicts as they arise and resolve them at that point. It is expected that every so often the entire name space will need to be expanded, by, for example, adding a department name to each persons unique address. It also goes without saying that this will be accessable by the name resolver, and that there will need to be a single master file somewhere. (we want parts of it on different hosts, however, so that users can have accounts on different machines, but a single email address). To show by example, let's consider when I went to school and how there was this annoying chap David Gurnsey Taylor III, who shared my first and last name... Let's say that I have the account ee160-ba and DGT has ee160-ab (for maximal confusion)...then the files could be something like; ee160-ba Dave.A.Taylor ee160-ab David.G.Taylor (we will need to learn to not distinguish between commonly used nicknames, like Dave and David, as an aside). But let's actually expand this a bit...and add the department that the person is majoring in: ee160-ba Dave.A.Taylor.EECS ee160-ab David.G.Taylor.Humanities Now we can see that we can in fact remove the middle initial altogether and still have a unique address... So, finally, when I would send mail out, while I might be logged in as ee160-ba@sdccs6 or something, the return address would be something more like; From: Dave.Taylor.EECS@UCSD.EDU (Dave Taylor) (the field in Parens, or in clear, if <> is used, should be user defineable too). No problem! Any comments? Further ideas?? -- Dave Taylor uniquely addressable as taylor@hplabs  Received: from SRI-IU.ARPA (TCP 1201200002) by MC.LCS.MIT.EDU 9 Jan 87 02:07:01 EST Date: Thu 8 Jan 87 23:05:15-PST From: Peter Karp Subject: Re: Unambiguous local addresses To: cfe#@ANDREW.CMU.EDU Cc: Arpa-MHS@BRL.ARPA, Header-People@MC.LCS.MIT.EDU, jr#@ANDREW.CMU.EDU, nsb#@ANDREW.CMU.EDU Message-ID: In-Reply-To: Message from "cfe#@andrew.cmu.edu (Craig F. Everhart)" of Wed, 7 Jan 87 17:41:37 est Craig, I will suggest that the problem is even worse than your describe. Here are two other forms that it takes: First is doing header re-writing to make messages from foreign mailers RFC822-compatible. For example, if I'm relaying a message from a DECnet to the Arpanet, the return path will include the token "::", which is illegal under RFC822. One option is to double-quote the entire address. Another option is to re-write these characters into something legal. Ultrix Sendmail uses "..", which happens to be illegal under RFC822 (bozos). It could be wise to use some legal characters. Second, naming other types of local mailboxes. This is more closely related to the problem you describe. For example, if on Tops-20 I want to mail directly to a file (e.g., a user's mailbox or a bboard file), I use the address: *filename , e.g., *PS:FOO.TXT . Under Unix, if I want a piece of mail to be piped down the standard input of some program, I use: |program , e.g., |/usr/local/bin/foo . I have adopted similar conventions for a VMS mail system I've written, but these are ugly hacks. It would seem that we want to specify two things in a local mail name: a type and an identifier within that type, for example: type=username, id=crane type=MM-file, id=FOO.TXT type=text-file, id=BAR.TXT type=personal-name, id=Peter.Karp type=program, id=/usr/local/bin/foo type=mail-id, id=pk001 Well, use your imagination to invent a syntax for the above. Incidentally, I believe the character '&' is also legal under RFC822. I don't know if it will break other mailers. peter -------  Received: from nrtc-gremlin.arpa (TCP 20030600021) by MC.LCS.MIT.EDU 9 Jan 87 04:06:05 EST Received: from nrtc-gremlin by nrtc-gremlin.arpa id a000532; 9 Jan 87 1:04 PST To: Peter Karp cc: cfe#@andrew.cmu.EDU, Arpa-MHS@brl.ARPA, Header-People@mc.lcs.mit.EDU, jr#@andrew.cmu.EDU, nsb#@andrew.cmu.EDU Subject: Re: Unambiguous local addresses In-reply-to: Your message of Thu, 08 Jan 87 23:05:15 -0800. Date: Fri, 09 Jan 87 01:03:55 -0800 Message-ID: <524.537181435@nrtc-gremlin.arpa> From: Einar Stefferud Having done some work on Gateways, one thing is very clear to me --- When a message goes from DECNET to INTERNET, it should lose all its DECNET attributes as it passes into INTERNET. As it leaves the gateway, all addresses, including the RETURN-PATH must be exactly RFC822, and nothing else. If this is not true, then nothing is standard and anything in RETURN-Path must be execptable from anyone anywhere at any time. Therefore, it is my judgement that your referenced DECNET/INTERNET gateway is defective is at least one very significant way. It shoudl be fixed at the Gateway site, and we should all guard very zealously agfainst letting that gateway's bad behave trigger netwide compensations for its erroroneous ways. This is just an INTERNET form of the old problem of tryin g to keep local problem from becoming global network problems. OK? -- Stef  Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 9 Jan 87 04:44:43 EST Received: from ucl-cs-vax2 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa01719; 9 Jan 87 9:39 WET To: Bob Larson cc: header-people@mc.lcs.mit.edu, jr#@andrew.cmu.edu, nsb#@andrew.cmu.edu Subject: Re: Unambiguous local addresses Phone: +44-1-380-7294 In-reply-to: Your message of Thu, 08 Jan 87 10:47:16 -0800. <12269330845.37.BLARSON@USC-ECLB.ARPA> Date: Fri, 09 Jan 87 09:35:04 +0000 Message-ID: <971.537183304@UK.AC.UCL.CS> From: Steve Kille From: Bob Larson Subject: Re: Unambiguous local addresses Date: Thu 8 Jan 87 10:47:16-PST People with exactly the same name will not be given accounts?!! A new form of discrimination, I'd like to see you defense.... This was said slightly toungue in cheek. In the short term, we will genuinely do this (there are paper world precedents). If we get that pathological clash, one or both will need to register with a different name. In the medium term, directory services and a more flexible name structuring (see Dave Crocker's message) will enable a more natural disambiguation in these cases (e.g. by locale or department or work area). Using addresses that may suddenly become ambiguous as the from addresses is not a good idea, not only because of unreliable replying to your messages. Mailing list maintainers would curse you for it. Mailing addresses change quite a lot, and people leave, and...... Mailing list maintainers have too many instabilities already (I do maintain more than one list). I would cerainly suggest use of "more stable" variants on lists (e.g. the list might contain Andrew.Eustace.Jones, even if the From: was A.Jones). However, I clearly agree that a "preferred" (i.e. From:) name becoming ambiguous would be a substantial pain. One thing we would do (not stated last time) is to "transition" in all such cases, so that there would be some use of the new From: field before the old one did not default correctly. This would help with replies. This is only acceptable if it is a pretty rare occurence. Howeever, I believe that removal of "unnatural" ids is worth a SMALL number of clashes. Steve  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Jan 87 05:25:46 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 9 Jan 87 05:28:25 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2714637835076478@MIT-MULTICS.ARPA>; 09 Jan 1987 05:03:55 est Message-ID: <225907@QZCOM> In-Reply-To: Date: 08 Jan 87 09:53 +0100 From: Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, HEADER-PEOPLE@AI.AI.MIT.EDU Subject: question on ReSent-To A quiet reflection: comparing with X.400, the ReSent-xxx fields would roughly correspond to the X.400.P1.Envelope.TraceInformation, i.e. they do not really belong to the message header, rather the envelope, 821.  Received: from Xerox.COM (TCP 1200400040) by MC.LCS.MIT.EDU 11 Jan 87 20:15:43 EST Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 87 16:58:41 PST Date: Sun, 11 Jan 87 16:58:26 PST From: Murray.pa@Xerox.COM Subject: Re: Unambiguous local addresses In-reply-to: In-reply-to: To: cfe#@andrew.cmu.edu (Craig F. Everhart), Peter Karp Cc: Arpa-MHS@BRL.ARPA, Header-People@MC.LCS.MIT.EDU, jr#@ANDREW.CMU.EDU, nsb#@ANDREW.CMU.EDU, Murray.pa@Xerox.COM Message-ID: <870111-165841-4156@Xerox> Craig: If I was working on your problem, I would: 1) Assign everybody a long name - something that would be almost unique. (More later.) 2) Disconnect your automatic attempt to try unix usernames. 3) Gain back the functionality lost in step 2 by adding a manually controlled alias table. 4) Modify your mail sending software to automatically translate short usernames and/or aliases into long/unique names, especially on mail that goes off campus. I said "almost" unique because I don't know how to totally solve that problem. As the user community grows, clashes are bound to happen. My guess is that names like "Craig F. Everhart" will be good enough for a user community of 5000 to 10000 people. I'd expect a few soft-clashes each year. I'd expect to be able to dodge around most of them one way or the other, for example by using just a middle initial rather than spelling out the whole middle name. I'm called Hal, but my formal/legal name is Hallam. I have a friend named Craig, but he is really Robert. His father had prior claim to Robert so he got Craig to solve the same problem in a different context. ... As the system grows, you will probably want to distribute the responsibility for assigning names. Spliting on something like a department level seems like a reasonable way to do that as well as reducing clashes. Somebody is bound to point out that long names are hard to type (and ugly and...). True, but it's not as bad as you might think. You don't type in names as often as you send mail. Most of the time, you use the Answer, Reply, or whatever-your-system-calls-it command. On top of that, many initial messages are sent through distribution lists. (It helps a lot if the software used to maintain distribution lists automatically fixes up aliases. Think of it as abbreviation expansion.) I might be a bit far out on this one, but many systems now have a mouse. I can select and copy a long name just as easily as a short one. Finally, you can use aliases, so you don't have to type in the whole long name as long as you know a short name and are willing to recover if/when the alias goes away. I feel that the stability of long names is necessary for tomorrow. An alias table can bridge the gap during the transition. A bit of software could probably make maintaining the alias table a lot easier and/or warn you when an expected/automatic alias turns into a clash. If you try to reduce the probility of name clashes, for example, by suffixing the department name, you get into a different sort of trouble. Parts of organizations occasionally get shuffeled and hence formal department names get changed. History departments probably don't change their name very often, but EE/CS departments are less stable. This also happens within companies, Xerox being a wonderful example. In the case that comes to mind, they just kept using the old names. New people ask questions, but it works. Our corporate telecommunications people suggested a neat trick. Make the users long/unique name correspond to the one listed in the company phone book. There probably has to be some simple algorithim, like delete puncutation and compress duplicate blanks. (And for the arpa world, change blanks to periods.) This would help a lot for internal mail, but doesn't do any good for outsiders. Every little bit helps though, and internal mail is a major portion of the problem. With a bit of work, you could probably get the phone book online. ----- From Peter Karp: "For example, if I'm relaying a message from a DECnet to the Arpanet, the return path will include the token "::", which is illegal under RFC822. One option is to double-quote the entire address." If your goal is to simply and conviently exchange mail with as many sites as you can, I strongly suggest that you avoid double quotes. Some of our user names contain spaces. I tried quoting them. It doesn't work very well. Postel told me I was asking for trouble. At the time, I didn't understand what he was saying. After all, the specs were pretty clear to me. Well, there are an amazing number of systems out there that just can't correctly process quoted strings. When we first started generating names with double quotes, we encountered a somewhat expected flurry of confusion. I knew many of the people who maintained the mail systems on nearby machines so we sorted out the first layer of quirks right away. The next layer took a bit longer to solve, but most of the major mail sites have pretty sharp people taking care of them. Then I started getting replies like "Sorry, we don't have sources" or "Huh, we are still using 2.8 and we don't have a system programer". After a while, I figured out what Postel had already told me. We've had pretty good luck after we translated spaces to/from underbars. This was several years ago. Things have probably gotten better around the internet, but then, more systems are joining the metanet so I won't bet that the change is actually in the right direction.  Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 12 Jan 87 09:16:08 EST Received: from ucl-cs-vax2 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa03306; 12 Jan 87 14:06 WET To: cfe#@andrew.cmu.edu, Header-People@mc.lcs.mit.edu Subject: Re: Unambiguous local addresses Date: Mon, 12 Jan 87 13:59:45 +0000 From: george@Cs.Ucl.AC.UK 10000 users is of the same order of magnitude as the community of UNIX e-mailers within the UK as a whole, at least those who know about and can use e-mail to the internet. This size of community is too big for one person to administrate. Assign username & friendly mailboxes for *ALL* academics in the UK from rutherford laboratories? -nochance! Trying to strike a balance between unambiguous names and ease of use is going to prove very difficult in practice. Trying to maintain a single logical address-space of this size must be a nightmare *anyhow* so to my mind partitioning of the "namespace" is of dual benefit: (1) smaller namespaces allow for shorter unique names (2) partitioned management reduces the load per manager Why not use local "dummy" hosts as logical sub-domains to divide people/mailboxes up amongst the community? (1) logical domains do *not* have to map into any "physical" domain. (2) method uses existing special characters, addressing format, so no problem with rest-of-world user training. -suggestions for assigning new chars in names/new formats have to address this problem. (3) routing/aliasing is (at least) a known problem, if not a solved problem. -since most mail manages to (finally) route through the internet we can assume a considerable body of knowledge exists to cope with problems encountered here... I suggest departments/faculties as a model of sub-domains, one global administrator to assign domain-names to each, then each department using the computer system to nominate a name-manager who assigns terminal mailbox names within that sub-domain. User.Friendly%Computer-Science@bighostname John.Smith%Physics@bighost John.Smith%Astro-physics@bighost John.Smith%Inst-Aardvark-Studies@bighost ...Catch-all is no-domain (ie just true host) for root, uucp etc etc Lots of scope for providing special-case system-wide aliases to route mail to heavy users sent stuff as person@bighost, also for inquiry systems / intelligent replies for mail sent to site without sub-domain. Can be implemented through special local-channel, final mailbox names are any system-wide unique string, assigned from any dumb(ish) program. model: take any local area network and imagine set of separate physical machines are logical sub-domains of the virtual machine... This model suggests to my mind that problems to be encountered are exactly the same as those encountered by a large community accessing a large pool of machines: dupication of mail, addressing, authorisation. Even if it provides problems of its own, they are likely to belong to a known set, rather than being fresh ones we don't know about yet. Can even re-write login to ask for logical sub-domain before username & have partitioned /etc/passwd.... George Michaelson, University College London PS X-400 probably *won't* solve all these problems (sigh)...  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 13 Jan 87 04:17:06 EST Received: from ub.com by csnet-relay.csnet id ag10891; 13 Jan 87 4:07 EST Date: Sun, 11 Jan 87 12:50:30 PST From: Dave Crocker To: Dave Crocker cc: "Craig F. Everhart" , Arpa-MHS@BRL.ARPA, Header-People@MC.LCS.MIT.EDU, "Craig F. Everhart" , Jonathan Rosenberg , Nathaniel Borenstein Subject: Re: Unambiguous local addresses Organization: Ungermann-Bass, Inc. There is a very small, very important point that I forgot to include, in my description of MCI Mail addressing. Some notes that followed suggest that I should have been explicit: Mail that is sent from someone must have a unique identifier for that person. At the very least, it must be possible for a recipient's auto-reply software to generate a return address that will work. This is the kind of reason that drove us to define MCI ID numbers. They are not user-frienldy, but they are guarateed unique. Even after their owner goes away, re-use of a number is not supposed to happen (well, not within our lifetime...). There was not attempt to make logins unique for MCI Mail, for a marketing reason; a smaller/different operation may want to merge unique id with login. (The marketing reason was that we wanted users to be able to choose their own login name.) Hence, login name is just-another-name, like "Formal Name" and the same rules for disambiguation apply. Dave  Received: from vax.darpa.mil (TCP 30001211143) by MC.LCS.MIT.EDU 13 Jan 87 05:23:38 EST Received: by vax.darpa.mil (4.12/4.7) id AA20742; Tue, 13 Jan 87 05:21:30 est Date: Tue 13 Jan 87 05:21:22-EST From: Dennis G. Perry Subject: Re: Re: Unambiguous local addresses To: dcrocker@engr.ub.com Cc: dcrocker@engr.ub.com, cfe#@ANDREW.CMU.EDU, Arpa-MHS@BRL.ARPA, Header-People@MC.LCS.MIT.EDU, jr#@ANDREW.CMU.EDU, nsb#@ANDREW.CMU.EDU, perry@VAX.DARPA.MIL Message-Id: In-Reply-To: Message from "Dave Crocker " of Sun, 11 Jan 87 12:50:30 PST Los Alamos also has 'unique' id numbers, it is also you badge number. How many site have to move to unique id numbers before some sites choose the same numbering mechanism and start with the same seed. Perhaps the spector of end times is upon us, where the unique id willl be written upon our forehead! dennis -------  Received: from BRL-SEM.ARPA (TCP 30001213410) by MC.LCS.MIT.EDU 13 Jan 87 20:02:12 EST Date: Tue, 13 Jan 87 19:43:05 EST From: Ron Natalie To: "Dennis G. Perry" cc: dcrocker@engr.ub.COM, dcrocker@engr.ub.COM, cfe#@andrew.cmu.EDU, Arpa-MHS@BRL.ARPA, Header-People@mc.lcs.mit.EDU, jr#@andrew.cmu.EDU, nsb#@andrew.cmu.EDU, perry@vax.darpa.MIL Subject: Re: Re: Unambiguous local addresses Message-ID: <8701131943.aa08017@SEM.BRL.ARPA> Several of us proposed at Martin Marietta to have the phone switch modified so that using your badge number as your extension number would always get you to the right place. -Ron  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 18 Jan 87 19:30:21 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2715466860193766@MIT-MULTICS.ARPA>; 18 Jan 1987 19:21:00 est Message-ID: <228235@QZCOM> In-Reply-To: Date: 18 Jan 87 19:18 +0100 From: Matts_Kallioniemi%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: Matts_Kallioniemi%QZCOM.MAILNET@MIT-MULTICS.ARPA, Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, arpa.mhs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA, "X.400/ARPA Conversion" , header-people@MC.LCS.MIT.EDU, arpa.mhs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: "Jonathan Rosenberg" , "Nathaniel Borenstein" , "Craig F. Everhart" , John_O'Connor_UCD@EUROKOM.UUCP Subject: Unambiguous local addresses Craig, Would it be a bad idea to consider your personal mailbox as a subdomain? I.e. and in the from: something like or perhaps prettier Matts Kallioniemi, Systems Programmer, KOMunity Software