Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 09:53:19 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05463; 13 Jul 89 9:49 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 13 Jul 89 08:19:02 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Jul 89 08:47:10 GMT From: bionet!%%%lear%%%%NET.BIO.NET@csd4.milw.wisc.edu Subject: Re: Assumptions & Rules for Transiting UUCP/SMTP Messages. Message-Id: References: <1368@fernwood.MPK.CA.US> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [In reply to Geoff Goodfellow's message, <1368@fernwood.MPK.CA.US>] This is not really a criticism on your suggestions for gateways, but more a point on interprotocol routing, in general. It is up to a gateway to decide how it will handle a protocol conversion. That site must perform some manipulation on the header (as specified by what protocol exists at the far end). So long as the message is delivered, the gateway's responsibility is discharged. It would also be nice, if at all possible, if the gateway presents a replyable message. For example, BITNET was in past well known for its limitations on usernames and hostnames. DECNET is even worse. -- Eliot Lear [lear@net.bio.net]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 12:46:46 EDT Received: from rice.edu by mintaka.lcs.mit.edu id aa07806; 13 Jul 89 12:42 EDT Received: from icsa.rice.edu by rice.edu (AA02509); Thu, 13 Jul 89 11:42:04 CDT Message-Id: <8907131642.AA02509@rice.edu> Received: from ICSA.RICE.EDU by icsa.rice.edu (IBM VM SMTP R1.2.1) with BSMTP id 4530; Thu, 13 Jul 89 11:41:46 CDT Received: by RICE (Mailer R2.04) id 0419; Thu, 13 Jul 89 11:41:30 CDT Date: Thu, 13 Jul 89 11:30:33 CDT From: "Mark R. Williamson" Subject: Resent- as a general prefix? To: Header People Can the description in RFC822 of the general philosophy of the prefix "Resent-" be taken to imply that any valid header field may have "Resent-" prefixed (e.g., Resent-Subject), or is the set of valid Resent-... fields defined by those which appear explicitly in the syntax rules? Opinions? Definitive statements? Mark R. Williamson, Rice University, Houston, TX; MARK@ICSA.RICE.EDU  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 16:47:18 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa15107; 13 Jul 89 16:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 13 Jul 89 15:47:30 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Jul 89 19:41:29 GMT From: Karl Kleinpaste Organization: Ohio State Computer Science Subject: Re: Assumptions & Rules for Transiting UUCP/SMTP Messages. Message-Id: References: <1368@fernwood.MPK.CA.US> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I note editorially at the outset of this response that I am not a General Rabid Rerouter, but merely a Domain Absolutist Rabid Rerouter, that is, I short-circuit to rightmost domain, but otherwise leave !-paths alone. The difference is significant. There are several of these rules with which I quibble, and it is not at all clear to me that the set of assumptions is complete. geoff@Fernwood.mpk.ca.us writes: > Assumptions: > [non-uniqueness of UUCP names; DNS names are unique; UUCP > envelopes are hacked via prepending of pass-through hosts.] How about "UUCP hosts cannot be counted on to respect RFC-compliant `operator precedence' in mixed-mode addresses"? E.g., some UUCP hosts will take a!b@c.d as a!(b@c.d) [broken] and others will take it as (a!b)@c.d [correct]. > Header Treatment Rules: > 1. Headers are treated the same regardless of transport. No. Example: Origin address given me by someone.else.edu: SomeUucpHost!username@out.there.gov If I hand it to someone via SMTP, especially DEC-20's w/MAISER: I leave it alone. If I hand it to a UUCP neighbor: out.there.gov!SomeUucpHost!username Reasoning: UUCP hosts should not be given mixed-mode addresses, due to my extra assumption above. I must do the work for them, to ensure sanity. This also happens to work around an old bug in smail 2.5 which I have never taken the time to trace down. > 2. Headers should not be touched as messages transit systems UNLESS > the message is transiting from the UUCP(!) to the SMTP(@) environment. No. See above, on SMTP->UUCP. > 3. While transiting a message from the UUCP(!) to the SMTP(@) environment, > 3a. IF the header contains an (@) style address with a rfqdm address on the > right of it THEN do not touch it; OK. > 3b. IF the header contains an (@) style address with a non-rfqdm address on > the right of it THEN do some type of %ification to the non-rfqdm > address and append the rfqdm (@) address of the transited system; Absolutely not. RFC 822, section 6.2.2, page 29: When a message crosses a domain boundary, all addresses must be specified in the full format, ending with the top-level name-domain in the right-most field. It is the responsibility of mail forwarding services to ensure that addresses conform with this requirement. There are several implications of this. First, if a header arrives with the address username@OneWordHostName (lacking, notably, any dotted domain qualifiers), I _cannot_ guarantee the intended interpretation of the OneWordHostName. The mailer which handed me that address has failed the 2nd quoted sentence from 6.2.2. I cannot say if OneWordHostName was supposed to have been known within the context of the mailer which handed me the mail, or some other entity farther behind itself (if the one which handed it to me was merely the Nth-stage intermediate transfer point). Second, as a result of the first, given that I have no means by which to interpret OneWordHostName reliably, I aggressively rewrite it _in_ _my_own_context_, cis.ohio-state.edu. Since I hide hostnames, I therefore rewrite this as username@cis.ohio-state.edu. I will _not_ %ify the header. I flatly refuse. I %ify the _envelope_ in order to reach, e.g., .bitnet. Under duress. Nowhere else. > 3c. IF the header does not contain an (@) style address THEN replace > the header "From:" address with envelope "From " address and > append the rfqdm (@) address of the transited system. I don't think so. In my configuration, anything lacking _both_ ! and @ is considered not to be punctuated at all; that is, it looks like a local username, and I add @cis.ohio-state.edu in accordance with 6.2.2. > There is no attempt to fix or clean-up bad/invalid headers or short-circuit > routing. garbage in ==> garbage out (with the exception for rule 3c's > handeling of "From:" when transiting a message from !-land into @-land). You ignore the Property of Non-Reversability of UUCP Paths, at your peril. I don't perform DARR[*] for nothing; it's a solution (which has worked without exception up to this point, mind you) to this particular Property. --Karl [*] DARR: Domain Absolutist Rabid Rerouting.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:44:40 EDT Received: from VAX.FTP.COM by mintaka.lcs.mit.edu id aa00403; 14 Jul 89 14:45 EDT Received: from stev.feather.ftp.com by vax.ftp.com via PCMAIL with DMSP id AA22759; Fri, 14 Jul 89 14:22:53 EDT Date: Fri, 14 Jul 89 14:22:53 EDT Message-Id: <8907141822.AA22759@vax.ftp.com> To: bionet!%%%lear%%%%net.bio.net@csd4.milw.wisc.edu Subject: re: assumptions & rules for transiting uucp/smtp messages. Cc: header-people@mc.lcs.mit.edu Sender: stev@vax.ftp.com From: stev@vax.ftp.com Repository: ftp.com Originating-Client: feather.ftp.com *So long as the *message is delivered, the gateway's responsibility is discharged. It *would also be nice, if at all possible, if the gateway presents a *replyable message. *Eliot Lear *[lear@net.bio.net] wrong, eliot. if you cant do it right (for some value of right) you shouldnt be doing it. as am example, i present your address as it arrived on my machine. sorta scary. hopefully, the right thing will happen with it. there are too many "weenie" users out there who can barely remember to delete their old mail when they leave their mail programs, dont make it too much harder for them. as a side note on the original note, i dont think you should assume all @ addresses are DNS resolvable. things are growing *very* quickly, and we will be seeing more addresses from people before the DNS stuff gets updated. i think all you can assume is that the server for the [sub]domain one level above should be resolvable, and that he could be given the mail. (this is an argument for the "wildcard" MX record.) stev knowles ftp software stev@ftp.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 15:11:07 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00509; 15 Jul 89 8:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 15 Jul 89 05:52:47 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Jul 89 06:04:02 GMT From: Keith Moore Organization: CS Dept -- University of TN, Knoxville Subject: Suggested goals for mail gatewaying in general Message-Id: <998@utkcs2.cs.utk.edu> Sender: header-people-request@MC.lcs.mit.edu To: header-people@MC.lcs.mit.edu [I've been working on a follow-up to the suggestions by Goodfellow, Vixie, and subsequently by Kleinpaste, but there are lots of cases to consider, and it's really difficult to think of everything. So I thought I'd take a step back and define some general goals. Here's what I have come up with so far. Comments?] Goals for successful gatewaying of electronic mail messages (in general): (Roughly in decreasing order of importance) 1. The first responsibility of a mail gateway is to either: a) to convert an incoming message and arrange for delivery to its recipients via the destination network, or b) to report failure of delivery to the originator if such conversion is not possible, for example, if the message body (for non-text messages), or an envelope recipient address could not be converted. 2. The gateway should make reasonable attempts to ensure that all components (e.g. envelope addresses, headers, and message body) of the gatewayed message are within accepted standards for the destination network, and if possible, also within the usual conventions for the destination network. 3. Ideally, the gateway should arrange that notification of delivery failure on the recipient's network will be returned to the originator. If this is not possible, such notification should be returned to the gateway postmaster. 4. Ideally, a recipient of the message should be able to reply to the message using his UA's "reply" or similar command. The gateway should arrange that such replies will be sent to the "correct" reply address(es) according to the conventions of the originator's mail system. 5. Gateways should preserve information which may be useful to a human in tracing the path that a message traversed in reaching its destination, and in determining an appropriate reply address should the gateway be unable to provide one. 6. Gateways should make a reasonable attempt to ensure that all header and envelope addresses are "correct" according to the standards and conventions of the destination network, for those headers that are likely to be interpreted by mail-handling programs. "Correct" means that the addresses are likely to be interpreted correctly by mailers, not simply that the addreses are syntatically correct. 7. Gateways should never knowingly pass invalid envelope or header addresses on to the destination network. If, for instance, an address cannot be translated appropriately according to the standards of the destination network, it should be hidden from mail-handling programs, and the original address preserved in an appropriate place (e.g. an extension message header) for interpretation by humans. -- Keith Moore Internet: moore@utkcs2.cs.utk.edu University of Tenn. CS Dept. BITNET: moore@utkvx 107 Ayres Hall, UT Campus UT Decnet: utkcs2::moore Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 17:43:04 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07147; 15 Jul 89 17:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 15 Jul 89 16:59:39 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Jul 89 20:19:09 GMT From: vax5!sdry@cu-arpa.cs.cornell.edu Subject: Enhanced "vacation" program sought Message-Id: <19038@vax5.CIT.CORNELL.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Does anybody have an enhanced version of the "vacation" program that uses RFC822 headers like "Reply-To" to decide where a reply is to be sent? This would be particularly useful for people (like myself) who are on a mailing list and would like to prevent the reply from going to the whole list. The version of "vacation" I have is designed with uucp in mind, and only looks at the "From " line. Another (perhaps even more useful) enhancement would be the possibility of specifying in advance a list of users who should not get a reply. I realise I could play with the .vacation.pag and .vacation.dir files, but that requires a special program. I could rewrite "vacation" myself, but if somebody else has already done it I see no point in duplicating his/her effort. Thanks, Sergio Gelato gelato@astrosun.tn.cornell.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 20:09:08 EDT Received: from Ahwahnee.Stanford.EDU by mintaka.lcs.mit.edu id aa23254; 21 Jul 89 20:02 EDT Received: by ahwahnee.Stanford.EDU; Fri, 21 Jul 89 16:56:37 PDT Date: Fri, 21 Jul 89 16:56:37 PDT From: Dave Crocker Subject: Re: Enhanced "vacation" program sought To: header-people@mc.lcs.mit.edu, vax5!sdry@cu-arpa.cs.cornell.edu Message-ID: <8907212002.aa23254@mintaka.lcs.mit.edu> I believe that the MMDF-based vaction-type program does the sorts of things you are interested in. Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Jul 89 17:16:57 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03295; 31 Jul 89 17:11 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 31 Jul 89 16:54:40 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 31 Jul 89 05:18:27 GMT From: Bruce Robert Larson Organization: UMASS-Boston, Boston, MA Subject: For Sale: Compaq 386/20 w/5MB 60MB Message-Id: <875@umb.umb.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu FOR SALE Compaq Deskpro 386/20 (nine months old) * 5 MB Compaq RAM * 60 MB Compaq (CDC) HD RLL w/1:1 interleave * 5-1/4 1.2MB floppy drive * 3-1/2" 1.44 MB Compaq drive * 2 serial ports * 2 parallel ports * Compaq Deskpro Technical Reference Guide vols. 1 & 2 (complete) * monitor and video card NOT included Have been running 386/ix on it. It's a real screamer. Asking $6800 or best offer. Call (617) 288-4377, and ask for Bruce. Or send email to blarson@umb.edu.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 4 Aug 89 17:47:43 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16590; 4 Aug 89 17:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 4 Aug 89 17:15:44 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 4 Aug 89 17:27:08 GMT From: Marc Cohen Organization: University of Massachusetts, Engineering Computer Services Subject: RE: CONVEX C-210 SUPERCOMPUTER Message-Id: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Sorry.... The reply address for those interested in the Convex C-210 should have read: blanchard@ecs.umass.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 4 Aug 89 17:47:50 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa16594; 4 Aug 89 17:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 4 Aug 89 17:14:08 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 4 Aug 89 15:43:41 GMT From: Marc Cohen Organization: University of Massachusetts, Engineering Computer Services Subject: CONVEX C-210 SUPERCOMPUTER FOR SALE Message-Id: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm posting this for our Director. Please respond to address below. -------------------------------------------------------------------- FOR SALE CONVEX C-210 SUPERCOMPUTER Complete System Hardware: o 32 Mb memory o (2) 434 Mb disk drives o 6250/1600 bpi tape drive o (2) 16 line async. comm. controllers o Ethernet controller Software: o CONVEX UNIX o Ethernet software o Vectorizing Fortran compiler o CONVEX consultant o COVUE Shell w/ network software Installation date: 6/3/88 For further information contact: Daniel Blanchard University of Massachusetts College of Engineering Amherst, MA 01003 413-545-1580 BLANCHARD@UMAECS.UMASS.EDU  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Aug 89 09:23:14 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12445; 13 Aug 89 9:17 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 13 Aug 89 09:08:54 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Aug 89 04:27:48 GMT From: Dan Heller Subject: Re: MH verses the "all in one file" MUAs Message-Id: <113567@sun.Eng.Sun.COM> References: <113461@sun.Eng.Sun.COM>, <1518@cbnewsc.ATT.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am moving this discussion to comp.mail.misc because it doesn't have anything to do with headers anymore. The reason this all started was that someone took notice of the Status: header present in Mail-based MUA's. Mail, Elm (I guess), Mush, mailx, ... all do this: use the Status: header to save information about whether the message is new, unread.. Mush also uses the status header to store info about whether the message has been saved, replied to, and so on. Greg points out that MH saves this info as well, but not in a header which is visible to the user -- MH apparently filters this information out when the message is displayed. The first part of this message contains the preliminary discussion between us. The latter part of the message actually discusses the drawbacks of MH and a few comments about Mush. People who are interested in continuing a discussion about good MUA development as well as hardline MH users are encouraged to read this message and participate in the discussion. Sorry if the preliminary dialog is hard to follow -- I edited it to make it clear about the direction the discussion is going. In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > From article <113461@sun.Eng.Sun.COM>, by argv%eureka@Sun.COM (Dan Heller): > > In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > >> And most of us use the appropriate MHL formats and filters to have them > >> stripped later. Note that MHs repl(1) command (for replying to a message) > >> will allow you to reply multiple times. The Replied headers are stripped > >> from the resulting message by the time you see it in the editor to add > >> your reply. > > > > There -are- other stupid UA's out there that > > don't do the right thing [referencing how mail is replied to]. But, > > that has nothing to do at all with how a mail folder is stored. It is > > incorrect to make the following statement: > > > >> people who continue to implement MUAs that use a single file for > >> storing all messages seem to continue to replicate all the things that > > note that I said SEEM...^^^^ Yes, you said "seem", but the implication is clear :-). Nevertheless, I'm willing to let it go. > > The reason [your statement] is incorrect is because your assumption is that it is > > the single-file-folder "feature" that makes the program "bad." > > A well written/designed UA should [try to] make it as transparent as > > possible about the method for how mail is stored. You are making a > > grave mistake by attributing the storage method utilized by a UA to the > > bugs or implementation (design) features of that UA. If you think that > > MH's "features" are a result of the fact that it's folder storage method > > is attributed to the fact that it stored messages on a file-per-message > > format, you are mistaken. > > I did not say anything about the merits of either method. What I said > was that I have yet to see a "all messages in the same file" UA that > does anything but what the others from the past do. People are > spending a lot of time reproducing PD replacements for MUAs that don't > do anything really that different and useful. You later admit that you haven't used anything else but MH for the past 5 years, so this statement doesn't carry much weight. Nevertheless, your observation is somewhat accurate: Most UAs developed today are limited in either functionality (feature-list) or tend to be ill-designed and are desitined to make the same mistakes as those that preceded them. With these problems in mind, I designed Mush for the purpose of avoiding these problems while taking advantage of other issues (described later). > Okay, here's some questions to think about. What does > mush/elm/mail/whatever not do that MH already does? How much effort will > it take to add those features (if they are desireable)? By the time > you have done that, what will have been added to MH that the other MUAs > then won't have? I don't want to discuss the entire feature list of Mush; the man page is 50 pages long. But, Mush does provide similar features like "pick" and other functions that MH provides. It does provide "piping" of commands, sorting of messages, etc.. The point is that these features can be provided regardless of the storage method of folders. The fact that many of the features of MH happen to be replicated (there are some very good ones), is a side effect of good design. However, MH has some poor design schemes that warrant the writing of a new MUA. So, I'm not reinventing the wheel with writing Mush, but instead I hope to provide a "new and improved" model. > I don't mean to start any wars on MUAs. I am just trying to see if the > individuals doing the work are thinking about were they are going. It > is a real waste of talent to continually play catchup, always adding the > feature that you don't have yet. Believe me, we are aware of what we're doing and are continuing in a well defined direction. There are definite problems with using a Mail-method folder format, but there are an equal number of problems with using the MH-method. One of the major advantages to using the Mail-based folder storage method is that it is backwards compatible with [most] other Mail applications (I address this issue again later). > I had a personal reply from my original article that stated this > >And MH is huge, and chews up disk space and inodes, and hard to learn, and > >slow to use. There are many things wrong with MH in this respect. Not only is it huge, but it *really is* hard to learn. I remember when I first went to SRI, I was set up with MH by default. I spent hours reading all sorts of doc and experimenting with commands and so on... I was really put off by the fact that all my mail was moved and split up. I struggled with it for a while, but was further put off by the fact that it was so slow. But what really took the cake for me was the fact that if your mail is configured for MH, there's no other UA you can use-- you are stuck with MH. What if I told you I had an editor I'd like you to try but told you that if you used this editor, you can't use any other editor on files you edit using that editor. This is how I see MH's folder format. What saves MH is the fact that there is no "standard" (even proposed standards or RFCs) which discuss folder formats or anything similar. Upon further investigation, I learned that MH wasn't portable to any other unix besides BSD systems. This may have changed lately -- I don't keep up with MH that much (my loss, I guess). Is it true that MH still only talks to sendmail as its sole MTA? > That, I cannot dispute. However, I take up the argument > that this is not a problem, but rather a feature. If you have ever written > an MH tool (I have written 4 to date), then you know how powerful and easy > to use the library routines are. Bad excuse. A good application (regardless of functionality; here we happen to be talking about MUAs) should have a "core" layer which makes the program function _independently_ of its user interface. MH solved the problem by making each MH function a separate shell command. Oy vey... You have to start a new process (fork!?), set up pipes, parse command line options, read init files (dot-files) and everything *for each MH command*. MH isn't a "library" as you described, but rather a set of commands. You build a "tool" in front of MH by doing a bunch of popen() calls, or system() calls, or whatever... Don't you think that's rather inefficient/expensive? Mush hasn't quite been set up to be totally independent of its user inter- face, but it is so close that it took me effectively two weeks to build the curses interface on it. It also has a suntools interface and a tty (csh-like) shell interface. Building a new front end of Mush is in fact very easy -- it'll even be easier once the implementation of its final design has been completed. The point is, Mush is a library of function calls, not a set of unix commands. > Putting this > aside, if you can type the strings > > inc > scan unseen (or scan unread) > show > rmm > refile > > you can use MH without any real difficulty. In mush, if you can type "help", you've got it just about licked.. Of course, if you know how to hit "?" that works, too. As simple as you seem to think it is to type "inc", etc..., I never knew to do that when I first learned MH. Despite the doc! > Now for the 'slow to use' part. The fact of the matter is that most people > using MH at universities are not going to have high speed CPUs. MH's > executables average about 200-300K here, and I imagine they are similar > in size elsewhere. This being the case, MH can be slow on a machine with > limited resources. But so is every other largish program I have seen. Mush averages about 100K and provides many features that MH has "as it turns out." That is, I didn't design mush to be MH compatible, it just so happened that some commands and features are very similar. With suntools, the binary is bigger -- about 1 MEG or so depending on the version of sunview or sunwindows you compile with. Without the curses interface, it's smaller. Mush runs on a 80286 running xenix or a ATT PC and more -- can MH? Mush outperforms MH dramatically on large files. For example, finding all messages from a particular author, that has a particular subject, that was sent (or delivered) between two dates from a folder with 500 messages takes about 6-10 seconds. Or, deleting all messages that have been saved takes about 1 second. > Give MH a try. If you hate it, throw it away (or even burn the tape in I'd love to look at it again... But where does one get it? Don't tell me I have to buy it :-). Actually, there's nothing wrong with selling MH (or software, for that matter -- sorry, rms :-), it just means that I won't buy it due to my limited personal financial resources. > But at least try it. MUAs are really a religous issue, so I will > not press any harder. I just needed to make some arguments against some > of the bad things that people are saying about MH. As I said, there are good things about MH (altho I didn't get into them here, just note that I recognize them), but I feel that all the good things about MH can be dupicated more efficiently in a different way. Future plans for Mush include supporting MH style folders, news, several inter- face enhancments (more csh-like features) and performance modifications. As you said, MUAs are as religious as using different editors -- you're never going to convince an emacs user to use vi, and chances are unlikely that you're going to convert an MH user to use Mush (altho there are some cases where this has happened :-). > gregg.g.wonderly@att.com (AT&T bell laboratories) dan ----- My postings reflect my opinion only -- When on the net, I speak for no company.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Aug 89 17:21:47 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa10988; 15 Aug 89 17:17 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 15 Aug 89 16:57:38 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Aug 89 20:16:25 GMT From: "Tom.Moore@ciss.Dayton.NCR.COM" Organization: NCR Corp. Network Application Services Subject: Confirm Delivery Message-Id: <909@ciss.Dayton.NCR.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu For what ever the reason and privacy isues aside, I need the ability to have the MTAs within the NCR mail system acknowledge that a message has been delivered to a user mailbox. Has there been any standardization within the net as to the proper header to use? Apparently there was some discussion a while back about "Return-Receipt-To:". This sounds like what I have in mind. -- * Tom Moore NCR Corporation PCD-6 (513) 445-1373 * * Consulting Analyst 1700 S. Patterson Blvd. VOICEplus 622-1373 * * Network Applications Dayton, OH 45479 Tom.Moore@Dayton.NCR.COM *  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Aug 89 19:47:34 EDT Received: from Ahwahnee.Stanford.EDU by mintaka.lcs.mit.edu id aa12630; 15 Aug 89 19:44 EDT Received: by ahwahnee.Stanford.EDU; Tue, 15 Aug 89 16:37:24 PDT Date: Tue, 15 Aug 89 16:37:24 PDT From: Dave Crocker Subject: Re: Confirm Delivery To: header-people@mc.lcs.mit.edu, ncrlnk!ciss!tmoore@uunet.uu.net Message-ID: <8908151944.aa12630@mintaka.lcs.mit.edu> Is there any interest in specifying a set of header-additions, to RFC822, which augment 822's functionality and make it equivalent to X.400? Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 15:04:42 EDT Received: from shamash.cdc.com by mintaka.lcs.mit.edu id aa20577; 16 Aug 89 10:33 EDT Received: by shamash.cdc.com (5.59/CDC1.2) id AA10880; Wed, 16 Aug 89 09:15:56 -0600 Return-Path: Received: by jpntok.cdjapan.co.jp (5.51++/1.14.7-TIS) id AA21781; Wed, 16 Aug 89 23:15:07 JST Message-Id: <8908171415.AA21781@jpntok.cdjapan.co.jp> Date: Wed, 16 Aug 89 23:15:04 -1500 From: Tim Kehres Subject: Re: Confirm Delivery To: Dave Crocker Cc: header-people@mc.lcs.mit.edu, ncrlnk!ciss!tmoore@uunet.uu.net X-Orig-Date: Tue, 15 Aug 89 16:37:24 PDT X-Orig-From: Dave Crocker X-Orig-Message-Id: <8908151944.aa12630@mintaka.lcs.mit.edu> In your message you write: > Is there any interest in specifying a set of header-additions, to RFC822, > which augment 822's functionality and make it equivalent to X.400? I'm not sure what you could do to augment 822's functionality to make it 'equivalent' to X.400. The X.400 recommendations encompass not only the address format of messages (roughly equivalent to P2 in X.400) but the entire Message Transfer System (MTS) as well as Message Store (MS) functions and certain types of gateways (oops, that's Access Units for OSI people that consider 'gateway' a dirty word), and certain types of conversions. The basic representation of messages is considerably different between the two worlds: most 822 based systems look at messages as being text based only, and only consisting of a single body part, where X.400 does not have these restrictions. While it may be possible to augment 822 to handle some of these cases, is it practical to think that the existing transport services that 822 users use will change to accomodate some of these enhancements? Please don't think that I am trying to argue against enhancements to 822. In fact, I do believe that there are certain areas, like defining standard header fields for delivery notification and return receipt requests that would be valuable additions to the protocol. It is just that your short query seems very open-ended and I am curious as to what you had in mind. Best Regards, Tim Kehres  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Aug 89 15:06:48 EDT Received: from Ahwahnee.Stanford.EDU by mintaka.lcs.mit.edu id aa21452; 16 Aug 89 11:46 EDT Received: by ahwahnee.Stanford.EDU; Wed, 16 Aug 89 08:39:21 PDT Date: Wed, 16 Aug 89 08:39:21 PDT From: Dave Crocker Subject: Re: Confirm Delivery To: dcrocker@ahwahnee.stanford.edu, kehres@tis.llnl.gov Cc: header-people@mc.lcs.mit.edu, ncrlnk!ciss!tmoore@uunet.uu.net Message-ID: <8908161146.aa21452@mintaka.lcs.mit.edu> It is interesting to send an (intentionally) simplistic suggestion and then watch the reactions. (Actually, I was a little too rushed, or I would have indicated the real gist of my interest: There are functions in X.400 that CAN be translated into an enhanced RFC822 specification. It seems to me that it would be worth having a fairly brief(?), focussed effort to define those upgrades. I believe that one type of confirmed delivery is a candidate. Certainly, we cannot and should not attempt to replicated P1 or P3, which are the protocols Tim is references. (Well, really only P1, for MTA-to-MTA transfers.) But 822 is primarily a UA-to-UA specification, so that keeping the focus on P2 seems reasonable. (Yes, I realize that the referenced conform-delivery will probably be of the MTA-to-UA-mailbox style and therefore goes beyond P2.) Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Aug 89 10:50:22 EDT Received: from janeb.cs.wisc.edu by mintaka.lcs.mit.edu id aa06541; 17 Aug 89 10:45 EDT Message-Id: <8908171445.AA04085@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Thu, 17 Aug 89 09:45:30 -0500 To: Dave Crocker Cc: kehres@tis.llnl.gov, header-people@mc.lcs.mit.edu, ncrlnk!ciss!tmoore@uunet.uu.net Subject: Re: Confirm Delivery In-Reply-To: Your message of Wed, 16 Aug 89 08:39:21 -0700. <8908161146.aa21452@mintaka.lcs.mit.edu> Date: Thu, 17 Aug 89 09:45:29 CDT From: hagens@cs.wisc.edu > There are functions in X.400 that CAN be translated into an enhanced > RFC822 specification. It seems to me that it would be worth having > a fairly brief(?), focussed effort to define those upgrades. I believe > that one type of confirmed delivery is a candidate. > Certainly, we cannot and should not attempt to replicated P1 or P3, which > are the protocols Tim is references. >... > Dave Dave, may I caution you to consider the amount of time it would take to 1) define the upgrades 2) implement them in a User Interface 3) distribute those changes If it takes more than 1 year, you might as well wait for real X.400 (with the help of RFC 1006) running over existing Internet links (via TCP/IP). Rob Hagens  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Aug 89 21:49:05 EDT Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa14901; 17 Aug 89 21:42 EDT Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id ; Thu, 17 Aug 89 21:28:48 EDT Received: from splat.UUCP by ssyx.ucsc.edu (4.0/1.1) id AA03578; Thu, 17 Aug 89 18:28:37 PDT Received: by Splat.Aptos.CA.US (smail2.5) id 00776; 17 Aug 89 18:08:57 PDT (Thu) From: Brad Allen Date: Thu, 17 Aug 89 18:08:55 PDT In-Reply-To: Dave Crocker "Re: Confirm Delivery" (Aug 15, 19:42) X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: Dave Crocker , Header-People@mc.lcs.mit.edu Subject: Re: Confirm Delivery Message-Id: <19890817.1808,00776@Splat.Aptos.CA.US> > Is there any interest in specifying a set of header-additions, to RFC822, > which augment 822's functionality and make it equivalent to X.400? I have always found it crazy that mail (of all things) doesn't require ACKnowledgement from the other side. I've always wanted to have a list for every user account I own which tells what mail is pending for acknowledgement, and to what extent it is pending acknowledgement. This comes more from the unreliable UUCP perspective, I think, than the Internet perspective. However, I've had my share of theoretically perfectly straightforward Internet mailings get lost. Clearly to me, knowing that the mail made it to the user's actual mailbox is the least which should be required for such acknowledgement. However, there are lots of things which could be acknowledged: - Actual receipt by the human user. (Often considered private information.) I can see two subtypes of this already, implicit and explicit; implicit acks are automatic, saying that the user pressed the key to have the message displayed; explicit means the user specifically gave a command saying "Here, I read this". There are possibly more subtypes which would be useful: "Yes I got it I'll read it later" "I have read it all." "I discarded it." "Whatever I did, I dealt with it; I'm done with it." This would be voluntary, but I would always suggest supporting it since I would find it useful to tell people which pieces of mail out of my 10 megabyte (yes) mailbox I've seen, read, noticed, etc. - Everything between the birth and death of the message -- you can interpolate from here. Things like "It got to machine X", "It got to the mailbox itself" (what I mentioned above), and "It did NOT get to machine X". This brings up the issue of complexity and usefulness. If designed well, acknowledgements could be made elegant and potentially complex in representation but simple in understanding. I have no idea what ISO X.400 says. Whatever X.400 does, I do suggest that it's always a good idea to keep Internet standards current, and at least comparable with ISO, while the Internet standards are still being used. What is more difficult to me is how to support these for automated use; if my local mailer is to retry sending a message, then how does it know if the remote host is conforming to this standard? It would be pretty easy to flood-enforce the community to upgrade to new mailers by simply letting the local mailers re-send until stopped, but this is not very elegant. And, don't get afraid of mailers which would send zillions of messages around: some people just haven't heard of restraint. The local mailer would use some rapidly increasing interval between resend, and would inform the local user of the progressing failure after an uncommon amount of time had transpired. I still really like my idea of the local mailer keeping a list of messages which haven't somehow been ACK'ed yet -- every day I log in, I can routinely muck with that list and the associated messages until they get there OK. A better solution is consulting the DNS to find out what protocols the remote host is using -- perhaps this is a good chance to change mail from TCP to some UDP, IP, or similar object-based protocol (where the ACK itself isn't being ACKed many times at lower levels, and where an IP packet doesn't have to be sent out for HELO, MAIL FROM:, and RCPT TO: type commands). Brad Allen 5 year BBS user  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 11:04:40 EDT Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa19594; 18 Aug 89 1:44 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Fri, 18 Aug 89 01:43:48 EDT Received: by XN.LL.MIT.EDU; Fri, 18 Aug 89 01:21:24 EDT Posted-Date: Thu, 17 Aug 89 8:13:30 EDT Received: by SCUBED.COM (1.2/5.20b) id AA25399; Thu, 17 Aug 89 08:52:59 pdt Message-Id: <8908171552.AA25399@SCUBED.COM> Subject: Re: Confirm Delivery To: Dave Crocker Date: Thu, 17 Aug 89 8:13:30 EDT From: Tom Moore Cc: header-people@mc.lcs.mit.edu, kehres@tis.llnl.gov In-Reply-To: <8908161546.AA07448@uunet.uu.net>; from "Dave Crocker" at Aug 16, 89 8:39 am X-Mailer: ELM [version 2.2 PL10] I'm still a novice at all of this but it seems that RFC 987 and RFC 1026 attempt to address the RFC822 <-> X.400 gateway issue. That was the first place that I looked for the comfirm delivery header. Unfortunately it was one of those that was not supported, probably due to the lack of capability within most RFC822 routers. I for one would be very interested in the RFC822 <-> X.400 discussion. My company is currently using RFC822 but we are committed to an X.25 network and X.400 mail in the near future. As this transition takes place we will need the gateway service. I would rather that we do not go swimming against the tide as we do it but rather go with the standards of the community. -- * Tom Moore NCR Corporation PCD-6 (513) 445-1373 * * Consulting Analyst 1700 S. Patterson Blvd. VOICEplus 622-1373 * * Network Applications Dayton, OH 45479 Tom.Moore@Dayton.NCR.COM *  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 11:04:49 EDT Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa19600; 18 Aug 89 1:44 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Fri, 18 Aug 89 01:44:07 EDT Received: by XN.LL.MIT.EDU; Fri, 18 Aug 89 01:21:57 EDT Posted-Date: Thu, 17 Aug 89 8:16:43 EDT Received: by SCUBED.COM (1.2/5.20b) id AA25406; Thu, 17 Aug 89 08:53:24 pdt Message-Id: <8908171553.AA25406@SCUBED.COM> Subject: Re: Confirm Delivery To: dcrocker@ahwahnee.stanford.edu Date: Thu, 17 Aug 89 8:16:43 EDT From: Tom Moore Cc: kehres@tis.llnl.gov, header-people@mc.lcs.mit.edu X-Mailer: ELM [version 2.2 PL10] I'm still a novice at all of this but it seems that RFC 987 and RFC 1026 attempt to address the RFC822 <-> X.400 gateway issue. That was the first place that I looked for the comfirm delivery header. Unfortunately it was one of those that was not supported, probably due to the lack of capability within most RFC822 routers. I for one would be very interested in the RFC822 <-> X.400 discussion. My company is currently using RFC822 but we are committed to an X.25 network and X.400 mail in the near future. As this transition takes place we will need the gateway service. I would rather that we do not go swimming against the tide as we do it but rather go with the standards of the community. -- * Tom Moore NCR Corporation PCD-6 (513) 445-1373 * * Consulting Analyst 1700 S. Patterson Blvd. VOICEplus 622-1373 * * Network Applications Dayton, OH 45479 Tom.Moore@Dayton.NCR.COM *  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 12:54:44 EDT Received: from janeb.cs.wisc.edu by mintaka.lcs.mit.edu id aa27056; 18 Aug 89 12:40 EDT Message-Id: <8908181640.AA05334@janeb.cs.wisc.edu> Received: from localhost by janeb.cs.wisc.edu; Fri, 18 Aug 89 11:40:31 -0500 To: Brad Allen Cc: Dave Crocker , Header-People@mc.lcs.mit.edu Subject: Re: Confirm Delivery In-Reply-To: Your message of Thu, 17 Aug 89 18:08:55 -0700. <19890817.1808,00776@Splat.Aptos.CA.US> Date: Fri, 18 Aug 89 11:40:28 CDT From: hagens@cs.wisc.edu > Clearly to me, knowing that the mail made it to the user's actual mailbox is > the least which should be required for such acknowledgement. In my (very personal) opinion, that's the most that you should be given. Until e-mail has "legal status", I don't don't think it is any of your business whether I read my mail, delete it, or print it out to read later. This issue is clearly a "religious war"! > I have no idea what ISO X.400 says. I am not well versed in X.400(88), but in 84, there were 2 kinds of confirmation information: Delivery Confirmation -- which tells you that it made it to the user's mailbox (MS or UA), and the Receipt Notificaion -- which tells you that the user agent has delivered the mail to the actual user (i.e., printed it on the screen). Both are optional. I believe in the former, but not in the latter. Rob Hagens  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 16:44:08 EDT Received: from tis.llnl.gov by mintaka.lcs.mit.edu id aa00857; 18 Aug 89 16:42 EDT Return-Path: Received: by tis.llnl.gov (4.0/1.14.5-TIS) id AA01267; Fri, 18 Aug 89 13:20:11 PDT Message-Id: <8908182020.AA01267@tis.llnl.gov> Date: Fri, 18 Aug 89 13:20:09 -0800 From: Tim Kehres Subject: Re: Confirm Delivery To: Tom Moore Cc: dcrocker@ahwahnee.stanford.edu, header-people@mc.lcs.mit.edu Reply-To: ifip-gtwy-request@tis.llnl.gov X-Orig-Date: Thu, 17 Aug 89 8:16:43 EDT X-Orig-From: Tom Moore X-Orig-Message-Id: <8908171553.AA25406@SCUBED.COM> In your message you write: : > I for one would be very interested in the RFC822 <-> X.400 discussion. There is currently another distribution list dedicated to these types of discussions. If you are interested in subscribing, please send a note to me at: ifip-gtwy-request@tis.llnl.gov As you have probably already noticed, the list can be accessed by sending messages to: ifip-gtwy@tis.llnl.gov In addition, the list archive is also located on tis.llnl.gov and can be retrieved via anonymous ftp. Regards, Tim Kehres ifip-gtwy-request@tis.llnl.gov  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 18:37:06 EDT Received: from EDDIE.MIT.EDU by mintaka.lcs.mit.edu id aa02460; 18 Aug 89 18:33 EDT Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id ; Fri, 18 Aug 89 18:33:02 EDT Received: from splat.UUCP by ssyx.ucsc.edu (4.0/1.1) id AA21928; Fri, 18 Aug 89 15:32:48 PDT Received: by Splat.Aptos.CA.US (smail2.5) id 00243; 18 Aug 89 15:21:50 PDT (Fri) From: scritzifchisted ulmo qzutvchsxik Date: Fri, 18 Aug 89 15:21:47 PDT In-Reply-To: ssyx!hagens%cs.wisc.edu "Re: Confirm Delivery" (Aug 18, 11:35) X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: Header-People@mc.lcs.mit.edu Subject: Re: Confirm Delivery Message-Id: <19890818.1521,00243@Splat.Aptos.CA.US> Hagens wrote: } > Clearly to me, knowing that the mail made it to the user's actual mailbox is } > the least which should be required for such acknowledgement. } } In my (very personal) opinion, that's the most that you should be given. Until } e-mail has "legal status", I don't don't think it is any of your business } whether I read my mail, delete it, or print it out to read later. } This issue is clearly a "religious war"! I think compromises need to made. My compromise is that this is optional. The compromise comes in that people like you have to admit to the world that you're not someone who admits which mails you acknowledge and which mails you don't; many people (like me) will have a predjiduce against people who don't want to admit the simplest of things such as this. However, it's something that can be implemented easily, has its obvious uses, and therefore is hard to stop from being done. Eventually, we'll probably have to deal with this issue at our doorstep, so why not today? Now, whether or not it made it to the user's input mail processor is not private information: unless that user uses corrupt methods which we in our society do not really accept (such as declaring certain gateways defunct and making sure they are so, so that mail to them gets sent to the black hole), then there's really no reason not to let us know that. The reason I want this to be mandatory for those mailers which support it is for the purpose of automated reliable delivery. There >are< errors all over the place, and not checking your work once you're done is just asking for more trouble than is necessary or acceptable. Brad Allen ulmo@splat.aptos.ca.us  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 23:34:48 EDT Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa07707; 18 Aug 89 23:32 EDT Received: by uunet.uu.net (5.61/1.14) id AA03271; Fri, 18 Aug 89 23:31:59 -0400 Date: Fri, 18 Aug 89 23:31:59 -0400 From: Rick Adams Message-Id: <8908190331.AA03271@uunet.uu.net> To: Header-People@mc.lcs.mit.edu, splat!ulmo@ssyx.ucsc.edu Subject: Re: Confirm Delivery Return receipts double the cost of sending mail. They are almost never justified. The people who chose to use them dont use them judiciously, they use them for EVERYTHING. (Observations from experience with a mail system that permitted return receipts) Unless the return receipt visibly costs the sender something, count on them either not using it or always using it. The post office has the right model (charge extra for it). Unfortunately there is no reasonable way to do this as most senders arent paying for it someone else (NSF/DARPA/Their company is)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Aug 89 11:06:10 EDT Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa15896; 19 Aug 89 11:01 EDT Received: by INFOODS id <000009B7046@INFOODS.MIT.EDU> ; Sat, 19 Aug 89 10:52:29 EDT Date: Sat, 19 Aug 89 10:20:02 EDT From: John C Klensin Subject: RE: Re: Confirm Delivery To: Rick Adams X-VMS-Mail-To: EXOS%"Rick Adams " Message-ID: <890819102002.000009B7046@INFOODS.MIT.EDU> cc: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu >Return receipts double the cost of sending mail. > ... >Unless the return receipt visibly costs the sender something, count on them >either not using it or always using it. > >The post office has the right model (charge extra for it). Unfortunately >there is no reasonable way to do this as most senders arent >paying for it someone else (NSF/DARPA/Their company is) Rick has an interesting point here, and my experience is consistent with his. Several of the comments that have been made about the desirability of return-receipts assume an error-prone environment, presumably an error-prone environment in which, if the message does not get through, no one bothers to send a rejection. If this is primarily an Internet discussion, at least at the first level, it is worth noting that: -> SMTP is a virtual connection protocol, not a "you send to intermediary A, whom you hope will send it to intermediary B, whom..." type of protocol (such as those used on BITNET and UUCP). The protocol already *requires* that error messages be produced, i.e., if the message is not delivered to the target mailbox, you are guaranteed to find out, at least within the fallibility parameters of the network. -> Consequently, confirmation from an MTA that it has delivered to a user mailbox or UA is redundant--you get confirmation of non-delivery anyway--unless you assume badly behaved hosts or more network fallibility than experience justifies. And, if things were that badly behaved or fallible, you couldn't reliably get your confirmations back in any event. -> Since there are (deliberately, I assume) no Internet protocols that standardize the behavior of UAs or of exactly how mail is handled within a given host (X.400 goes a bit further in this direction), some of the distinctions among types of acknowledgements don't work. If you say "tell me when the message is delivered by the MTA to the user's UA", an Internet host has the right to respond "what do you mean UA? that is an interesting conceptual model, but we haven't layered things that way." -> Since the protocol uses virtual circuits, in the absence of MXs and/or source routes, the only place you need to ask "whose queue is this sitting in now" is your own sending host. There is no need for equivalents of the BITNET facility to query the queues on an intermediate machine or, presumably, its UUCP equivalent, since there are no intermediate hosts. -> This means that, if one is using confirmations to monitor network transit (several of the suggestions have implied this), only the following cases are important for SMTP: o Your own machine opened a connection to a remote machine and successfully pushed the message down the connection. That is purely a local issue, and requires no protocol changes. o The message is going through a mail exchange or relaying host, and you want to know when it has passed things on. Dandy idea, but how are you supposed to tell which hosts are mail exchangers? The idea of a universal name space is that you shouldn't have to know or need a way to find out. o The message is going through a mail exchanger / gateway into an unreliable network and you want to know if and when it gets to the ultimate target machine. Seems like a good idea, but, from an Internet standpoint, probably best worked out--perhaps using some of the ideas suggested in the last few days--by having enough acknowledgement action between the mail exchanger MTA and the target machine MTA so that the mail exchanger can do its job (i.e., not violate the protocols) by returning accurate non-delivery messages when deliveries are not made. This brings me back to Rick's point about costs. There are really two separate issues, neither attractive. As things now work, if anyone pays for an acknowledgement, it is likely to be the environment of the receiver, not the environment of the confirmation-requestor. That is not particularly desirable, to say the least, and makes a reason for not supporting confirmations: "I don't feel like paying for your amusement". Rick's "who pays" point remains interesting if one could pass the cost of receipts on to the requestor. It would be interesting to check with, e.g., MCIMail, where delivery receipt requests are optional and charged to senders, to find out who uses them, who doesn't, and in what patterns if they have that information. Also keep in mind that voluntary confirmation of receipt and understanding by the end user, in situations where you are unsure about the network or user requires no protocol change. We request, and get, such receipts all the time. The procedure is to include, in the body of the message, something to the effect of "hey, Joe, if theis reaches you, please send me a confirming message, since I don't trust the system. If I don't hear from you, I'll use the phone." "Joe", wanting to avoid phone calls, usually manages to respond if the message is received. So, let's step back a bit and answer the question "what are delivery conformations for, and which confirmations?" before worrying about how to do them technically. john klensin Klensin@INFOODS.MIT.EDU  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Aug 89 11:52:51 EDT Received: from Ahwahnee.Stanford.EDU by mintaka.lcs.mit.edu id aa16375; 19 Aug 89 11:50 EDT Received: by ahwahnee.Stanford.EDU; Sat, 19 Aug 89 08:42:56 PDT Date: Sat, 19 Aug 89 08:42:56 PDT From: Dave Crocker Subject: Re: Confirm Delivery To: Header-People@mc.lcs.mit.edu, splat!ulmo@ssyx.ucsc.edu Message-ID: <8908191150.aa16375@mintaka.lcs.mit.edu> The discussion about which kind of acks to generate is one that always ensues, when one asks about whether to generate mail acks. It is exactly the kind of discussion that can cause 822-enhancement efforts to take more than a year. It is exactly the kind of discussion that I was trying to help avoid, buy suggesting blindly adopting any of the X.400 functionality that can easily be translated into 822 syntax and semantics. The discussions certainly are important and often can be interesting. They also are quite time-consuming. Given that many of these discussion already have taken place among a significant body of email-knowledgeable people, I suggest that the intellectual exercises be moved out of the path of generating 822 upgrade specification. Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Aug 89 12:01:19 EDT Received: from cunyvm.cuny.edu by mintaka.lcs.mit.edu id aa27648; 20 Aug 89 11:55 EDT Received: from UIAMVS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 4197; Sun, 20 Aug 89 11:55:18 EDT Received: (from R25@UIAMVS for MAILER@UIAMAIL via NJE) (KHENRY$M-5656; 6 LINES); Sun, 20 Aug 89 10:53:07 CDT Date: Sun, 20 Aug 89 10:53 CDT From: Ken Henry To: HEADER-PEOPLE@MC.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: Please add to HEADER-PEOPLE Message-ID: <8908201155.aa27648@mintaka.lcs.mit.edu> SUBSCRIBE HEADER-PEOPLE Ken Henry  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Aug 89 23:55:15 EDT Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa29951; 20 Aug 89 17:32 EDT Received: by garnet.berkeley.edu (5.57/1.32) id AA06603; Sun, 20 Aug 89 14:31:52 PDT Date: Sun, 20 Aug 89 14:31:52 PDT From: Postmaster & BITINFO Message-Id: <8908202131.AA06603@garnet.berkeley.edu> To: Header-People@MC.lcs.mit.edu, splat!ulmo@ssyx.ucsc.edu Subject: Re: Confirm Delivery In reply to: ... for the purpose of automated reliable delivery There are various levels of acknowledgement possible. I do not trust automated acknowledgements and never will. The only valid reader to drafter acknowledgement is a message sent by the addressee of original message back to the drafter. An automatically generated acknowledgement could be generated by the wrong reader in a shared mailbox. Bill Wells Disclaimer. This opinion is my own and not that of my employer.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Aug 89 23:55:23 EDT Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa29961; 20 Aug 89 17:33 EDT Received: by INFOODS id <000009BA072@INFOODS.MIT.EDU> ; Sun, 20 Aug 89 17:23:37 EDT Date: Sun, 20 Aug 89 17:19:09 EDT From: John C Klensin Subject: RE: Re: Confirm Delivery To: Dave Crocker X-VMS-Mail-To: EXOS%"Dave Crocker " Message-ID: <890820171909.000009BA072@INFOODS.MIT.EDU> cc: @mintaka.lcs.mit.edu:header-people@MC.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Dave, My understanding of the X.400 ack structure (and I have studied the red book version much more closely than the 88 version) is that "you name it, they've got it". They also have a strong model of user-code -> UA -> MTA -> MTA -> UA -> user-code, and their definitions of what gets sent to whom, when, are built on that model. The quasi-philosophical discussion is needed because the mapping between "what X.400 supports" and SMTP/RFC822 is not obvious, especially given that the Internet protocols leave behavior of local systems almost completely unspecified and unmodeled. john  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 09:33:38 EDT Received: from gjetost.cs.wisc.edu by mintaka.lcs.mit.edu id aa07845; 21 Aug 89 9:32 EDT From: Marvin Solomon Message-Id: <8908211332.AA02826@gjetost.cs.wisc.edu> Received: by gjetost.cs.wisc.edu; Mon, 21 Aug 89 08:32:35 -0500 Subject: Re: Confirm Delivery To: Dave Crocker <@mc.lcs.mit.edu:dcrocker@ahwahnee.stanford.edu> Date: Mon, 21 Aug 89 8:32:33 CDT Cc: Header-People@mc.lcs.mit.edu, splat!ulmo@ssyx.ucsc.edu In-Reply-To: <8908191150.aa16375@mintaka.lcs.mit.edu>; from "Dave Crocker" at Aug 19, 89 11:27 am X-Mailer: ELM [version 2.2 PL10] Dave's right, this is one of those perennial discussions that come up every few years and generate lots of heat but very little light. Let me briefly summarize the X.400 situation and try to avoid value judgetments. X.400 distinguishes between "delivery notifications", "non-delivery notifications", and "receipt notifications". A delivery notification is high-level ack. It means that the message got to the destination MTA (in Internet terms, you can think of that as roughly "destination host"). A non-delivery notification is an error report. A reciept notification means that it was actually delivered to the user. The specs are rather vague (deliberately, I suspect) on exactly what that means. They explain exactly how to request receipt notification and what one should look like when sent, but don't explain the precise significance of when they are sent. To do so would involve standardizing aspecs of the user interface--something the OSI specs studious avoid doing. So far as I know, receipt notification is seldom implemented in "real" systems, but I haven't taken a scientific survey. The sender of a message can request any combination of notifications--or none at all--and the specification is on a per-recipient basis. It is also possible to indicate whether the contents of the original message should be included in a non-delivery notification. Notifications are flagged as different "types" of messages. When the original message is returned as part of a notification, it is delimited so that it is possible to unambiguously extract it from the notification. Message id's are used to correlate notifications with the messages to which they pertain. In effect 822/821 mandates "non-deliverly notification: always" and "other notifications: never". There has been some debate about "return of contents". As I recall, the specs are pretty vague about this. Most implementations include the contents, but may truncate it if it is "very long". At least one implementation used to send the notification with an indication that "the message follows under separate cover". That was extremely unpopular, since it was almost impossible to correlate the notification with the returned contents. My experience with naive users is that if they have ever used a mail system with some sort of notifications, they love this feature and cannot understand why Internet mail doesn't support it. When I try to find out whether it is delivery notification or receipt notification they really want, they have a lot of trouble understanding the distinction, but I get the general impression that it is delivery notification they really like, because they don't really trust the mail delivery system. I could speculate further on this issue, but I'd like to stick to mechanism and avoid policy for now. I will simply say that both kinds of notification have their uses. I've listed the essential features of X.400 wrt notifications in the third paragraph above. 822/821 currently supports little of this mechanism. Some parts could be added by extensions or even simple conventions. For example, o there is already an rfc suggesting encapsulalion techniques for embedding one message in another o a special header field or special string in the subject could be used to indicate that a message is a notification o message id's exist, but there may be some additional standardization required concerning how they are used for notifications The one change that would require major additions to the spec is the ability to specify options on a per-recipient basis. Items in the X.400 equivalent of To: and From: fields are called "originator/recipient names" (O/R names). An O/R name is a record that contains not only a designation of a mailbox, but also addtional information, including an indication of the kind of notifications desired. (It is also used to record in a message which recipients have already had copies delivered to them.) Back in the early days of CSNET, we encountered another place where per-recipient info was needed: as a check on cached mappings from CSNET id to address. At the 822 level, there seemed to be only two possible approaches, neither very attractive. We could list all the id's in a separate header field and try to match them up with addresses elsewhere in the header, or we could stuff the id in the "phrase" or comment part of an address. At the 821 (SMTP) level, it was even harder. I approached the "mail police" for a solution. I proposed that an address become a sort of "property list". My proposal was very cooly received. I believe we finally settled on including the id in an 822 comment, despite strong warnings from Dave Crocker (he felt the spec gave no reassurance that comments wouldn't be altered or deleted). I can't resist ending with a little sermon. Some Internet folks write off all OSI developments as junk. It is true that some OSI standards are garbage, many contain some garbage, and the presentations of nearly all are unreadable garbage. The political and religious wars in OSI land make the Internet community look like a love-in. Nonetheless, there are some very good ideas there, and those who are serious about advancing the state of the art should take the trouble to learn about them. In the case of mail, I think that X.400 is fundamentally better than 822. You could try to stuff bits of X.400 functionality into 822, but in the short term I don't think it would work (most "822" implementors haven't even read rfc822!) and in the long term I don't think there's much point to it. A '69 Chevy Ipala with tail fins isn't a very modern vehicle, but it will get you accross country better than a horse. ...And adding wheels to the horse won't change that. Marvin Solomon Computer Sciences Department University of Wisconsin, Madison WI solomon@cs.wisc.edu, uwvax!solomon  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 11:55:56 EDT Received: from p.lanl.gov by mintaka.lcs.mit.edu id aa26854; 18 Sep 89 11:49 EDT Received: by p.lanl.gov (5.54/1.14) id AA03698; Mon, 18 Sep 89 09:04:39 MDT Received: by sneezy.lanl.gov (4.0/5.17) id AA02376; Mon, 18 Sep 89 09:04:34 MDT Date: Mon, 18 Sep 89 09:04:34 MDT From: "C. Philip Wood" Message-Id: <8909181504.AA02376@sneezy.lanl.gov> To: header-people@mc.lcs.mit.edu Subject: What is the correct way to set up mailing lists? When I mail to various lists, I often get a bunch of replys from MAILER-DAEMON, Darth-Vador or someone like him. I get the impression that there is a correct way to set up lists so that the maintainter of the list will get errors rather than the list itself. Since, I have a few local lists myself, I would like to do it right the second time. 1. Where is the inter-relationship of the following aliases defined: -request owner- 2. Why are there both -request and owner-? 3. Are there more aliases needed to handle a mail group correctly? 4. Is the following a good idea for sublists: : "|/usr/lib/sendmail -oi -f-request -sublist" -sublist: u1, u2, ... uN Phil Wood Los Alamos National Laboratory  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 13:39:08 EDT Received: from p.lanl.gov by mintaka.lcs.mit.edu id aa28412; 18 Sep 89 13:26 EDT Received: by p.lanl.gov (5.54/1.14) id AA07591; Mon, 18 Sep 89 11:26:15 MDT Received: by sneezy.lanl.gov (4.0/5.17) id AA00310; Mon, 18 Sep 89 11:26:09 MDT Date: Mon, 18 Sep 89 11:26:09 MDT From: "C. Philip Wood" Message-Id: <8909181726.AA00310@sneezy.lanl.gov> To: header-people@mc.lcs.mit.edu Subject: Re: correct way to set up mailing lists. What is the correct way to handle the following, which I got in in response to the original posting about how to set up mailings lists? Phil ----- Begin Included Message ----- From @mc.lcs.mit.edu:Mailer-Daemon@unix.sri.com Mon Sep 18 11:03:14 1989 Received: from p.lanl.gov by sneezy.lanl.gov (4.0/5.17) id AA00303; Mon, 18 Sep 89 11:03:11 MDT Received: by p.lanl.gov (5.54/1.14) id AA07068; Mon, 18 Sep 89 11:03:05 MDT Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27697; 18 Sep 89 12:35 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 12:36:11 EDT Received: from UNIX.SRI.COM by mintaka.lcs.mit.edu id aa27582; 18 Sep 89 12:29 EDT Received: by unix.sri.com (4.0/SMI-4.0) id AB21391; Mon, 18 Sep 89 09:27:40 PDT Date: Mon, 18 Sep 89 09:27:40 PDT From: Mail Delivery Subsystem Subject: Returned mail: Service unavailable Message-Id: <8909181627.AB21391@unix.sri.com> To: @mc.lcs.mit.edu@LANL.GOV, cpw@sneezy.LANL.GOV Mmdf-Warning: Parse error in original version of preceding line at lcs.mit.edu Status: R ----- Transcript of session follows ----- mail: /var/spool/mail/knutsen has more than one link or is a symbolic link Mail saved in dead.letter 554 ... Service unavailable ----- Unsent message follows ----- Return-Path: <@mc.lcs.mit.edu,@p.lanl.gov:cpw%sneezy@lanl.gov> Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by unix.sri.com (4.0/SMI-4.0) id AA21384; Mon, 18 Sep 89 09:27:40 PDT Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27120; 18 Sep 89 12:10 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Sep 89 11:55:56 EDT Received: from p.lanl.gov by mintaka.lcs.mit.edu id aa26854; 18 Sep 89 11:49 EDT Received: by p.lanl.gov (5.54/1.14) id AA03698; Mon, 18 Sep 89 09:04:39 MDT Received: by sneezy.lanl.gov (4.0/5.17) id AA02376; Mon, 18 Sep 89 09:04:34 MDT Date: Mon, 18 Sep 89 09:04:34 MDT From: "C. Philip Wood" Message-Id: <8909181504.AA02376@sneezy.lanl.gov> To: header-people@mc.lcs.mit.edu Subject: What is the correct way to set up mailing lists? When I mail to various lists, I often get a bunch of replys from MAILER-DAEMON, Darth-Vador or someone like him. I get the impression that there is a correct way to set up lists so that the maintainter of the list will get errors rather than the list itself. Since, I have a few local lists myself, I would like to do it right the second time. 1. Where is the inter-relationship of the following aliases defined: -request owner- 2. Why are there both -request and owner-? 3. Are there more aliases needed to handle a mail group correctly? 4. Is the following a good idea for sublists: : "|/usr/lib/sendmail -oi -f-request -sublist" -sublist: u1, u2, ... uN Phil Wood Los Alamos National Laboratory ----- End Included Message -----  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Sep 89 07:42:12 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa17923; 21 Sep 89 7:38 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8690; Thu, 21 Sep 89 07:37:12 EDT Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 2321; Thu, 21 Sep 89 07:37:11 EDT Received: from ODEN by brage.qz.se; Thu, 21 Sep 89 12:18 +0200 Date: 21 Sep 89 10:31 +0200 From: Jacob Palme QZ Subject: Re: correct way to set up mailing lists. To: header-people Reply-to: Jacob Palme QZ Message-ID: <449434@QZCOM> In-Reply-To: <8909181726.AA00310@sneezy.lanl.gov> <8909181504.AA02376@sneezy.lanl.gov> bcc: "C. Philip Wood" Perhaps there should be an RFC to describe how a good mailing list expander in the SMTP-based domain should work? Here are some comments on what should be in it: (1) SMTP-sender should be set to the name of the maintainer of the list. Not the list itself, not the original author. (2) From: and Message-ID should not be altered. (3) If the message lacks a Message-ID, such an Id should be added, computed by hashing the author name, date and text. (The advantage with hashing is that if another mail expander expands the same message, it should get the same hashed value for the ID.) (4) The name of the list should be added in a standardized format to the Received: part of the header, so that this can be used for loop control if the same message comes around once more to the same list. (The advantage with this kind of loop control, is that it can be translated, via a gateway, to the corresponding loop control in X.400). Also, the RFC should say something about the proper activity of a User Agent or Postmaster Agent when receiving a message from a list. Such as that non-delivery messages should be sent to the SMTP-sender, not the From-field-name, etc. I am willing to supply a proposal for the Message-ID hashing algorithm, but cannot do the whole work. <  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Sep 89 11:08:00 EDT Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa20265; 21 Sep 89 11:06 EDT Received: by INFOODS id <00001472062@INFOODS.MIT.EDU> ; Thu, 21 Sep 89 10:58:13 EDT Date: Thu, 21 Sep 89 10:50:16 EDT From: John C Klensin Subject: RE: Re: correct way to set up mailing lists. To: Jacob Palme QZ X-VMS-Mail-To: EXOS%"Jacob Palme QZ " Message-ID: <890921105016.00001472062@INFOODS.MIT.EDU> cc: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu >(1) SMTP-sender should be set to the name of the maintainer of >the list. Not the list itself, not the original author. Already in the forthcoming Host Requirements RFC. >(2) From: and Message-ID should not be altered. Ditto, albeit with some qualifications about gateways. >(3) If the message lacks a Message-ID, such an Id should be added, >computed by hashing the author name, date and text. (The advantage >with hashing is that if another mail expander expands the same >message, it should get the same hashed value for the ID.) Only if we can all agree on a hashing algorithm for this purpose that is completely machine-independent. Most of the ones in active use aren't. >Also, the RFC should say something about the proper activity >of a User Agent or Postmaster Agent when receiving a message >from a list. Such as that non-delivery messages should be sent >to the SMTP-sender, not the From-field-name, etc. It has ALWAYS been the rule that SMTP error messages are sent to the SMTP (RFC821) sender, not any of the addresses in the header. While there have been some ill-behaved SMTP MTAs and UAs, most of the problems have been the result of gateways that don't bother to capture the RFC821 From field and then use it properly. The forthcoming Host Requirements RFC further clarifies and stresses this point. >I am willing to supply a proposal for the Message-ID hashing >algorithm, but cannot do the whole work. Seems like a large fraction of the work is done already. What is needed is correct and consistent application of existing protocols. John Klensin, Klensin@INFOODS.MIT.EDU  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Sep 89 22:55:18 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa29474; 21 Sep 89 22:49 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1567; Thu, 21 Sep 89 22:48:12 EDT Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 3397; Thu, 21 Sep 89 22:48:11 EDT Received: from ODEN by brage.qz.se; Fri, 22 Sep 89 04:33 +0200 Date: 22 Sep 89 02:51 +0200 From: Jacob Palme QZ Subject: RE: Re: correct way to set up mailing lists. To: header-people Reply-to: Jacob Palme QZ Message-ID: <449731@QZCOM> In-Reply-To: <890921105016.00001472062@INFOODS.MIT.EDU> > From: John C Klensin > > >Also, the RFC should say something about the proper activity > >of a User Agent or Postmaster Agent when receiving a message > >from a list. Such as that non-delivery messages should be sent > >to the SMTP-sender, not the From-field-name, etc. > It has ALWAYS been the rule that SMTP error messages are sent to the > SMTP (RFC821) sender, not any of the addresses in the header. While > there have been some ill-behaved SMTP MTAs and UAs, most of the problems > have been the result of gateways that don't bother to capture the RFC821 > From field and then use it properly. The forthcoming Host Requirements > RFC further clarifies and stresses this point. > > >I am willing to supply a proposal for the Message-ID hashing > >algorithm, but cannot do the whole work. > Seems like a large fraction of the work is done already. What is > needed is correct and consistent application of existing protocols. Yes, certainly. Much of the text in an RFC on mailing lists will be already known and by many implementors accepted principles. But by combining this knowledge in an RFC, we will increase the likelihood that implementations will handle distribution lists in a proper way. For example, I did receive non-deliveries on the message you are replying to, non-deliveries which should have been sent to the header-people maintainer. Some of my proposals, such as putting the history of which lists a message hast passed in the "Received:" fields is not so common, but would be very valuable in co-working with X.400, since X.400 has such a trace and puts large emphasis on its use. Here are some additional points which might be inclunded in an RFC on distribution lists: (a) The custom of adding "-request" at the end of a list name in order to address its maintainer. (b) An automatic protocol for adding and deleting a user from a list by sending mail to "-request" or perhaps "-autoserver" to distinguish between messages to be handled by a human and those to be handled by an automatic server. LISTSERV in BITNET already has such a protocol, the AMIGO MHS+ group defined an alternative, other protocol ideas may exist. (c) An automatic protocol for requesting sending/resending of messages from a list archive, if such exists, from a server which could be the list name with "-archive" added at the end? This protocol could be useful (i) if you lost a message from a list (ii) if you are new and want to read previous messages. (d) A RFC822-heading field, added by the list, giving a sequence number of all messages distributed by the list. This sequence number can be used by recipient UA-s to automatically recognize that they have lost messages, and automatically request renewed sending using the protocol (c) above.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 01:45:59 EDT Received: from WSMR-SIMTEL20.ARMY.MIL by mintaka.lcs.mit.edu id aa02474; 22 Sep 89 1:41 EDT Date: Thu, 21 Sep 1989 23:40 MDT Message-ID: From: "Frank J. Wancho" To: Jacob Palme QZ Cc: header-people , WANCHO@wsmr-simtel20.army.mil Subject: correct way to set up mailing lists. In-reply-to: Msg of 22 Sep 89 02:51 +0200 from Jacob Palme QZ Jacob, I believe that the apparently logical convention of listname-REQUEST, which has now been around some 13 years, was a mistake. It has been far too easy to simply forget to add the -REQUEST, mostly in haste if not in ignorance, and accidentally send an administrative message to an unmoderated list. I propose to break this traditional convention and move to a prefixed form of anything-listname, such as REQUEST-listname. Get the first part right and the second part will naturally follow, mainly because you have to *think* before you act. Not so with the current form because you are mostly concentrating on getting the listname@hostname right. Also, please consider where rejection notices should be sent in the case of lists which redistribute to secondary or sublists. The main list maintainer usually does not have ability nor the desire to repair sublist problems. When passing through a mailer which explodes a sublist, it should be required that the mailer replace the RFC-821 From line with one pointing to the sublist maintainer, or, in a non-SMTP environment, make the appropriate header modifications which have similar meaning. --Frank  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 07:09:37 EDT Received: from shamash.cdc.com by mintaka.lcs.mit.edu id aa07265; 22 Sep 89 7:06 EDT Received: by shamash.cdc.com (5.59/CDC1.2) id AA23522; Fri, 22 Sep 89 05:59:03 -0600 Return-Path: Received: by jpntok.cdjapan.co.jp (5.51++/1.14.7-TIS) id AA28426; Fri, 22 Sep 89 19:07:53 JST Message-Id: <8909231007.AA28426@jpntok.cdjapan.co.jp> Date: Fri, 22 Sep 89 19:07:50 -1500 From: Tim Kehres Subject: Re: correct way to set up mailing lists. To: "Frank J. Wancho" Cc: JPALME%com.qz.se@mitvma.mit.edu, HEADER-PEOPLE@mc.lcs.mit.edu, WANCHO@wsmr-simtel20.army.mil X-Orig-Date: Thu, 21 Sep 1989 23:40 MDT X-Orig-From: "Frank J. Wancho" X-Orig-Message-Id: In your message you write: : + I propose to break this traditional convention and move to a prefixed + form of anything-listname, such as REQUEST-listname. Get the first + part right and the second part will naturally follow, mainly because + you have to *think* before you act. Not so with the current form + because you are mostly concentrating on getting the listname@hostname + right. I would vote not to do this, primarily because in the process you will break a lot of the software currently running on the internet. The idea is sound, but since there is already a mechanism in place to handle this situation, I don't consider the trade-off to be a good one. + Also, please consider where rejection notices should be sent in the + case of lists which redistribute to secondary or sublists. The main + list maintainer usually does not have ability nor the desire to repair + sublist problems. When passing through a mailer which explodes a + sublist, it should be required that the mailer replace the RFC-821 + From line with one pointing to the sublist maintainer, or, in a + non-SMTP environment, make the appropriate header modifications which + have similar meaning. I have a filter program running on tis.llnl.gov now for close to two years that does the required header munging for sendmail. For distribution lists, it automatically adds the -request address for the Sender: and Return-Path: fields. It has saved a *lot* of aggrivation in running the mhsnews and ifip-gtwy lists. In addition, I am currently updating the program to filter out the Return-Receipt: fields. Depending on how the filter is invoked, the Return-Receipt field will either be removed or changed to point to the list maintainer. I realize that the Return-Receipt field is not "official" RFC822, but there are enough sendmail sites out there that will respond with a delivery notification message, that without the added capability it is impossible to keep the addresses in the list private. If there is any interest in this program, please let me know. If the interest is great enough, I'll go ahead and make it generally available. Regards, Tim Kehres  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 10:34:29 EDT Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa09663; 22 Sep 89 10:31 EDT Received: by INFOODS id <00001975061@INFOODS.MIT.EDU> ; Fri, 22 Sep 89 10:23:45 EDT Date: Fri, 22 Sep 89 09:44:07 EDT From: John C Klensin Subject: RE: RE: Re: correct way to set up mailing lists. To: Jacob Palme QZ X-VMS-Mail-To: EXOS%"Jacob Palme QZ " Message-ID: <890922094407.00001975061@INFOODS.MIT.EDU> cc: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu I want to stress that I was not opposing such an RFC. Indeed, I think it would be extremely useful. Instead, I was trying to suggest that (1) it would not need to contain very much that was controversial, since several of the original comments (especially error handling) are already parts of the standards. (2) because there are clear statements in these areas in the existing protocols, the effort would be less large than might initially be supposed. However, part of the historical problem with defining an inter-network mail distribution protocol is that these messages pass through several networks, each with its own variations on headers, procedures, and protocols. Each has also tended to behave as if it is the center of the universe, with other networks being "similar to" its rules. Since, for example, USENET newsfeeds are different in concept from Internet distribution lists and neither is quite isomorphic with what LISTSERV does, one needs ways to translate concepts in an appropriate way, not just make statements about protocols in the protocol-language of a single network. Again, just as an example, it is sad that non-delivery messages from header-people are still delivered to message originators, not to the list maintainer. But it is not surprising, given the number of odd gateways and translations through which the messages pass. We can agree that errors go to the address in the RFC821 "From" field (referred to as the SMTP-sender field in earlier messages), and agree that the Internet protocols require that. The Host Requirements RFC insists that the RFC821 From field be recorded in a final Received header so that UAs processing the RFC822 headers can generate error messages to the right place (this is just a clarification of a long-standing rule). But, of necessity, where the Internet (in the narrow sense) stops, so does RFC821 and HRRFC. Even RFC822 stops at that boundary: BITNET and UUCP use mail header arrangements that are similar to RFC822, but that are not strictly RFC822. So, messages routinely pass from the Internet, through a gateways onto other well-known networks, into other modes for handling distribution lists, and thence through other gateway into private nets with their own arrangements and it is very difficult to enforce the rules as information gets lost and other information is made up. If, some intermediary drops the RFC821 From field because it discards the envelope, then it is going to be difficult for something further downstream to generate a correct error message to the correct place. No amount of protocol specifying is going to cure this problem. If the gateway passed the correct information along, it is rarely useful to heap abuse on the gateway maintainer, since they typically have only very limited control over systems on the far end of the gatewayed network. And the far-end system is often behaving reasonably according to its understanding of the rules of the network on which it operates. So, I suggest that the interesting and hard part of a distribution list RFC effort is specifying, and getting agreement on, the reversible transformations and mappings as the message, and its envelope and headers, move through a series of redistributions, on a series of heterogeneous networks, each with similar, but not identical, header and envelope rules. We don't even have a good (in the sense of completeness and specificity) set of "what gateways are supposed to do with *mail* between X and Y" documents yet. In particular, we don't have a published one between the Internet and BITNET/EARN/NETNORTH/etc., partially because we continue to pretend that mail on these systems is identical. John Klensin Klensin@INFOODS.MIT.EDU  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Sep 89 11:12:51 EDT Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa10360; 22 Sep 89 11:07 EDT Received: by INFOODS id <00001994031@INFOODS.MIT.EDU> ; Fri, 22 Sep 89 11:00:13 EDT Date: Fri, 22 Sep 89 10:57:02 EDT From: John C Klensin Subject: RE: correct way to set up mailing lists. To: "Frank J. Wancho" X-VMS-Mail-To: "Frank J. Wancho" Message-ID: <890922105702.00001994031@INFOODS.MIT.EDU> cc: @mintaka.lcs.mit.edu:header-people@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu >I believe that the apparently logical convention of listname-REQUEST, >which has now been around some 13 years, was a mistake. It has been >far too easy to simply forget to add the -REQUEST, mostly in haste if >not in ignorance, and accidentally send an administrative message to >an unmoderated list. > >I propose to break this traditional convention and move to a prefixed >form of anything-listname, such as REQUEST-listname. Get the first >part right and the second part will naturally follow, mainly because >you have to *think* before you act. Not so with the current form >because you are mostly concentrating on getting the listname@hostname >right. Frank, I think you are right, but it is too late. It is already getting very difficult, with BITNET hosts assuming domain-style names, to remember which lists should be sent administrative messages to xxx-request and which ones require such messages to be sent in specific form to the list or to some LISTSERV. At least there, if one can figure out which network the host is really on (something I shouldn't have to do), it is possible to make educated guesses. But, to know which Internet lists use xxx-listname and which ones use listname-xxx is likely to be impossible. And, based on the things that creep out onto unmoderated lists, if someone tries listname-request and it fails, the next attempt is going to be a message to the list asking where one sends messages to desubscribe. It happens anyway, much too often, and a change in conventions would tend to reinforce it. I think I'm opposed to it, but, if you wanted a semi-foolproof convention that could be implemented today, you would specify something like the following: 1) For this list, all messages must start with a single line consisting of, say, an asterisk followed by a keyword. If that line does not appear as the first text line in the message, the message will be returned to the sender, with a polite, but tedious, error message. 2) The first line keyword would be either: *distribute in which case the message was intended to go out to the list or *request in which case the message was intended for administrative processing or some sort. You could define additional keywords as needed. Now, again with the understanding that I'm not sure I like this particular idea, it accomplishes several things: a) The list management activity is handled by list management fields within the list-message, not by unofficial conventions or by trying to overload headers. b) If Jacob can talk you into it, the initial list exploder for lists operating with this convention could generate a special message id as a second *-line. Since this would not depend on header or envelope management, it could be preserved across all sorts of network-induced transformations. More broadly, this could be the beginning of saying "mailing lists and similar things are not mail, they just use mail facilities as a transport medium". c) It has the right sort of error hierarchy behavior, i.e., - someone who understands and follows the rules gets smooth behavior. - someone who tries sending to the wrong address (e.g., listname-request) gets automatic 'no addressee' messages or, if one feels inclined, a message that explains the correct procedure. - someone who sends administrative requests to the list without understanding the conventions can get a long, and automatically generated, reply explaining what should be done. >When passing through a mailer which explodes a >sublist, it should be required that the mailer replace the RFC-821 >From line with one pointing to the sublist maintainer, or, in a >non-SMTP environment, make the appropriate header modifications which >have similar meaning. Yep. The sublist is where such a message is originating, after all, regardless of where it copied it from. However, the occasional counterargument, which has to do with the sublist tracking down trash that might have originated from the original list, reinforces the value of building carefully structured Received fields any time the RFC821 From field is altered. --john  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Sep 89 09:23:45 EDT Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa28817; 25 Sep 89 9:19 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 7863; Mon, 25 Sep 89 09:18:26 EDT Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 0888; Mon, 25 Sep 89 09:18:24 EDT Received: from ODEN by brage.qz.se; Mon, 25 Sep 89 14:13 +0200 Date: 23 Sep 89 10:13 +0200 From: Jacob Palme QZ Subject: Re: correct way to set up mailing lists. To: header-people Reply-to: Jacob Palme QZ Message-ID: <449949@QZCOM> In-Reply-To: <8909231007.AA28426@jpntok.cdjapan.co.jp> In order to ensure that non-delivery-notifications are sent to the list maintainer, and not to the author, non-delivery-notifications should be sent to the SMTP-sender. The "From:" field should stay as the original author. If a message is expandet by successive sublists, each sublist should change SMTP-sender to the latest sublist maintainer. There is one problem with this. In an old, today mostly discarded, protocol used in BITNET, there was no SMTP information, only RFC822 information. But this old protocol is not used very much in BITNET now, BSMTP is used instead.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Sep 89 13:51:22 EDT Received: from tis.llnl.gov by mintaka.lcs.mit.edu id aa22644; 29 Sep 89 6:26 EDT Return-Path: Received: by tis.llnl.gov (4.0/1.14.5-TIS) id AA08251; Fri, 29 Sep 89 02:39:56 PDT Message-Id: <8909290939.AA08251@tis.llnl.gov> Date: Fri, 29 Sep 89 02:39:54 -0800 From: Tim Kehres Subject: Mailing List Software To: Header People Distribution List A week or so back I volunteered some software to assist with the modification of header fields when processing mailing lists with sendmail. Since that time I have received several requests for this code. I still have about one week of cleanup (writing a man page and cleaning up the M4 macros that go with it) prior to being able to distribute the code. Unfortunately, I will not be available to do this cleanup until after I return to the States in late October (I leave Tokyo tomorrow for approx 3 1/2 weeks). I am currently anticipating that the code will be available near the first of November, at which time I will send a message indicating how the code can be obtained. Regards, Tim Kehres  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Oct 89 21:51:15 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19686; 11 Oct 89 21:14 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA12095; Wed, 11 Oct 89 21:12:01 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Oct 89 00:30:59 GMT From: Jon Boede Organization: The People's Republic of Austin, Texas Subject: Date -> time(2) Message-Id: <19481@ut-emx.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Rather than re-invent the wheel, I'm looking for a piece of code that converts the Date field of messages into a nice time(2) style long integer that my C program can use. The messages envelopes on the other side of a gateway I'm in charge of use a long instead of the ASCII date -- currently we're using the date the letter arrived at the gateway as the "Date:" which, given the speed of most Internet letters, is pretty good... but, not always. The variety among Date: lines is even more frightening than From: lines. :-) If anyone has a piece of code written, please mail me. If anyone WANTS this code, mail me as well... I'll have to write it if I don't get somebody else's, and I'll be happy to re-distribute. Please mail to jon@bodedo.ucm.org as I hardly ever get a chance to read news these days (sigh). Thanks! -- - - - - - - - - - - Jon Boede jon@bodedo.ucm.org 7117 Wood Hollow #726 ...!{uunet,texbell}!cs.utexas.edu!bodedo!jon Austin, TX 78731-2548 +1 512 346-3142 "People who are incapable of making decisions are the ones that hit those barrels at freeway exits"  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Oct 89 15:48:28 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa04377; 12 Oct 89 15:45 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA00563; Thu, 12 Oct 89 14:29:01 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Oct 89 15:42:52 GMT From: Henry Spencer Organization: U of Toronto Zoology Subject: Re: Date -> time(2) Message-Id: <1989Oct12.154252.23144@utzoo.uucp> References: <19481@ut-emx.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <19481@ut-emx.UUCP> jon@walt.cc.utexas.edu (Jon Boede) writes: >Rather than re-invent the wheel, I'm looking for a piece of code that converts >the Date field of messages into a nice time(2) style long integer that my C >program can use... Check out the getdate() function, shipped with most versions of news software. It's the de-facto standard for such things. It is not perfect, but pretty good. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Oct 89 16:09:24 EDT Received: from mcs.nlm.nih.gov by mintaka.lcs.mit.edu id aa21503; 13 Oct 89 16:03 EDT Received: from ncbi.nlm.nih.gov by mcs.nlm.nih.gov (5.59/1.14) id AA10006; Fri, 13 Oct 89 16:04:24 EDT Received: by tech.nlm.nih.gov (4.0/SMI-4.0) id AA07572; Fri, 13 Oct 89 16:05:11 EDT Date: Fri, 13 Oct 1989 16:05:10 EDT From: Peter Karp To: header-people@mc.lcs.mit.edu Subject: mail servers Message-Id: I'm looking for information on mail server programs -- the kind of program that can process queries from people via mail. For example, I might mail a message to such a program asking it to send me a piece of software. If you know of such a server that I can get hold of, that runs under Unix, please let me know. Peter  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Oct 89 23:29:44 EDT Received: from MIT.MIT.EDU by mintaka.lcs.mit.edu id aa26809; 13 Oct 89 23:20 EDT Received: from STL-07SIMA.ARMY.MIL by MIT.EDU with SMTP id AA10416; Fri, 13 Oct 89 23:19:59 EDT Message-Id: <8910140319.AA10416@MIT.EDU> Date: Fri, 13 Oct 89 22:21:50 CDT From: Rich Zellich To: Peter Karp Cc: header-people@MC.lcs.mit.edu Subject: Re: mail servers If nothing else, under Unix you can easily put together a combination of shell scripts and optionally a small program to unpack file-names from message bodies, put the requested file in the body of an outgoing message, and send it back to the requestor. I did just that here, before we got all our machines hooked together on an Ethernet, and it worked just fine; it would even understand requests for Internet-resident files, FTP them onto the gateway machine, and then mail them internally to the requestor (I had a setup requiring a dedicated "ftpmail" account on each of our machines, but with MMDF it's not really necessary since I can specify a filter to pick out mail with certain Subject entries and route them to a server from any account). I can send you what I did if you want, but it's really pretty trivial. Cheers, Rich  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Oct 89 14:24:55 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03337; 21 Oct 89 14:19 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA13430; Sat, 21 Oct 89 12:37:06 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 20 Oct 89 18:33:45 GMT From: Ed Wright Organization: 10*E12 Dyne & Zehn and The Art of ATE Subject: ForSale Shaved Ice Sno Cone Machine and Supplies Message-Id: <1864@zehntel.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Please reply to this posting by Phone directly to: Mohammed H. Kahn Home 408 227 1936 Work 415 966 2560 mail replies (via this acct) will NOT reach the seller For Sale Swan SI-100 Shaved Ice Machine. All accessories included such as spare blades, foot pedal, plastic syrup bottles, amber/black pour spouts. Paid over $1300.00 for the machine and used for only three months. Asking $895.00 and will include over $1000.00 (at retail) worth of syrups to go with machine. This is a high profit margin item. Approx Size 36" high, 12" wide, 12" deep, Weight 70LBS To answer ALL your questions: What color is it, Why is it being sold, When can I make a sample sno cone, How will I get it, Can you ship it, will he dicker on the price why is the sky blue? Beats me ! I have never seen it! Call Mohammed At The number(s) above Mohammed is an aquaintance, seems like a nice enough guy, and I am posting this as a favor. My only research was to validate that he does not sell stuff for a living. ie I assured myself that this is personal property, and not a business venture. Tha tha tha thats all folks UUCP Path ucbvax or sun or varian !zehntel!edw KA9AHQ Life Is Hard .... Can't get to heaven on roller skates, Can't take a taxicab to Timbuktu. ... Timbuk3  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Oct 89 19:24:26 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05465; 21 Oct 89 19:16 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA20410; Sat, 21 Oct 89 19:15:54 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 21 Oct 89 08:05:28 GMT From: "John R. Galloway Jr." Organization: Galloway Research Subject: Unix/X/DOS/MS-Windows computer system for sale Message-Id: <35810@apple.Apple.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu UNIX/DOS Computer System For Sale John Galloway (408) 259-2490 An AT with coprocesor running Unix V.3 with the X Window system and Microsoft Windows on a 19" monchrome screen at 58% off current (good i.e. Frys) retail (let alone what I paid a couple of years ago :-) current retail guess 55% Discount $800 $360 Wells America 8Mhz AT clone with 1Mbyte on board, 1.2 MB 5.25" floppy & flpy/HD ctlr $575 $259 Segate ST4096, 80 Meg (formated) internal winchester $35 $16 second serial port $120 $54 Logiterch 3 button mouse $250 $113 Idea Associates monochrome/CGA/serial/parallel/clock $150 $68 Hyundai amber monitor, 2 keyboards (pc and AT styles) $800 $360 Everex internal 60MB cartridge tape (incl backup software) $570 $257 18 DC300A and 12 DC600A cartridges for above drive $50 $23 DOS 3.1 $150 $75 Speed store disk format and diagnostic utility ----- ----- $3724 $1575 AT clone with hard disk and tape HW & SW total 65% discount $5500 $1925 Opus 220-8 coprocessor, NSC 32332 15Mhz CPU, MMU, & FPU, and 8 Mbytes (w parity) $450 $158 Unix Sys V.3 (+BSD utils) for Opus, uses AT for I/O processor with concurrent DOS usage $150 $53 AT&T Unix Prog ref, User ref, Prog guide, Sys Admin Ref & Sys Admin guide manuals. $450 $150 X 10.4 for Opus/Moniterm Viking-1 combination (I think X 11 is available from Opus) ----- ----- $6550 $2293 Unix Sys V.3 on 2 MIP, 8MBV coprocesor with X, HW & SW total 40% Discount $1600 $960 HP Laserjet II (512 KBytes, no font cartridges) & parallel cable $99 $59 Glyphix soft downloadable fonts for HP-LJII, (font generator)" $100 $60 Laser Control (various printer emulations for HP-LJII) ----- ----- $1799 $1079 Laser Printer HW & SW total 55% Discount $2100 $945 Moniterm Viking 1 (19" 1280x960x1, monitor & AT card with Hitachi GPU) $150 $68 MicroSoft Windows 2.1 (windows/286)) plus Moniterm Viking-1 driver $295 $133 MicroSoft Excel (for windows) ----- ----- $2545 $1145 Micro Soft Windows on 19" monitor HW & SW total ===== ===== $14394 $6092 GRAND TOTAL (68% discount overall!!) The system has worked flawlessly for between 1 and 3 years (depending on component). It is working now and you are welcome to stop by for a demo. Preferences will be given to a purchase of the entire system, follwed by complete groups with individual items as a last resort. Sale of the AT or Opus board is contingent on sale of the other (i.e. neither does me any good alone) Included are all cables, manuals and original packaging. Purchase of the entire system includes shipping/transportation & installation at your site (within 100 mile radius of San Jose). All offfers cheerfully discussed. -- apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Oct 89 23:20:54 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa00530; 22 Oct 89 17:16 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA03056; Sun, 22 Oct 89 09:12:53 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 21 Oct 89 22:48:27 GMT From: Ed Wright Organization: 10*E12 Dyne & Zehn and The Art of ATE Subject: Re: ForSale Shaved Ice Sno Cone Machine and Supplies Message-Id: <1873@zehntel.UUCP> References: <1864@zehntel.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I have been getting some interesting questions from the land of bitnet like what the *&%^ is this doing in header . people or mail . comp or whatever Whoever is the keeper of the gateway might want to look into this as thats not where stuff got posted. This groups below are a duplicate of the original header (just in case things are getting hosed along the way) ############################################################## ## Newsgroups: na.forsale,misc.forsale,ba.market,ca.wanted ## ############################################################## Its always nice when strange things happen :-) /2 Ed UUCP Path ucbvax or sun or varian !zehntel!edw KA9AHQ Life Is Hard .... Can't get to heaven on roller skates, Can't take a taxicab to Timbuktu. ... Timbuk3  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Oct 89 11:26:19 EDT Received: from ATHENA.MIT.EDU by mintaka.lcs.mit.edu id aa05665; 23 Oct 89 11:19 EDT Received: from PORTNOY.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA16229; Mon, 23 Oct 89 11:16:52 EDT Received: by PORTNOY.MIT.EDU (5.61/4.7) id AA23950; Mon, 23 Oct 89 11:16:26 -0400 Date: Mon, 23 Oct 89 11:16:26 -0400 From: Bill Sommerfeld Message-Id: <8910231516.AA23950@PORTNOY.MIT.EDU> To: rick@uunet.uu.net Cc: Erik Fair , usenet@bloom-beacon.mit.edu, header-people@MC.lcs.mit.edu In-Reply-To: Rick Adams's message of Sun, 22 Oct 89 22:57:22 -0400, <8910230257.AA04668@uunet.uu.net> Subject: header-people, used computers, Sno-Cones, and misdirected messages. Two messages have been gatewayed to header-people from apparantly random newsgroups (including misc.forsale) in the past couple of days. The reason why was fairly obvious if you look at one of articles in question while its still in the news system. <35810@apple.Apple.COM> was posted with the following newsgroups and distributions: Newsgroups: na.forsale,misc.forsale,ne.forsale,dc.forsale,pa.forsale Distribution: na Note the "na.forsale" newsgroup in the Newsgroups: line. Now, in our sys file, we find the following entry for the news->mail gateway software for header-people/comp.mail.headers; this is the first entry with system name "INTERNET" (the pseudo-system for mail gatewaying). INTERNET:comp,!comp.all,comp.mail.headers,!comp.mail.headers.all,world,inet,ddn!ddn.all,na,usa\ :S:/usr/lib/news/gateway header-people header-people header-people-requs Note that there isn't an "!na.all", because we were under the delusion that "na" names a Distribution, not a Newsgroup Hierarchy, and we don't have any "na.*" newsgroups on Beacon. Fortunately, rnews doesn't push the article through more than one sys file entry for a given name, or else we would have sent ads for sno-cone machines to all the mailing lists we gateway.. Erik: I made the following change to `macros.m4' in our mail-news gateway setup to fix this: *** macros.m4 Thu Apr 7 03:06:09 1988 --- macros.m4.new Mon Oct 23 10:43:56 1989 *************** *** 94,100 **** define(TOP,{substr($1,0,index($1,.))}) define(DIST,{$1,!$1.all}) define(GRP,{DIST(TOP($1)),DIST($1)}) ! define(STDDIST,{DEFDIST,inet,DIST(ddn),na,usa}) define(GROUPLIST,{GRP($1),STDDIST}) define(SYSFILE,{PSEUDO:GROUPLIST($1):S:MAILER $2 $3 $4 $5}) --- 94,100 ---- define(TOP,{substr($1,0,index($1,.))}) define(DIST,{$1,!$1.all}) define(GRP,{DIST(TOP($1)),DIST($1)}) ! define(STDDIST,{DEFDIST,DIST(inet),DIST(ddn),DIST(na),DIST(usa)}) define(GROUPLIST,{GRP($1),STDDIST}) define(SYSFILE,{PSEUDO:GROUPLIST($1):S:MAILER $2 $3 $4 $5}) - Bill  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Oct 89 11:26:34 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05705; 23 Oct 89 11:21 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21907; Mon, 23 Oct 89 10:58:53 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 23 Oct 89 14:57:23 GMT From: Bill Sommerfeld Organization: /mit/wesommer/.organization Subject: This is a test. Message-Id: Sender: header-people-request@MC.lcs.mit.edu To: header-people@MC.lcs.mit.edu If my hunch is correct, this will wind up on header-people If you're reading this on header-people, sorry for the noise; this will be corrected shortly. In any case, DO NOT REPLY TO THIS MESSAGE. Thanks for your patience. - Bill -- Henry Spencer is so much of a | Bill Sommerfeld at MIT/Project Athena minimalist that I often forget | sommerfeld@mit.edu he's there - anonymous |  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Oct 89 11:26:41 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05707; 23 Oct 89 11:21 EDT Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22044; Mon, 23 Oct 89 11:05:14 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 23 Oct 89 15:03:26 GMT From: Bill Sommerfeld Organization: /mit/wesommer/.organization Subject: This is a second test. Message-Id: Sender: header-people-request@MC.lcs.mit.edu To: header-people@MC.lcs.mit.edu This should *NOT* wind up in header-people. Sorry for filling up people's junk groups.. - Bill -- Henry Spencer is so much of a | Bill Sommerfeld at MIT/Project Athena minimalist that I often forget | sommerfeld@mit.edu he's there - anonymous |  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Oct 89 18:26:06 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25593; 29 Oct 89 18:22 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA29671; Sun, 29 Oct 89 18:17:25 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 29 Oct 89 23:05:58 GMT From: Michael DeCorte Organization: Clarkson University, Potsdam NY Subject: Precedence: field Message-Id: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Under Unix there is a program called vacation. It is used to reply to incoming mail if you are on vacation. In the documentation it says that it won't reply to mail containing the header lines: Precedence: junk or Precedence: bulk (The idea is that mail from newsgroups would contain this field) The 'Precedence' field is not mentained in RFC822 but it seems useful and I want to use it (I maintain a BIG archive-server you see). Now I have found that many mailers get a bit upset if they see this little field. So, the question is: How do I get this field to work or is this a little bit of nonsence made up by the author of vacation who didn't bother to read RFC-822 and he should have used 'X-Precedence:'? -- Michael DeCorte // H215-546-0497 W386-8164 Fax386-8252 // mrd@clutx.bitnet 2300 Naudain St. "H", Phil, PA 19146 // mrd@sun.soe.clarkson.edu --------------------------------------------------------------------------- Clarkson Archive Server // commands = help, index, send, path archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ---------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Oct 89 20:59:07 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28894; 29 Oct 89 20:52 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01195; Sun, 29 Oct 89 20:37:32 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 30 Oct 89 01:29:05 GMT From: Jeff Beadles Organization: Tektronix, Inc., Wilsonville, OR Subject: Re: Precedence: field Message-Id: <5156@orca.WV.TEK.COM> References: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article mrd@sun.soe.clarkson.edu (Michael DeCorte) writes: | |Under Unix there is a program called vacation. It is used to reply |to incoming mail if you are on vacation. In the documentation it says |that it won't reply to mail containing the header lines: | |Precedence: junk |or |Precedence: bulk | |(The idea is that mail from newsgroups would contain this field) |The 'Precedence' field is not mentained in RFC822 but it seems useful |and I want to use it (I maintain a BIG archive-server you see). Now |I have found that many mailers get a bit upset if they see this little |field. | |So, the question is: How do I get this field to work or is this a |little bit of nonsence made up by the author of vacation who didn't |bother to read RFC-822 and he should have used 'X-Precedence:'? Well, it's not vacation's fault. Sendmail uses the precedence field. As I recall, there are a few "default" values that can be used. For example, if I say "Precidence: bulk" in my message, and it's sent to a site that can not deal with it, (unknown/no such user) it should silently trashcan the message, and not bounce it back to me. I've been running with this on the rc-cars mailing list for some time now, with NO bounced messages that I know of. (Unless the site trashcans it, then that's ok :-) -Jeff -- Jeff Beadles Utek Engineering, Tektronix Inc. jeff@quark.WV.TEK.COM Maintainer of rc-cars mailing list. Requests to rc-cars-request@quark.wv.tek.com  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Oct 89 09:59:53 EST Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa25959; 30 Oct 89 9:52 EST Return-Path: Received: from Underprize.Think.COM by Think.COM; Mon, 30 Oct 89 09:53:45 -0500 Received: by underprize.think.com; Mon, 30 Oct 89 09:48:53 EST Date: Mon, 30 Oct 89 09:48:53 EST Message-Id: <8910301448.AA22109@underprize.think.com> From: "Robert L. Krawitz" Sender: rlk@think.com To: header-people@mc.lcs.mit.edu In-Reply-To: Subject: Precedence: field Date: 29 Oct 89 23:05:58 GMT From: Michael DeCorte Under Unix there is a program called vacation. It is used to reply to incoming mail if you are on vacation. In the documentation it says that it won't reply to mail containing the header lines: Precedence: junk or Precedence: bulk So that's why I never have problems with vacation mail bouncing back to me (owner-info-nets). Sometimes I wish mailers would respect that in general and not send certain types of bounce mail back at all, like postal third-class mail, where forwarding addresses are not reported. I've never even read the man page on vacation, since I refuse to use it even when I am on vacation. (The idea is that mail from newsgroups would contain this field) The 'Precedence' field is not mentained in RFC822 but it seems useful and I want to use it (I maintain a BIG archive-server you see). Now I have found that many mailers get a bit upset if they see this little field. What mailers? I`ve never had anything complain. The only mailer that's ever barfed at me is the Symbolics user agent, which refuses to allow ANY nonstandard headers, even those prefixed by X-, unless you do something nasty to the mailer to start with. Of course, there are always those mailers that send "comments" back to me every time a non-compliant address passes through them. Those are incredibly annoying, but fortunately few and far between. So, the question is: How do I get this field to work or is this a little bit of nonsence made up by the author of vacation who didn't bother to read RFC-822 and he should have used 'X-Precedence:'? RFC822 page 25 states that users are free to define and add additional header fields, but that unless they begin with 'X-' they may be pre-empted by future standards. I assume that that means that you're free to use precedence: as you see fit, but that its meaning is not presently standardized although it may be in the future. X-precedence doesn't avoid the problem of non-standardization; the only difference with that name is that it can never be standardized. Of course, another mailer is free to do as it pleases with the additional header, and that includes bouncing it back to you, although that sounds like a rather pedantic over-reaction. Given that sendmail and vacation respect precedence: fields, and use them fairly wisely (sendmail reduces the priority of junk mail and increases the priority of special delivery mail), I recommend that you continue to use precedences in your mailing list mail. ames >>>>>>>>> | Robert Krawitz 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Nov 89 12:52:12 EST From: Rob Austein Sender: sra@MINTAKA.lcs.mit.edu To: Michael DeCorte In-reply-to: mrd@sun.soe.clarkson.edu's message of 29 Oct 89 23:05:58 GMT Subject: Precedence: field CC: Header-People@mc.lcs.mit.edu Date: Wed, 1 Nov 89 12:24:58 EST Message-ID: <8911011225.aa02675@mintaka.lcs.mit.edu> The "Precedence:" field is not defined by the standard (more precisely, it's what RFC822 calls a "user-defined-field"), and falls under the so-called "local rights" clause: Vacation is within its rights to do whatever it wants to do based on the "Precedence:" field, including replying to certain messages based on its value. Sendmail is within its rights to do whatever it wants to do based on the "Precedence:" field, including discarding certain messages based its value. Other mailers are within their rights to do whatever they want to do based on the "Precedence:" field, including bouncing certain messages based on its existance. Anybody sending messages with "Precedence:" headers is violating the "be conservative in what you send, liberal in what you accept" dictum. In practice there are so many people using random user-defined-fields ("Favorite-Beer:", "Zippy-Says:" ...) that bouncing messages because they contain one seems pretty silly, but it's not a crime. User-defined-fields should be used only between consenting adults. If the authors of the vacation and sendmail programs had used "X-Precedence:" instead of "Precedence:" it would not have changed this situation in any material way; all that the "X-" prefix does is guarantee that nobody will will ever be allowed to standardize "X-Precedence:" while, in theory, somebody could come along and standardize "Precedence:", possibly with different semantics than those used by sendmail and vacation. --Rob Austein  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Nov 89 04:30:14 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa10723; 2 Nov 89 4:26 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8513; Thu, 02 Nov 89 04:25:31 EST Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 5078; Thu, 02 Nov 89 04:25:31 EST Received: from ODEN by brage.qz.se; Thu, 2 Nov 89 10:23 +0100 Date: 02 Nov 89 09:07 +0100 From: Jacob Palme QZ Subject: Precedence: field To: header-people Reply-to: Jacob Palme QZ Message-ID: <460994@QZCOM> In-Reply-To: <8910301448.AA22109@underprize.think.com> The X.400 recommendation has facilities like "supression of non-delivery notifications" to get similar results.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Nov 89 04:30:19 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa10724; 2 Nov 89 4:26 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8514; Thu, 02 Nov 89 04:25:34 EST Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 5080; Thu, 02 Nov 89 04:25:33 EST Received: from ODEN by brage.qz.se; Thu, 2 Nov 89 10:22 +0100 Date: 02 Nov 89 09:04 +0100 From: Jacob Palme QZ Subject: - To: header-people Reply-to: Jacob Palme QZ Message-ID: <460992@QZCOM> In-Reply-To: <8910292359.AA13296@qzuno.qz.se> If you want to include undocumented fields, like the Precedence field, in headers, my advice is to put it last of the lines in the RFC822 header lines. Some mail programs quit processing the RFC822 header at the first un-understandable line in it.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Dec 89 13:21:02 EST Received: from IU.AI.SRI.COM by mintaka.lcs.mit.edu id aa28606; 4 Dec 89 13:16 EST Date: Mon 4 Dec 89 10:15:14-PST From: Peter Karp Subject: [barmar@THINK.COM: Inferior Lisp mode conflicts with] To: header-people@mc.lcs.mit.edu Message-ID: <628798514.750000.PKARP@IU.AI.SRI.COM> Mail-System-Version: The following message illustrates an interesting problem in Internet mailing lists. Someone at Buffalo has subscribed an account there to a number of different mailing lists, and then set mail forwarding on that account to the INFO-VAX mailing list, thereby forwarding many different mailing lists to INFO-VAX (it appears thus far that the person has not subscribed to INFO-VAX!). (This happened about a week ago, and the system administrator at Buffalo disabled the account, but now it's happening again; I've sent a note to the administrator). My question is: what automatic methods could be used to detect such actions (which could even happen unintentionally)? For example, mailing list expanders might insert header lines such as "Redistribute: No" in outgoing messages, and then refuse to redistribute incoming messages containing this header. Other ideas? Peter --------------- Return-Path: <@Gizmo.SRI.COM:RELAY-INFO-VAX@CRVAX.SRI.COM> Received: from Gizmo.SRI.COM by IU.AI.SRI.COM via SMTP with TCP; Mon, 4 Dec 89 04:01:14-PST Received: From ubvmsc.cc.buffalo.edu ([128.205.2.8]) by CRVAX.SRI.COM with TCP; Mon, 4 DEC 89 03:23:07 PDT Received: from PUCC.PRINCETON.EDU by UBVMS.BITNET; Mon, 4 Dec 89 06:20 EST Received: by PUCC (Mailer R2.06X) id 1586; Mon, 04 Dec 89 06:17:31 EST Date: Mon, 4 Dec 89 02:46:44 EST From: barmar@THINK.COM Subject: Inferior Lisp mode conflicts with Shell mode Sender: Gnu-Emacs bugs & info To: Tao Uwang X-VMS-To: Tao Uwang Reply-to: barmar@THINK.COM Resent-date: Mon, 4 Dec 89 06:20 EST Resent-to: INFO-VAX@SRI.COM Comments: To: bug-gnu-emacs@prep.ai.mit.edu Comments: cc: bug-gmacs@think.com In GNU Emacs 18.52.25... Setting some key bindings in inferior-lisp-mode-map causes those same keys to be bound in shell-mode-map. It happens whenever you rebind a multi-key sequence whose default value is copied from Shell mode (e.g. c-c c-z). The cause is that inferior-lisp-mode-map is initialized to be (copy-alist shell-mode-map). This only copies two levels of the tree structure of the sparse keymap. The second-level alists, which are used for dispatching after a prefix key, are shared by both keymaps. When rebinding a key that is already bound in the keymap the shared cons is RPLACDed, affecting both keymaps. Instead of using copy-alist, it should be using copy-keymap, so that all levels of the keymap are copied. barmar ------- -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Dec 89 13:04:21 EST Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa07047; 8 Dec 89 12:59 EST Return-Path: Received: from Underprize.Think.COM by Think.COM; Fri, 8 Dec 89 13:00:20 -0500 Received: by underprize.think.com; Fri, 8 Dec 89 12:55:34 EST Date: Fri, 8 Dec 89 12:55:34 EST Message-Id: <8912081755.AA28834@underprize.think.com> From: "Robert L. Krawitz" Sender: rlk@think.com To: header-people@MC.lcs.mit.edu, info-nets@think.com Subject: [MAILER-DAEMON@Think.COM: Returned mail: User unknown] I'm amazed. There are still people living in the dark ages out there... ames >>>>>>>>> | Robert Krawitz 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111 Date: Fri, 8 Dec 89 12:53:43 -0500 From: Mail Delivery Subsystem Subject: Returned mail: User unknown To: ----- Transcript of session follows ----- >>> RCPT To: <<< 550 User "postmaster" Unknown. 550 ... User unknown  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Dec 89 16:31:39 EST Received: from BBN.COM by mintaka.lcs.mit.edu id aa13639; 13 Dec 89 16:14 EST From: Jack Haverty Subject: Re: [barmar@THINK.COM: Inferior Lisp mode conflicts with] To: PKARP@iu.ai.sri.com Cc: haverty@bbn.com, header-people@mc.lcs.mit.edu In-Reply-To: <628798514.750000.PKARP@IU.AI.SRI.COM> Date: Wed, 13 Dec 89 15:53:44 EDT Mail-System-Version: Message-ID: <8912131614.aa13639@mintaka.lcs.mit.edu> I think I remember that one of the original reasons for insisting on a Message-id field in a message was to permit the implementation of mail handling software which could be resilient in situations such as 'loops' in mail distribution. For example, a host receiving a message could compare it's ID against a list of the IDs of messages it has received recently, and cull duplicates; this would prevent loops and also reduce the number of multiple copies a user receives, e.g., when you reply to a message which includes a list of which you are a member. Of course, how successful such a scheme is depends on the host's choice of "recently", but that is a local argument to have. This wouldn't permit configuration problems where a mailing list is forwarded to another mailing list, but I don't think a new field would either. The problem is that the user is setting the configuration to do something which is presumably not having the desired result. My vote for a new mechanism would be a mail-list management tool that simply says things like "All mail on the XXX list will be forwarded automatically to 7683 users on 4 continents. Is that what you intended?" I'd be curious to hear if any software out there actually uses the message-id field in any way. There were lots of notions flying around in the 70s, e.g., "threading" a sequence of replies by tracking message-ids and "in-reply-to". Anybody do anything with message ids? Jack  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Dec 89 19:25:19 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa16312; 13 Dec 89 19:19 EST Received: by ifi.uio.no (5.61++/1.15) id AA21968; Thu, 14 Dec 89 01:17:03 +0100 Date: Thu, 14 Dec 89 01:17:03 +0100 Message-Id: <8912140017.AA21968@ifi.uio.no> From: Erik Naggum Sender: enag@ifi.uio.no To: Jack Haverty Cc: PKARP@iu.ai.sri.com, haverty@bbn.com, header-people@mc.lcs.mit.edu In-Reply-To: <8912131614.aa13639@mintaka.lcs.mit.edu> "Jack Haverty " Subject: [barmar@THINK.COM: Inferior Lisp mode conflicts with] I seem to just have gotten my subscription working again due to problems at what was perceived as a safe relay point. Anyway, Jack asks about software that uses the Message-ID field. Mine does. I use the Reference field in USENET, too. I can review the message that something is a reply to, IFF the message has a properly used In-Reply-To field, and I also let my mailer strip out quotes (excerpts) from the replied-to message and store them in a special space-conserving way (#Q@) to refer to that line in the replied-to message. Messages quoted in this way are also flagged, so as not to delete them. Copies of my own messages are also flagged as answered when I get replies. This also works for USENET news, but based on the Reference field instead. (With NNTP this works great except for expired messages. That problems remains to be solved.) I have not found many systems who consistently use Message-IDs, and some users insist on reformatting quoted text, anyway. There is also a lot of software which disobeys the syntax rules for the In-Reply-To field, and even some PC-based network news software which uses unquoted `[' and `]' in the message-id. (The authors thought they were true to RFC 1036, but had "forgotten" about the explicit references to RFC 822 as the superior RFC when in conflict.) I don't know the context of this discussion, but if you are about to discourage the use of Message-IDs in general, I think that there is no reason to do so, even if you do not want to insert your own. Oh, one more thing. I use Message-IDs to request mail, from the sender, that lost for some reason. Most people are totally unable to find a message by this unique id. I also use Message-IDs in the specified accounts I send to my network's (uu.no) users when I bill them their share of the costs. Some of these use them to check against their own logs, for forgeries or other mishaps. While on the topic, let me throw in a little discussion on the format of Message-IDs. Sendmail's verbose is too long. I am trying a shorter one , where jjj is the day of the year (Julian date) and mmmm is the number of the message that day. Beta-test users note that it is easier to recognize and use when it's short and readable. Some software insists on total garbage in the local-part field, which I dislike intensely. Prominent hosts like A.ISI.EDU (or some prominent users, maybe) also use formats like <[A.ISI.EDU].verbose-date.USER> with no `@'-sign in it at all. I once got across a piece of software which rewrote Message-IDs the way it rewrote addresses, tacking on "@domainname" and making the other `@' a `%'... --Erik  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 08:22:52 EST Received: from ACF6.NYU.EDU by mintaka.lcs.mit.edu id aa20168; 14 Dec 89 0:07 EST Date: Thu, 14 Dec 1989 0:06:03 EST From: Stephen Tihor Message-Id: <891214000603.34a03825@ACF6.NYU.EDU> Subject: A sad comentary To: header-people@mc.lcs.mit.edu X-Vmsmail-To: IN%"header-people@mc.lcs.mit.edu" From: BITNET%"ned@YMIR.BITNET" "Ned Freed, Postmaster" 13-DEC-1989 23:31:12.31 To: CSERH000@KENTVMS.BITNET, INFO-PMDF@YMIR.BITNET CC: Subj: RE: Question about implementing a BITNET -> Internet gateway Received: From YMIR(POSTMAST) by NYUACF7 with Jnet id 8241 for TIHOR@NYUACF; Wed, 13 Dec 89 23:31 EST Received: from HMCVAX.BITNET by YMIR.BITNET; Wed, 13 Dec 89 16:56 PST Resent-date: Wed, 13 Dec 89 17:00 PST Date: Wed, 13 Dec 89 16:55 PST From: "Ned Freed, Postmaster" Subject: RE: Question about implementing a BITNET -> Internet gateway Resent-to: INFO-PMDF-LIST2@YMIR.BITNET To: CSERH000@KENTVMS.BITNET, INFO-PMDF@YMIR.BITNET Errors-to: postmast@YMIR.BITNET Resent-message-id: <0CAB5FE026BF600D2C@YMIR.BITNET> Message-id: <0CADBF2E6D5F20011F@HMCVAX.BITNET> X-Envelope-to: TIHOR@NYUACF.BITNET X-VMS-To: IN%"CSERH000@KENTVMS.BITNET" X-VMS-Cc: IPMDF Leo Holmberg writes: > I am sending this to you, rather than to the list, because I'm not sure that > is a PMDF issue; it might just represent my lack ok knowledge of Internet > mail. Feel free to post it, if you think it relates to PMDF... > During the last 2 months, we have had a user here, who was flooding BITNET > with mailings for a China News digest. He was sending to about 2000 > subscribers, and due to the topology here, in the state of Ohio, all his > messages were clogging up the machine, that serves as the focus for most > of the BITNET trafic in the state. About half his messages were destined for > Internet addresses, and these were being sent to Cornell, as our Internet- > BITNET gateway. I therfore decided to try and implement a BITNET -> Internet > gateway here on KENTVMS.BITNET, using PMDF. > Well, to make a long story short, it was fairly easy to do. I had one problem , > getting PMDF to act as the local mail delivery agent. I sent out a message to > the list, and got a reply from some guy at APPSTATE, who informed me my error > was probably in my definition of channel L (it was). I had the IBM mailer here , > (on KENTVM) point to me as Interbit, and it's been working OK, for a couple of > weeks or so. > Now yesterday morning, I found the following in my mail.... > > Note the attached header. I'm not an expert, but it appears that this > > mail was routed to the Internet without any indication of the gateway, > > leaving the From: address as 'user@node.bitnet'. > > Isn't this a violation of some Internet policy? I know it confuses our > > mailer, which has never heard of domains such as '___.uucp' or '___.bitnet'! > > Ric Nauen > > > From: PETER HORWITZ > Is he complaining because the return is HOROWITZ@KENTVM.BITNET? Have I set > something up wrong. Currently, the machine KENTVM.BITNET does not have an > Internet addresss, so what else could it be? Am I violating Internet policy? > We haven't registered the domain yet with BITNIC, but we had planned on doing > at some point in the future? Can you advise? Thanks in advance...Leo This is a very interesting and complex issue. I have received a couple of messages about it in the past few days, so I thought it was time to post something to info-pmdf. Let's deal with the "violation of some Internet policy" part first. I've looked through the various standards, and it seems to me (as well as several other people I've corresponded with about this) that the relevant information is in RFC1123 (Internet host requirements, and in particular, the requirements for gatewaying mail messages): > (D) The gateway MUST ensure that all header fields of a > message that it forwards into the Internet meet the > requirements for Internet mail. In particular, all > addresses in "From:", "To:", "Cc:", etc., fields must be > transformed (if necessary) to satisfy RFC-822 syntax, and > they must be effective and useful for sending replies. The "requirements for Internet mail" are not spelled out anywhere else I can find, so this little paragraph seems to be the definitive source of information on the subject. HORWITZ@KENTVM.BITNET is certainly syntactically correct. So the remaining requirement is that the address is "effective and useful". And that's a matter of opinion. I think .BITNET is a useful address form. You may not, but so what? Any reasonable mailer can be told to route anything that ends in .BITNET to the closest Internet-BITNET gateway. So the address is "effective" (again in my opinion). So I don't think a case can be made for this being a violation of Internet policy. It is, however, typical to see people claiming that something is a violation without ever having checked to see if it is true or not. (Ric Nauen is nice about it, at least. Most messages I've seen of this type have been much uglier.) But this leaves open the issue of "is it a good idea to emit .BITNET addresses on the Internet?" My feeling (and this is only my opinion) is that it is a good idea to avoid it when there's an acceptable substitute available. In this particular case, I'd recommend registering your domain, selecting a domain-style name for your systems, and using those addresses whenever possible (I would continue to use .BITNET style addresses on BITNET until your domain definitions percolate around BITNET). I draw the line at source routes, however. Source routes are (still) strongly discouraged (and this *does* have the status of an Internet policy). If the choice is between emitting a .BITNET address and using a source route, I'll take the .BITNET address every time. My interpretation of the Internet host requirements seem to support this view. But on the practical side, I always come back to the fact that practically any mailer can be told how to handle .BITNET addresses with a simple configuration change, while many mailers are fundamentally broken when it comes to source routes and cannot be fixed without substantial recoding that nobody is willing to do. No matter how I slice it, source routes lose when compared to defacto standard domain names. Ned  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 10:58:37 EST Received: from PO2.ANDREW.CMU.EDU by mintaka.lcs.mit.edu id aa28465; 14 Dec 89 10:53 EST Received: by po2.andrew.cmu.edu (5.54/3.15) id for header-people@mc.lcs.mit.edu; Thu, 14 Dec 89 10:49:16 EST Received: via switchmail; Thu, 14 Dec 89 10:49:03 -0500 (EST) Received: from apollo.andrew.cmu.edu via qmail ID ; Thu, 14 Dec 89 10:46:19 -0500 (EST) Received: from apollo.andrew.cmu.edu via qmail ID ; Thu, 14 Dec 89 10:46:06 -0500 (EST) Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.andrew.cmu.edu.rt.r3 via MS.5.6.apollo.andrew.cmu.edu.rt_r3; Thu, 14 Dec 89 10:46:05 -0500 (EST) Message-Id: Date: Thu, 14 Dec 89 10:46:05 -0500 (EST) From: "Craig F. Everhart" To: header-people@mc.lcs.mit.edu, Erik Naggum Subject: Re: [barmar@THINK.COM: Inferior Lisp mode conflicts with] Cc: PKARP@iu.ai.sri.com, haverty@bbn.com, header-people@mc.lcs.mit.edu, @bellcore.com:nsb@thumper, Jonathan Rosenberg , "Craig F. Everhart" MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu In-Reply-To: <8912140017.AA21968@ifi.uio.no> References: <8912140017.AA21968@ifi.uio.no> You betcha we use Message-IDs (and their cousins, In-reply-to and References). I. Eliminate duplicate deliveries. We use 'em to eliminate mail forwarding loops by keeping a mostly-correct database on the local disks of our post-office machines, containing (key, value) pairs like: ( key=(message-id, recipient-addr); value=(timestamp, return-path, ``for'' information) ) That is, whenever a PO machine delivers mail, it records the message-id of the message and the recipient-addr to which it was delivered. (This neatly handles the problems of receiving the same message multiple times, but for different recipients each time--usually routed by diverse mail forwardings.) We eliminate old entries (over four days old) by reading the whole database and deleting every entry whose ``timestamp'' makes it uninteresting. The return-path and ``for'' information (e.g. that in a Received: header--in our case, what mail forwardings are currently being expanded) are useful inclusions in the status-report message that we generate for the local administrator. Every message we send off-site, or to any forwarding mechanism, has a Message-ID (or a ReSent-Message-ID, if appropriate), even if the delivery system has to invent one and add it. This is strictly necessary if the mechanism is to eliminate problems from mail forwarding loops, which are awfully common here since there are lots of different mechanisms by which users set their own forwarding addresses; they all have different latencies before changes take effect. II. Duplicate elimination in folders The duplicate-elimination mechanism in the delivery system mentioned in I., above, works on each individual post office machine; four different machines serve the andrew.cmu.edu domain. (Putting the database on each local disk makes it cheap enough. It tolerates errors; mail is delivered even if it couldn't be noted in the database. The point to that database was to eliminate outright disasters of thousands of copies of the same piece of forwarded mail, not to eliminate the occasional duplicate.) In addition, lots of (local) mail is delivered straight from a workstation to a user's mailbox in the distributed file system. So, further duplicates are possible by all sorts of mechanisms. Our principal mail filing program does duplicate elimination within individual folders of messages, using the Message-ID field. Each folder has an index file, containing a fixed-width summary of each message in the folder. One field in each message summary is a 32-bit signature hash of the Message-ID field, which is used to find duplicates in a given database. (Yes, hash collisions are tolerated, because the full Message-ID field values are checked on hash equality.) It works great. III. In-reply-to and References fields. The same mail-filing program also maintains other indexed values, one for any principal In-reply-to/References field and one for a heuristically-based ``message thread'' identifier. Whenever messages are added to a folder, the mail-filing program tries to find the ``related'' messages by comparing hashes and texts of its Message-ID and In-reply-to fields with the comparable fields in all the existing messages in the folder. ``Related'' messages are, by definition, stored with the same message-thread identifier. IV. Complaints. Lots of software doesn't generate sensible Message-ID fields. I don't care how long such fields are, but apparently many Netnews implementations do. It's always a bear when you see Message-ID fields used as an advertisement for a mailer, where the same string is used for many messages, e.g.: Message-Id: Also, many Netnews implementations do case-folding on the local-part of Message-IDs, so when we try to compress lots of (to our minds, necessary) unique-ifying information into a short message-ID value using a case-sensitive base-64 digit basis, some sites discard information by case-folding 26 digits of our base-64 identifiers into 26 different ones. Well, enough flaming for now. Craig  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 11:44:38 EST Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa29256; 14 Dec 89 11:37 EST Received: by uunet.uu.net (5.61/1.14) id AA12168; Thu, 14 Dec 89 11:36:26 -0500 Date: Thu, 14 Dec 89 11:36:26 -0500 From: Rick Adams Message-Id: <8912141636.AA12168@uunet.uu.net> To: TIHOR@acf6.nyu.edu, header-people@mc.lcs.mit.edu Subject: Re: A sad comentary Despite your particular ideas about valid addresses, foo.bitnet is NOT a valid internet address. It never has been and I am quite sure that it never will be. The fact that some hosts can handle it does not change the fact that the internet gateway is OBLIGATED to change it into a valid internet domain (the usual cheap way to do this is to change user@site.bitnet into user%site.bitnet@internetgateway). The gateway is clearly, undeniably at fault and needs to be fixed. :p Your suggestion that the many thousands of internet hosts change their mailer to accept your invalid host.bitnet address is ludicrous. If you want to sent internet mail, you have to play by the internet rules. BITNET is not a valid top level domain.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 15:42:53 EST Received: from NYU.EDU by mintaka.lcs.mit.edu id aa03974; 14 Dec 89 15:30 EST Received: from ACF7.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34) id AA25675; Thu, 14 Dec 89 15:08:56 -0500 Date: 14 Dec 89 13:48 EST From: TIHOR@acf7.nyu.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: rick@uunet.uu.net MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: RE: A sad comentary Cc: header-people@MC.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Message-Id: <3484BDBAA.34C02303.1989@ACF7.ACF7.NYU.EDU.ARPA> In-Reply-To: Message of 14-DEC-1989 11:37:49 from rick@uunet.uu.net Rick, I happen to agree with you. But Ned raises a reasonable question: Why we all know the intention is for the right had side of everything in a SMTP address to be a domain name system resolvable name THAT REQUEUIRMENT DOES NOT SEEM TO BE WRITTEN DOWN ANYWHERE. I remember its discussion way back when but it does not see to have made it into even the host requirements document except eliptically. Thats no way to write standards. Please provide exact citation and quotation for why X.Y.Z must be a DNS name if the following addresses by the RFCs: <@A.B.C:user@X.Y.Z> <@A.B.C,@X.Y.Z:user@D.E.F> If you can you have refuted Ned's proactical arguements (and some other things people have been asserting I can rebut properly.) That will leave the "accept generously emit strictly" rule as justification for .BITNET. -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 16:06:39 EST Received: from NYU.EDU by mintaka.lcs.mit.edu id aa05965; 14 Dec 89 16:04 EST Received: from uunet.UU.NET by cmcl2.NYU.EDU (5.61/1.34) id AA27409; Thu, 14 Dec 89 16:03:26 -0500 Received: by uunet.uu.net (5.61/1.14) id AA29665; Thu, 14 Dec 89 16:02:13 -0500 Date: Thu, 14 Dec 89 16:02:13 -0500 From: Rick Adams Message-Id: <8912142102.AA29665@uunet.uu.net> To: TIHOR@acf7.nyu.edu Subject: RE: A sad comentary Cc: header-people@mc.lcs.mit.edu RFC822 clearly states that the domain-ref (the part to the right of the @) must be an "official name". RFC974 discusses how to route it. I have better things to do than waste my time searching the exact paragraphs.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 17:40:06 EST Received: from NYU.EDU by mintaka.lcs.mit.edu id aa12667; 14 Dec 89 17:36 EST Received: from CMCL1.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34) id AA29499; Thu, 14 Dec 89 17:35:11 -0500 Date: 14 Dec 89 17:11 EDT From: TIHOR@cmcl1.nyu.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: rick@uunet.uu.net MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: RE: A sad comentary Cc: header-people@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Message-Id: <3485E704B.00022376.1989@CMCL1.CMCL1.NYU.EDU.ARPA> In-Reply-To: Message of 14-DEC-1989 16:55:09 from rick@uunet.uu.net Thank you so much for your kind assistance. I appologize most humbly for lacking also myself the intelligence and copius time to locate the necessary citations to put such non-conforming mail things as X@Y.BITNET and <@A.B.C:TNEILAND@FALCON> on notice of their non-conformaty. I will send them your message. I am sure it will convince these people of the errors of their ways. -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Dec 89 17:40:15 EST Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa12705; 14 Dec 89 17:36 EST Posted-Date: Thu, 14 Dec 89 14:34:15 PST Message-Id: <8912142233.AA21198@venera.isi.edu> Received: from poneria.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 14 Dec 89 14:33:38 -0800 To: TIHOR@acf7.nyu.edu Cc: rick@uunet.uu.net, header-people@mc.lcs.mit.edu Reply-To: pvm@venera.isi.edu Subject: Re: A sad comentary In-Reply-To: Your message of 14 Dec 89 13:48:00 -0500. <3484BDBAA.34C02303.1989@ACF7.ACF7.NYU.EDU.ARPA> Date: Thu, 14 Dec 89 14:34:15 PST From: Paul Mockapetris The Host Requirements group intentionally avoided specifying mail gateway behaviour, the argument being that it was HOST requirements. You can check the SMTP section of RFC1123 in the RCPT command to find an envelope level DNS requirement. But all this is somewhat peripheral. These .BITNET addresses (and the like) are litter in the Internet mail system, and it didn't seem like there would be real interest in strict enforcement of littering laws, especially because it is usually just easier to clean up other's trash. paul  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 10:25:22 EST Received: from WS6.NNSC.NSF.NET by mintaka.lcs.mit.edu id aa06260; 15 Dec 89 10:09 EST To: TIHOR@acf7.nyu.edu cc: rick@uunet.uu.net cc: header-people@mc.lcs.mit.edu Subject: Where it says what's on the right of @ Date: Fri, 15 Dec 89 10:08:07 -0500 From: Craig Partridge Message-ID: <8912151009.aa06260@mintaka.lcs.mit.edu> A few places where Internet standards state the thing on the right of the @ sign needs to be a valid Internet domain. Section 5.2.18 of 1123 is particularly clear on this... RFC 1123 5.2.2 Canonicalization: RFC-821 Section 3.1 The domain names that a Sender-SMTP sends in MAIL and RCPT commands MUST have been "canonicalized," i.e., they must be fully-qualified principal names or domain literals, not nicknames or domain abbreviations. A canonicalized name either identifies a host directly or is an MX name; it cannot be a CNAME. ------ 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 Errors in formatting or parsing 822 addresses are unfortunately common. This section mentions only the most common errors. A User Agent MUST accept all valid RFC-822 address formats, and MUST NOT generate illegal address syntax. o A common error is to leave out the semicolon after a group identifier. o Some systems fail to fully-qualify domain names in messages they generate. The right-hand side of an "@" sign in a header address field MUST be a fully-qualified domain name. RFC 822 6.2.3. DOMAIN TERMS A domain-ref must be THE official name of a registry, network, or host. Craig  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Dec 89 13:48:59 EST Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa11445; 15 Dec 89 13:44 EST Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 15 Dec 89 10:42:53 -0800 Date: Fri, 15 Dec 89 10:43:52 PST From: postel@venera.isi.edu Posted-Date: Fri, 15 Dec 89 10:43:52 PST Message-Id: <8912151843.AA00326@bel.isi.edu> Received: by bel.isi.edu (4.0/4.0.3-4) id ; Fri, 15 Dec 89 10:43:52 PST To: header-people@mc.lcs.mit.edu, ietf-hosts@nnsc.nsf.net, info-pmdf%ymir.bitnet@cunyvm.cuny.edu Subject: Forwarding Mail into the Internet Cc: Braden@venera.isi.edu, NAHAJ@cc.utah.edu, Postel@venera.isi.edu, Tihor@acf7.nyu.edu, ned%ymir.bitnet@cunyvm.cuny.edu, rick@uunet.uu.net Folks: RFF-1123 page 67 says: (D) The gateway MUST ensure that all header fields of a message that it forwards into the Internet meet the requirements for Internet mail. In particular, all addresses in "From:", "To:", "Cc:", etc., fields must be transformed (if necessary) to satisfy RFC-822 syntax, and they must be effective and useful for sending replies. The last phrase means that you can't send a message into the Internet with a mailbox address in its header that is not registered in the Domain Name System (DNS). For a mailbox address to be effective and useful for sending replies to an Internet host, the Internet host must be able to translate the domain part of the mailbox to an IP address via the DNS (either MX or A records). So if the host asserted in the domain part is not registered in the DNS database, then it is illegal to forward a message with that mailbox address into the Internet. Since ".BITNET" and ".UUCP" are not currently registered domains in the DNS, mailbox address ending in these strings can't legally be sent into the Internet. --jon.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Dec 89 14:25:23 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa22098; 16 Dec 89 14:22 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6783; Sat, 16 Dec 89 14:21:39 EST Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 1781; Sat, 16 Dec 89 14:21:38 EST Received: from ODEN by brage.qz.se; Sat, 16 Dec 89 20:18 +0100 Date: 16 Dec 89 18:26 +0100 From: Jacob Palme QZ Subject: Re: [barmar@THINK.COM: Inferior Lisp mode conflicts with] To: header-people Reply-to: Jacob Palme QZ Message-ID: <475948@QZCOM> In-Reply-To: <8912131614.aa13639@mintaka.lcs.mit.edu> Our COM conferencing software uses message-id-s to eliminate duplicates, stop loops etc. Note however, that there is a security problem with this function. If a user happens to know the ID of a message, but does not know the content, then that user can send a false message, with different content but the same ID, and the merging facility will then merge them, which will allow people who have not access rights to the original message to read it. In order to avoid this security problem, we check that the content is the same also, not only the ID, before merging. This, however, also causes problems, since two copies of the same message can sometimes be different, mostly in double "headers". So some differences should be acceptable, still accepting them as the same message.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Dec 89 14:25:29 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa22101; 16 Dec 89 14:22 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6784; Sat, 16 Dec 89 14:21:43 EST Received: from brage.qz.se by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 1783; Sat, 16 Dec 89 14:21:43 EST Received: from ODEN by brage.qz.se; Sat, 16 Dec 89 20:19 +0100 Date: 16 Dec 89 18:30 +0100 From: Jacob Palme QZ Subject: Message-ID To: header-people Reply-to: Jacob Palme QZ Message-ID: <475949@QZCOM> In-Reply-To: <8912140017.AA21968@ifi.uio.no> I have spent a lot of effort in the last years in getting the CCITT to accept the Message-ID as mandatory in the X.400 standard. The reason for this is the advantage of Message-ID-s (1) For merging duplicates of the same message (2) For preserving conversations (set of messages related by in-reply-to-links) from system to system, so that users can be given facilities to browse conversations, store them in special folders etc. (3) For avoding loops. This is the least important use, since CCITT has chosen to use other methods for loop elimination in X.400.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Dec 89 00:14:35 EST Received: from ALLSPICE.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa23033; 20 Dec 89 0:12 EST Received: by PTT.LCS.MIT.EDU id AA10876; Wed, 20 Dec 89 00:11:26 EST Date: Wed, 20 Dec 89 00:11:26 EST From: Noel Chiappa Message-Id: <8912200511.AA10876@PTT.LCS.MIT.EDU> To: postel@venera.isi.edu Subject: Re: Forwarding Mail into the Internet Cc: header-people@mc.lcs.mit.edu.jnc, ietf-hosts@nnsc.nsf.net Jon, I find your argument straightforward and compelling; if the Host RFC does not say this clearly then the next Rev (dunno when we can get that out, given the desire of manufacturers not to have Musical Specs) ought to be cleaned up. Noel  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Dec 89 19:46:31 EST Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa02038; 20 Dec 89 19:42 EST Received: by decwrl.dec.com; id AA09745; Wed, 20 Dec 89 16:41:35 -0800 Received: by volition.pa.dec.com (5.57/4.7.34) id AA20380; Wed, 20 Dec 89 16:39:00 PST Message-Id: <8912210039.AA20380@volition.pa.dec.com> To: header-people@MC.lcs.mit.edu Subject: Date: Wed, 20 Dec 89 16:38:58 PST From: Dave Crocker ------- Forwarded Message Date: 14 Dec 89 13:48 EST From: TIHOR@acf7.nyu.edu Mmdf-Warning: Parse error in original version of preceding line at lcs.mit.edu To: rick@uunet.uu.net Mmdf-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: RE: A sad comentary Cc: header-people@mc.lcs.mit.edu Mmdf-Warning: Parse error in original version of preceding line at lcs.mit.edu Message-Id: <3484BDBAA.34C02303.1989@ACF7.ACF7.NYU.EDU.ARPA> In-Reply-To: Message of 14-DEC-1989 11:37:49 from rick@uunet.uu.net ... Why we all know the intention is for the right had side of everything in a SMTP address to be a domain name system resolvable name THAT REQUEUIRMENT DOES NOT SEEM TO BE WRITTEN DOWN ANYWHERE. I remember its discussion way back when but it does not see to have made it into even the host requirements document except eliptically. Thats no way to write standards. Please provide exact citation and quotation for why X.Y.Z must be a DNS name if the following addresses by the RFCs: <@A.B.C:user@X.Y.Z> <@A.B.C,@X.Y.Z:user@D.E.F> ... - ------- ------- End of Forwarded Message The Host Requirements document, for the upper layers, should leave no doubt that the right-hand side must be "globally" resolvable to an Internet host. Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Jan 90 02:36:59 EST Received: from ACF7.NYU.EDU by mintaka.lcs.mit.edu id aa13524; 3 Jan 90 2:37 EST Date: Wed, 3 Jan 1990 2:36:13 EST From: Stephen Tihor Message-Id: <900103023613.35409504@ACF7.NYU.EDU> Subject: w/r/t Ned's reply To: header-people@mc.lcs.mit.edu X-Vmsmail-To: IN%"header-people@mc.lcs.mit.edu" I'll start by (once again) disagreeing with Ned's "answer" that .BITNET is the "right" ting to emit. I assert that (a) in the real world mailers shoudl be able to handle .BITNET if it is handed to them. (b) gateways should mangle the BITNET user@host into the local part of their internet address. Since I am on serious drugs after oral surgery I can get away with being brief. I very much admire Ned's work on PMDF. His reply that someone someone will play with x%y in x%y@z so you should not use it is, perhaps, an arguement for x.y@z. It is not an arguement for .BITNET. I have pushed this issue because I think we can get it fixed and that the Ixyz (for whatever xyz is apprporate) is responsible enough to recognize the problem and agree with CREN as to the fix and tell the rest of us. I don't care if we break the internet to bitnet links personally since we are on both sides of the fence already and similarly we have no problems with .BITNET nor with using eithe the offical INTERBIT gateway or our own private gateway. But NYU was an early ARPANET site. We have allways had local mailer expertise. I do want to see a real working and offical solution in place. SOON. I want to see Ned's "it just won't happen" disproved for the good of the little guys like the one that started this discussion on INFO-PMDF.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Jan 90 07:10:57 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21997; 3 Jan 90 7:10 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA10787; Wed, 3 Jan 90 06:47:28 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Jan 90 18:05:53 GMT From: 1770 MCI Organization: |UUCP Mail : osu-cis!vlink01!steve |Vlink | Subject: MCIMAIL CMSLINK Message-Id: <131@vlink01.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu There is a company called CMSLINK, in Southfield, MI, which makes a package which retrieves and sends MCI Mail. It is available for Xenix. I am looking for someone which could write me a bridge from the elm mailer to re-format the enevelope from elm to work with this package available from CMSLink. If anyone is interested in helping me out or can point me in the right direction, I would welcome their email. Thanks so much, in advance. uucp!osu-cis!vlink01!steve -- |UUCP Mail : osu-cis!vlink01!steve |Vlink | |MCI Mail : uucp!mcimail.com!368-5882 |Steven E. Frazier | |ATT Mail : attmail!vlink01!steve |1828 Darrow Drive | |Voice Mail: 614-755-3772 |Powell, Ohio 43065 |  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Jan 90 12:14:29 EST Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa01424; 3 Jan 90 12:12 EST Received: by decwrl.dec.com; id AA25431; Wed, 3 Jan 90 09:11:04 -0800 Received: by dcrocker.pa.dec.com (5.57/4.7.34) id AA06164; Wed, 3 Jan 90 09:09:49 PST Message-Id: <9001031709.AA06164@dcrocker.pa.dec.com> To: Stephen Tihor Cc: header-people@mc.lcs.mit.edu Subject: Re: w/r/t Ned's reply In-Reply-To: Your message of Wed, 03 Jan 90 02:36:13 -0500. <900103023613.35409504@ACF7.NYU.EDU> Date: Wed, 03 Jan 90 09:09:47 PST From: Dave Crocker Drugs? For oral surgery? Gee, I thought that oral surgery would just fix what you say... Let me express some confusion about the .bitnet confusion. No doubt, much of what follows will show ignorance, ratherthan anything more constructive: The domain name system model should have no problem with the general reference to bitnet. Within that model, you can use either the existing .NET top-level domain, registering .BIT.NET underneath it, or you can try to convince a number of powers-that-be to register .BIT or .BITNET at the top-level. Assuming that you want to Bitnet gateways to encode routing information, so that return mail will go to the same gateway that sent the original message, then you need to code a domain name for each gateway. Hence, a global Bitnet address, such as user@host1, becomes an Internet address of user.host1@gatex.bit.net. If you want to be extremely clever, you could code it as user@host1.gatex.bit.net. This requires choices at the gateway and in the domain name system data base. Neither should be that tough to develop or operate. So, What subtleties have I missed? Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Jan 90 15:11:25 EST Received: from NYU.EDU by mintaka.lcs.mit.edu id aa07425; 3 Jan 90 15:07 EST Received: from ACF1.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34) id AA27891; Wed, 3 Jan 90 15:06:33 -0500 Date: 3 Jan 90 13:03 EST From: TIHOR@acf7.nyu.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu To: dcrocker@nsl.dec.com MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: RE: w/r/t Ned's reply Cc: header-people@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Message-Id: <347B774.35409A05.1990@ACF7.ACF7.NYU.EDU.ARPA> In-Reply-To: Message of 3-JAN-1990 12:12:28 from dcrocker@nsl.dec.com Someone say registereing BIT.NET would be a bad idea from a domain point of view since its a physical connectivity rather than a logical location. Anyway what I want is just to have the gateway which has to have an internet address use user.host1@gateway.internetdomain.whatevertoplevels or anything else it understands. Ned says this is bad because there is a brain damaged mailer out there (or several) that will parse user.host1 [Did I say that right or do I need more Oral surgery? :-) wince |-{ ] -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Jan 90 19:09:53 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa16461; 3 Jan 90 19:07 EST Date: Wed 3 Jan 90 19:02:41-EST From: John C Klensin Subject: Re: w/r/t Ned's reply To: dcrocker@nsl.dec.com Cc: TIHOR@acf7.nyu.edu, header-people@mc.lcs.mit.edu Message-ID: <631411361.140000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9001031709.AA06164@dcrocker.pa.dec.com> Mail-System-Version: Dave and others, I've been away several times in the course of this discussion and decided to follow it, rather than putting my two cents in. Now you get four cents. My apologies for going back over a little old ground, but it may be needed in context. Much of this is also review of ancient history, but I think it may be worth repeating. A few little problems--but it is these sorts of "few" and "little" that cause most of the problems of the universe. The whole DNS notion, in addition to distributing the authority for names and name spaces, focused on "administrative" domains, not network-topological ones. Since a large, and rising, number of BITNET sites are at institutions that have Internet sites and domains, establishing foo.bit.net is going to cause logical problems. For example, you don't want to know whether MITVMC.MIT.EDU is a BITNET site or an Internet one (the former, but with an appropriate MX address). Similarly, INFOODS.MIT.EDU (Internet) and MITVMA.MIT.EDU (both, and a gateway). The BITNET folks have, incidentally, gone to a lot of trouble to make their part of this work--BITNET mail from most BITNET hosts addressed to Klensin@INFOODS.MIT.EDU will be routed to an appropriate BITNET host, over BITNET, and that host will know what to do with it (much like MX handling, but less dynamic). The powers-that-be, as I understand it, would probably be happy to register .BIT.NET (or maybe even .BITNET) as a domain for the administrative folks who operate/maintain the thing, much as .CS.NET has long been registered as a domain. But that would do no good for the user on an Internet machine who wants to address mail to a user on a BITNET machine which was not one of the operator/maintainer organization's installations, any more than a CSNET user node uses .CS.NET, rather than its own domain name and structure. But the hard problems don't lie there anyway. One can clearly write a UA that would take something the user types as user@foo.BITNET and transform it into user%foo.BITNET@gateway. One could, in principle, transform it into "<@gateway:user@foo.BITNET>" but, as has been pointed out, this has always been illegal, since foo.BITNET isn't part of the DNS system--whether one could put it in and legalize it in future really has no bearing at the moment--and the HRRFC went out of its way to discourage the RFC822 source-route format anyway. If the RFC does not make it completely clear that names that appear to the right of @ must be DNS-registered names, I can assure you that it wasn't because we didn't try: Bob and I had several exchanges in the hope of text that was clear without being irritating and patronizing. I thought we had succeeded until this discussion chain started. Given that interpretation, there are three forms in which a BITNET address can appear on the Internet: (1) The BITNET node can acquire and register a DNS name, possibly with MXs pointing to nearby gateways with preferences descending with increasing "distance". That is what it is supposed to be all about. Then we see, e.g., user@foo.bar.edu (2) The bitnet address can be shown as local-part of a valid Internet address, e.g., user%foo.bar.edu@Internet-Bitnet-Gateway.mumble.edu or user%foo.BITNET@Internet-Bitnet-Gateway.mumble.edu or, in principle, as "/BITNET/user%foo"@Internet-Bitnet-Gateway.mumble.edu. The point behind this last being that only the gateway cares how to parse the local part. If the gateways were run by "the BITNET administration", they could be gateway.BIT.NET, as you point out. But there really hasn't been a "BITNET administration", and the gateways are not run by them. The advertised ones all all in university hands, and the unadvertised ones--well, who knows, but there are lots of them. (3) One can show the gateway, against the explicit recommendations of HRRFC, by using, e.g., <@gateway.mumble.edu:user@foo.bar.edu>. But, here, foo.bar.edu must be an Internet DNS name of Internet-wide name definition, not something that only 'gateway.mumble.edu' can resolve unambiguously. In the examples in (2) above, 'foo.BITNET' and 'foo.bar.edu' need only be names in the extended name space of the host/gateway Internet-Bitnet- Gateway.mumble.edu. They need not be Internet-unique, nor does '.edu' in that context necessarily mean what it would to the DNS. All that is fine. The problem arises with what a well-behaved gateway will do with BITNET mail coming into the Internet. From the BITNET side of the gateway, it may get mail from, e.g., UNIVCMS1 or UNIVCMS1.BITNET or CMS1.UNIV.EDU (these are common transformations, but not rules, and it cannot be guaranteed that the second and third are, from the Internet side, the same machine). Now, assuming that the gateway does not have sufficient knowledge to turn one of the first two into the third, the only thing that it can do is to map them into user%UNIVCMS1.BITNET@gateway-DNS-name (although it can leave the ".BITNET" off if it likes, or spell it differently). Can't emit it to the Internet as @UNIVCMS1.BITNET because that isn't a DNS address, and that is the way we wrote the rules, regardless of what Ned's software can do. And, since we (HRRFC) prohibit anyone but the gateway itself from rewriting a local-part, a reply to the message is going back the way it came in. No problem--unless a message is forwarded several times, such as by a distribution list--that is probably the right gateway anyway. And, if it isn't, it will work anyway, just be a tad suboptimal. But so much for routing information. But, say the gateway gets lucky and sees @CMS1.UNIV.EDU. The HRRFC text says, or was intended to say, that gateways should be pretty scrupulous about names being DNS names. Let's even assume that it passes the name through a resolver and verifies that everyone is being well-behaved. Now, what does it put out? It has three choices: user%cms1.univ.edu@gateway-DNS-name (anyway) user@cms1.univ.edu <@gateway-DNS-name:user@cms1.univ.edu> Now, if the first is used, there is no hope for the receiving UA, in generating a reply, to send things out through another, more convenient, gateway, since we prohibit looking at the local-part. The second is, I think, our Internet preference, but it assumes/requires that the receiving host support the DNS and MX resolution (that is ok, since we require that capability now). However, if "user" (the local-part) implies some machine reached via an MX, it also implies either that the final machine support the DNS for replies, or that the MX-target-gateway transform the address in some appropriate way. The current BITNET->Internet gateways found those to be bad assumptions in practice--when it worked, it was fine, but, when it didn't, there was no way to reply--so that form is not used, at least at present. Finally, the third. Well, HRRFC pretty agressively discourages its use at all. My BITNET colleagues say "but it provides a hint as to how to get back and hence more robustness", which is a worthy goal. And, while HRRFC quite deliberately avoided taking that position, it is logically possible to write an RFC821/822-consistent pair of rules that say, if you are a UA and receive something with an address in <@gateway-domain:user@user-domain> form, and the user says "reply": (i) You may reply to that address, i.e., source-route to 'gateway-domain' or, since you are guaranteed that 'user-domain' is a DNS name and parsing the address sufficiently to find it does not require that you parse a local-part, (ii) You may forget the source route, resolve 'user-domain' directly, and go happily on your way. Presumably, if you couldn't handle MXs, or were lazy, you would pick the first option; if you were clever or trying to be optimal, you would pick the second. And, now, we have routing information, handled correctly. The BITNET host, and associated arrangements, specify which gateway its mail to the Internet goes through. An Internet host, originating mail to a BITNET host, looks it up in the DNS, gets an MX, and does the right thing, using a gateway preference chosen by the target host. An Internet host, *replying* to a message from a BITNET host, either replies through the originating gateway or pretends that it is originating mail and uses the DNS resolver, depending on the incoming address syntax and on how smart it wants to be. >Assuming that you want to Bitnet gateways to encode routing information, >so that return mail will go to the same gateway that sent the original >message, ... Actually, you often don't want mail to go back to the same gateway through which it came, which is one of the reasons this is a problem. Let's assume that a BITNET user at Stanford sends a contribution to header-people@mc.lcs.mit.edu. Using standard BITNET software and tables, that is a well-defined address in that form. The message traverses the country on BITNET, gets to the MIT BITNET-Internet gateway, and shows up on the list and back to you as "From: user%stanfbar.BITNET@MITVMA.MIT.EDU" or as "From: <@MITVMA.MIT.EDU:user@bar.stanford.edu>" (you actually see one of the other choices today, but it is illegal, and...). Now, you want to send a note direct to the originator. While it would work, albeit slowly, you really don't want to go back to MIT in order to get to a host that is a few miles from you. You want to look up "bar.stanford.edu" in the DNS, and dispatch your message, presumably to a gateway within a hundred or so miles (and a very small number of BITNET hops) from the Stanford machine. And adding bar.stanford.bit.net addresses to the DNS really does not do much for that problem, regardless of how you spell it. And it does mean that Stanford suddenly has to maintain two DNS name spaces, one for its BITNET hosts and one for its Internet hosts. And that, in turn, implies that its gateway(s), if any, could end up with two names--bar.stanford.edu and bar.stanford.bit.net--which is part of what the DNS was intended to avoid. Now, there is another part of Ned's comment, and the appropriate response. Read what he is doing a different way, and I think it is completely reasonable. The distinction is between what capabilities it should be reasonable to have in an originating UA (or a surrogate for one) and what should be floating around the Internet or presented to an SMTP Server. If, on my local host, it amuses me to be able to type "myfriend@host.BITNET", or even "myfriend@host.bn", as if they were Internet DNS addresses, and I can negotiate or create a UA that will transform that into myfriend%host.bitnet@nearby-gateway-domain before passing them to an MTA, then there is nothing, in any protocol that prevents or argues against that. It is a very handy typing/abbreviation convention, and a member of a class of things that a nice UA might have in it, nothing else. Somewhat similar arguments can be made for "cleaning up" addresses in incoming traffic, but have to be made carefully because nothing guarantees that, in the syntax xxx%yyy.bitnet@remote-domain, "xxx" is a user name and "yyy" is the name of a host on BITNET. Only "remote-domain" is presumed to know in any authoritative way. My apologies for kicking a dead horse, but this seems to keep coming up, in one form or another. john Klensin@INFOODS.MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 00:52:35 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa01994; 4 Jan 90 0:41 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA07465; Thu, 4 Jan 90 01:38:00 -0400 Message-Id: <9001040538.AA07465@alw.nih.gov> To: KLENSIN@infoods.mit.edu Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Thu, 04 Jan 90 00:39:55 EST Subject: Re: w/r/t Ned's reply I have just one question. If user@node.BIT.NET is a bad idea, why are user@host.UU.NET and the use of fidonet.org as a gateway to all of Fidonet good ideas? Both are being done now.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 01:41:25 EST Received: from WSMR-SIMTEL20.ARMY.MIL by mintaka.lcs.mit.edu id aa03821; 4 Jan 90 1:34 EST Date: Wed, 3 Jan 1990 23:31 MST Message-ID: From: "Frank J. Wancho" To: Roger Fajman Cc: header-people@MC.lcs.mit.edu, KLENSIN@infoods.mit.edu, WANCHO@wsmr-simtel20.army.mil Subject: w/r/t Ned's reply In-reply-to: Msg of 3 Jan 1990 22:39-MST from Roger Fajman If user@node.BIT.NET is a bad idea, why are user@host.UU.NET and the use of fidonet.org as a gateway to all of Fidonet good ideas? Actually, the use of "...fidonet.org" is an excellent idea because *all* of the entries exist as MX records pointing to the fidonet gateway nearest to the target host. Its clever use of MX records should be the model for ...BIT.NET. --Frank  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 10:05:23 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa00671; 4 Jan 90 10:04 EST Date: Thu 4 Jan 90 07:53:42-EST From: John C Klensin Subject: Re: w/r/t Ned's reply To: WANCHO@wsmr-simtel20.army.mil Cc: RAF@cu.nih.gov, header-people@MC.lcs.mit.edu Message-ID: <631457622.950000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: Mail-System-Version: >> If user@node.BIT.NET is a bad idea, why are user@host.UU.NET and >> the use of fidonet.org as a gateway to all of Fidonet good ideas? > >Actually, the use of "...fidonet.org" is an excellent idea because >*all* of the entries exist as MX records pointing to the fidonet >gateway nearest to the target host. Its clever use of MX records >should be the model for ...BIT.NET. I'm not sure that "...fidonet.org" is the best idea I've ever heard of, and would be interested in an authoritative answer from the namekeepers on this one. Fidonet is, however, an "org", and its members are participants in that organization, which makes it at least a reasonable idea. And, as Frank points out, subdomains point to the "right" gateways with carefully- chosen MX records, and many of the "wrong" gateways would be really wrong: There is no attempt to implement a guess-as-guess-can "Interbit" strategy on the Internet side, one which relies, on the BITNET side, on "nearest" gateway to the sender, not nearest to the receiver. "...fidonet.org" would become a relatively poor idea at the point that either of two things happened (my apologies for picking on Roger): (i) A fidonet site was set up at, e.g., NIH, and was given the name xxx.yyy.fidonet.org, rather than doggie.nih.gov. Keep in mind that, since NIH already has a domain, "doggie.nih.gov" could perfectly well be a fidonet node, running fidonet protocols, as long as the DNS record could contain an MX pointing to an appropriate exchanger/gateway. or, even worse, (ii) that hypothetical machine had to be known, on the Internet, by both of those names, with different address routings to access them and the fact that it was the same machine known only by oral tradition and obscure lists. This is the pragmatic problem with .BITNET, independent of all of the philosophical ones. The vast majority of BITNET sites are located at places that have DNS domain assignments, or that will soon. A machine having two name-identities is a poor idea, especially if those two identities imply two separate routings from a given point. As more and more of the institutions that support BITNET capability also acquire Internet/CREN capability, there will be more and more gateways which should be known to software and the DNS, but not the active concern of users. For example, Roger, I now see your address as CU.NIH.GOV. While I have vague recollections of TCP/IP nodes at NIH, it is a great pleasure to not have to know whether this machine is something that is "really" a BITNET site, and if it is, whether the MX gateway is at NIH or elsewhere, or whether it is actually an Internet site. And, if my MTA here breaks, as it managed to do a few weeks ago for a short time, and I decide to answer your message from another machine, with different network connections (e.g., a BITNET host) it is a great pleasure that it can figure out what to do, (nearly-)optimally with CU.NIH.GOV given its topology and connections and, in particular, that I don't need to figure out if CU.NIH.GOV is "really" NIHCU.BITNET in order to avoid the "cross network B in order to deliver mail between two sites on network A" problem. There are also a few pragmatic reasons why one does not want to try to maintain DNS resolution for fidonet nodes one at a time, or one per institution/household. Most of the BITNET institutions already have adequate administrative setups, and there are enough alternate, but quite plausible, gateways to make a rich system of per-institution MXs, etc., quite useful. As soon as the notions of ".BIT.NET" implying one gateway and there being any advantage in either maintaining a separate DNS registration authority for BITNET nodes or of trying to avoid such an authority at the node/host level (as in fidonet) disappear, there are just no practical advantages to .BIT.NET as part of the DNS. And there are several disadvantages. As an aside, the evolving procedures for US and International registration of organizational identifiers for OSI are following along much the same lines that I've attributed to the DNS registration rules: organizations, and hence subdomains, are administrative entities with the ability to do some administering or to pay someone to do that for them, they are not network topologies or lengths of wire. --john -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 10:10:42 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa00763; 4 Jan 90 10:07 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 7340; Thu, 04 Jan 90 03:49:37 EST Received: from HASEOC.BITNET (NOREILLY) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 5133; Thu, 04 Jan 90 03:49:36 EST Date: Thu, 4 Jan 90 09:40 N From: NOREILLY%HASEOC.BITNET@mitvma.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: RE: w/r/t Ned's Reply To: HEADER-PEOPLE@MC.lcs.mit.edu X-Original-To: HDR-PPL Message-ID: <9001041007.aa00763@mintaka.lcs.mit.edu> On Wed, 3 Jan 90 23:31:00 MST, "Frank J. Wancho" said: > > Actually, the use of "...fidonet.org" is an excellent idea because > *all* of the entries exist as MX records pointing to the fidonet > gateway nearest to the target host. Its clever use of MX records > should be the model for ...BIT.NET. > > --Frank Is everyone shouting the same thing, then? How soon can we have all of BITNET existing as MX records pointing to the INTERBIT gateway nearest to the target host, or even nearest to the source host. Niall  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 10:16:33 EST Received: from en-c06.prime.com by mintaka.lcs.mit.edu id aa00865; 4 Jan 90 10:11 EST Received: from NET.Prime.COM by EN-C06.Prime.COM; 04 Jan 90 10:15:38 EST Received: from Relay.Prime.COM by NET.Prime.COM; 04 Jan 90 10:09:32 EST Received: (from user ARIEL) by Relay.Prime.COM; 04 Jan 90 10:11:40 EST To: header-people@MC.lcs.mit.edu Cc: cic@sh.cs.net From: Robert Ullmann Subject: re: .BITNET domain Date: 04 Jan 90 10:11:40 EST Message-ID: <9001041011.aa00865@mintaka.lcs.mit.edu> Hi, The following is a slightly updated version of a message sent to the CSnet/BITnet list(s) debating the (then) pending merger: Re: how does a domain site handle user@somesite.BITNET ? Please recall the almost painless (for DNS sites) conversion from .ARPA to the preferred domain names, with the .ARPA zone gradually coming to consist only of CNAME RRs ... Proposal: the .BITNET domain should be registered, with CSnet/BITnet (whatever they call themselves now :-) providing the name service *.BITNET would then be MX'd to the default Interbit gates, with appropriate reference weights the gates would use addresses on outgoing (to Internet) mail with .BITNET where the sending host did not have a "real" domain name known to the gateway. At this point, we have essentially the current routings. Then: BITNET sites with local gates could request the addition of MX records for their .BITNET systems. (with whatever definition of "local" the site and gateway prefer) as BITNET systems acquire real domain names, CNAME records can be added to redirect route inquiries to the domain MX records. the CNAMEs can then be used by the gates themselves to canonicalize names on outgoing mail. gates can stop generating routes (e.g.) ABC%SITE.BITNET@MITVMA.MIT.EDU instead generating ABC@SITE.BITNET the domain names can be phased in with little or no disruption The .BITNET zone would be restricted, as a matter of policy, to contain only CNAME and MX RR's; it would exist only as a transition domain. This could be done with .BIT.NET instead; but it would involve many changes to gates first, and also is a user-visible change; whereas a .BITNET zone could be implemented with no changes, and has the advantage of being "obviously" a transition domain ala .ARPA. [ irrelevent observations: I believe that there are any number of sites that would be willing to act as Interbit gates, if only the traffic was limited to a controllable set of BITNET destinations. At present, these are invisible to the normal internet routing. This sort of thing could also be done with .uucp. I have a program which munches the /pathalias/ maps into a zone consisting entirely of MX's and CNAMEs. I have a collection of incendiary mail received from the first time this was sent out; you are welcome to add to it ... :-) ] Robert Ullmann Prime Computer Ariel@Relay.Prime.COM +1 508 879 2960 x1736  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 10:39:45 EST Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa01360; 4 Jan 90 10:28 EST Received: by decwrl.dec.com; id AA29600; Thu, 4 Jan 90 07:26:12 -0800 Received: by dcrocker.pa.dec.com (5.57/4.7.34) id AA07524; Thu, 4 Jan 90 07:24:52 PST Message-Id: <9001041524.AA07524@dcrocker.pa.dec.com> To: Roger Fajman Cc: header-people@mc.lcs.mit.edu Subject: Re: w/r/t Ned's reply In-Reply-To: Your message of Thu, 04 Jan 90 00:39:55 -0500. <9001040538.AA07465@alw.nih.gov> Date: Thu, 04 Jan 90 07:24:50 PST From: Dave Crocker Roger, you raise a good political question, given that .uu.net is currently used/accepted. Technical point of distinction, however, is that bitnet has multiple gateways to the Internet. As I recall, uu.net refers to a single gateway. Therefore, bitnet would have to use gatex.bit.net, to get the same degree of precision. Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 14:13:22 EST Received: from nnsc.nsf.net by mintaka.lcs.mit.edu id aa09111; 4 Jan 90 14:10 EST To: header-people@MC.lcs.mit.edu Subject: re: .BITNET domain Date: Thu, 04 Jan 90 14:07:52 -0500 From: Craig Partridge Message-ID: <9001041410.aa09111@mintaka.lcs.mit.edu> Like John, I'd planned to stay out of the particular discussion about .BITNET, I know too much of the history, but.... Some history: In January of 1986 a group of people responsible for running the key e-mail networks (or in the case of UUCP, a senior UUCPer, since no one runs UUCP) met at SRI to discuss how the Internet's conversion to domain names would affect the other networks. After considerable discussion about the merits of .BITNET and .CSNET vs descriptive domain names ending in .EDU, .COM, etc., the following concensus emerged: (1) That topology based names like .BITNET and .CSNET were bad. In practice, users find the names confusing ("Gee, was Joe's account on BIG-U.BITNET or BIG-U.CSNET or BIG-U.ARPA???"). Lest you think this is philosophical sophistry, there was, for a couple of years, a very large and prestigious university that had two hosts, named .BITNET and .CSNET which were not connected to each other. Every week, the e-mail admins of the two machines held a tape swap to exchange mis-delivered mail. I kid you not. (2) That there was a need for a domain for machines which were affiliated with network administrators as opposed to the corporations which ran them. (I.e. BITNET has an identity independent of EDUCOM, and CSNET has an identity independent of BBN -- so for example, csnet-relay.bbn.com was clearly not the right name for the CSNET relay -- relay.cs.net made it's purpose more clear). (3) That all the networks (BITNET included) could reasonably implement domain names internally on their network, in a matter of a few years, thus allowing a unified e-mail world in which users only needed to type user@domain-name, no matter what network they were on (yes those of us at the meeting were being a bit starry eyed). The policies the NIC tries to enforce on use of .NET and .BITNET are a result of this meeting. Observe that this meeting did not preclude naming BITNET gateways in BIT.NET. Many networks do just this -- relay.cs.net is a good example, but so to are the names in NSF.NET which were given to the Phase I NSFNET Fuzzballs. Clearly the gateways play an important role in BITNET and, in some sense, have a relationship with the folks that administer BITNET. What is precluded is doing something like BIG-U.BIT.NET where BIG-U.BIT.NET is not an Interbit gateway but instead is simply the BITNET host at BIG-U. BIG-U should have its own domain name. Note this meeting further precluded there ever being a .BITNET. Craig PS: I should further point out that, with the exception of BITNET, all the major networks have gotten a long way to achieving universal use of domains. The last holdout in the Internet is the military. CSNET is totally converted. A large fraction of UUCP-land is converted. And user@domain is sure a whole lot less painful than all those '%', '!' things. PPS: As I recall, the BITNET plan was to revise the mail software to map domain names into the fixed-length BITNET ids. So there'd be a step where the name vm.cuny.edu would map into an envelope address CUNYVM that only the BITNET mailer would see; never the user. Unknown addresses would be mapped to Interbit gateways which would forward or reject them as appropriate (hacks like checking the right side of unknown domain names against lists of known top-level domains were to be used to limit the amount of bad mail being sent to gateways).  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 17:03:54 EST Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa15717; 4 Jan 90 17:00 EST Received: by garnet.berkeley.edu (5.57/1.32) id AA03874; Thu, 4 Jan 90 13:58:55 PST Date: Thu, 4 Jan 90 13:58:55 PST From: Postmaster & BITINFO Message-Id: <9001042158.AA03874@garnet.berkeley.edu> To: HEADER-PEOPLE@MC.lcs.mit.edu, MAIL-L@bitnic.bitnet Subject: Simplification of internet mail addresses Cc: hostmaster@nic.ddn.mil I think it is time to go back to using simple internet mail addresses. 1. Recommendation: Stop adding host-table-defined-domain hosts to addresses as in: mailbox%DNS-defined-domain@host-table-defined-domain and use: mailbox@domain For example, use: mailbox@dali.berkeley.edu instead of: mailbox%dali.berkeley.edu@ucbvax.berkeley.edu or: <@ucbvax.berkeley.edu:mailbox@dali.berkeley.edu> Justification: Elimate source routing resulting from using a gateway type address to permit direct SMTP delivery. All MILNET should have converted to the Internet Distributed Nameserver System by October 1989 per RFC 1031. Does anyone know if this time table has been changed? RFC 1031 MILNET DOMAIN TRANSITION November 1987 MIGRATION TIMETABLE Table 1 shows the events and dates involved in the MILNET transition from host table to domain system. The operational testing of the root server software has been completed. Voluntary conversion can begin immediately, with mandatory conversion required by October 1989. After this date, hosts not converted need to obtain the host table equivalent by private arrangement (see "Migration Path" above). Start End Milestone Date Date =========================================== ====== ====== Root server operational testing Dec 86 Jul 87 Policy announced in DDN Management Bulletin Oct 87 Host conversion Oct 87 Oct 89 Host table discontinued Oct 89 MILNET Name Domain Timetable Table 1 2. Recommendation: Advise Internet mail users in the BITNET zone that they can stop using: mailbox%domain@mail-gateway-domain on BITNET in most cases, and use the simple: mailbox@domain Justification: INTERBIT mail gateways now use DNS to resolve addresses and can handle MX defined domains. All internet top-domains are being added to the DOMAIN NAMES mail gateway routing file. (MX only domains were previously omitted because the gateways could not handle them.) 3. Recommendation: Encourage Internet mail users in the UUCP zone to use mail software that will support: mailbox@domain or at least: domain!mailbox (in UUCP mail, not the internet) Justification: Simplification of addresses. Bill Wells, E-mail Postmaster & Network Consultant ------------------------------------------------------------------------ | William C. Wells Telephone: 1 415 642-9801 (CA-ATSS: 582-9801) | | Data Communication & Network Services, 269 Evans Hall, | | University of California, Berkeley, CA 94720, USA | ------------------------------------------------------------------------ | Internet Mail System postmaster@jade.berkeley.edu | | & BITNET VM Mailer: netinfo@garnet.berkeley.edu | | UUCP: {harvard,rutgers,ucbvax,uunet}!garnet.berkeley.edu!netinfo | | FAX (group III): 1 415 643-5385 (8am - 4:15pm, PST or PDT) | ------------------------------------------------------------------------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 18:37:03 EST Received: from NIC.DDN.MIL by mintaka.lcs.mit.edu id aa17071; 4 Jan 90 17:32 EST Date: Thu, 4 Jan 90 14:29:55 PST From: Ken Harrenstien Subject: re: .BITNET domain To: header-people@mc.lcs.mit.edu cc: KLH@nic.ddn.mil In-Reply-To: <9001041410.aa09111@mintaka.lcs.mit.edu> Message-ID: <12555632625.27.KLH@NIC.DDN.MIL> Like everyone else, I had hoped to stay out of this discussion too, but it looks like a few words from here may help to prevent additional go-arounds. As far as I know, I was the person who originally invented .COM, .EDU, .ORG, and the rest (guilty!). We in our little NIC/ISI group had many other ideas, but this was the one we reached consensus on. I'm pretty sure this was not the same meeting Craig mentions (which I recall as the "bang-percent-atsign" group), but the conclusions we arrived at did not change much with further meetings. In particular, Craig's points are all correct. In much the same way that the consequences of relativity fall out of the simple assumption that the speed of light is always constant, most of the domain name system policies fall out of the simple goal of giving a host a name that remains constant and unique regardless of your reference frame (network). Starry-eyed maybe, but laudable. Note that the parallel extends to the fact that from a single fixed frame, DNS looks the same as a simple hostname scheme, just as relativistic equations collapse into Newtonian mechanics. Human policies are not quite as reliable as the laws of physics, however. A classic example is MITRE.ORG, which should really be MITRE.COM; it just slipped past because the NIC staff who did the actual registration paperwork were still new to the concepts and reluctant to challenge apparently knowledgeable applicants. Then it was (or seemed) too late. UU.NET was an aberration as well, which is why it is not a good model for BITNET. At the NIC we have received and rejected many, many requests to register .NET. After due explanation, most applicants readily understand what we're trying to do. All NET domains are supposed to be used only for associating names with addresses used for network control -- gateways, operation and information centers, and the like -- where the network is a recognizably distinct organization such as CSNET is. I'm encouraged by the fact that more and more people are seeing the light and taking over the evangelical duties formerly performed by Paul Mockapetris and others. As a contractual minion of DCA, it is not always practical to speak up from here. --Ken P.S. An aside about FIDONET. After a number of long discussions caused by our refusal to register FIDO.NET, we eventually compromised with IFNA.ORG since the IFNA (International FidoNet Association) was the only thing close to an administrative entity. Tim Pozar later decided to replace it with FIDONET.ORG instead, which in my personal opinion only continues to perpetuate Newtonian thinking. Oh well. -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 18:50:22 EST Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa20463; 4 Jan 90 18:47 EST Received: by garnet.berkeley.edu (5.57/1.32) id AA05785; Thu, 4 Jan 90 14:50:09 PST Date: Thu, 4 Jan 90 14:50:09 PST From: Postmaster & BITINFO Message-Id: <9001042250.AA05785@garnet.berkeley.edu> To: header-people@MC.lcs.mit.edu Subject: Re: w/r/t Ned's reply Cc: postmaster@uunet.uu.net The issue is simple, those BITNET sites that do not register internet domain names for their sites and impliment mail software that can handle internet domain addressess are not part of the Internet Mail System. I see the nodeid.BIT.NET and nodeid.BITNET domain proposals as a move by those BITNET sites that are too lazy to implement the proper software to participate in the Internet Mail System. These proposals are fueled in part by "true blue" nodes on the BITNET who will only run IBM software on their IBM systems. In reply to: Date: Thu, 04 Jan 90 07:24:50 PST From: Dave Crocker Roger, you raise a good political question, given that .uu.net is currently used/accepted. According to the Internet nameserver at uunet.uu.net the following domains are defined in the UU.NET domain: bugbiter.uu.net caliph.uu.net color.uu.net eu-gw.uu.net janus.uu.net mono.uu.net ns.uu.net rlavax.uu.net seismo.uu.net tb.uu.net uunet.uu.net So it should be apparent at UU.NET domain is only being used for UUNET network gateway services related hosts and not all the nodes in the UUCP world. Technical point of distinction, however, is that bitnet has multiple gateways to the Internet. As I recall, uu.net refers to a single gateway. UUNET is not a network, but a gateway service providing forwarding services for messages sent to contracting sites. I believe that all sites paying for UUNET gateway services now have or will soon internet domain names. I suspect that in the future, uunet.uu.net may phase out support for addresses of the form host!user@uunet.uu.net since they are not a general Internet/UUCP gateway. Therefore, bitnet would have to use gatex.bit.net, to get the same degree of precision. Dave This is a bad idea. Users should not be doing source routing. Addressing from any part of the Internet mail system (SMTP, UUCP, or BITNET zones) should use the simple internet address format: mailbox@domain From the internet SMTP zone, MX records should be defined for BITNET zone mail domains to at least two and perhaps all INTERBIT gateways with different precedences reflecting the topology of the BITNET. With this setup the user is not concerned with source routing and mail is automatically routed to the next nearest INTERBIT gateway when is the primary gateway is down. Bill Wells postmaster@jade.berkeley.edu netinfo@garnet.berkeley.edu PS. The above opinions are my own and not necessarily those of my employer, the University of California.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 20:16:22 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa23780; 4 Jan 90 20:13 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA13390; Thu, 4 Jan 90 21:00:59 -0400 Message-Id: <9001050100.AA13390@alw.nih.gov> To: KLENSIN@infoods.mit.edu Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Thu, 04 Jan 90 20:03:57 EST Subject: Re: w/r/t Ned's reply > I'm not sure that "...fidonet.org" is the best idea I've ever heard of, > and would be interested in an authoritative answer from the namekeepers on > this one. Fidonet is, however, an "org", and its members are participants > in that organization, which makes it at least a reasonable idea. And, as > Frank points out, subdomains point to the "right" gateways with carefully- > chosen MX records, and many of the "wrong" gateways would be really wrong: > There is no attempt to implement a guess-as-guess-can "Interbit" strategy > on the Internet side, one which relies, on the BITNET side, on "nearest" > gateway to the sender, not nearest to the receiver. Why is FidoNet more of an "org" than BITNET? BITNET, of course, currently has different administrations for BITNET (US), EARN, and NETNORTH. But the International FidoNet Association does not by any means own all the FidoNet nodes. I think that some if the FidoNet zones (e.g., RBBS-NET) are separately administered, but I'm not positive about that. (I'm just starting to learn more about FidoNet.) CREN is the corporation that administers the US portion of BITNET. Somehow I don't think you would be happier with user@host.CREN.ORG, user@host.EARN.ORG, etc., but I still don't see the essential difference from FidoNet. You may say that most of the FidoNet systems are operated by individuals, and I agree with that. But such systems, could, in principle, be registered under the US and other country domains. Not that I'd care to take on that job. And what about the use of user@host.UU.NET? Why is that OK? > "...fidonet.org" would become a relatively poor idea at the point that > either of two things happened (my apologies for picking on Roger): > (i) A fidonet site was set up at, e.g., NIH, and was given the name > xxx.yyy.fidonet.org, rather than doggie.nih.gov. Keep in mind that, since > NIH already has a domain, "doggie.nih.gov" could perfectly well be a > fidonet node, running fidonet protocols, as long as the DNS record could > contain an MX pointing to an appropriate exchanger/gateway. > or, even worse, > (ii) that hypothetical machine had to be known, on the Internet, by both > of those names, with different address routings to access them and the fact > that it was the same machine known only by oral tradition and obscure > lists. I see no mention in the FidoNet gateway description of the possiblity of a FidoNet node having its own name (i.e., doggie.nih.gov) in the DNS. But if it did, I don't see how that would prevent it also being addressed as Fnnn.Nnnn.Zn.FIDONET.ORG. In order to implement DNS domains for FidoNet nodes, the gateways would have to keep a large list giving the translation. This is similar to the problem for BITNET if the translation idea suggested by some is used. For a more real life example, I am SYSOP of a BBS for the Capital PC User Group. I plan to put that BBS on FidoNet. I could apply for a domain name (CPCUG.ORG) and probably find someone to do name service for it, but as near as I can tell, there's no way for the FidoNet gateway to be told about it. Please correct me if I am wrong. > This is the pragmatic problem with .BITNET, independent of all of the > philosophical ones. The vast majority of BITNET sites are located at > places that have DNS domain assignments, or that will soon. A machine > having two name-identities is a poor idea, especially if those two > identities imply two separate routings from a given point. As more and > more of the institutions that support BITNET capability also acquire > Internet/CREN capability, there will be more and more gateways which should > be known to software and the DNS, but not the active concern of users. Where are the statistics that support your statement? I see 161 domains defined in the current BITNET DOMAIN NAMES file. Even if all are assumed to be US domains (they're not - many are country domains), that's still maybe only a third of the BITNET membership (not counting EARN and NETNORTH). And the mere fact that a domain is registered doesn't make the software to support domains magically appear on all BITNET machines that might possibly be a part of that domain. We had to write ours. > For example, Roger, I now see your address as CU.NIH.GOV. While I have > vague recollections of TCP/IP nodes at NIH, it is a great pleasure to not > have to know whether this machine is something that is "really" a BITNET > site, and if it is, whether the MX gateway is at NIH or elsewhere, or > whether it is actually an Internet site. And, if my MTA here breaks, as it > managed to do a few weeks ago for a short time, and I decide to answer your > message from another machine, with different network connections (e.g., a > BITNET host) it is a great pleasure that it can figure out what to do, > (nearly-)optimally with CU.NIH.GOV given its topology and connections and, > in particular, that I don't need to figure out if CU.NIH.GOV is "really" > NIHCU.BITNET in order to avoid the "cross network B in order to deliver > mail between two sites on network A" problem. I agree with that, and have worked towards getting better support for domains in the BITNET protocols. But the fact is that domains are only partially supported in the BITNET protocols -- only for mail, not for file transfer or interactive messages. So when we put CU.NIH.GOV on the Internet (yes, it is an Internet host now), we had to make a decision about how to be known on BITNET. Mail can be sent to CU.NIH.GOV on BITNET and we will accept it, but when we send mail to BITNET we do it as NIHCU. The reason is that it is easier to explain that we are CU.NIH.GOV on the Internet and NIHCU on BITNET, than to explain that for mail it's CU.NIH.GOV, but for BITNET file transfer and interactive messages it's NIHCU. > There are also a few pragmatic reasons why one does not want to try to > maintain DNS resolution for fidonet nodes one at a time, or one per > institution/household. Most of the BITNET institutions already have > adequate administrative setups, and there are enough alternate, but quite > plausible, gateways to make a rich system of per-institution MXs, etc., > quite useful. True, but the protocols are not in place to do a complete job to implement domains on BITNET. I've made proposals myself to change that, but so far it's come to no more than talk. > As soon as the notions of ".BIT.NET" implying one gateway and there being > any advantage in either maintaining a separate DNS registration authority > for BITNET nodes or of trying to avoid such an authority at the node/host > level (as in fidonet) disappear, there are just no practical advantages to > .BIT.NET as part of the DNS. And there are several disadvantages. There's nothing that says that BIT.NET would have to imply only one gateway any more than FIDONET.ORG does. There may be no practical advantages on the Internet side, but given the current state of things, there are on the BITNET side. > As an aside, the evolving procedures for US and International registration > of organizational identifiers for OSI are following along much the same > lines that I've attributed to the DNS registration rules: organizations, > and hence subdomains, are administrative entities with the ability to do > some administering or to pay someone to do that for them, they are not > network topologies or lengths of wire. > --john > ------- It's easier to do when you get to define the protocols in advance. Of course, it is taking a while to get done. :-) I agree that network-independent naming is a great idea. But BITNET isn't ready for it and may never be. So the real question is whether it's worth doing anything beyond what we already have while we are waiting. Roger Fajman  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 20:16:42 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa23828; 4 Jan 90 20:15 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA13419; Thu, 4 Jan 90 21:12:09 -0400 Message-Id: <9001050112.AA13419@alw.nih.gov> To: dcrocker@nsl.dec.com Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Thu, 04 Jan 90 20:15:22 EST Subject: Re: w/r/t Ned's reply > Roger, you raise a good political question, given that .uu.net is > currently used/accepted. > > Technical point of distinction, however, is that bitnet has multiple > gateways to the Internet. As I recall, uu.net refers to a single > gateway. > > Therefore, bitnet would have to use gatex.bit.net, to get the same > degree of precision. > > Dave No, multiple gateways could be done with appropriate MX records, just as is done with FIDONET.ORG. A.BIT.NET and B.BIT.NET could be MXed to different gateways. And how is the following justified? It's from a recent message to Info-Nets. +=============== HOW TO ADDRESS MESSAGES TO INDIAN SITES ================+ | | | If you are at an Internet site | site!user@shakti.uu.net OR | | that can handle domains | user%site@shakti.uu.net | |------------------------------------------------------------------------| | If you are at a site that can't | uunet!shakti!site!user | | handle domains | | +========================================================================+ Apparently, shakti.uu.net is in India.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 20:32:30 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa24327; 4 Jan 90 20:28 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA13427; Thu, 4 Jan 90 21:24:41 -0400 Message-Id: <9001050124.AA13427@alw.nih.gov> To: craig@nnsc.nsf.net Cc: header-people@MC.lcs.mit.edu From: Roger Fajman Date: Thu, 04 Jan 90 20:27:37 EST Subject: re: .BITNET domain > (3) That all the networks (BITNET included) could reasonably implement > domain names internally on their network, in a matter of a few > years, thus allowing a unified e-mail world in which users only > needed to type user@domain-name, no matter what network they were > on (yes those of us at the meeting were being a bit starry eyed). Unfortunately, this has not come to pass on BITNET. It does (mostly) work for mail, but not for other BITNET services (file transfer and interactive messages). So it's not possible for a BITNET node to use its domain name exclusively. How would you like it if you had to use one name to send email to a machine and another to FTP to it? That's the situation with domain names on BITNET. > The policies the NIC tries to enforce on use of .NET and .BITNET are > a result of this meeting. > > Observe that this meeting did not preclude naming BITNET gateways in > BIT.NET. Many networks do just this -- relay.cs.net is a good example, > but so to are the names in NSF.NET which were given to the Phase I > NSFNET Fuzzballs. Clearly the gateways play an important role in BITNET > and, in some sense, have a relationship with the folks that administer > BITNET. > > What is precluded is doing something like BIG-U.BIT.NET where > BIG-U.BIT.NET is not an Interbit gateway but instead is simply the > BITNET host at BIG-U. BIG-U should have its own domain name. > > Note this meeting further precluded there ever being a .BITNET. > > Craig My original question is why are these policies not enforced consistently with respect to FIDONET.ORG and UU.NET? Why is an Indian host named shakti.uu.net acceptable while a similarly named BITNET host is not? > PS: I should further point out that, with the exception of BITNET, > all the major networks have gotten a long way to achieving universal > use of domains. The last holdout in the Internet is the military. > CSNET is totally converted. A large fraction of UUCP-land is > converted. And user@domain is sure a whole lot less painful than > all those '%', '!' things. > > PPS: As I recall, the BITNET plan was to revise the mail software to > map domain names into the fixed-length BITNET ids. So there'd be > a step where the name vm.cuny.edu would map into an envelope address > CUNYVM that only the BITNET mailer would see; never the user. > Unknown addresses would be mapped to Interbit gateways which would > forward or reject them as appropriate (hacks like checking the right > side of unknown domain names against lists of known top-level domains > were to be used to limit the amount of bad mail being sent to gateways). This is pretty much the way it works. But only for email.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 20:54:14 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa25225; 4 Jan 90 20:52 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA13487; Thu, 4 Jan 90 21:48:47 -0400 Message-Id: <9001050148.AA13487@alw.nih.gov> To: KLH@nic.ddn.mil Cc: header-people@MC.lcs.mit.edu From: Roger Fajman Date: Thu, 04 Jan 90 20:51:36 EST Subject: re: .BITNET domain > UU.NET was an aberration as well, which is why it is not a good model for > BITNET. What's the story there? > At the NIC we have received and rejected many, many requests to > register .NET. After due explanation, most applicants > readily understand what we're trying to do. All NET domains are supposed > to be used only for associating names with addresses used for network > control -- gateways, operation and information centers, and the like -- > where the network is a recognizably distinct organization such as CSNET is. > > I'm encouraged by the fact that more and more people are seeing the > light and taking over the evangelical duties formerly performed by > Paul Mockapetris and others. As a contractual minion of DCA, it is not > always practical to speak up from here. > > --Ken I understand the policy and have for a long time. What I don't understand is why exceptions are made in some cases and not others. > P.S. An aside about FIDONET. After a number of long discussions > caused by our refusal to register FIDO.NET, we eventually compromised > with IFNA.ORG since the IFNA (International FidoNet Association) was > the only thing close to an administrative entity. Tim Pozar later > decided to replace it with FIDONET.ORG instead, which in my personal > opinion only continues to perpetuate Newtonian thinking. Oh well. Why did you compromise? As I understand the policy, none of those names should have been registered for the use in question. I don't think that many people care much whether the name ends in NET, ORG, or whatever.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Jan 90 21:10:56 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa25960; 4 Jan 90 21:09 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA13502; Thu, 4 Jan 90 22:04:49 -0400 Message-Id: <9001050204.AA13502@alw.nih.gov> To: netinfo@garnet.berkeley.edu Cc: header-people@MC.lcs.mit.edu, postmaster@uunet.uu.net From: Roger Fajman Date: Thu, 04 Jan 90 21:07:50 EST Subject: Re: w/r/t Ned's reply > The issue is simple, those BITNET sites that do not register > internet domain names for their sites and impliment mail software > that can handle internet domain addressess are not part of the > Internet Mail System. I see the nodeid.BIT.NET and nodeid.BITNET > domain proposals as a move by those BITNET sites that are too lazy > to implement the proper software to participate in the Internet > Mail System. These proposals are fueled in part by "true blue" nodes > on the BITNET who will only run IBM software on their IBM systems. That's not my motivation -- we've already written such software for ourselves. I'm just trying to make people more familiar with the significant problems remaining with the implementation of domains on BITNET. In my opinion, there's too much Internet-centric thinking on the issue. BITNET is not the Internet. > According to the Internet nameserver at uunet.uu.net the following > domains are defined in the UU.NET domain: > > bugbiter.uu.net caliph.uu.net color.uu.net eu-gw.uu.net > janus.uu.net mono.uu.net ns.uu.net rlavax.uu.net > seismo.uu.net tb.uu.net uunet.uu.net > > So it should be apparent at UU.NET domain is only being used for UUNET > network gateway services related hosts and not all the nodes in the > UUCP world. So where does shakti.uu.net come into it? I've also seen mail come from intercon.uu.net (but not recently).  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Jan 90 13:31:39 EST Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa01263; 5 Jan 90 13:25 EST Received: by uunet.uu.net (5.61/1.14) id AA13394; Fri, 5 Jan 90 10:42:13 -0500 From: UUNET Postmaster Message-Id: <9001051542.AA13394@uunet.uu.net> Subject: Re: w/r/t Ned's reply To: Roger Fajman Date: Fri, 5 Jan 90 10:42:08 EDT Cc: netinfo@garnet.berkeley.edu, header-people@MC.lcs.mit.edu In-Reply-To: <9001050204.AA13502@alw.nih.gov>; from "Roger Fajman" at Jan 04, 90 9:07 pm X-Mailer: ELM [version 2.2 PL14] > From RAF@CU.NIH.GOV Fri Jan 5 05:35:34 1990 > From: "Roger Fajman" > Date: Thu, 04 Jan 90 21:07:50 EST > [discussion about BIT.NET vs BITNET sites deleted] > > > According to the Internet nameserver at uunet.uu.net the following > > domains are defined in the UU.NET domain: > > > > bugbiter.uu.net caliph.uu.net color.uu.net eu-gw.uu.net > > janus.uu.net mono.uu.net ns.uu.net rlavax.uu.net > > seismo.uu.net tb.uu.net uunet.uu.net > > > > So it should be apparent at UU.NET domain is only being used for UUNET > > network gateway services related hosts and not all the nodes in the > > UUCP world. > > So where does shakti.uu.net come into it? I've also seen mail > come from intercon.uu.net (but not recently). There are tremendous number of uunet subscribers using such domain addresses much to my dismay. At some point some site started this little problem and way to many sites have picked up on it. Everytime I see it used (and that's a *lot*) I send a nice little form letter requesting that they either register a real domain name or stop using ours. Mostly they seem to disregard it. If we ever feel like removing the relevant lines from sendmail.cf we'll bring down the whole thing in a hurry. I really don't want to have to deal with all those people asking why their mail doesn't work though. -- uunet postmaster (James Revell)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Jan 90 15:19:10 EST Received: from uunet.UU.NET by mintaka.lcs.mit.edu id aa05930; 5 Jan 90 15:15 EST Received: by uunet.uu.net (5.61/1.14) id AA25399; Fri, 5 Jan 90 13:53:09 -0500 Date: Fri, 5 Jan 90 13:53:09 -0500 From: Rick Adams Message-Id: <9001051853.AA25399@uunet.uu.net> To: RAF@cu.nih.gov, dcrocker@nsl.dec.com Subject: Re: w/r/t Ned's reply Cc: header-people@MC.lcs.mit.edu And how is the following justified? It's from a recent message to Info-Nets. +=============== HOW TO ADDRESS MESSAGES TO INDIAN SITES ================+ | | | If you are at an Internet site | site!user@shakti.uu.net OR | | that can handle domains | user%site@shakti.uu.net | |------------------------------------------------------------------------| | If you are at a site that can't | uunet!shakti!site!user | | handle domains | | +========================================================================+ Apparently, shakti.uu.net is in India. ----- Funny how the people who claim that network independant naming is a good idea are complaing about the geographic location of uunet's gateway to India (which is,cleverly enough, in India). Shatki is within UUNET's organizational domain, so the name SHOULD be unrelated to geography. Purist will be happy to note that the .IN top level domain for India has been registered and the sites we are dealing with that are Physically in India are being converted to that domain (including shakti). The use of shakti.uu.net is a transitional convenience. Remember that, uunet != all uucp sites != all usenet sites (although I'm working on it...) ---rick  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Jan 90 23:11:09 EST Received: from nnsc.nsf.net by mintaka.lcs.mit.edu id aa00579; 5 Jan 90 22:50 EST To: raf@cu.nih.gov cc: header-people@mc.lcs.mit.edu Subject: re: .BITNET domain Date: Fri, 05 Jan 90 08:14:49 -0500 From: Craig Partridge Message-ID: <9001052250.aa00579@mintaka.lcs.mit.edu> > My original question is why are these policies not enforced > consistently with respect to FIDONET.ORG and UU.NET? Why is an Indian > host named shakti.uu.net acceptable while a similarly named BITNET host > is not? If shakti isn't a host involved in running uu.net it isn't acceptable use. (I don't personally know the status of shakti). As for enforcement, that's a tricky question. It isn't clear there is an enforcement mechanism, short of turning off uu.net at the root domain servers -- that's a rather extreme act. All the more reason for the NIC to be careful about who it gives .NET domains to. >> PPS: As I recall, the BITNET plan was to revise the mail software to >> map domain names into the fixed-length BITNET ids. So there'd be >> a step where the name vm.cuny.edu would map into an envelope address >> CUNYVM that only the BITNET mailer would see; never the user. >> Unknown addresses would be mapped to Interbit gateways which would >> forward or reject them as appropriate (hacks like checking the right >> side of unknown domain names against lists of known top-level domains >> were to be used to limit the amount of bad mail being sent to gateways). > This is pretty much the way it works. But only for email. Why only for e-mail? It would seem to me that if a conversion scheme exists, you ought (in principle) to be able to fit it into the user interface of other protocols. My internet address is 128.89.1.178 -- but I can type nnsc.nsf.net to telnet.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU; 6 Jan 90 00:53:04 EST Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 6 Jan 90 00:53:09 EST Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa03955; 6 Jan 90 0:50 EST Received: by garnet.berkeley.edu (5.57/1.32) id AA25210; Fri, 5 Jan 90 21:50:39 PST Date: Fri, 5 Jan 90 21:50:39 PST From: Postmaster & BITINFO Message-Id: <9001060550.AA25210@garnet.berkeley.edu> To: header-people@ai.ai.mit.edu, postmaster@uunet.uu.net, RAF@cu.nih.gov Subject: Re: w/r/t Ned's reply In reply to: From: "Roger Fajman" Date: Thu, 04 Jan 90 21:07:50 EST Subject: Re: w/r/t Ned's reply ... In my opinion, there's too much Internet-centric thinking on the issue. BITNET is not the Internet. Yes, BITNET is not the Internet. But, the VM Mailer system and clones are part of the Internet Mail System. Thus, we need to adopt Internet policies and procedures for the BITNET VM Mailer System. I prefer to encourage BITNET/EARN/NETNORTH/ASIANET net sites to become part of the Internet mail system by registering an internet domain name and implementing the appropriate internet software. Defining a network domain name is inappropriate for the following reasons: a. We will soon have hundreds of BITNET sites on the Internet as internet nodes. b. It is inappropriate to be sending mail from the internet via the BITNET to a directly connected internet site. This is already accords because network dependant addresses are given to users. We need network independant addresses to allow routing to be determined by site, not networks. c. Network domain names do not allow for direct routing to a site gateway on the internet. d. Listing each node of a network in the Internet nameserver is more work than listing wild-card entries by site. (BITNET only lists country domains by country, it should also allow entries by sites in the DOMAIN NAMES file, but then that is also more work). ---- So where does shakti.uu.net come into it? I've also seen mail come from intercon.uu.net (but not recently). It is not authorized, but it works because the uu.net nameserver has a wild-card entry for *.uu.net. If I was the postmaster at uunet.uu.net I would remove that wild card entry. ---- Bill Wells postmaster@jade.berkeley.edu netinfo@garnet.berkeley.edu PS. The opinions expressed above are my own.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Jan 90 05:47:38 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa03064; 6 Jan 90 0:15 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1914; Sat, 06 Jan 90 00:15:04 EST Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 8069; Sat, 06 Jan 90 00:15:03 EST Date: Fri, 05 Jan 90 21:14 PST To: Craig Partridge Cc: header-people@mc.lcs.mit.edu From: Leonard D Woren Subject: Re: .BITNET domain Message-ID: <9001060015.aa03064@mintaka.lcs.mit.edu> On Fri, 05 Jan 90 08:14:49 -0500, Craig Partridge said: > >> (discussion of mapping domain names to bitnet node names deleted) > > This is pretty much the way it works. But only for email. > > Why only for e-mail? It would seem to me that if a conversion scheme > exists, you ought (in principle) to be able to fit it into the user > interface of other protocols. My internet address is 128.89.1.178 -- but > I can type nnsc.nsf.net to telnet. Yes, in principle. Bitnet E-mail uses programs written by Bitnet people, not vendors, so it can be made to do what we need, and in finite time rather than in geologic time. Other services (file transfer and interactive messaging) use facilities supplied by vendors, generally without source code. For TSO, it should be possible to write a front end to the TRANSMIT command to allow domain names to be used. I suspect that everyone is waiting for someone else to do it. I could write it, but it's low on my priority list, since I think that Bitnet has leapt too fast into domain names.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Jan 90 14:09:42 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa24217; 6 Jan 90 13:59 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA18823; Sat, 6 Jan 90 14:57:34 -0400 Message-Id: <9001061857.AA18823@alw.nih.gov> To: craig@nnsc.nsf.net Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Sat, 06 Jan 90 13:58:58 EST Subject: re: .BITNET domain > >> PPS: As I recall, the BITNET plan was to revise the mail software to > >> map domain names into the fixed-length BITNET ids. So there'd be > >> a step where the name vm.cuny.edu would map into an envelope address > >> CUNYVM that only the BITNET mailer would see; never the user. > >> Unknown addresses would be mapped to Interbit gateways which would > >> forward or reject them as appropriate (hacks like checking the right > >> side of unknown domain names against lists of known top-level domains > >> were to be used to limit the amount of bad mail being sent to gateways). > > > This is pretty much the way it works. But only for email. > > Why only for e-mail? It would seem to me that if a conversion scheme > exists, you ought (in principle) to be able to fit it into the user > interface of other protocols. My internet address is 128.89.1.178 -- but > I can type nnsc.nsf.net to telnet. Yes, in principle, it can be done for the other protocols and it should be. But the current reality is that it hasn't. I made a proposal myself to enhance BSMTP to support BITNET-style file transfer with domain names. But that proposal has not been adopted and no others have been put forward. One problem is that there still is no mechanism for adopting standards for BITNET. Another problem is that no one is stepping forward to write the software. We can't do it, as our environment is not typical of BITNET, in which IBM VM and VAX VMS systems predominate. Given the current state of things, there is a strong motivation for a system with both BITNET and Internet connections to support domain names on BITNET as well as the Internet. But for systems with only a BITNET connection, domain names are currently something of a negative, because of the lack of support for file transfer and interactive messages.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Jan 90 16:45:55 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa29011; 6 Jan 90 16:26 EST Received: from svarte.uio.no by ifi.uio.no (5.61++/1.15) with SMTP id AA04547; Sat, 6 Jan 90 22:25:33 +0100 Date: Sat, 6 Jan 90 22:25:33 +0100 From: Erik Naggum Sender: enag@ifi.uio.no To: header-people@mc.lcs.mit.edu Subject: .BITNET and the Internet Summary: The problem should be solved at the gateways. Message-Id: <90-006-1521@uunic.uu.no> There have been gripes about a certain Internet-centricity in this discussion. This is certainly right -- the Internet has a full body of standards, and if you want to play, you have to follow the rules. However, none of the people who write these standards try to enforce their view on networks who borrow good ideas, or just look similar to Internet ways in certain application. An occasionally squeeking spectator in the RFC 1122/3 work, I saw that it was hard enough to get the Old Network Boys to consider other networks at all. It took me some time to realize that it wasn't really their business to care about these other networks who were nevertheless likely to follow their lead, anyway. IMHO, this is the problem that e.g. Roger Fajman has. As far as the Internet is concerned, you can mangle your mail headers all you want as long as you are not travelling on the Internet. If some user wants to see "FOOBAR.BITNET" in his mail, and send to it, the underlying software should rewrite this to the equivalent domain name when the mail enters the Internet. Equivalently, you can talk ISO LATIN 1 with your computer, but you've got to talk ASCII with SMTP. A case in point. In Norway, we have a BITNET node called NOBIVM, which has the domain name BI.NO. The MX for BI.NO is runix.runit.sintef.no, which NOBIVM also talks to to send mail (BITNET-wise, it is NORUNIX, I believe). As I see it, this mail gateway should translate "NOBIVM" to "BI.NO" on outgoing mail and "BI.NO" to "NOBIVM" on incoming mail (as seen from the BITNET side). The mail gateway has to do a lot of header massaging, anyway. Users on the BITNET site should be informed that they have two different addresses, a BITNET address and an Internet address, where the latter is preferable to hand out to other people. (Not dissimilar to having a telephone number and a telex number, is it?) I think we have to take cognizance of the fact that we deal with different networks, all of which are not able to go domain-based very soon. My base experience is with UUCP (which is no more than a point-to-point transfer protocol and should never have been used for mail addressing, in my opinion). Even though the UUCP world is moving to domains, when you issue UUCP commands, you still have to use the "link-level" uucp node name. Knowing that "uunic.uu.no" is "naggum" in this way is not intuitive, but we won't be able to rewrite our uucp software to ask sundry domain name servers about what is what. Isn't this exactly similar to the BITNET problem? There are a lot fewer BITNET <-> Internet gateways than there are BITNET sites, so why not publish the domain name of a BITNET site in their map data bases or whatever, and then the gateways know what to do? As far as I know, BITNET is a lot more well-defined than the aggregate of UUCP sites (in the absence of a "UUCP Network"). Then, when the gateways are upgraded, we (who? :-) enforce the requirements implicit in RFC 821/2 and explicit in RFC 1123 about Fully Qualified Domain Names, so that .BITNET becomes non-functioning in addition to its long standing as illegal. We should do the same with .UUCP. Note that we preserve the old BITNET (and UUCP) ways as long as we operate within their respective networks (or "networks"), and that the User Agent can do what it wants, including, as one participant noted, supporting .BITNET to the user. There already exists software in the UUCP world to support .UUCP to the user, and gateways solve this problem. Is BITNET so fundamentally different? I think we could perhaps learn something from the telephone people who split area codes. Graceful transitions, if you ask me. It seems a lot rougher on the users with e-mail "splits". All of this is of course my opinion, not official Internet policies. [Erik]  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU; 6 Jan 90 21:57:53 EST Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 6 Jan 90 21:58:04 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa08649; 6 Jan 90 21:53 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA19211; Sat, 6 Jan 90 22:51:39 -0400 Message-Id: <9001070251.AA19211@alw.nih.gov> To: header-people@ai.ai.mit.edu From: Roger Fajman Date: Sat, 06 Jan 90 21:52:56 EST Subject: Re: w/r/t Ned's reply > Yes, BITNET is not the Internet. But, the VM Mailer > system and clones are part of the Internet Mail System. > Thus, we need to adopt Internet policies and procedures for the > BITNET VM Mailer System. Well, what the Columbia Mailer and it's relatives send to the Internet ought to conform to Internet standards. And it pretty much does, at least as well as most other things do. What is done on BITNET is not subject to Internet standards unless BITNET chooses to adopt those standards as it's own in whole or in part. > b. It is inappropriate to be sending mail from the > internet via the BITNET to a directly connected internet site. > This is already accords because network dependant addresses are > given to users. We need network independant addresses to allow > routing to be determined by site, not networks. Exclusive use of network-independent addresses is not possible given the current state of protocol definition and software implementation. People are not going to give up transfering files and sending interactive messages on BITNET. Those things cannot be done with domain names today. If you really want network independent addressing, support the efforts of myself and others to standardize the necessary protocols for BITNET. > d. Listing each node of a network in the Internet nameserver > is more work than listing wild-card entries by site. (BITNET only lists > country domains by country, it should also allow entries by sites in > the DOMAIN NAMES file, but then that is also more work). Yes, it definitely is more work. Someone would have to write a piece of software to extract the necessary information for the name servers from BITEARN NODES. This is a considerably smaller job than converting BITNET entirely to domains and could be viewed as part of a transition effort. It would have the beneficial effect of avoiding the mention of specific gateways in addresses.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Jan 90 23:31:04 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa08934; 6 Jan 90 22:01 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA19215; Sat, 6 Jan 90 22:59:43 -0400 Message-Id: <9001070259.AA19215@alw.nih.gov> To: erik.naggum@uunic.uu.no Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Sat, 06 Jan 90 22:01:01 EST Subject: Re: .BITNET and the Internet > There have been gripes about a certain Internet-centricity in this > discussion. This is certainly right -- the Internet has a full body > of standards, and if you want to play, you have to follow the rules. > However, none of the people who write these standards try to enforce > their view on networks who borrow good ideas, or just look similar to > Internet ways in certain application. An occasionally squeeking > spectator in the RFC 1122/3 work, I saw that it was hard enough to get > the Old Network Boys to consider other networks at all. It took me > some time to realize that it wasn't really their business to care > about these other networks who were nevertheless likely to follow > their lead, anyway. IMHO, this is the problem that e.g. Roger Fajman > has. No, my meaning was simply that Internet standards do not automatically apply outside the Internet. Some people seem to think they do. When you are considering a gateway between two networks, then the needs of both networks have to be considered. This is not the subject of RFCs 1122 and 1123. Or RFCs 821 and 822, for that matter.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Jan 90 20:13:07 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa25225; 7 Jan 90 7:57 EST Received: from slembe.uio.no by ifi.uio.no (5.61++/1.15) with SMTP id AA09062; Sun, 7 Jan 90 13:57:16 +0100 Received: by slembe.uio.no (5.61++/SMI-3.2) id AA20185; Sun, 7 Jan 90 13:57:14 +0100 Date: Sun, 7 Jan 90 13:57:14 +0100 From: Erik Naggum Sender: enag@ifi.uio.no To: Roger Fajman Cc: header-people@mc.lcs.mit.edu In-Reply-To: <9001070259.AA19215@alw.nih.gov> ""Roger Fajman" " Subject: .BITNET and the Internet Message-Id: <90-007-0432@uunic.uu.no> No, my meaning was simply that Internet standards do not automatically apply outside the Internet. Some people seem to think they do. Some people outside the Internet want to follow Internet standards as long as they fit their networks. The Internet application layer is useful and good not only for the Internet. RFC 822, for instance. Other than this admittedly minor nit, I think we are in agreement. When you are considering a gateway between two networks, then the needs of both networks have to be considered. This is not the subject of RFCs 1122 and 1123. Or RFCs 821 and 822, for that matter. Exactly my point. However, you didn't come across (to me, anyway) saying this in your previous messages. So, it is decided, then. .BITNET as a top-level Internet domain is bad idea, and gateways do the necessary work. [Tongue in cheek.] [Erik]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Jan 90 20:15:16 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa00949; 7 Jan 90 12:43 EST Date: Sun 7 Jan 90 12:40:08-EST From: John C Klensin Subject: Re: Re: .BITNET and the Internet To: RAF@cu.nih.gov Cc: header-people@mc.lcs.mit.edu Message-ID: <631734008.460000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9001070259.AA19215@alw.nih.gov> Mail-System-Version: >No, my meaning was simply that Internet standards do not automatically >apply outside the Internet. Some people seem to think they do. Curiously, this problem does not originate from the Internet side of the boundary, but from the "other" side. Let me use BITNET, specifically the VM/CMS systems that have dominated its design, as an example, since I know something about it, but I suspect that the UUCP and other histories are similar. When the time came to do a MAIL command for VM/CMS BITNET, that command was done by people who were already familiar with Internet mail and liked (at least because they were used to it) the general style in which Internet mail (and one or two implementations in particular) worked. So they imitated it: because it was familiar, because it was demonstrated to work, and because, as has been mentioned, it was well-documented and well- understood. I imagine that the origins of the Crosswell MAILER were much the same--an attempt to simulate, as nearly as possible, the Internet facility on BITNET. And that--the combination of Internet experience, Internet documentation, and probably a certain amount of Internet-envy-- is what has produced Internet-centric notions on BITNET. The problem, as I've said many times before in other forums, is that these decisions, while understandable, may not be correct ones. BSMTP, for example, is more or less a strict translation of SMTP (RFC821) into batch transmission terms. However, as such, it fails to capture two kinds of things. The first of these is the very nature of SMTP as an *interactive* protocol, working over virtual circuits. That distinction means that there are a series of strategies available to SMTP for dealing with errors and non-delivery problems that are not available to BSMTP. And, because BSMTP is essentially a translation and sequencing, there are no sensible alternatives. The second is that a number of things that are unique to BITNET (or BITNET-like networks)--things that are meaningless on the Internet--probably ought to be reflected in the BSMTP envelope so that MAILERs and gateways can take advantage of them, but, largely because of the "translation" problem, haven't been. The example that is relevant to the recent discussion is that it would be possible for the BSMTP envelope to contain: My-hosts-NJE/rscs-address-is: My-hosts-DNS-name-is: The-DNS-name-represents-an-A-record. The-appropriate-gateway-from-the-Internet-is: Errors-to: and a series of similar things. I'm not suggesting that any particular one of these would be a good idea, only that this sort of thing would provide MAILERs and gateways with a lot of information that they don't have and that they could take good advantage of. I am also suggesting that, because of Internet-centricity ON THE BITNET DESIGN SIDE, these types of BSMTP extensions, and their MAILER implications, have not been seriously addressed at the right times and by the right people. These things are not needed on the Internet because the addressing model is different, the MTA model uses virtual circuits rather than host-to-host store-and-forward, etc. It is also interesting to note that this discussion--once again--is occurring on an Internet list--header-people--and that, in my limited experience, it tends to vanish without a trace when it shows up on the BITNET INTERBIT and FUTURE-L and similar lists. In addition, and compounding the problem, is the fact that Internet RFCs go through a stage of being just that--more or less widely-circulated documents available for comment. BSMTP, to use that example again, is not written down, and is treated as a private agreement among MAILER maintainers. That approach has some advantages, but reflection by, and comment from, a large variety of perspectives is not one of them. >When you are considering a gateway between two networks, then the needs >of both networks have to be considered. This is not the subject of >RFCs 1122 and 1123. Or RFCs 821 and 822, for that matter. Fortunately, the only thing that one network can rationally say about others is to specify the form that messages (or whatever) take once they cross into one's own network. That is what these RFCs and others do about, e.g., BITNET traffic, which is to say--or try to say--what those messages must look like when they traverse the Internet. From an Internet perspective, it would also be possible to say "look, folks, if you were part of our network, and used our network-layer protocols, then you could really simulate our applications-level protocols". In other words, if BITNET dropped this RSCS/NJE stuff and ran TCP/IP, a lot of problems-- with respect to the Internet--would vanish. That statement is true, but useless and *really* Internet-centric and, fortunately, I haven't heard it much lately. Let me stress that I favor Roger's approach that BITNET should develop some protocols that, while adapted from Internet ones if appropriate, really reflect BITNET requirements, including requirements for proper handling of error conditions (especially those resulting from the actions of sophisticated and distributed list-expanders) and reasonable behavior at gateway-boundaries to networks for which there are multiple plausible gateways. Finally, it has been suggested that part of the BITNET problem is that DNS addressing works only for mail, and that it would be more widely accepted if it worked for file transfer and interactive messaging also. I suggest that the first-level problem is easier than it appears but that there is a second-level problem that makes things much more difficult. If CMS is representative, equipping SENDFILE and TALK with a table lookup that would accept DNS names and translate them into NJE addresses (i.e., the eight-character things) would be pretty easy (under a day's work). I know, I just looked at the code in SENDFILE. There are some efficiency and performance issues associated with opening and searching large files (this lookup has to occur in file whose size is 'one BITNET/EARN/etc node, one , but it is not clear how big a problem that really is. So: could it be done? Sure, it is just a matter of someone getting motivated. If someone could solve the "other" problem, I'd do it myself to prove it. Part of the "real" problem is that, while OSI model clearly involves layered protocols, and TCP/IP is reasonably well layered, some features of NJE/RSCS more or less encourage users to deal directly with what we would normally think of as the network and transport layers, and discussions with them have to be in terms of host addresses, just as the TCP/IP versions at those levels use IP addresses, not host names. Providing applications- level code to do the right thing and hide this is not particularly hard, but convincing users to change their ways might be. For that reason, the comment above describes SENDFILE and TALK, and does not mention PUNCH and SMSG. If a user has execs, or commands, or habits, that addresses these lower levels (I realize that the analogies are not exact, but let's not quibble) then he or she is going to need to know that the low-level stuff must use BITNET names, while the upper-level stuff may (or must) use DNS names. And the re-education job is a tough one. It is much easier to change software than it is to change user knowledge, behavior, and entry', not one the size of DOMAIN NAMES) environments. But, while it is an issue that should not be underestimated, that is just a symptom. The greater difficulty is that there is a case to be made that there are some things that it is not appropriate to make transparent. For example, while mail is, within a close approximation, mail, the BITNET file-sending model is not analogous to Internet FTP and, although it is done frequently, hiding file transfers in mail messages has always been viewed as being in bad taste on the Internet. I think I might rather explain to a BITNET user that SENDFILE is a low-ish level facility and that, to use it, one needs to address a host by its BITNET name although mail works better using a DNS name than to try to explain to that same user why the set of names that works with SENDFILE is a proper, and lexically unpredictable, subset of the names that work with MAIL. I'm not saying that it cannot be done, only that one would want to think carefully about the model, the supporting tools, the documentation, and the error messages. Fortunately or not, mail is the unusual case in which differences in protocols can be smoothed over (even if we have not done it as well as we might have wanted to). In the other cases, the Internet and OSI models are dominated by logics that depend on virtual circuits: "I've got this for you, are you willing to accept it?" protocol styles, rather than "here it comes, like it or not" styles. BITNET does not have the former, nor has it evolved appropriate protocol surrogates. For example, it would be possible, within the BITNET model (albeit at the price of tampering with fairly low-level vendor-supplied code), for me to have accounting records that specified whom I was, or was not, willing to receive a file from. Using those as an FTP-surrogate might still require taking up the bandwidth needed to transfer the file before it was rejected (unlike FTP, which does not permit the transfer to start), but it would be a step in the right direction. It would even be possible to structure things so that those accounting records could be checked, via interactive messaging, one RSCS process to another before data was actually sent, or to invent "BFTP", with target file names and directories, passwords, etc. But none of those things has been done, and the blame for that certainly does not lie with the Internet community. John Klensin Klensin@INFOODS.MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Jan 90 20:17:59 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa05393; 7 Jan 90 15:30 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA19835; Sun, 7 Jan 90 16:28:10 -0400 Message-Id: <9001072028.AA19835@alw.nih.gov> To: erik@naggum.uu.no Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Sun, 07 Jan 90 15:30:30 EST Subject: Re: .BITNET and the Internet > So, it is decided, then. .BITNET as a top-level Internet domain is > bad idea, and gateways do the necessary work. [Tongue in cheek.] > > [Erik] Tongue not in cheek, I see several possibilities: (1) Leave things as they are, with Internet users using explicit gateway names in addresses, unless the BITNET node happens to have its own domain name. Gateway names are difficult to change and mail sometimes takes very non-optimal paths. (2) Use a Fidonet-style solution of something like user@node.gateway-domain (.BITNET, .BIT.NET, .BITNET.ORG, .CREN.ORG, or whatever). The BITNET node name is embedded in the address, so the gateway does not have to keep a translation table. With MX records, different BITNET nodes could be serviced by different gateways. Gateways could be changed without impacting users. BITNET nodes with their own domain names would continue to use them. Gateway software to support this would have to be developed. (3) Force all BITNET nodes to have a domain name. Gateways would maintain a translation table between BITNET node names and domain names. This avoids the need for all BITNET nodes to have software capable of handling domain names. BITNET users would have to know two names for their node. The necessary gateway software would need to be developed. (4) Force all BITNET nodes to have a domain name and to install software capable of using it for mail. Other BITNET services (file transfer and interactive messages) would continue to use BITNET node names. BITNET users would have to know two names for their node. Software for some BITNET environments would need to be developed. (5) Enhance BITNET protocols so that they support domain names for all services. Develop the necessary software to support the protocols. Eventually force all BITNET nodes to have a domain name and install the software to support it. BITNET users would use only domain names. The BITNET routing table could be reduced to one gateway node per site. Option (5) is what was recommended by the BITNET Domains Task Force. This recommendation was never adopted by the BITNET Board. These options are not all mutually exclusive. Personally, I favor (5) with (2) as a transition aid.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Jan 90 22:30:15 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa05324; 7 Jan 90 15:28 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA19831; Sun, 7 Jan 90 16:26:26 -0400 Message-Id: <9001072026.AA19831@alw.nih.gov> To: erik@naggum.uu.no Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Sun, 07 Jan 90 15:28:31 EST Subject: Re: .BITNET and the Internet > No, my meaning was simply that Internet standards do not automatically > apply outside the Internet. Some people seem to think they do. > > Some people outside the Internet want to follow Internet standards as > long as they fit their networks. The Internet application layer is > useful and good not only for the Internet. RFC 822, for instance. > Other than this admittedly minor nit, I think we are in agreement. Yes, of course, RFC 822 and a few others have been used outside the Internet when appropriate. And I agree that the Internet is under no obligation to accomodate such use, although it may wish to do so anyway. Sometimes it has done so. It's up to each network to decide which Internet standards, if any, it would like to use and which parts of those standards. For example, although BITNET uses RFCs 821 and 822, not everything in them applies to BITNET. Unfortunately the differences are not formally specified. I, too, don't see any serious disagreement here. As an aside, perhaps someone could explain why RFC 821 (SMTP) calls for only a 7 bit data path, instead of the 8 bit path supplied by TCP. Here are some interesting quotes from RFC 821: 1. INTRODUCTION The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Appendices A, B, C, and D describe the use of SMTP with various transport services. A Glossary provides the definitions of terms as used in this document. An important feature of SMTP is its capability to relay mail across transport service environments. A transport service provides an interprocess communication environment (IPCE). An IPCE may cover one network, several networks, or a subset of a network. It is important to realize that transport systems (or IPCEs) are not one-to-one with networks. A process can communicate directly with another process through any mutually known IPCE. Mail is an application or use of interprocess communication. Mail can be communicated between processes in different IPCEs by relaying through a process connected to two (or more) IPCEs. More specifically, mail can be relayed between hosts on different transport systems by a host on both transport systems. APPENDIX D X.25 Transport service It may be possible to use the X.25 service [7] as provided by the Public Data Networks directly, however, it is suggested that a reliable end-to-end protocol such as TCP be used on top of X.25 connections. > When you are considering a gateway between two networks, then the needs > of both networks have to be considered. This is not the subject of > RFCs 1122 and 1123. Or RFCs 821 and 822, for that matter. > > Exactly my point. However, you didn't come across (to me, anyway) > saying this in your previous messages. I had gotten the feeling that some people thought only the needs of the Internet are worth considering.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Jan 90 22:35:07 EST Received: from maui.engin.umich.edu by mintaka.lcs.mit.edu id aa04440; 8 Jan 90 8:50 EST Received: by caen.engin.umich.edu (5.59.1/caen.0.9) id 47e98d51d.0017b5e; Mon, 8 Jan 90 08:48:51 EST Message-Id: <47e98d51d.0017b5e@caen.engin.umich.edu> To: Craig Partridge Cc: header-people@mc.lcs.mit.edu Subject: Re: .BITNET domain In-Reply-To: Your message of Thu, 04 Jan 90 14:07:52 -0500. <9001041410.aa09111@mintaka.lcs.mit.edu> Date: Mon, 08 Jan 90 08:48:49 -0500 From: paul killey You write ... "...there was, for a couple of years, a very large and prestigious university that had two hosts, named .BITNET and .CSNET which were not connected to each other. Every week, the e-mail admins of the two machines held a tape swap to exchange mis-delivered mail. I kid you not." umich.csnet was a vax running unix in electrical and computer engineering and umich.bitnet was a vax running vms in the physics department. I made tapes for the physics people and read the ones they brought over. I don't know if that's the case you knew about, but it is a true story. This was a while ago, when we had just gotten on csnet via dialup, etc. After several years of "advances" in e-mail I have to admit that the setup we had then (we called it MAGnet, of course) now has a certain primitive appeal. -:) --paul  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Jan 90 01:08:03 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id aa02123; 8 Jan 90 20:16 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5073; Mon, 08 Jan 90 20:16:22 EST Received: from ACADVM1.UOTTAWA.CA by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 2867; Mon, 08 Jan 90 20:16:21 EST Received: by UOTTAWA (Mailer R2.04) id 7740; Mon, 08 Jan 90 20:15:59 EST Date: Mon, 8 Jan 1990 20:15:43 EST From: Neil Duffee Subject: Re: .BITNET suffix, etc. To: HEADER-PEOPLE@MC.lcs.mit.edu Message-ID: <9001082016.aa02123@mintaka.lcs.mit.edu> ----> this originally was sent to MAIL-L but found that I was ----> also getting the same discussion here on header-people. ----> So.... thought that the other half might like a chance ----> to shoot me down too. ;-> Well, I've learned a massive amount in following this discussion and appreciated the bits of history lessons that were included for people such as myself. I know this will continue on since the resolution will be a major one no matter the course of action chosen. However, my two cents worth. In all this reading, I've come to the conclusion that most of us are attempting to compare oranges and apples in the internet vs Bitnet discussion. One of the beauties of the internet is the use of wildcards to reduce routing tables (not the best word here, but given my personal Bitnet background, understandable) with items such as: *.INSTITUTE.EDU - that will point to a single sub-net 'gateway'. (really, please excuse my vocabulary here, I've picked up a lot about the internet but NOTHING beats hands-on and daily use.) A real problem with internet/Bitnet/UUCP/etc. gatewaying is that SEVERAL gateways are desirable. Fidonet.Org has been used as an example but I'll bet my bottom dollar that the MX-records resemble: *.z1.fidonet.org *.z2.fidonet.orf *.z3.fidonet.org *.fidonet.org - just in case - since fidonet already seems to be physically divided by naming conventions into these differing zones. This, obviously, cannot be used in reference to Bitnet/etc due to its flat naming space. Also, registering '*.host1.bitnet.org' is non-viable since Bitnet itself is suffering under a burgeoning routing table of 2.5K+. To suggest that the internet add this to their list - not reasonable. However, I'm not without a suggestion but it will require more expertise knowledge of the internet gurus for help. This is because I've not been able to determine exactly what a name server is and how it works. (I wouldn't mind private mail on this from any and all with a summary forwarded to any and all that give me a private mail request to be included. ANYthing to keep the minor details out of the mainstream discussion. :) My belief and understanding is that the name server will supply an MX (or A) record on demand. (in the most simplest of terms) Proposal: that an entry such as: *.BITNET.ORG ns=cunyvm.cuny.edu pref=10 (or however the order of ns=cornellc.edu pref=20 ( preference is given ns=other.interbit.org pref=30 - with the preference changing for each internet host to point the the nearest 'official' INTERBIT gateway. Thus each Mail Transfer Agent (MTA) can query the name server with UOTTAWA.BITNET.ORG and be provided with the proper MX to the gateway closest to the Bitnet host and, purportedly, the best routing. This would allow the gateways to blithely add '.BITNET.ORG' to mail from Bitnet and remove it from internet mail. The internet address need not changed since the top-level domains are resolvable for Bitnet mailers. Any replies for list mail to the original submitter will also be sent through a more appropriate gateway rather than the gateway that the LISTSERVer used (usually half way 'round the world, too). This would easily be adapted to other networks since only 4-5 entries are required to cover the top-levels of *.com, *.org, *.edu, *.mil, *.net. This obviously won't work if my understanding of name servers stinks. However, is it at least on the right track? Discussion? (hah, as if I really need to ask, eh?) ---------------> signature = 9 lines follows <------------------- Neil Duffee System Operator, U. of Ottawa, Ottawa, Ontario, Canada BITNET: NJD2D@UOTTAWA .CA DOMAIN: njd2d@acadvm1.uottawa.ca (requires MX records) or: njd2d%acadvm1.uottawa.ca@ugw.utcs.utoronto.ca (explicit route) INTERNET: see .CA DOMAIN above UUCP: gatech!utai!uottawa.bitnet!njd2d COMPU$ERVE: >INET:njd2d@acadvm1.uottawa.ca 'If I was allowed an opinion, you'd be the first to hear about it.' Neil Duffee MAIL-L@MARIST 1/05/90*.BITNET suffix, etc. ---------------> signature = 9 lines follows <------------------- Neil Duffee System Operator, U. of Ottawa, Ottawa, Ontario, Canada BITNET: NJD2D@UOTTAWA .CA DOMAIN: njd2d@acadvm1.uottawa.ca (requires MX records) or: njd2d%acadvm1.uottawa.ca@ugw.utcs.utoronto.ca (explicit route) INTERNET: see .CA DOMAIN above UUCP: gatech!utai!uottawa.bitnet!njd2d COMPU$ERVE: >INET:njd2d@acadvm1.uottawa.ca 'If I was allowed an opinion, you'd be the first to hear about it.' Acknowledge-To:  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Jan 90 03:33:30 EST Received: from [128.32.136.6] by mintaka.lcs.mit.edu id aa11456; 8 Jan 90 23:48 EST Received: by garnet.berkeley.edu (5.57/1.32) id AA03606; Mon, 8 Jan 90 20:48:16 PST Date: Mon, 8 Jan 90 20:48:16 PST From: Postmaster & BITINFO Message-Id: <9001090448.AA03606@garnet.berkeley.edu> To: header-people@mc.lcs.mit.edu, RAF@cu.nih.gov Subject: Re: .BITNET and the Internet I believe the node management plan is to have the internet domain name (and X.400 information) defined in the BITNET/EARN/NETNORTH "NODES" file as proposed in "NODES File Format and Contents (of the 1989 version)" by Berthold Pasch. (File NODETAGS DESCRIPT from the NETSERV fileserver). The ":internet" tag is defined in section 2.3.8 on pages 21-22. These NODES files are not maintained by the gateway(s) but by the site that owns the node. Bill Wells NETINFO at UCBGARNE netinfo@garnet.berkeley.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Jan 90 03:39:09 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa14680; 9 Jan 90 0:59 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA24993; Tue, 9 Jan 90 01:57:37 -0400 Message-Id: <9001090557.AA24993@alw.nih.gov> To: netinfo@garnet.berkeley.edu Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Tue, 09 Jan 90 00:59:12 EST Subject: Re: .BITNET and the Internet > I believe the node management plan is to have the internet domain name > (and X.400 information) defined in the BITNET/EARN/NETNORTH "NODES" > file as proposed in "NODES File Format and Contents (of the 1989 > version)" by Berthold Pasch. (File NODETAGS DESCRIPT from the NETSERV > fileserver). The ":internet" tag is defined in section 2.3.8 on pages > 21-22. > > These NODES files are not maintained by the gateway(s) but by the site > that owns the node. > > Bill Wells > NETINFO at UCBGARNE > netinfo@garnet.berkeley.edu Yes, that's correct. However, it's not clear when that plan will be implemented.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Jan 90 03:39:43 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa15025; 9 Jan 90 1:10 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA25001; Tue, 9 Jan 90 02:08:22 -0400 Message-Id: <9001090608.AA25001@alw.nih.gov> To: netinfo@garnet.berkeley.edu Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Tue, 09 Jan 90 01:09:56 EST Subject: Re: .BITNET and the Internet > I believe the node management plan is to have the internet domain name > (and X.400 information) defined in the BITNET/EARN/NETNORTH "NODES" > file as proposed in "NODES File Format and Contents (of the 1989 > version)" by Berthold Pasch. (File NODETAGS DESCRIPT from the NETSERV > fileserver). The ":internet" tag is defined in section 2.3.8 on pages > 21-22. > > These NODES files are not maintained by the gateway(s) but by the site > that owns the node. > > Bill Wells > NETINFO at UCBGARNE > netinfo@garnet.berkeley.edu I replied too soon. Yes, what you say is correct. However, that mechanism would have to be extended to support a gateway capable of translating between domain addresses and BITNET addresses. The problem is that there is no indication of whether such a translation is desired or not. Many sites currently supporting domains for mail on BITNET would not want the translation to be performed. It's also true that it's not clear when the new BITEARN NODES format will be implemented.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Jan 90 03:42:00 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa15675; 9 Jan 90 1:30 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA25018; Tue, 9 Jan 90 02:28:03 -0400 Message-Id: <9001090628.AA25018@alw.nih.gov> To: KLENSIN@infoods.mit.edu Cc: header-people@mc.lcs.mit.edu From: Roger Fajman Date: Tue, 09 Jan 90 01:29:37 EST Subject: Re: Re: .BITNET and the Internet > But, while it is an issue that should not be underestimated, that is just > a symptom. The greater difficulty is that there is a case to be made that > there are some things that it is not appropriate to make transparent. For > example, while mail is, within a close approximation, mail, the BITNET > file-sending model is not analogous to Internet FTP and, although it is > done frequently, hiding file transfers in mail messages has always been > viewed as being in bad taste on the Internet. I think I might rather > explain to a BITNET user that SENDFILE is a low-ish level facility and > that, to use it, one needs to address a host by its BITNET name although > mail works better using a DNS name than to try to explain to that same user > why the set of names that works with SENDFILE is a proper, and lexically > unpredictable, subset of the names that work with MAIL. I'm not saying > that it cannot be done, only that one would want to think carefully about > the model, the supporting tools, the documentation, and the error messages. I have also worried about this problem. However, it's not a new one. FTP and Telnet work with some hosts and not others (i.e., those with a domain name and MX record, but no IP address). One of the benefits of adopting domain names on BITNET is reducing the size of the routing tables by having only one gateway node per site. This cannot be done if users continue to use NJE node names. The Internet could decide that it would like to facilitate file transfer gateways with other networks by defining an Internet file transfer protocol that works in a manner analogous to mail. This could be a new protocol, an addition to SMTP, or an extension to RFC 822 to allow attached files. The concept of attaching files to a mail message is popular in LAN email systems for PCs. Unfortunately, such an enhancement to the Internet protocol suite seems unlikely at the present time. Yes, of course, there's UUENCODE and it's relatives, but they are not user friendly.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Jan 90 14:32:57 EST Received: from nnsc.nsf.net by mintaka.lcs.mit.edu id aa13033; 9 Jan 90 14:29 EST To: raf@cu.nih.gov cc: header-people@mc.lcs.mit.edu Subject: re: .BITNET domain Date: Fri, 05 Jan 90 08:14:49 -0500 From: Craig Partridge Message-ID: <9001091429.aa13033@mintaka.lcs.mit.edu> > My original question is why are these policies not enforced > consistently with respect to FIDONET.ORG and UU.NET? Why is an Indian > host named shakti.uu.net acceptable while a similarly named BITNET host > is not? If shakti isn't a host involved in running uu.net it isn't acceptable use. (I don't personally know the status of shakti). As for enforcement, that's a tricky question. It isn't clear there is an enforcement mechanism, short of turning off uu.net at the root domain servers -- that's a rather extreme act. All the more reason for the NIC to be careful about who it gives .NET domains to. >> PPS: As I recall, the BITNET plan was to revise the mail software to >> map domain names into the fixed-length BITNET ids. So there'd be >> a step where the name vm.cuny.edu would map into an envelope address >> CUNYVM that only the BITNET mailer would see; never the user. >> Unknown addresses would be mapped to Interbit gateways which would >> forward or reject them as appropriate (hacks like checking the right >> side of unknown domain names against lists of known top-level domains >> were to be used to limit the amount of bad mail being sent to gateways). > This is pretty much the way it works. But only for email. Why only for e-mail? It would seem to me that if a conversion scheme exists, you ought (in principle) to be able to fit it into the user interface of other protocols. My internet address is 128.89.1.178 -- but I can type nnsc.nsf.net to telnet.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 10 Jan 90 19:41:48 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa21005; 10 Jan 90 19:38 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA04160; Wed, 10 Jan 90 20:35:24 -0400 Message-Id: <9001110035.AA04160@alw.nih.gov> To: HEADER-PEOPLE@MC.lcs.mit.edu From: Roger Fajman Date: Wed, 10 Jan 90 19:36:42 EST Subject: Naming with an Internet to BITNET Gateway Sorry to start this discussion again, but I can't resist copying the messages below from the TCP/IP list. It seems to be that the bottom line here is that CREN could, if it wished, register a domain name and offer an Internet to BITNET gateway service using names something like user@node.BITNET.CREN.ORG. While it is not in accordance with the intent of the DNS, it has been found to be expedient by other networks, such as SPAN and Fidonet. There's no reason why CREN should or would be treated differently. Presumably the implementors of such a gateway, if it is ever done, would wish to develop a program to construct the necessary MX records from the BITNET nodes data base so that the gateway nearest each BITNET node would be used. Roger Fajman Date: 9 Jan 90 17:45:42 GMT From: haven!uvaarpa!randall@purdue.edu (Randall Atkinson) Subject: Re: %-Hack .vs. Route Address In article <836@ccadfa.adfa.oz.au> cjsv@cs.adfa.oz.au (Christopher J S Vance) wr ites: >But it seems to me that you're only allowed to use route-addresses when all >the hosts are registered with the NIC. Since they won't want to register >every PC in the world, or even every mainframe on lots of networks which are >not on the Internet, it seems you've got to break some rules to make things >work. Personally, I think source-routes are nasty since they aren't pure >left-to-right or right-to-left. But then I've never had to use them.... Actually, any node on the GE internal DECnet can be reached as node.DNET.GE.COM and there are no A records or in fact IP addresses for virtually all of the machines on that network. The RFC states that you are only allowed to use route-addresses with fully-qualified domain names in registered domains. GE's solution is fairly general and requires only a single MX record pointing *.DNET.GE.COM to a relay-host directly on the Internet. There are special cases that won't be covered, but this solution DOES handle the case of PCs on an internal network or any other such situation. The main case it won't (legally) handle is gatewaying to a network whose machines aren't under your theoretical administrative control. NASA's SPAN DECnet is circumventing this by having *.SPAN.NASA.GOV and I heartily approve of NASA's solution even though many nodes on that DECnet aren't owned or operated by NASA. The %-hack is widely overused and I'd like to see it used only when really necessary because it causes a lot of mail delivery problems. Ran Subject: Re: %-Hack .vs. Route Address Date: Tue, 09 Jan 90 18:41:35 -0800 From: "Milo S. Medin" (NASA ARC NSI Project Office) (quote from previous message deleted) This was/is a hack to enable reasonable functionality for mail relay to SPAN systems. It's not the right thing to do, but was expedient. The reason it's not right is that SPAN is not run by a single organizational unit (to use OSIspeak). The right way of skinning the cat would be to use individual MX records for machines at sites to map them into the local domain name space of the facility. For example, a DECNET node named SAT located at Ames, should not be addressed at user@sat.span.nasa.gov, but user @sat.arc.nasa.gov. This way, if the machine happens to speak IP (as it does), it could be considered a CNAME for it's full hostname, or an MX record could be used that points mail at an Ames local MAIL-11 relay system. If you use an MX record for *.span.nasa.gov, then all of it has to go through a single mail relay. You can get into the case of a JPL host sending internet mail to a JPL DECNET host via a relay at ARC or GSFC. If the JPL DECNET host had an MX record in the jpl.nasa.gov subdomain, a more optimal path could be taken. I think JPL actually does this, but the point is the obvious. The problem with this is that it means having all the individual system administrators interacting with all the site domain managers and whoever runs a relay at the site to fix things so they work right, which is harder than fixing it once using the span.nasa.gov pseudodomain. The same reason holds why a .BIT.NET or .CS.NET (or maybe .ONE.NET these days I guess) is a bad idea. Those systems really should reside in a site's name local namespace. If people obeyed these rules, Internet mail delivery would be much more transparent, and the fact that a particular network (SPAN,BITNET,CSNET, etc...) was being used as transport would be hidden from the users. And that makes life easier on them. Why should 3 different forms of different address specifications be used to talk to 3 machines connected in different ways at one site? Thanks, Milo PS All the usual disclaimers about the government not being responsible for anything I say apply of course...  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 04:46:16 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa10672; 11 Jan 90 4:44 EST Date: Thu 11 Jan 90 04:41:06-EST From: John C Klensin Subject: Re: Naming with an Internet to BITNET Gateway To: RAF@cu.nih.gov Cc: HEADER-PEOPLE@mc.lcs.mit.edu Message-ID: <632050866.700000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9001110035.AA04160@alw.nih.gov> Mail-System-Version: >It seems to be that the bottom line here is that CREN could, if it >wished, register a domain name and offer an Internet to BITNET gateway >service using names something like user@node.BITNET.CREN.ORG. While it >is not in accordance with the intent of the DNS, it has been found to >be expedient by other networks, such as SPAN and Fidonet. There's no >reason why CREN should or would be treated differently. Roger, The discussion cited does not, fortunately or unfortunately, prove anything, nor does it really address anything not already discussed here. Let me try to summarize what I think all of this "means": (1) The DNS, as an operational mechanism, is technologically capable of supporting any of the .BIT.NET, .BITNET, etc., suggestions that have been made, with only one exception. The exception requires that MXs work the way INTERBIT does, i.e., that, when I make an inquiry about a given node, I get back an MX list, preference-ordered by how Internet-close I am to the gateway, rather than how BITNET-close the gateway is to the target host. (2) The historical Internet/DNS consensus has been that it is best if the Internet reflect administrative entities and domains, not geography or (worse) network topology. That consensus has generated a bias against host.BITNET (or spelling variations on that theme) in situations where "host" does not belong to the "BITNET administration" but, rather, to an academic or governmental entity. The bias is especially strong in the BITNET case, as distinct (historically) from, e.g., the SPAN case, because there are many gateways and, more important, most hosts exist in institutional settings that already have Internet connections and DNS domains, and because most of those BITNET hosts belong to the institution. (3) There is also a historical Internet/DNS consensus that use of CNAMEs to point from one domain to another, while desirable to have as an available facility for special cases and as a transitional mechanism, it is not a wonderful idea to use a great deal, partially because it creates confusion. There are many advantages associated with living in a "one host, one name" world, rather than having to guess whether a pair of names actually represent one address or whether they really represent two. This same principle is presumably the reason why CNAMEs exist at all--if you must have multiple names for the same host, one "real" name with some aliases pointing to it is preferable to, e.g., several (primary) names with the same A-records and IP addresses. (4) The combination of an "administrative domains" rule and the lack of an enforcement mechanism once a domain (at some level) is delegated and registered almost guarantees that there will be ambiguous situations and that little or nothing will be done about anything but the most flagrant of abuses. To a certain extent, if you own a domain, and want to abuse whatever informal principles there are in assigning host names within it, the most anyone is likely to do is to point out that it is a bad idea. And, of course, the abuses of the past are likely to be cited as precedents for the future. Equally naturally, people's sensitivity to marginal cases and abuses increases insofar as a given domain name gets closer to the root or causes multiple names for the same machine in contexts where people have to notice. The SPAN and HEPNET issue illustrates one of those ambiguities that is not pointed out in the material you forwarded. Among universities, there are many BITNET machines. Almost without exception, those machines belong to the universities, in every administrative sense of "belong" including ownership or lease-holding. On the other hand, there are many SPAN and HEPNET machines that, while resident on university campuses, "belong" to NASA or DOE financially and, in many respects, administratively. Now, are they part of the university's "administrative domain", or that of NASA or DOE? Possible to argue it either way and, if you conclude the latter, and then NASA comes along and says "*our* SPAN-type machines are administratively different from our 'internal' computers, and we want to handle them through a different administrative zone", then there is no reason to object to host.SPAN.NASA.GOV. Note that the strawman argument here does not mention where the MXs point, only the character of an administrative domain. foo.ENET.DEC.COM is, incidentally, an unambiguous and correct example of DNS application. Again, that statement does not have anything to do with MX structures, or where the "wildcards" are located, but that the "DEC Engineering Network" is an administrative entity, with the same organizational entity having responsibility for all of the machines in a very real sense. And if DEC decides at some stage in the future to further subdivide that domain by inventing foo.VMS.DEC.COM and foo.ULTRIX.DEC.COM or something, then, while they will cause some confusion (changing the name of a host is never very attractive), and may want to use some CNAMEs for at least a while, it is clearly within the scope of their organization to do so. Summary of the summary: I. There is absolutely no technical reason why .BITNET or .BIT.NET could not be made to function. The basic DNS addressing system really does not care how domains are structured. II. These names are not good ideas, primarily because they would either severely distort the "administrative domain" notion or force multiple names per host on the Internet. And "severely", here, is not a moral concept but one that has to do with the frequency of impact and the frequency of people having to notice. Statistically, mumble.BITNET (sic) is much more likely to *be* an Internet node, or to be standing next to one with which it may have a private connection (people running tapes across the room included under "connection"), than mumble.fidonet.org is. john Klensin@INFOODS.MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 13:35:35 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27145; 11 Jan 90 12:52 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA05513; Thu, 11 Jan 90 12:34:03 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Jan 90 17:26:41 GMT From: mcsun!ukc!tcdcs!csvax1.cs.tcd.ie!swift.cs.tcd.ie!ccvax.ucd.ie!h235_062@uunet.uu.net Organization: University College Dublin Subject: test Message-Id: <377.25aa1ed1@ccvax.ucd.ie> Sender: header-people-request@MC.lcs.mit.edu To: header-people@MC.lcs.mit.edu Testing....1,2,3......1,2,3,4..........................  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 15:30:48 EST Received: from alw.nih.gov by mintaka.lcs.mit.edu id aa03666; 11 Jan 90 15:24 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m) id AA06286; Thu, 11 Jan 90 16:21:47 -0400 Message-Id: <9001112021.AA06286@alw.nih.gov> To: KLENSIN@infoods.mit.edu Cc: HEADER-PEOPLE@mc.lcs.mit.edu From: Roger Fajman Date: Thu, 11 Jan 90 15:23:55 EST Subject: Re: Naming with an Internet to BITNET Gateway First of all, let me say that in an ideal world, BITNET would have full domain support and we wouldn't be having this discussion. But there's still a long way to go on that. I would like to eliminate the gateway names from the addresses in the meantime. The DNS is quite capable, given the right MX records, of giving the gateway that's nearest in BITNET terms to the destination BITNET node. Since the Internet is the higher performance network, that makes the most sense to me. A program would have to be written to produce those MX records from the BITNET node data base. I think your reaching when you argue that SPAN is different from BITNET because SPAN hosts are under one administration. Milo Medin said in his mail that it is not so. In looking through a list of SPAN sites, I see a lot that are by no stretch of the imagination part of NASA. Even supposing that these nodes are funded by NASA, it doesn't make then part of NASA. If it does, then NIH (where I am) is a lot bigger than I thought. :-) And even if what you say about a comparison of SPAN to BITNET is true, I find it interesting that the managers of SPAN found the complexity of having each host in its "proper" domain too much to deal with. Let me suggest that the real difference between SPAN and BITNET is that SPAN uses DECnet. Thus it does not use RFC 822 and nobody expects that it should try to convert to domains within itself.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 16:40:15 EST Received: from ucbeh.san.uc.edu by mintaka.lcs.mit.edu id aa04135; 11 Jan 90 15:37 EST Date: Thu, 11 Jan 90 14:13 EST From: Amin Shafie - Univ of Cincinnati Comp Ctr Subject: SIGUCCS CALL for PARTICIPATION To: 386USERS@twg.com, 9370-L%HEARN.BITNET@mitvma.mit.edu, AAI@st-louis-emh2.army.mil, ADA-SW@wsmr-simtel20.army.mil, ADVISE-L%CANADA01.BITNET@cunyvm.cuny.edu, ADVSYS@eddie.mit.edu, AG-EXP-L%NDSUVM1.BITNET@cunyvm.cuny.edu, AI-ED@sumex-aim.stanford.edu, AIDSNEWS%RUTVM1.BITNET@cunyvm.cuny.edu, AIList@ai.ai.mit.edu, AIX-L%BUACCA.BITNET@mitvma.mit.edu, ALLIN1-L@ccvm.sunysb.edu, AMETHYST-USERS@wsmr-simtel20.army.mil, AMIGA-RELAY@udel.edu, ANDREW-DEMOS@andrew.cmu.edu, ANTHRO-L%UBVM.BITNET@cunyvm.cuny.edu, apollo@umix.cc.umich.edu, ARMS-D@xx.lcs.mit.edu, ARPANET-BBOARDS@mc.lcs.mit.edu, ASM370%UCF1VM.BITNET@cunyvm.cuny.edu, AVIATION@mc.lcs.mit.edu, AVIATION-THEORY@mc.lcs.mit.edu, bicycles@bbn.com, BIG-LAN@suvm.acs.syr.edu, BIG-LAN@suvm.bitnet, BIOTECH%UMDC.BITNET@cunyvm.cuny.edu, BIOTECH@umdc.umd.edu, BITNEWS%BITNIC.BITNET@cunyvm.cuny.edu, BMDP-L%MCGILL1.BITNET@cornellc.ccs.cornell.edu, bug-1100@sumex-aim.stanford.edu, CA@think.com, CADinterest^.es@xerox.com, CAN-INET@mc.lcs.mit.edu, cisco@spot.colorado.edu Message-id: X-Envelope-to: V2LNI-PEOPLE@MC.LCS.MIT.EDU, SCHEME@MC.LCS.MIT.EDU, NIHONGO@MC.LCS.MIT.EDU, INFO-JAPAN@MC.LCS.MIT.EDU, Heath-People@MC.LCS.MIT.EDU, HEADER-PEOPLE@MC.LCS.MIT.EDU, Dead-Flames@MC.LCS.MIT.EDU, CAN-INET@MC.LCS.MIT.EDU, AVIATION-THEORY@MC.LCS.MIT.EDU, AVIATION@MC.LCS.MIT.EDU, ARPANET-BBOARDS@MC.LCS.MIT.EDU X-VMS-To: @LISTS.DIS X-VMS-Cc: SHAFIE <-------------------------------------------------------------------- < < SIGUCCS User Services Conference XVIII < Call For Participation < < New Centerings in Computing Services < < September 30 through October 3, 1990 < < Westin Hotel < Cincinnati, Ohio < < <<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << < Organization: Kuwait Petroleum Sweden, Stockholm Subject: chopping off identical domains Message-Id: <644@kps.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu It seems that my sendmail chops the top domain name, (.se in my case) if a mail is sent to that domain in which my host also resides. The problem does not exist when I'm in a subdomain to .se sending to a host in the top domain. Is my mailer (or .cf) to be considered as broken? -Leif ---------- uunet!mcsun!sunic!kps!llj||llj@kps.se  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 14 Jan 90 11:19:18 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa14333; 14 Jan 90 11:14 EST Date: Sun 14 Jan 90 11:10:49-EST From: John C Klensin Subject: Re: chopping off identical domains To: mcsun!sunic!kps!llj@uunet.uu.net Cc: header-people@MC.lcs.mit.edu Message-ID: <632333449.800000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <644@kps.UUCP> Mail-System-Version: >It seems that my sendmail chops the top domain name, >(.se in my case) if a mail is sent to that domain in >which my host also resides. There is a lot of flexibility within a given subdomain, and, in particular, it is assumed that your users should never have to type the domain qualification when sending from one host to another in the same subdomain. However, all messages that reach any machine *must* be fully-qualified. It turns out, in practice, that it is virtually impossible to make partially-qualified names work between machines in a subdomain and not have them, sooner or later, turn up somewhere else. The RFCs require that messages transferred between hosts use fully- qualified names. >Is my mailer (or .cf) to be considered as broken? I would consider it broken. The only circumstances under which it would not be broken would require exceptionally careful gateways. Note that, even if the gateways operate to prevent any of the protocol rules from being broken, leaving off part of the domain name is a poor idea because of the user confusion it ultimately causes. Sooner or later, someone who does not understand the issues will give out a chopped-off address at an international meeting to someone else who does not understand the issues, and there will be massive confusion a few weeks later when people try to guess at what the first and second level domains might have been. --john Klensin@INFOODS.MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Jan 90 09:07:43 EST Received: from NSFNET-RELAY.AC.UK by mintaka.lcs.mit.edu id aa15401; 15 Jan 90 9:05 EST Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa09990; 15 Jan 90 13:05 GMT Received: from prg.ox.ac.uk (jael) by prg.oxford.ac.uk id AA16518; Mon, 15 Jan 90 13:13:05 GMT Received: by prg.ox.ac.uk (4.0/prg3.0) id AA05342; Mon, 15 Jan 90 13:14:45 GMT Date: Mon, 15 Jan 90 13:14:45 GMT Message-Id: <9001151314.AA05342@prg.ox.ac.uk> From: Geraint Jones To: HEADER-PEOPLE%mc.lcs.mit.edu@nsfnet-relay.ac.uk Subject: Re: chopping off identical domains >-> Message-Id: <632333449.800000.KLENSIN@INFOODS.MIT.EDU> >-> ... leaving off part of the domain name is a poor >-> idea because of the user confusion it ultimately causes. Sooner or later, >-> someone who does not understand the issues will give out a chopped-off >-> address at an international meeting to someone else who does not understand >-> the issues, and there will be massive confusion a few weeks later when >-> people try to guess at what the first and second level domains might have >-> been. >-> --john Klensin@INFOODS.MIT.EDU >-> ------- Some of us over here are in the habit of referring to addresses in the USA as, say, HEADER-PEOPLE@mc.lcs.mit.edu.usa (well, strictly speaking, as HEADER-PEOPLE@usa.edu.mit.lcs.mc, but that's because we still drive on the left; don't let's get led astray by that red herring). What is the status of the .USA ? Is it a UK fiction? Is it not a damn good idea even if it is? What is the proper atitude to adopt to an American who thinks the most significant domain of his address is EDU or COM, when there seems no reason not to have EDU or COM next-to-most-significant-level domains elsewhere? gj  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Jan 90 13:01:12 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa18814; 15 Jan 90 12:59 EST Received: from slembe.uio.no by ifi.uio.no (5.61++/1.15) with SMTP id AA01894; Mon, 15 Jan 90 18:58:31 +0100 Received: by slembe.uio.no (5.61++/SMI-3.2) id AA09341; Mon, 15 Jan 90 18:58:29 +0100 Date: Mon, 15 Jan 90 18:58:29 +0100 Message-Id: <9001151758.AA09341@slembe.uio.no> From: Erik Naggum Sender: enag@ifi.uio.no To: Geraint.Jones@prg.oxford.ac.uk Cc: HEADER-PEOPLE@mc.lcs.mit.edu In-Reply-To: <9001151314.AA05342@prg.ox.ac.uk> "Geraint.Jones%prg.oxford.ac.uk@nsfnet-relay.ac.uk" Subject: UK fiction (.USA) Flame ON! UK never ceases to surprise me. So you "invent" your own top-level domain just to screw the name-servers, the Internet idea of domains, and interoperability. How nice. It may be in the British way of life to be pragmatic and unerringly avoid thinking about consequences and design philosophy, but please keep this to your own island, OK? Flame half off There already exists a .US top-level domain, with geographical subdomains. .USA does NOT exist. If we were to follow ISO 3166, it would be correct to have .GB instead of .UK. As far as I know, the rest of the national top-level domains follow this standard. While on the topic of standards and suggestions, may I suggest that you people over there try to follow those that already exist before you "suggest" all kinds of "improvements"? Flame off > What is the status of the .USA? Is it a UK fiction? Yes, indeed it is. > Is it not a damn good idea even if it is? It is not a damn good idea. The Internet is an American invention. EDU, COM, etc are there for historical reasons. The same is true for UK as a top-level domain. [Erik]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Jan 90 14:24:56 EST Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa20164; 15 Jan 90 14:19 EST Posted-Date: Mon, 15 Jan 90 11:18:05 PST Message-Id: <9001151917.AA25409@venera.isi.edu> Received: from poneria.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 15 Jan 90 11:17:16 -0800 To: Craig Partridge Cc: raf@cu.nih.gov, header-people@mc.lcs.mit.edu Reply-To: pvm@venera.isi.edu Subject: Re: .BITNET domain In-Reply-To: Your message of Fri, 05 Jan 90 08:14:49 -0500. <9001091429.aa13033@mintaka.lcs.mit.edu> Date: Mon, 15 Jan 90 11:18:05 PST From: Paul Mockapetris > > > My original question is why are these policies not enforced > > consistently with respect to FIDONET.ORG and UU.NET? Why is an Indian > > host named shakti.uu.net acceptable while a similarly named BITNET host > > is not? > > If shakti isn't a host involved in running uu.net it isn't acceptable use. > (I don't personally know the status of shakti). As for enforcement, > that's a tricky question. It isn't clear there is an enforcement mechanism, > short of turning off uu.net at the root domain servers -- that's a rather > extreme act. All the more reason for the NIC to be careful about who it > gives .NET domains to. The .NET domain is an obvious breeding ground for Trojan horses. Why UU.NET and not .BITNET? As my mother would say "fool me once - shame on you; fool me twice - shame on me." Or as someone else said, I forget who, "We won't be fooled again." paul  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Jan 90 16:44:59 EST Received: from NSFNET-RELAY.AC.UK by mintaka.lcs.mit.edu id aa22687; 15 Jan 90 16:38 EST Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa24760; 15 Jan 90 20:19 GMT Received: from prg.ox.ac.uk (jael) by prg.oxford.ac.uk id AA23213; Mon, 15 Jan 90 20:26:54 GMT Received: by prg.ox.ac.uk (4.0/prg3.0) id AA05844; Mon, 15 Jan 90 20:28:34 GMT Date: Mon, 15 Jan 90 20:28:34 GMT Message-Id: <9001152028.AA05844@prg.ox.ac.uk> From: Geraint Jones To: Erik Naggum Cc: HEADER-PEOPLE%mc.lcs.mit.edu@nsfnet-relay.ac.uk Subject: fiction > Message-Id: <9001151758.AA09341@slembe.uio.no> > > > What is the status of the .USA? Is it a UK fiction? > > Yes, indeed it is. Thank you for the information; I assure you I really was asking because I wanted to know. > The Internet is an American invention. I am told that politeness and a sense of humour are English inventions. There are times I wonder what it would be like to be English. I bet you do too. gj  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 30 Jan 90 18:17:02 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id aa28615; 30 Jan 90 18:09 EST Received: from CCRMA-F4 by SAIL.Stanford.EDU with PUP; 30-Jan-90 15:09 PST Date: 30 Jan 90 1509 PST From: Tovar Subject: Junk EMail To: Header-People%MC.LCS.MIT.EDU@sail.stanford.edu Message-ID: <9001301809.aa28615@mintaka.lcs.mit.edu> If there isn't an Internet regulation explicitly prohibiting this kind of abuse, there ought to be something in the header to permit these things to be automatically flushed. While it might be argued that the conference in question might have some vague relevence to Header-People, it is clearly of little interest to readers of AIDS-News, Dead-Flames or Aviation-Theory! Some states prohibit junk faxing, and we should do likewise; but if we can't, at least we should be able to throw the stuff away before it gets in the door. You know what will happen if we don't... -- Tovar Partial enclosure of ~500 line message: _______________________________________________________________________________ 11-Jan-90 1959 @mc.lcs.mit.edu:SHAFIE@ucbeh.san.uc.edu SIGUCCS CALL for PARTICIPATION Received: from SAIL.STANFORD.EDU by CCRMA with PUP; 11-Jan-90 19:59 PST Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jan 90 20:02:01 PST Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07416; 11 Jan 90 17:00 EST Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Jan 90 16:40:15 EST Received: from ucbeh.san.uc.edu by mintaka.lcs.mit.edu id aa04135; 11 Jan 90 15:37 EST Date: Thu, 11 Jan 90 14:13 EST From: Amin Shafie - Univ of Cincinnati Comp Ctr Subject: SIGUCCS CALL for PARTICIPATION To: 386USERS@twg.com, 9370-L%HEARN.BITNET@mitvma.mit.edu, AAI@st-louis-emh2.army.mil, ADA-SW@wsmr-simtel20.army.mil, ADVISE-L%CANADA01.BITNET@cunyvm.cuny.edu, ADVSYS@eddie.mit.edu, AG-EXP-L%NDSUVM1.BITNET@cunyvm.cuny.edu, AI-ED@sumex-aim.stanford.edu, AIDSNEWS%RUTVM1.BITNET@cunyvm.cuny.edu, AIList@ai.ai.mit.edu, AIX-L%BUACCA.BITNET@mitvma.mit.edu, ALLIN1-L@ccvm.sunysb.edu, AMETHYST-USERS@wsmr-simtel20.army.mil, AMIGA-RELAY@udel.edu, ANDREW-DEMOS@andrew.cmu.edu, ANTHRO-L%UBVM.BITNET@cunyvm.cuny.edu, apollo@umix.cc.umich.edu, ARMS-D@xx.lcs.mit.edu, ARPANET-BBOARDS@mc.lcs.mit.edu, ASM370%UCF1VM.BITNET@cunyvm.cuny.edu, AVIATION@mc.lcs.mit.edu, AVIATION-THEORY@mc.lcs.mit.edu, bicycles@bbn.com, BIG-LAN@suvm.acs.syr.edu, BIG-LAN@suvm.bitnet, BIOTECH%UMDC.BITNET@cunyvm.cuny.edu, BIOTECH@umdc.umd.edu, BITNEWS%BITNIC.BITNET@cunyvm.cuny.edu, BMDP-L%MCGILL1.BITNET@cornellc.ccs.cornell.edu, bug-1100@sumex-aim.stanford.edu, CA@think.com, CADinterest^.es@xerox.com, CAN-INET@mc.lcs.mit.edu, cisco@spot.colorado.edu Message-id: X-Envelope-to: V2LNI-PEOPLE@MC.LCS.MIT.EDU, SCHEME@MC.LCS.MIT.EDU, NIHONGO@MC.LCS.MIT.EDU, INFO-JAPAN@MC.LCS.MIT.EDU, Heath-People@MC.LCS.MIT.EDU, HEADER-PEOPLE@MC.LCS.MIT.EDU, Dead-Flames@MC.LCS.MIT.EDU, CAN-INET@MC.LCS.MIT.EDU, AVIATION-THEORY@MC.LCS.MIT.EDU, AVIATION@MC.LCS.MIT.EDU, ARPANET-BBOARDS@MC.LCS.MIT.EDU X-VMS-To: @LISTS.DIS X-VMS-Cc: SHAFIE <-------------------------------------------------------------------- < < SIGUCCS User Services Conference XVIII < Call For Participation < < New Centerings in Computing Services < < September 30 through October 3, 1990 < < Westin Hotel < Cincinnati, Ohio < ...  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU; 5 Feb 90 15:46:33 EST Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 5 Feb 90 15:46:13 EST Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa19792; 5 Feb 90 15:38 EST Received: by garnet.berkeley.edu (5.57/1.32) id AA04865; Mon, 5 Feb 90 12:39:20 PST Date: Mon, 5 Feb 90 12:39:20 PST From: Postmaster & BITINFO Message-Id: <9002052039.AA04865@garnet.berkeley.edu> To: header-people@ai.ai.mit.edu Subject: Keep it simple gateways! Lets keep it simple folks. The gateway address suffixes are getting to be to much. Networks are not even following their own rules. Here is how the address was changed to: vanbastelaer%ts.info.fundp.rtt.be%fun-cs.uucp%blekul60.bitnet@jade.berkeley.edu as it was relayed: vanbastelaer%ts.info.fundp.rtt.be %fun-cs.uucp UUCP node incorrectly added a ".UUCP" host name. (fun-cs.uucp is in the UUCP zone of the internet mail system with the name fun-cs.info.fundp.ac.be and should have left the internet address as is). %blekul60.bitnet UUCP/BITNET gateway incorrectly added a ".bitnet" node name (should have left it as is since .UUCP is a valid top domain in the BITNET VM Mailer system.) @jade.berkeley.edu UCBJADE correctly added internet hostname to .BITNET address for relay into the campus internet. Bill Wells postmaster@jade.berkeley.edu netinfo@garnet.berkeley.edu NETINFO@UCBGARNE.BITNET In reference to: From vanbastelaer%ts.info.fundp.rtt.be%fun-cs.uucp%blekul60.bitnet@jade.berkeley.edu Fri Feb 2 22:41:56 1990 Received: by garnet.berkeley.edu (5.57/1.32) id AA21080; Fri, 2 Feb 90 22:41:55 PST Received: from jade.Berkeley.EDU by violet.berkeley.edu (5.61/1.31) id AA00866; Fri, 2 Feb 90 22:41:49 PST Received: from BLEKUL60.BITNET by jade.berkeley.edu (5.61.1/1.16.23) id AA27520; Fri, 2 Feb 90 22:41:58 PST From: vanbastelaer%ts.info.fundp.rtt.be%fun-cs.uucp%blekul60.bitnet@jade.berkeley.edu Received: by kulcs.uucp; Fri, 2 Feb 90 18:12:01 +0100 Date: 2 Feb 90 17:49 To: Cc: Message-Id: <213:vanbastelaer@ts.info.fundp.rtt.be> Subject: BRIE Return-Receipt-To: vanbastelaer%ts.info.fundp.rtt.be%fun-cs.uucp%blekul60.bitnet@jade.berkeley.edu (text deleted)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Feb 90 17:33:19 EST Received: from [129.122.1.1] by mintaka.lcs.mit.edu id aa25156; 5 Feb 90 17:25 EST Received: (from user DRB) by Relay.Prime.COM; 05 Feb 90 17:29:09 EST To: header-people@mc.lcs.mit.edu Cc: Rob Ullmann From: David Robinson (Special Systems) Subject: Proposed RFC on Encoding header field Encoding: 13 text, 342 text Date: 05 Feb 90 17:29:09 EST Message-ID: <9002051726.aa25156@mintaka.lcs.mit.edu> The following is a draft RFC for an Encoding header field to support the mailing of multi-part, multi-structured Internet messages. A mail user interface (MUA) using Encoding for message structures has been in use at Prime for the past 2 years. A newer MUA and mailer, which uses Encoding for multiple parts as well as structures, has been in use for the past 6 months. Comments welcome. David Robinson Rob Ullmann Prime Computer, Inc. Network Working Group D. Robinson, R. Ullmann Request for Comments: DRAFT Prime Computer, Inc. February 1990 Encoding Header Field for Internet Messages 1. Status of the Memo This RFC proposes an Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding obsoletes RFC 943 (Message encapsulation), updates RFC 1049 (Content-Type), and updates RFC 1040 (Privacy enhancement). Distribution of this memo is unlimited. 2. Introduction RFC 822 [2] defines an electronic mail message to consist of two parts, the message header and the message body, separated by an apparently blank line. The Encoding header field permits the message body itself to be further broken up into parts, each part also separated from the next by an apparently blank line. Thus, conceptually, a message has a header part, followed by one or more body parts, all separated by blank lines. Each body part has an encoding type. The default (no Encoding field in the header) is a message body of one part of type "text". 3. The Encoding Field The Encoding field consists of one or more subfields, separated by commas. Each subfield corresponds to a part of the message, in the order of that part's appearance. A subfield consists of a line count, a keyword defining the encoding, and optional information relevant only to the specific encoding. The line count is optional in the last subfield. Robinson, Ullmann [Page 1] RFC DRAFT Encoding Header Field for Internet Messages February 1990 3.1. Format of the Encoding Field The format of the Encoding field is: [ [], ]* [] [] where: := a decimal integer := a single alphanumeric token starting with an alpha := keyword-dependent options 3.2. The line count is a decimal number specifying the number of text lines in the part. Parts are separated by a blank line, which is not included in the count of either the proceeding or following part. Since a count always begins with a digit and a keywords always begins with an letter, it is always possible to determine if the count is present. (The count is first because it is the only information of interest when skipping over the part.) The count is not required on the last or only part. 3.3. The keyword defines the encoding type. The keyword is a common single word name for the encoding type. The keywords are not case-sensitive. Standard keywords are registered with the Internet NIC (presently J. K. Reynolds), the list is intended to be the same as the list used for the Content-Type: header descibed in [6]. This RFC proposes additions to the list. Implementations can then treat "Content-Type" as an alias of "Encoding", which will always have only one body part. 3.4. The optional information is used to specify additional keyword-specific information needed for interpreting the contents of the encoded part. It may be any sequence of tokens not containing a comma. 3.5. Encoding Version Numbers In general, version numbers for encodings, when not actually available within the contents of the encoded information, will be handled as options. Robinson, Ullmann [Page 2] RFC DRAFT Encoding Header Field for Internet Messages February 1990 3.6. Comments Comments enclosed in parentheses may, of course, be inserted anywhere in the Encoding field. Mail reading systems may or may not pass the comments to their clients. Comments may not be used by mail reading systems for content interpretation; that is the function of options. 4. Encodings This section describes some of the defined encodings used. As with the other keyword-defined parts of the header format standard, extensions in the form of new keywords are expected and welcomed. Several basic principles should be followed in adding encodings: - The keyword should be the most common single word name for the encoding, including acronyms if appropriate. The intent is that different implementors will be likely to choose the same name for the same encoding. - Keywords not be too general: "binary" would have been a bad choice for the "hex" encoding. - The encoding should be as free from unnecessary idiosyncracies as possible, except when conforming to an existing standard, in which case there is nothing that can be done. - The encoding should, if possible, use only the 7 bit ASCII printing characters if it is a complete transformation of a source document (such as "hex" or "uuencode". If it is essentially a text format, the full range may be used. If there is an external standard, the character set may already be defined. Keywords beginning with "X-" are permanently reserved to implementation- specific use. No standard registered encoding keyword will ever begin with "X-". 4.1. Text This indicates that the message is in no particular encoded format, but is to be presented to the user as is. The full range of the ASCII character set is used. The message is expected to consist of lines of reasonable length (less than 1000 characters). On some transport services, only the 7 bit subset of ASCII can be used. Where full 8 bit transparency is available, the text is assumed to be ISO 8859-1 [3] (ASCII-8) Robinson, Ullmann [Page 3] RFC DRAFT Encoding Header Field for Internet Messages February 1990 4.2. Message This encoding indicates that the body part is itself in the format of an Internet message, with its own header part and body part(s). A "message" body part's message header may be a full internet message header or it may consist only of an Encoding field. Using the message encoding on returned mail makes it practical for a mail reading system to implement a reliable resending function, if the mailer generates it when returning contents. It is also useful in a "copy append" MUA operation. Message encoding is also used when mapping to X.400 to handle recursively included X.400 P2 messages. 4.3. Hex The encoding indicates that the body part contains binary data, encoded as 2 hexadecimal digits per byte, highest significant nibble first. Lines consist of an even number of hexadecimal digits. Blank lines are not permitted. The decode process should accept lines with between 2 and 998 characters, inclusive. 4.4. EVFU EVFU (Electronic Vertical Format Unit) specifies that each line begins with a one-character "channel selector". The original purpose was to select a channel on a paper tape loop controlling the printer. This encoding is sometimes called "FORTRAN" format. It is the default output format of FORTRAN programs on a number of computer systems. The legal characters are `0' to `9', `+', `-', and space. These correspond to the 12 rows (and absence of a punch) on a printer control tape (used when the control unit was electromechanical). The channels that have generally agreed definitions are: 1 advances to the first print line on the next page 0 skip a line, i.e. double-space + over-print the preceeding line - skip 2 lines, i.e. triple-space (space) print on the next line, single-space 4.5. EDI The EDI (Electronic Document Interchange) keyword indicates that the message or part is a business document, formatted according to ANSI X12 Robinson, Ullmann [Page 4] RFC DRAFT Encoding Header Field for Internet Messages February 1990 or related standards. The first word after the EDI keyword indicates the particular interchange standard. A message containing a note and 2 X12 purchase orders might have an encoding of: Encoding: 17 TEXT, 146 EDI X12, 69 EDI X12 4.6. X.400 The Encoding header field provides a mechanism for mapping multi-part messages between CCITT X.400 [1] and RFC 822. The X.400 keyword specifies a section that is converted from an X.400 body part type not known to the gateway, or not corresponding to a useful internet encoding. If the message transits another gate, or if the receiving user has the appropriate software, it can be decoded and used. The X.400 keyword is followed by a second token indicating the method used. The simplest form is "X.400 HEX", with the complete X.409 encoding of the body part in hexadecimal. More compact is "X.400 3/4", using the 3-byte to 4-character encoding as specified in RFC 1040, section 4.2.3.4. 4.7. uuencode The uuencode keyword specifies a section consisting of the output of the uuencode program supplied as part of uucp. 4.8. encrypted The encrypted keyword indicates that the section is encrypted with the methods in RFC1040 [4] and revisions. This replaces the possible use of RFC934 [5] encapsulation. References [1] International Telegraph and Telephone Consultative Committee. Data Communication Networks: Message Handling Systems. In CCITT Recommendations X.400 to X.430. VIIIth Plenary Assembly, Malaga-Torremolinos, 1984. Fascicle VIII.7 ("Red Book"). [2] David H. Crocker. Standard for the Format of ARPA Internet Text Messages. RFC 822, University of Delaware, August, 1982. Robinson, Ullmann [Page 5] RFC DRAFT Encoding Header Field for Internet Messages February 1990 [3] International Organization for Standardization. Information processing - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1. ISO 8859-1, ISO, 1987. [4] J. Linn. Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures.. RFC 1040, IAB Privacy Task Force, January, 1988. [5] M. T. Rose, E. A. Stefferud. Proposed standard for message encapsulation. RFC 943, University of Delaware and NMA, January, 1985. [6] M. A. Sirbu. Content-type header field for Internet messages. RFC 1049, CMU, March, 1988. Authors' Addresses David Robinson 10-30 Prime Computer, Inc. 500 Old Connecticut Path Framingham, MA 01701 Phone: +1 508 879 2960 x1774 Email: DRB@Relay.Prime.COM Robert Ullmann 10-30 Prime Computer, Inc. 500 Old Connecticut Path Framingham, MA 01701 Phone: +1 508 879 2960 x1736 Email: Ariel@Relay.Prime.COM Robinson, Ullmann [Page 6]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Feb 90 20:39:51 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa03564; 5 Feb 90 20:31 EST Received: from slembe.uio.no by ifi.uio.no (5.61++/1.15) with SMTP id AA20735; Tue, 6 Feb 90 01:47:18 +0100 Received: by slembe.uio.no (5.61++/SMI-3.2) id AA03964; Tue, 6 Feb 90 01:47:16 +0100 Date: Tue, 6 Feb 90 01:47:16 +0100 In-Reply-To: <9002051726.aa25156@mintaka.lcs.mit.edu> "DRB@relay.prime.com" Message-Id: <90-037-0007@naggum.uu.no> From: Erik Naggum Sender: enag@ifi.uio.no To: DRB@relay.prime.com Cc: header-people@mc.lcs.mit.edu, Ariel@relay.prime.com Subject: Proposed RFC on Encoding header field Robert and David, I appreciate the effort you have made, and like the result. I think this will gain more acceptance in the user community than the Content-Type field has (at least as far as I've seen -- I've never received any mail with this header). It may render me biased, since I exchange mail with Robert now and then, but I _have_ seen mail with the "Encoding" header in it. :-) Your list of added keywords is just what the doctor ordered. However, it seems to me that Encoding and Content-Type solve somewhat similar problems, but very differently. You indicate that one could regard Encoding as an alias for Content-Type in the presence of one body-part. I never liked the number of semicolons in Content-Type, which I think makes the header harder to read for humans, and I see Encoding as more versatile than Content-Type in general applications, whereas Content-Type is better for whole documents being transmitted. My comment reflects on the appropriateness of stressing the similarity between Encoding and Content-Type. As far as I can see, they serve different purposes which are somewhat similar, but not enough to make the solutions similar. To the extent that design decisions have been made to accomodate the similarity and "aliasability" between these, I think these should be reassessed. From a cursory, midnight reading of the draft RFC, I want to implement it in my mailer software, particularly the part about "message", which my MTA will need. I didn't get as far as implementing Content-Type, although I started to read about SGML because of it... [Erik]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Feb 90 00:49:01 EST Received: from [129.189.192.2] by mintaka.lcs.mit.edu id aa14128; 6 Feb 90 0:42 EST Received: by orc.olivetti.com (4.0/SMI-3.2) id AA01865; Mon, 5 Feb 90 21:42:39 PST Resent-Message-Id: <9002060542.AA01865@orc.olivetti.com> Return-Path: Received: from orc.olivetti.com (Pisa) by Ricerca (4.0/SMI-3.2) id AA06987; Mon, 5 Feb 90 21:38:07 PST Received: by orc.olivetti.com (4.0/SMI-3.2) id AA01823; Mon, 5 Feb 90 21:37:32 PST Date: Mon, 5 Feb 1990 21:37:30 PST From: David Roode To: header-people@mc.lcs.mit.edu Cc: DRB@relay.prime.com, header-people@mc.lcs.mit.edu, Ariel@relay.prime.com, enag@ifi.uio.no, roode@orc.olivetti.com Subject: Re: Proposed RFC on Encoding header field In-Reply-To: Your message of Tue, 6 Feb 90 01:47:16 +0100 Message-Id: Resent-To: header-people%mc.lcs.mit.edu@MINTAKA.lcs.mit.edu, drb%relay.prime.com@relay.cs.net, ariel%relay.prime.com@relay.cs.net Resent-Date: Mon, 5 Feb 1990 21:42:37 PST Resent-From: David Roode Message-Id: My feeling is that what is needed is the analog of the content-type/ encoding header, but that it is too important to be encoded as a header. I think this piece of information belongs in the SMTP (mail transfer) envelope. This would broaden SMTP to be a "Typed Simple Message Transfer Protocol" with exactly 1 type of content negotiated between sender and receiver for each message. This broadening of SMTP would permit, using the same definition as is currently done for SMTP, the transfer of typed data such as Group III Facsimile data or digitally encoded voice or postscript. Where alternative representations are possible at the source, the destination could negotiate a translation, or relay back to the sender "message type not supported at receiving site." One thing I think critical to this broadening of SMTP into TSMTP would be the requirement of support for 8-bit bytes rather than limitations to 7 bit ASCII. The header information expected would be dependent on the message type, i.e. a new RFC 822 might be required for each new message type. The services this transport protocol might efficiently support are many. To name a few: 1. Users could have Voice and FAX mailboxes on each host in addition to text. 2. A voice mailbox might be forwarded by the host into a voice mail system accessible from the telephone network. Long-haul transmission would be by the Internet. 3. FAX mailboxes might be redirected to various printing FAX machines, as the recipient travels. 4. Efficient relaying of FAX traffic from the Internet to persons not on the Internet would be possible. 5. Simple and more economical transmission of FAX data would be possible through the use of the Internet. 6. New user agents might be created which would not only let the user read his text mail, but also permit him to browse through stored voice and FAX. At the same time, a voice-only user agent could be allowed, both for receipt and transmission. 7. To support incoming data from the switched telephone GROUP III FAX network, a standard header, perhaps in bar code format, could be defined for the header page of a hardcopy FAX transmitted into a relay for conversion to TSMTP FAX traffic.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Feb 90 01:37:14 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa16085; 6 Feb 90 1:29 EST Received: from slembe.uio.no by ifi.uio.no (5.61++/1.15) with SMTP id AA22737; Tue, 6 Feb 90 07:29:13 +0100 Received: by slembe.uio.no (5.61++/SMI-3.2) id AA06511; Tue, 6 Feb 90 07:29:11 +0100 Date: Tue, 6 Feb 90 07:29:11 +0100 Message-Id: <9002060629.AA06511@slembe.uio.no> From: Erik Naggum Sender: enag@ifi.uio.no To: David Roode Cc: header-people@mc.lcs.mit.edu, DRB@relay.prime.com, Ariel@relay.prime.com In-Reply-To: Subject: Proposed RFC on Encoding header field David, Have you considered what it takes to get something like that implemented? (8 out of 10 random vendors implement SMTP wrong as it is, and more than half of the programmers behind them can't spell "state machine".) Have you considered what it would take to get system admins to want to support it? We have a good protocol as it is, SMTP, and we have a tremendously versatile standard for the messages carried on top of it. (I mean, how would you introduce an "Encoding" field in X.400 if it wasn't already there? Ever looked at the difference between X.400-1984 and X.400-1988?) This present draft RFC solves a problem very neatly. No binary trash, no real need to rush to implement it in the UA's as the users can do without it (using the field as guidelines, only) for a while. In short, if you want to reinvent X.400 (which basically is a reinvention of the Internet mail services with a lot of wishes thrown in to make it hard to implement), it has to be less than a wish-list. God, it's 7.30. Where did the night go? :-) [Erik]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Feb 90 21:42:34 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa00410; 6 Feb 90 21:35 EST Date: Tue 6 Feb 90 21:31:33-EST From: John C Klensin Subject: Re: Proposed RFC on Encoding header field To: erik@naggum.uu.no Cc: header-people@MC.lcs.mit.edu Message-ID: <634357893.80000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9002060629.AA06511@slembe.uio.no> Mail-System-Version: I tend to agree with David, but for another reason. Strangely enough, it starts from Eric's premise, but I reach a different conclusion. We have gone to considerable lengths, in the original protocols and in HRRFC (RFC1123) to say, more or less, "if you accept the envelope, you are accepting responsibility for getting the message delivered". I would add to this "in intelligible form". The protocols also specify how the errors are to be reported if reporting must be delayed, specifically use of <> in the MAIL FROM field, to avoid error-reporting loops. In most systems, envelope management at that level must be done by the MTA, not an MUA. Now, if the type of information implied by "Encoding" is in the headers, the MTA cannot guarantee intelligible delivery, since it can't verify that the delivery host has the required capabilities, without looking at the message headers, which MTAs are not supposed to need to do. And, with a good MTA/MUA separation, the UA, upon discovering that it can't handle the Encoding properly, cannot generate a protocol-conforming non-delivery message (here really a non-comprehensibility message). It may well be that one would optimally want both Encoding headers and encoding information in the envelope, but the envelope information must be sufficient that the MTA can determine whether or not the receiver can process the information. Erik argues that, since many sites can't get SMTP right, tampering with it is worse. I suggest that, since many sites cannot get SMTP right, and many others won't implement this feature [quickly], the envelope is exactly the right place to do it. Consider three cases: Case 1. Server-SMTP gets an "encoding" verb and the host knows how to process it. Encoding is handled properly, much as in the original proposal. Case 2. Server-SMTP gets an "encoding" verb and understands about them, but the host does not know how to handle whatever encoding is specified in the predicate. Server-SMTP sends back a proper fatal error message, typically within the protocol by rejecting the "encoding" verb. Case 3. Server-SMTP gets an "encoding" verb but--either because it is a bad implementation or because it has not implemented it yet--does not recognize it at all. Server-SMTP rejects the verb, replying with either a syntax error or some type of "facility not available" error. I think that is the desired behavior. Suggested metarule: Any proposed change to mail that involves a feature that would change the interpretation of the message in a fundamental way if it were used (i.e., where ignoring the use of the feature if it were not recognized would be hazardous to intelligibility or worse) should require a change to the envelope that will cause older systems, that don't have knowledge of the feature, to reject the message. This suggested metarule could take a form much more simple than putting an encoding verb in the envelope. One could, in principle, define an extended SMTP (ESMTP? EMTP?) that would have several new "required" header fields ("required" in this context, means only that mail systems would need to be prepared to cope with them, not that they would necessarily appear in every message). That extended version could then be a near superset of the existing RFC821/822 but with at least one envelope modification that would distinguish "ordinary" from "extended". As an extreme example, a system originating an "extended" message might send STUF FROM: <...> in the envelope, rather than MAIL FROM: <...> Guaranteed to stop an old, poor, implementation in its tracks. Note that this is arguably necessary for something as "trivial" as transmission of ISO8859-1, since SMTP implementations have the RIGHT TO EXPECT that only seven-bit characters will be transmitted. This is a little different from saying "some transport media won't support eight bit characters". --john klensin Klensin@INFOODS.MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 7 Feb 90 08:48:10 EST Received: from cise.cise.nsf.gov by mintaka.lcs.mit.edu id aa23496; 7 Feb 90 8:40 EST Received: from ncri.cise.nsf.gov by cise.cise.nsf.gov id ; Wed, 7 Feb 90 08:40:57 -0500 From: Stephen Wolff Received: by ncri.cise.nsf.gov id ; Wed, 7 Feb 90 08:40:47 -0500 Date: Wed, 7 Feb 90 08:40:47 -0500 Message-Id: <9002071340.AA05831@ncri.cise.nsf.gov> To: header-people@mc.lcs.mit.edu, roode@orc.olivetti.com Subject: Re: Proposed RFC on Encoding header field Cc: Ariel@relay.prime.com, DRB@relay.prime.com Why spend so much energy on a vanishing species? Do it for X.400. -s  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 7 Feb 90 12:33:35 EST Received: from apollo.transarc.com by mintaka.lcs.mit.edu id aa02569; 7 Feb 90 12:21 EST Received: by apollo.transarc.com (5.57/Ultrix3.0-C) id AA08935; Wed, 7 Feb 90 11:08:02 EST Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.transarc.com.pmax.3 via MS.5.6.apollo.transarc.com.pmax_3; Wed, 7 Feb 90 11:07:59 -0500 (EST) Message-Id: Date: Wed, 7 Feb 90 11:07:59 -0500 (EST) From: Craig_Everhart@transarc.com Reply-To: Craig_Everhart@transarc.com To: header-people@mc.lcs.mit.edu Subject: Re: Proposed RFC on Encoding header field Cc: DRB@relay.prime.com, Ariel@relay.prime.com, Craig_Everhart@transarc.com, nsb@thumper.bellcore.com In-Reply-To: <9002060629.AA06511@slembe.uio.no> References: <9002060629.AA06511@slembe.uio.no> Here are my comments, shorter to longer. Point 1: line count. Does the counting begin with the first non-blank line of the encoded part? do blank lines within the encoded part count? Are transport mechanisms rigorous enough in not introducing extra blank lines after the end of a header? Point 2: some of the new encoding types, such as ``hex'', ``uuencode'', and ``encrypted''. These are ill-specified, I think. It's clear that a part described by one of these encodings should undergo the named transformation before becoming useful; that is, one needs to uudecode a body part that's described by a ``uuencode'' encoding. But what's the result? Is it text? Is it a tar file? Is it a compressed tar file? Is it a raster image in some format? Is it an encrypted mail message with headers and all? If you're going to admit simple data-transformation ``encoding'' types, the language for specifying them has to be richer than this. Probably EVFU encoding implies that the resultant object is a line-printer image, much as PostScript encoding/content-type implies that the resultant object is a printed or displayed page. I don't know enough about the actual content-types in EDI or X.400 (why 1984? why not 1988?) to comment on whether this is a sufficient mapping. Point 3: descriptors in the envelope or header or body. In our Content-Type: use in Andrew messages, we treat the header value as a tag on the body type. We worked out a solution to the exchange problem, but never implemented or published it. I'll outline it here, just to muddy the waters (:-)). Invent a new class of delivery agent, in some ways similar to the one in the X.400 architecture. This class of delivery agent is, in general, responsible for doing content-type manipulation as well as doing actual delivery. That is, each message to be delivered may have a Content-type: header indicating that it isn't a vanilla-text message. If the delivery agent is being asked to deliver the message to a recipient that is unable to understand the given content-type, perhaps the message should be translated into a form that the recipient is able to understand (with the presumption that all recipients understand vanilla text). We introduce the If-Type-Unsupported: field, which takes one of three values that indicate what to do if the delivery agent can't know that the recipient is able to understand the content-type of the given message. The values are: - alter transform the message to an understandable form - send send the message with content-type unaltered - reject do not transform the message; reject it back to its sender. With this, message senders can indicate what content-type transformations should occur when the delivery system can't be sure that the content-type will be understood. We've implemented this much, and we're pretty happy with it. Now, how does the delivery agent ever tell whether a fancy content-type will be understood? (This is what we never really implemented; our own delivery system can never tell whether an off-site message recipient will be able to understand a fancy content-type, so it always has to use the If-type-unsupported information for formatted mail going off-site.) The answer to the question depends on the delivery protocol. For SMTP, imagine an extension command something like XCT that would allow SMTP-users to query SMTP-servers as to whether they understood . Clearly, responses such as ``500 Command unrecognized'' would have to be interpreted as indicating that the recipient understood only vanilla text, but imagine a more structured response, such as 250 OK to indicate that the given format was OK, or 277 to indicate that the recipient understood only the listed formats (which would, at least implicitly, always include vanilla text format). The SMTP-user would then consult the list of transformations that it had at its disposal. (For any content-type that it was trying to deliver, presumably it always has some method for transforming it to vanilla text, but it may also have some method for transforming it to some other format. For instance, one can convert most ATK/BE2 formatting to troff without much pain.) The SMTP content-type negotiation can stop here; the sender has enough information to decide on an acceptable content-type transformation, and the mail, as it will be transmitted, will simply be tagged with the given type. I don't have an intimate understanding of other transport mechanisms, but I can certainly imagine comparable things happening elsewhere. For example, UUCP could be told what content-types are acceptable for each of its outgoing links (in the L.sys file or elsewhere). The only remaining issue here is that before a delivery receiver indicates that it is willing to receive a given format of message, it has to be willing to engage in the same negotiation should it ever be called on to transmit that message elsewhere. That is, all the delivery-agent senders have to perform this negotiation and translation, and must have some transform-to-vanilla-text operation available, before any delivery-agent receivers can announce that they will accept a given special format. Otherwise, a mail node could accept a formatted piece of mail, then discover that it was in fact to be forwarded off-site, and not discover that, in forwarding the message off-site, the content-type needs to be reduced to vanilla-text. --------- OK, so what does this have to do with the Encoding header discussion? Two points: - Encoding versions need to go in the header, not in the body, so that they can be used properly for negotiation between cooperating delivery agents. That is, it does me little good if you tell me that you understand PostScript, so I send you my postscript message body, yet when you get it you find that you can't understand the PostScript version 41 that it's encoded in. - The header information is important to delivery agents. The encoding information can't simply go in the envelope, though, since even after delivery, message readers will have to know how to interpret the message body. It's convenient to have the stored-mail representation be the same as the message-in-transit one (in the header rather than in the envelope), since then you don't run into problems when a stored-mail message is re-injected into the system (by a re-send operation, for instance). Craig Everhart  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 7 Feb 90 13:00:07 EST Received: from bells.cs.ucl.ac.uk by mintaka.lcs.mit.edu id aa04326; 7 Feb 90 12:54 EST Received: from lion.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id aa02376; Wed, 7 Feb 90 17:53:57 +0000 To: David Robinson (Special Systems) (Special Systems) cc: header-people@mc.lcs.mit.edu, Rob Ullmann Subject: Re: Proposed RFC on Encoding header field Phone: +44-1-380-7294 In-reply-to: Your message of 05 Feb 90 17:29:09 -0500. <9002051726.aa25156@mintaka.lcs.mit.edu> Date: Wed, 07 Feb 90 17:51:47 +0000 Message-ID: <2215.634413107@UK.AC.UCL.CS> From: Steve Kille Negative response coing up - sorry about this. I feel strongly that this is an RFC we do not need. RFC 822 was obsolete when it was written - however it was needed to keep the services going. Internet work on Multimedia messaging followed a different track, and lead to much excellent work. Now we have X.400, which in conjunction with RFC 1006 is a clear choice for the Internet. If you try to extend 822 you will get problems: - agreeing a spec (there are several other approaches to this already) - coding implementations - interworking - more X.400 gatewaying problems Summary - don't hack 822, deploy X.400 Steve  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 7 Feb 90 14:58:16 EST Received: from en-c06.prime.com by mintaka.lcs.mit.edu id aa10522; 7 Feb 90 14:50 EST Received: from Relay.Prime.COM by EN-C06.Prime.COM; 07 Feb 90 14:56:23 EST Received: (from user DRB) by Relay.Prime.COM; 07 Feb 90 14:53:39 EST To: header-people@mc.lcs.mit.edu Cc: Rob Ullmann From: David Robinson (Special Systems) Subject: Re: Proposed RFC on Encoding header field Date: 07 Feb 90 14:53:40 EST Message-ID: <9002071450.aa10522@mintaka.lcs.mit.edu> The proposed Encoding header field permits the mailing of multi-part, multi-structured Internet messages. There have been several header-people postings suggesting that this functionality would be better provided within the tranport protocol (SMTP) rather than in the message header. RFCs 821 and 822 define a separation of tasks between the mail transport service and higher level services. Generally speaking, the mail transport service is responsible for transporting the mail messages. Higher level agents are responsible for processing the actual mail messages. The encoding functionality is used to describe the internal structure and interpretation of the message body. Under the current separation of responsibilities, the appropriate place for this information is in the header, not in the transport service. Under the current separation of responsibilities, any processing of mail messages into a more "intelligible form" is the responsibility of the destination mail processing agent. This current separation of responsibilities is simple and works well. Use of the Encoding header field will not require changes to any mailers. Mail reading programs can be modified to use Encoding ... or not. The user can always file the message and extract the information separately. On the other hand, if the mail transport service is to make decisions about what will be an "intelligible form" to the destination message processor, then the entire transport network will require modification. The problem is that "intelligible form" is not necessarily a problem that *can* be solved. And, it can't be solved theoretically, then specifying that the transport service will solve it with some future protocol is just voidware. Which is prohibited! What I mean to say is that PostScript version incompatibility is only a drop in the ocean. Taken to its logical end, one should be able to specify that all messages whose "text" encoding type has the option "Deutch" to be converted to English. Thank you, no! I'd rather have it in German and find someone I trust to translate it for me. Better still, I'd rather agree with the sender that we'll both exchange mail in French which we both understand (un peu!). Which is the real solution. We have to create common well-defined encodings for those mail objects whose exchange is considered most useful. If we really want to exchange PostScript, then we need to specify what constitutes acceptible, generally exchangable PostScript. (As Jon Postel did for PostScript RFCs in RFC 1111.) And, when a message arrives that the processing agent cannot be converted to an "intelligible form", the decision to reject it should be made by the processing agent, not the mail transport service. After all, if the processing agent is my mail reading program, I'll probably file the message and see if I can find some other way to crack it. Or discard it. Either way, I'd like the opportunity afforded by having the message in my mailbox as it was sent by the sender, without transport service reformatting. Cheers, David  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 7 Feb 90 16:24:24 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa15286; 7 Feb 90 16:16 EST Date: Wed 7 Feb 90 16:12:37-EST From: John C Klensin Subject: Re: Proposed RFC on Encoding header field To: DRB@relay.prime.com Cc: header-people@mc.lcs.mit.edu Message-ID: <634425157.700000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9002071450.aa10522@mintaka.lcs.mit.edu> Mail-System-Version: David, I will continue to disagree, and, since I'm not likely to convince you or vice versa, let me define two points of difference for others to discuss: (1) If the encoded information is *ever* going to contain eight-bit characters, that is a matter for the transport service by the part of the rules where our reasoning intersects. The transport service has to be able to verify that the high bit will go through unmolested in order to function as a reliable transport. The only way for the transport service to verify that within the general spirit and context of SMTP requires an envelope modification, with the envelope itself remaining in seven-bit ASCII. Now, if I thought this was worth pursuing, I would say "ok, assume that you are mostly right, then let's figure out what envelope information--or restrictions--are needed to ensure correct transport, and then go to work on putting the 'rest' in the header". But that brings me to the second point: (2) While I would not agree with the characterization of RFC822 as being "obsolete when written", SMTP is the wrong place to do this work at this point. X.400 (1988) has the right framework, is expected to carry some of the types of information you are interested in, and is designed around a type-of-field/length-of-field/field organization. You need the latter, you are specifying the latter, and it fits rather poorly on top of SMTP messages. Not to say it can't be done, but why bother? john klensin Klensin@INFOODS.MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 7 Feb 90 17:12:40 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa17612; 7 Feb 90 17:06 EST Received: from nautsund.uio.no by ifi.uio.no (5.61++/1.15) with SMTP id AA20922; Wed, 7 Feb 90 23:05:13 +0100 Date: Wed, 7 Feb 90 23:05:13 +0100 In-Reply-To: <2215.634413107@UK.AC.UCL.CS> "Steve Kille " Message-Id: <90-038-0163@naggum.uu.no> From: Erik Naggum Sender: enag@ifi.uio.no To: Steve Kille Cc: David Robinson (Special Systems) , Rob Ullmann , header-people@mc.lcs.mit.edu Subject: Proposed RFC on Encoding header field Steve, While you may believe that X.400 is a good idea, you have a few million users to convince, and they aren't yet. I do not know X.400 in the detail I know you do, but I know that I would much rather go for a simpler solution and expand on it, than trust some committee somewhere to decide what I need. Each user is different, and his computer system will never be that envisioned "Open System" dream, anyway. Another thing which I dislike with X.400 is it's propensity for binary transmission form, instead of the humanly-readable format of RFC 821/822. You can't just extend ASN.1, either, as you can with RFC 822-headers. There are many new ideas within the X.400 framework, and some of them good, but the bigotry that goes with them is disgusting. You X.400 people could at least credit the Internet for the basic ideas that you exploit so merrily. Look how easily the Internet has adopted many of your acronyms, for instance. (And don't tell me that they're better ideas -- my point is that we're listening in order to solve problems, and don't particularly care whose idea it was (except for crediting them).) Let's take an example. I have been able to do a full RFC 821/822 implementation in less than 3 months from scratch. I can "deploy" my mailer at clients and interested parties for well under $100, sometimes I just give it away. If I spent 3 years on X.400, they'd put out an incompatible new "standard" four years after the one I used for spec, and I couldn't just give the thing away, and there would not be enough people who could or would buy it to support my three years of development, anyway. My summary is quite opposite of yours: Don't wait for X.400, do it in the Internet. [Erik] "The Internet has it *NOW*." (paraphrased from a well-known vendor)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 7 Feb 90 23:28:46 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa04254; 7 Feb 90 23:20 EST Received: from nautsund.uio.no by ifi.uio.no (5.61++/1.15) with SMTP id AA23488; Thu, 8 Feb 90 05:20:10 +0100 Date: Thu, 8 Feb 90 05:20:10 +0100 Message-Id: <9002080420.AA01558@nautsund> From: Erik Naggum Sender: enag@ifi.uio.no To: KLENSIN@infoods.mit.edu Cc: DRB@relay.prime.com, header-people@MC.lcs.mit.edu In-Reply-To: <634425157.700000.KLENSIN@INFOODS.MIT.EDU> Subject: Proposed RFC on Encoding header field The debate over 8-bit vs 7-bit transport services prompts a question: Why was RFC 821 restricted to 7-bit data paths in the first place? For a while, my mailer regarded anything after the blank line that separates header and body as "data", and did not attempt to treat it as lines, and subsequently ate 8-bit data without hesitation. I had to stop doing that and break things into lines (max length 1000 chars) and strip the 8th/most significant/parity bit for compliance reasons. Now I wonder -- is there any need to retain this 7-bit restriction? Or the line length restriction in the body? It's supposed to be left untouched by the MTA's, anyway. I know that there are 7-bit restrictions outside the Internet. [Erik]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Feb 90 06:36:41 EST Received: from bells.cs.ucl.ac.uk by mintaka.lcs.mit.edu id aa18509; 8 Feb 90 6:31 EST Received: from lion.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id aa12892; Thu, 8 Feb 90 11:30:13 +0000 To: Erik Naggum cc: David Robinson (Special Systems) , Rob Ullmann , header-people@mc.lcs.mit.edu Subject: Re: Proposed RFC on Encoding header field Phone: +44-1-380-7294 In-reply-to: Your message of Wed, 07 Feb 90 23:05:13 +0100. <90-038-0163@naggum.uu.no> Date: Thu, 08 Feb 90 11:27:59 +0000 Message-ID: <1043.634476479@UK.AC.UCL.CS> From: Steve Kille Erik, I'm going to try not to get cauhgt up in this! >From: Erik Naggum >To: Steve Kille >Subject: Proposed RFC on Encoding header field >Date: Wed, 7 Feb 90 23:05:13 +0100 > >Steve, >While you may believe that X.400 is a good idea, you have a few >million users to convince, and they aren't yet. I don't think most users care about either 822 or X.400. User requirements are for a good UA and connectivity. The protocol stuff should be buried. >in the detail I know you do, but I know that I would much rather go >for a simpler solution and expand on it, Agreed, but I'd rather have one complex solution, as opposed to lots of simple solutions, each addressing different needs. Uniform service is a major user requirement. We want as few standards as possible. >Another thing which I dislike with X.400 is it's propensity for binary >transmission form, instead of the humanly-readable format of RFC >821/822. You can't just extend ASN.1, either, as you can with RFC >822-headers. I like text encoding, particularly for prototyping. However, there are many arguments both ways. I believe that the general concesus is now moving towards binary encoded protocols (e.g., quite a few recent Interet protocols in ASN.1). I would suggest X.400 (88 not 84) is more extensible than 822. >There are many new ideas within the X.400 framework, and some of them >good, but the bigotry that goes with them is disgusting. Most technical groups have their bigots. You might even find one or two on the Internet. >You X.400 >people could at least credit the Internet for the basic ideas that you >exploit so merrily. I think that credit is given in many places. However, I find it sad that the Internet applications have not evolved in the way the underlying technology has. >Let's take an example. I have been able to do a full RFC 821/822 >implementation in less than 3 months from scratch. I can "deploy" my >mailer at clients and interested parties for well under $100, >sometimes I just give it away. If I spent 3 years on X.400, they'd >put out an incompatible new "standard" four years after the one I used >for spec, and I couldn't just give the thing away, and there would not >be enough people who could or would buy it to support my three years >of development, anyway. >My summary is quite opposite of yours: Don't wait for X.400, do it in >the Internet. I think that some aspects of X.400 are a bit trickier - in part becuase the services offered are a good deal richer. However, I think that implementing a system is a remarkably small part of the effort involved in deploying a SERVICE to hundreds of thousands of users. Because the effort is large, the strategic choice is critical. Saving you a few months coding effort does not enter into the picture. >[Erik] Steve  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Feb 90 12:04:09 EST Received: from en-c06.prime.com by mintaka.lcs.mit.edu id aa29243; 8 Feb 90 11:56 EST Received: from Relay.Prime.COM by EN-C06.Prime.COM; 08 Feb 90 12:02:15 EST Received: (from user ARIEL) by Relay.Prime.COM; 08 Feb 90 11:59:33 EST To: Header People From: Robert Ullmann Subject: on evolution in internet mail Date: 08 Feb 90 11:59:33 EST Message-ID: <9002081156.aa29243@mintaka.lcs.mit.edu> [a side note: while discussion of the relative merits of internet and X.400 is interesting, this group (header-people/comp.mail.headers) is about RFC-822-et-al headers: the usefulness of RFC 822 and the continued use and development of internet mail is (usually :-) taken as axiomatic in this forum. -- Rob] Steve, [just to provide context :-] > I think that credit is given in many places. However, I find it sad that > the Internet applications have not evolved in the way the underlying > technology has. The rate of evolution is directly proportional to the environmental pressure present. Animals evolve faster when a changing environment produces problems. When they have evolved to solve the problem, the evolution stops. Actually it slows, to an imperceptable rate. Further changes occur only as "tweaks", or in non-linear response to periodic climate variation. I believe that internet mail appeared to stop evolving precisely because the problem of internetwork electronic mail was solved. However, a few new environmental pressures have emerged. One of them is the enthusiastic promotion of X.400 :-) The response is as expected: new trial variations are introduced, and may or may not be successful. The Encoding: proposal is one of these. Since you lament the perceived lack of evolution, I am startled to see you immediately criticize it when it starts occuring at a faster rate! Best Regards, Rob  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 8 Feb 90 19:46:35 EST Received: from venera.isi.edu by mintaka.lcs.mit.edu id aa19805; 8 Feb 90 19:41 EST Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 8 Feb 90 16:39:17 -0800 Date: Thu, 8 Feb 90 16:41:30 PST From: postel@venera.isi.edu Posted-Date: Thu, 8 Feb 90 16:41:30 PST Message-Id: <9002090041.AA01900@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Thu, 8 Feb 90 16:41:30 PST To: erik@naggum.uu.no Subject: Re: Proposed RFC on Encoding header field Cc: DRB@relay.prime.com, KLENSIN@infoods.mit.edu, header-people@mc.lcs.mit.edu > Why was RFC 821 restricted to 7-bit data paths in the first place? The were at the time many machines that stored ascii as 7-bit data internally. If mail is routed through such machines the 8th bit is lost. There still are a few in operation on the Internet. --jon.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Feb 90 03:29:06 EST Received: from en-c06.prime.com by mintaka.lcs.mit.edu id aa08138; 9 Feb 90 3:25 EST Received: from HBAPN1.Prime.COM by EN-C06.Prime.COM; 09 Feb 90 03:30:52 EST Received: (from user MDELANY) by HBAPN1.Prime.COM; 09 Feb 90 19:24:57 +1100 From: Mark Delany To: David Robinson , Rob Ullmann Cc: Header-People@MC.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Subject: Proposed RFC on Encoding header field Date: 09 Feb 90 19:24:58 +1100 Message-ID: <9002090325.aa08138@mintaka.lcs.mit.edu> Hi Dave & Rob: A few comments on your proposed RFC. [The group should note my "From:" line and be wary of possible bias.] Trivial editorial comments. --------------------------- The section on encoding types should probably provide a more precise definition of uuencode as even this humble encoder now suffers from a number of mutants/variants. Perhaps it would also be of benefit to define a minimum subset that all implementations should be encouraged to support? Is it needed? ------------- Leaving the larger question of whether this sort of effort is better directed at x.400, to those more capable; the smaller question of applicability to 821/822 remains. Apart from the inherent functionality, the aspect I'd like to concentrate on is that the proposal provides a frame-work for standardizing a set of long-standing de facto practices. When you think about it, encoded mails are probably the pre-eminent form of file transfer between dis-similar or unknown target OS's. Good examples are the obviously popular uuencode, atob and shar forms of encoding. (I've taken some license in this statement, but I'm sure you get the drift.) In spite of such popular usage (and I pass no judgement on this, but to say that it's surely going to continue), aren't the current methods one enormous pain? Try extracting the useful data from a shar file on a non-UNIX system, or uudecode a file for that matter! The worst case of course is a compressed, uuencoded, tar file that some of the popular archivers send. Interoperable it's not. (BTW, top marks to HP's shar, it ships the source of uudecode with the encoded file! An admirable approach to the current mess, but probably impractical for something like Postscript :-). Now there's no reason why these need to be inherently painful, and it's certainly no reflection on the original creators - given the circumstances they did a good job - it's just that in the absence of a standard, people tended to grab the nearest tool to hand, which invariably turns out to be OS specific. So if you take the view that 821/822 will be alive for years to come, and you accept that encoded file transfers are a common user, then it's probably not a bad idea to specify a vehicle that helps move such prevalent usage away from it's OS specific origins to something more generally applicable. Returning to the earlier suggestion of a minimum subset. To attract this type of usage to the fold, I imagine that the subset would have to include satisfactory replacements for uuecode and tar styled encodings. The former is well covered, but the latter may best be satisfied by some form of the Usenix/IEEE POSIX tar. An anecdote addendum for the discussion group: ---------------------------------------------- I've been in a position to use the implementation mentioned by the authors, and I can atest to it's usefulness. While it's nice to be able to exactly pick out the relevant portions, the important point is that it eliminates the error-prone cut/paste/decode/process methods currently in wide-spread use. Whether this is an appropriate place to provide the functionality is an open question; however, from my point of view there is little doubt as to it's usefulness. Mark.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Feb 90 18:37:44 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa07876; 9 Feb 90 18:30 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA01695; Fri, 9 Feb 90 16:30:20 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Feb 90 20:23:41 GMT From: Rouben Rostamian Organization: University of Maryland, Baltimore County Subject: How to set a "Reply-To: " filed in the mail header? Message-Id: <2773@umbc3.UMBC.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I use ucb mail in ULTRIX. I wonder if there is an option to add a header line of the sort: "Reply-To: a_preferred_return_address" in some of the mail that I send out from various machines, just like it's done in usenet postings. My man page on mail is silent about this. Any hints will be appreciated. --Rouben Rostamian P.S.: I do know about .forward files, but nevertheless I would prefer specifying a Reply-To header field. -- Rouben Rostamian Telephone: (301) 455-2458 Department of Mathematics and Statistics e-mail: University of Maryland Baltimore County rostamian@umbc.bitnet Baltimore, MD 21228 rostamian@umbc3.umbc.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 00:53:26 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24355; 20 Feb 90 0:50 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA11337; Mon, 19 Feb 90 23:32:22 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 20 Feb 90 03:21:12 GMT From: Robert Stephens Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: How to set a "Reply-To: " filed in the mail header? Message-Id: <51174@sgi.sgi.com> References: <2773@umbc3.UMBC.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <2773@umbc3.UMBC.EDU>, rouben@math9.math.umbc.edu (Rouben Rostamian) writes: > > I use ucb mail in ULTRIX. I wonder if there is an option to add a header line > of the sort: > > "Reply-To: a_preferred_return_address" Not that I know of. I just had to add such an option to our version of ucb Mail in IRIX. I don't think you can do it at all with standard ucb Mail. Robert Stephens  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 02:47:57 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27876; 20 Feb 90 2:45 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA19401; Tue, 20 Feb 90 02:15:27 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 20 Feb 90 07:00:31 GMT From: Dan Heller Subject: Re: How to set a "Reply-To: " filed in the mail header? Message-Id: <132047@sun.Eng.Sun.COM> References: <2773@umbc3.UMBC.EDU>, <51174@sgi.sgi.com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <51174@sgi.sgi.com> roberts@nimrod.wpd.sgi.com (Robert Stephens) writes: > In article <2773@umbc3.UMBC.EDU>, rouben@math9.math.umbc.edu (Rouben Rostamian) writes: > > I use ucb mail in ULTRIX. I wonder if there is an option to add a header line > > of the sort: > > "Reply-To: a_preferred_return_address" > Not that I know of. I just had to add such an option to our version of ucb > Mail in IRIX. I don't think you can do it at all with standard ucb Mail. In Mush, just type: my_hdr Reply-To: roberts and there you go. Note: Mush is backwards compatible with ucbMail, so there's no learning curve involved in getting up to speed with Mush. However, Mush is as powerful as the other mail packages, if not more so, so it might be worth your while to ftp it than to continue hacking your ucbMail. And while I'm pushing Mush :-), it's portable to virtually all versions of UNIX (no problems yet) and there is a DOS version as well. ftp info: ucbvax:pub/mailers/mush-7.0.tar.Z those who want the DOS version mail to lmoc@lena.uucp (via uunet). Mush is currently at version 7.0.4. 7.1 will be out shortly -- this has significant improvements to the sunview mode. dan ----------------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com 632 Petaluma Ave, Sebastopol, CA 95472 800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 12:29:24 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa18167; 20 Feb 90 12:25 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA15386; Tue, 20 Feb 90 11:56:04 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 20 Feb 90 16:51:37 GMT From: "Barton E. Schaefer" Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR Subject: Re: How to set a "Reply-To: " filed in the mail header? Message-Id: <7459@ogicse.ogc.edu> References: <2773@umbc3.UMBC.EDU>, <51174@sgi.sgi.com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <51174@sgi.sgi.com> roberts@nimrod.wpd.sgi.com (Robert Stephens) writes: } In article <2773@umbc3.UMBC.EDU>, rouben@math9.math.umbc.edu (Rouben Rostamian) writes: } > } > I use ucb mail in ULTRIX. I wonder if there is an option to add } > } > "Reply-To: a_preferred_return_address" } } Not that I know of. I just had to add such an option to our version of ucb } Mail in IRIX. I don't think you can do it at all with standard ucb Mail. You can't do it "right", but you can do it: ---------------------------------------- #! /bin/sh # "mail" front-end for Reply-To: headers echo -n "Subject: " read subject # Note imbedded return in the "" text mail -s "$subject Reply-To: a_preferred_return_address" $* ---------------------------------------- I won't go to the work of figuring out how to test for "set ask" before prompting for the subject, nor how to parse a -s option to the script, but it can be done. You still ought to get Mush. ;-) Just the other mush hacker, -- Bart Schaefer "February. The hangnail on the big toe of the year." -- Duffy schaefer@cse.ogi.edu (used to be cse.ogc.edu)  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 16:42:04 EST Received: from inet.att.com by mintaka.lcs.mit.edu id aa29086; 20 Feb 90 16:28 EST Received: by inet; Tue Feb 20 14:27:10 1990 From: smb@ulysses.att.com To: header-people@MC.lcs.mit.edu Subject: Re: How to set a "Reply-To: " filed in the mail header? Date: Tue, 20 Feb 90 14:27:00 EST Original-From: smb@toucan Message-ID: <9002201628.aa29086@mintaka.lcs.mit.edu> In '81 or thereabouts, when I first wrote pathalias, I hacked ucbmail to let you specify arbitrary headers. You could create a variable to specify your header set; each element in the comma-separated list specified another variable to include in the header. But that code died with 4.1bsd, as far as I know. --Steve Bellovin  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Feb 90 20:42:05 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29928; 21 Feb 90 20:38 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA28937; Wed, 21 Feb 90 19:14:56 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 21 Feb 90 12:54:34 GMT From: Jan Stevens Organization: Philips CFT Subject: Re: How to set a "Reply-To: " filed in the mail header? Message-Id: <970@philtis.cft.philips.nl> References: <2773@umbc3.UMBC.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Most mailers use a fixed, predefined header. To change the header you must use a mailer which is capable of adding lines to the header. Elm is such a type of mailer. What the layout of the header concerns : It ends with an empty line. It must have a To and From line. Jan Stevens, Unix Support Engineer Philips CFT, the Netherlands e-mail: jan@philtis.cft.philips.nl  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Feb 90 17:15:53 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa09653; 24 Feb 90 17:05 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA07095; Sat, 24 Feb 90 15:53:35 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 24 Feb 90 20:50:27 GMT From: Matt Madison Organization: Rensselaer Polytechnic Institute, Troy, NY Subject: Mild flame about (some) UNIX mailers Message-Id: <00932CA6.30EE8E00@vms.ecs.rpi.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Having just finished writing some new E-mail software for our VMS system, I have spent several hours studying both RFC 821 and RFC 822 to ensure that this software complies with these standards. After all, these standards are used by all the systems on the Internet, right? As soon as this software went into production use, we started experiencing problems exchanging mail with (you guessed it) some UNIX systems on our network (and elsewhere). There have been three problems so far, and trivial though they may be, they have been rather aggravating. Problem 1. In implementing a gateway between VMS MAIL coming in over DECnet and SMTP, my software generates return addresses of the form <"node::user"@domain>. The quotation marks are necessary because colons are considered "special" by RFC 822. This immediately started to cause problems because (I'm told) sendmail by default strips quotation marks from the user portion of an address. So when UNIX users tried to reply to messages sent from my system, the replies would be rejected by my SMTP server becuase is not valid RFC 822. Problem 2. RFC 821 states that all lines sent should be terminated with a carriage return/line feed sequence. It turns out that some UNIX-based SMTP implementations do not adhere to this and by default terminate lines simply with line feeds. Now, I can understand this behaviour in older UNIX implementations. But we're talking recent versions of ULTRIX and SGI's UNIX (whatever it's called)! Problem 3. Some UNIX mail systems appear to generate return addresses of the form real name Where "real name" is simply pulled from the passwd file (or wherever this information is obtained on UNIX systems), without verifying that it can be left unquoted and still comply with RFC 822. This means that anyone who has included their middle initial with their name, with a dot, will have a return address that violates the standard (dots are not allowed in the leading phrase before the address). Parsing 822-compliant addresses is complicated enough without having to deal with crap like this. What really burns me up about this, is that it's considered _my_ fault that this stuff doesn't work! Argh. -- Matthew Madison, Systems Programmer | "First they built the world's standard. Engineering Computing Services | Then they added standards no one else Rensselaer Polytechnic Institute | had." - an ad for SCO Xenix Troy, New York 12180-3590 USA | madison@vms.ecs.rpi.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Feb 90 01:00:39 EST Received: from RUDY.FAC.CS.CMU.EDU by mintaka.lcs.mit.edu id aa16309; 25 Feb 90 0:55 EST Received: from rudy.fac.cs.cmu.edu by RUDY.FAC.CS.CMU.EDU id aa01909; 25 Feb 90 0:54:54 EST To: Matt Madison cc: header-people@mc.lcs.mit.edu Subject: Re: Mild flame about (some) UNIX mailers In-reply-to: <00932CA6.30EE8E00@vms.ecs.rpi.edu> Date: Sun, 25 Feb 90 00:54:19 EST From: Rudy.Nedved@rudy.fac.cs.cmu.edu Message-ID: <9002250055.aa16309@mintaka.lcs.mit.edu> Matt, You are not alone in you frustrations but after you have hacked mail systems you understand that mail systems are an example of extreme software politics, policy and peopleness and you live with it. This is why you hear comments like "Be liberal in what you accept and conservative in what you generate" when referring to mail protocol implementations. You understand why. Rudy Nedved (old mail wizard for TOPS-10/20, Unix, VMS, ??) Operations Manager School of Computer Science Carnegie Mellon University P.S. In the spirit of progress, why are you using source-routed addresses embedded in a mail address. Why don't you register you DECnet node names in a domain name server and have incoming mail from DECnet nodes translated from DECnet names to internet domain name?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Feb 90 03:34:11 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22275; 25 Feb 90 3:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA11216; Sun, 25 Feb 90 02:42:57 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 25 Feb 90 04:31:23 GMT From: crash!simpact!jeh@nosc.mil Organization: Simpact Associates, San Diego CA Subject: Re: Mild flame about (some) UNIX mailers Message-Id: <985.25e6ef1b@simpact.com> References: <00932CA6.30EE8E00@vms.ecs.rpi.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <00932CA6.30EE8E00@vms.ecs.rpi.edu>, madison@vms.ecs.rpi.edu (Matt Madison) writes: > Problem 1. In implementing a gateway between VMS MAIL coming in over > DECnet and SMTP, my software generates return addresses of the form > <"node::user"@domain>. The quotation marks are necessary because colons > are considered "special" by RFC 822. This immediately started to cause > problems because (I'm told) sendmail by default strips quotation marks > from the user portion of an address. So when UNIX users tried to reply > to messages sent from my system, the replies would be rejected by my > SMTP server becuase is not valid RFC 822. I suggest that you do what we (the DECUS uucp folks) do for our "user base": We have an address rewrite mechanism that, for From addresses on outbound mail, can be set up to rewrite node::user to user@node.rest_of_domain eg, stuff coming from SKYVAX::user here ('here' is simpact.com) ends up coming from user@skyvax.simpact.com. This is in concert with most domain naming schemes anyway, where the second-level domain ('simpact' in our case) specifies which company within .com, and the third-level specifies which machine within .simpact.com . Our rewrite rules can get fancier; for example, if there may be overlaps between DECnet nodename space and some other internal network's namespace to which you must also delivery mail, you can choose to rewrite to something like user@node.decnet.simpact.com or even user%node@decnet.simpact.com (but a lot of other mailers don't do what you want with %'s) And, of course, for To: addresses on inbound mail, we can look for things that match whichever of the above patterns the user wants, and rewrite to node::user for inbound delivery. This works for us (simpact), even in a horribly mixed decnet/tcp-ip/uucp environment, and we don't even use PMDF (yet). > ...[descriptions of other hassles deleted] > What really burns me up about this, is that it's considered _my_ fault that > this stuff doesn't work! Argh. Being chief recipient for e-mail and phone calls regarding DECUS uucp, I know EXACTLY what you mean. (And thanks to all of you who have communicated thanks to us for the package; you are keeping us going!) The above commentary is in no way meant to suggest that mailers Out There ought NOT to take "anything_at_all"@domain and pass the stuff in quotes intact. But suggesting that they do so is probably tilting at windmills. (p.s.: DECUS uucp is uucp for VMS with full mail and netnews support. It is essentially free. Send mail to me for info.) --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Feb 90 20:39:01 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa28048; 25 Feb 90 20:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA17906; Sun, 25 Feb 90 18:34:26 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 25 Feb 90 23:27:14 GMT From: Eliot Organization: GenBank Computing Resource for Mol. Biology Subject: Re: Mild flame about (some) UNIX mailers Message-Id: References: <00932CA6.30EE8E00@vms.ecs.rpi.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [From RFC1123] 1.2.2 Robustness Principle At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability: "Be liberal in what you accept, and conservative in what you send" UNIX doesn't let you forget that. -- Eliot Lear [lear@TURBO.BIO.NET]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 07:36:16 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa22635; 26 Feb 90 7:28 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22843; Mon, 26 Feb 90 06:46:03 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 Feb 90 11:39:44 GMT From: Ned Freed Organization: Harvey Mudd College, Claremont, CA 91711 Subject: Re: Mild flame about (some) UNIX mailers Message-Id: <4674@jarthur.Claremont.EDU> References: <00932CA6.30EE8E00@vms.ecs.rpi.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Welcome to the real world of mailers! As the primary author of PMDF, a very popular mail system for VMS machines, I've run into all the problems you cite on numerous occasions. You've only just started -- there are lots more waiting for you. Now some advice. You'll never get mailers to accept "node::user"@domainhost format. It is a hopeless task. So I'd recommend using something of the form user%node@domainhost if possible. This even generalizes to multiple nodes if you need them. Note that this does not solve the entire problem of how to handle all the wierd stuff VMS MAIL likes to use, but it will get you started at least. The problem of mailers inserting some bogosity into the personal name field in an address is well-known too. My advice on this one is to simply ignore it. You should not be looking at header lines for delivery purposes anyway. The envelope should suffice, and personal name fields are flagrantly illegal in an envelope (PMDF accepts them but strips them for reasons that I won't get into in this forum). You can either insert a sanitized header line in place of the incorrect line or just pass it on unchanged and let the next mailer downstream worry about it. If it rejects it your hands are clean -- that's a battle between the offending mailer and the picky mailer! A final note. All the standards say that a blank address is completely legal in various places, e.g. an SMTP MAIL FROM: line. Watch out for those. Several UNIX mailers (you know who you are) go into infinite loops when they get one of these. And if you think you've had trouble with users whose mail got lost in the past, you've got a new treat when you deal with a sysmgr whose load average was at 50 before he wiped out all those looping mail processes. Not a pretty sight. Good luck on your project. I saw an announcement of your system on the JNET-L list, I believe. Sounds good. Ned Freed ned@ymir.claremont.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 10:02:42 EST Received: from decpa.pa.dec.com by mintaka.lcs.mit.edu id aa28569; 26 Feb 90 9:56 EST Received: by decpa.pa.dec.com; id AA06273; Mon, 26 Feb 90 06:56:40 -0800 Received: by dcrocker.pa.dec.com; id AA12692; Mon, 26 Feb 90 06:54:37 PST Message-Id: <9002261454.AA12692@dcrocker.pa.dec.com> To: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!csvned@think.com Cc: header-people@mc.lcs.mit.edu Subject: Re: Mild flame about (some) UNIX mailers In-Reply-To: Your message of 26 Feb 90 11:39:44 +0000. <4674@jarthur.Claremont.EDU> Date: Mon, 26 Feb 90 06:54:36 PST From: Dave Crocker Just to add to the fun, an alternate to the format that Ned suggests is: user@node.domain but this requires you to set up the domain servers which handle domain to MX all references to *.domain to the appropriate gateway. Actually, this is not onerous overhead and results in Internet email addresses that look quite natural. The '%' usage (kindly called the percent hack) was developed originally to overcome the lack of any mechanism such as MX records, around the spring of 79. Most of the world has advanced, so it would be nice to take advantage of it. On the other hand, the percent hack is simple and always works. Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 11:22:03 EST Received: from decpa.pa.dec.com by mintaka.lcs.mit.edu id aa02712; 26 Feb 90 11:13 EST Received: by decpa.pa.dec.com; id AA10514; Mon, 26 Feb 90 08:13:46 -0800 Received: by dcrocker.pa.dec.com; id AA12820; Mon, 26 Feb 90 08:11:35 PST Message-Id: <9002261611.AA12820@dcrocker.pa.dec.com> To: header-people@mc.lcs.mit.edu Subject: Re: Mile flame about (some) Unix mailers Date: Mon, 26 Feb 90 08:11:32 PST From: Dave Crocker Well, this certainly is interesting... ------- Forwarded Message Return-Path: Postmaster@rutgers.edu Received: by jove.pa.dec.com; id AA20020; Mon, 26 Feb 90 07:34:38 -0800 Received: by decpa.pa.dec.com; id AA08268; Mon, 26 Feb 90 07:34:33 -0800 Received: from uwvax.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP id AB17668; Mon, 26 Feb 90 10:34:05 EST Date: Mon, 26 Feb 90 10:34:05 EST From: Postmaster@rutgers.edu (Mail Delivery Subsystem) Subject: Returned mail: Unable to deliver mail Message-Id: <9002261534.AB17668@rutgers.edu> To: dcrocker ----- Transcript of session follows ----- 554 ames!indri!uakari!brutus!jarthur!csvned... Mail loop detected 554 sendall: too many hops (17 max) ----- Unsent message follows ----- Received: from uwvax.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP id AA17668; Mon, 26 Feb 90 10:34:05 EST Received: from uakari.primate.wisc.edu by spool.cs.wisc.edu; Mon, 26 Feb 90 09:31:26 -0600 Received: from indri.primate.wisc.edu by uakari.primate.wisc.edu; id AA17370; 5.61/41.6; Mon, 26 Feb 90 09:31:11 -0600 Received: from ames.arc.nasa.gov by indri.primate.wisc.edu; id AA06486; 5.61/37.11; Mon, 26 Feb 90 09:31:05 -0600 Received: from iuvax.cs.indiana.edu by ames.arc.nasa.gov (5.61/1.2); Mon, 26 Feb 90 07:30:51 -0800 Received: from uiucdcs!brutus!nsl.dec.com by iuvax.cs.indiana.edu with UUCP (5.61+/1.4jsm) id AA02194; Mon, 26 Feb 90 10:30:48 -0500 Received: from brutus.cs.uiuc.edu by a.cs.uiuc.edu with SMTP (5.61+/IDA-1.2.8) id AA19452; Mon, 26 Feb 90 09:00:50 -0600 Received: from Choices.cs.uiuc.edu (babym.cs.uiuc.edu) by brutus.cs.uiuc.edu (4.0/1.2nn-UIUC-Systems-Research-Group) id AA07063; Mon, 26 Feb 90 08:59:27 CST Received: from zaphod.mps.ohio-state.edu by Choices.cs.uiuc.edu (4.0/1.2nn-UIUC-Systems-Research-Group) id AA16516; Mon, 26 Feb 90 09:02:38 CST Received: from decpa.pa.dec.com by zaphod.mps.ohio-state.edu (4.1/1.890401) id AA13621; Mon, 26 Feb 90 10:00:30 EST Received: by decpa.pa.dec.com; id AA06410; Mon, 26 Feb 90 06:59:26 -0800 Received: by nsl.pa.dec.com; id AA04542; Mon, 26 Feb 90 06:56:48 -0800 Received: by decpa.pa.dec.com; id AA06318; Mon, 26 Feb 90 06:57:21 -0800 Received: from Fafnir.Think.COM by Think.COM; Mon, 26 Feb 90 09:57:12 -0500 Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 26 Feb 90 09:55:56 EST Return-Path: Received: from decpa.pa.dec.com by Think.COM; Mon, 26 Feb 90 09:56:56 -0500 Received: by decpa.pa.dec.com; id AA06273; Mon, 26 Feb 90 06:56:40 -0800 Received: by dcrocker.pa.dec.com; id AA12692; Mon, 26 Feb 90 06:54:37 PST Message-Id: <9002261454.AA12692@dcrocker.pa.dec.com> To: brutus!csvned@uakari.primate.wisc.edu Cc: header-people@mc.lcs.mit.edu Subject: Re: Mild flame about (some) UNIX mailers In-Reply-To: Your message of 26 Feb 90 11:39:44 +0000. <4674@jarthur.Claremont.EDU> Date: Mon, 26 Feb 90 06:54:36 PST From: Dave Crocker Just to add to the fun, an alternate to the format that Ned suggests is: ...  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 16:50:36 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa18994; 26 Feb 90 16:45 EST Date: Mon 26 Feb 90 16:40:52-EST From: John C Klensin Subject: Re: Mild flame about (some) UNIX mailers To: dcrocker@nsl.dec.com Cc: header-people@mc.lcs.mit.edu Message-ID: <636068452.670000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9002261454.AA12692@dcrocker.pa.dec.com> Mail-System-Version: >On the other hand, the percent hack is simple and always works. Actually, the percent hack "always" works iff the mail servers at the gateway understand how to make the translation to an address on your network. Some do, some don't, although all can be designed to do so. The user@node.domain approach avoids this problem, as well as use of the hack- domain. --john -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 17:38:29 EST Received: from decpa.pa.dec.com by mintaka.lcs.mit.edu id aa21642; 26 Feb 90 17:35 EST Received: by decpa.pa.dec.com; id AA05831; Mon, 26 Feb 90 14:35:59 -0800 Received: by dcrocker.pa.dec.com; id AA13458; Mon, 26 Feb 90 14:33:53 PST Message-Id: <9002262233.AA13458@dcrocker.pa.dec.com> To: John C Klensin Cc: header-people@mc.lcs.mit.edu Subject: Re: Mild flame about (some) UNIX mailers In-Reply-To: Your message of Mon, 26 Feb 90 16:40:52 -0500. <636068452.670000.KLENSIN@INFOODS.MIT.EDU> Date: Mon, 26 Feb 90 14:33:51 PST From: Dave Crocker Experimental psychologists sometimes are accused of doing an experiment that shows a difference which is significant, but without meaning. That is, the statistics point to a discernible difference, but there is no real impact. To carry the example into current reality: anything which involves a relay requires its consent. user@node.domain requires that the machine which is MX's for *.domain be a consenting cpu, the same as the machine referenced by domain, in user%node@domain. Certainly the syntax and some of the underlying mechanisms (e.g., support for MX records) is different. The point behind my implying greater safety in the %-hack is that it has less dependence upon outside mechanism. In particular, use of the domain name system and MX records works less often than we all would wish. Dave  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 08:36:11 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02625; 2 Mar 90 8:30 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA10206; Fri, 2 Mar 90 07:43:00 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Mar 90 11:18:25 GMT From: Jerry Peek Organization: Syracuse University, Syracuse, NY Subject: Re: How to set a "Reply-To: " filed in the mail header? Message-Id: <2323@rodan.acs.syr.edu> References: <2773@umbc3.UMBC.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <2773@umbc3.UMBC.EDU>, rouben@math9.math.umbc.edu (Rouben Rostamian) writes: > I use ucb mail in ULTRIX. I wonder if there is an option to add a header line > of the sort: > > "Reply-To: a_preferred_return_address" I'm two weeks behind on my news :-(, so sorry if I missed someone else's posting (expired by now) with this answer. MH lets you customize the header completely. You make a blank draft template file called "components". It could look like this: To: Reply-to: a_preferred_return_address cc: Subject: ------- Then, when you send a message, you'll be prompted for the empty components. The Reply-to: component in this file will be used, as is, automatically. --Jerry Peek; Syracuse University Academic Computing Services; Syracuse, NY jdpeek@rodan.acs.syr.edu, JDPEEK@SUNRISE.BITNET +1 315 443-3995 -- --Jerry Peek; Syracuse University Academic Computing Services; Syracuse, NY jdpeek@rodan.acs.syr.edu, JDPEEK@SUNRISE.BITNET +1 315 443-3995  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 14:35:18 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa19377; 2 Mar 90 14:29 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA00414; Fri, 2 Mar 90 14:11:22 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Mar 90 18:06:27 GMT From: Jef Poskanzer Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal Subject: Re: Mild flame about (some) UNIX mailers Message-Id: <16483@well.sf.ca.us> References: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu } "Be liberal in what you accept, and } conservative in what you send" In my experience, the typical postmaster who quotes this aphorism wants others to abide by the first part, so that he doesn't have to abide by the second. Not Eliot, of course. But every other time this bullshit has appeared, that has been what was actually going on. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef Now how much would you pay?  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 18:32:28 EST Received: from akbar.cac.washington.edu by mintaka.lcs.mit.edu id aa00216; 2 Mar 90 18:14 EST Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.61/UW-NDC Revision: 2.11 ) id AA27641; Fri, 2 Mar 90 15:14:35 -0800 Date: Fri, 2 Mar 1990 15:06:46 PST From: Mark Crispin Sender: mrc@tomobiki-cho.cac.washington.edu Subject: Re: Mild flame about (some) UNIX mailers To: Jef Poskanzer Cc: header-people@mc.lcs.mit.edu In-Reply-To: <16483@well.sf.ca.us> Message-Id: In <16483@well.sf.ca.us>, Jef Poskanzer writes: >} "Be liberal in what you accept, and >} conservative in what you send" > >In my experience, the typical postmaster who quotes this aphorism wants >others to abide by the first part, so that he doesn't have to abide by >the second. It's worse than that. They also expect others to abide by the second part, so that they don't have to abide by the first. :-( -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 2 Mar 90 21:58:49 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12256; 2 Mar 90 21:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16013; Fri, 2 Mar 90 21:45:49 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Mar 90 20:04:18 GMT From: Peter da Silva Organization: Xenix Support, FICC Subject: Re: Mild flame about (some) UNIX mailers Message-Id: References: , <16483@well.sf.ca.us> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu > } "Be liberal in what you accept, and > } conservative in what you send" > In my experience, the typical postmaster who quotes this aphorism wants > others to abide by the first part, so that he doesn't have to abide by > the second. Not Eliot, of course. But every other time this bullshit > has appeared, that has been what was actually going on. One does not always have the option of abiding by the second, unless you use the newfangled meaning of the word "conservative" (i.e., reactionary). Those of us at sites with proprietary mail software that can't economically be replaced are kind of stuck. Even if we generate standard UUCP version 2 headers (which conform to RFC822 via a grandfather clause, according to people I've spoken to) we're out of luck for sites running smail 3.0. -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 3 Mar 90 15:31:20 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa18910; 3 Mar 90 15:28 EST Date: Sat 3 Mar 90 15:22:37-EST From: John C Klensin Subject: Re: Mild flame about (some) UNIX mailers To: header-people@mc.lcs.mit.edu Message-ID: <636495757.200000.KLENSIN@INFOODS.MIT.EDU> Mail-System-Version: > Even if we generate standard UUCP version >2 headers (which conform to RFC822 via a grandfather clause, according >to people I've spoken to) ... Peter, I don't know whom you have spoken to, but there are no grandfather clauses in RFC822, and RFC1123 (Host Requirements) clarifies and stresses several things that should have already been clear from any careful and reasonable reading of RFC822. Your note implies to me that there is more merit in blaming, and pressuring, vendors of email (etc.) software packages than it is in blaming and pressuring those who run the package, and, having been forced to run some things I was very unhappy with, I concur. On the other hand, it is typically the case that vendors are more easily "persuaded" by their current and potential users than by "the community" and -- especially from your standpoint -- the most attractive way for the rest of us to create that situation often involves yelling at the people who put the incorrect headers (or whatever) out. The only alternative the Internet community has is to strenuously encourage gateways to stop passing mail traffic that does not conform to the standards, and that would cut you off entirely until your vendor came into line. john klensin Klensin@INFOODS.MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 4 Mar 90 00:59:58 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa08824; 4 Mar 90 0:57 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA29984; Sun, 4 Mar 90 00:34:51 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Mar 90 05:28:12 GMT From: ccavax!tinkelman@uunet.uu.net Organization: Cambridge Computer Associates, Inc. Subject: Replacing colons with periods in To-addresses Message-Id: <18538.25edbe1d@ccavax.camb.com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I have a question about a sendmail.cf rule. But first the background. Recently I received mail from a friend at Digital who was using a new mail system. It arrived with an illegal return address, albeit one that I, as a human, could understand. It was meaning make uucp hops to uunet and decwrl, then DECnet mail-ll to koala, then through mrgate into the message router, then to node koala (aren't we already here?), to Message Router mailbox x4, to user graff. (Simple, huh?) Despite the fact I was 99% certain that those colons would cause problems somewhere, I decided to try replying, just to see what would happen. What happened was a rejection from decwrl: > ----- Transcript of session follows ----- > 550 ... User unknown Surprise! uunet accepted the address with those colons, passed it on to decwrl, but changed the colons into periods. It really was uunet that had made the changes. In reply to my inquiry, the postmaster at uunet said that their sendmail.cf has scattered throughout it lines like # map colons to dots everywhere..... R$*:$* $1.$2 map colons to dots I'm not a sendmail.cf expert (and I certainly don't have uunet's entire sendmail.cf in front of me to look at). I'd assume that uunet knows what they're doing. Could someone please explain it? When would the above rule make sense? -- Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830 bob@ccavax.camb.com or ...!uunet!ccavax!bob -- Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830 bob@ccavax.camb.com or ...!uunet!ccavax!bob  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Mar 90 20:07:57 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21371; 5 Mar 90 19:59 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA04893; Mon, 5 Mar 90 19:29:17 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 5 Mar 90 23:42:23 GMT From: John Gilmore Organization: Cygnus Support, Palo Alto Subject: Re: "X.400" articles with >To:, Message-Version:, etc Message-Id: <10613@hoptoad.uucp> References: Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu emv@math.lsa.umich.edu (Edward Vielmetti) wrote: > My B News 2.11.14 croaks on articles with articles that look like > this. Note the > >To: > and >From: > headers. > > I'm converting to C News soon, not sure if this is a bug in B News, > a bug in something else, or just a problem with bit.*. (The article is below...you won't believe it.) This is a bug in the email software that gatewayed this message into the Internet from some X.400 based mail system. In particular, I have seen this cruft on EVERY message that goes through the "attmail" service, even if it is just relaying from a uucp site to another uucp site. When the email happens to gateway into a newsgroup, netnews barfs on it. I complained to attmail but they said "Every one of those headers has a purpose, you are just full of shit." Tell it to the Marines. Note the three different Message-ID's, the four useless version numbers and End-Of headers (haven't they noticed that RFC822 specifies that the order of header lines is not preserved?), and the mangled ">To:" and ">From:" lines instead of To: and From: lines. John > article > 220 0 Article retrieved, head and body follow. > Path: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!psuvm!MD3B2P!HMACK > Approved: NETNEWS@PSUVM.BITNET Gateway > Message-Version: 2 > >To: att!tecmtyvm.bitnet!dbase-l > >From: hmack (Herbert C. Mack x6098) > UA-Content-ID: > End-of-Header: > Email-Version: 2 > UA-Message-ID: > Phone: 631-6098 > End-of-Protocol: > Content-Type: text > Content-Length: 237 > Message-ID: > Newsgroups: bit.listserv.dbase-l > Date: Wed, 28 Feb 90 18:33:53 EDT > Reply-To: Discussion on the use of the dBase language and related dialects > > Sender: Discussion on the use of the dBase language and related dialects > > From: hmack@MD3B2P.ATT.COM > Subject: dBase Listing > > To Whom It May Concern, > > I am interested in receiving information regarding dbase, fox, and > clipper. My return mail address is as follows: > > EMAIL DBASE -L md3b2p!hmack@att.att.com > > > Thanks, > > Herb > . -- John Gilmore {sun,pacbell,uunet,pyramid}!hoptoad!gnu gnu@toad.com Boycott the census! The government that invaded Central America does not hesitate to break into "their own" census database to violate your privacy. Maximum penalty for refusing to answer: $100, no jail.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 6 Mar 90 10:00:43 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa05158; 6 Mar 90 9:56 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA23570; Tue, 6 Mar 90 09:52:31 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 6 Mar 90 14:49:01 GMT From: TRANSARC.COM!Craig_Everhart@ucbvax.berkeley.edu Subject: Re: "X.400" articles with >To:, Message-Version:, etc Message-Id: References: <10613@hoptoad.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I don't think there's anything out-and-out illegal about what you quoted in the gatewayed-from-X.400 header. You may not *like* the >To: and >From: headers, but RFC822 says they're OK. (Whether B-news likes them is another matter, but that's a ``small matter of programming.'') The two additional IDs will doubtless be useful to you three years hence when you're debugging your own installation of X.400. Craig  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 07:05:36 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa25074; 9 Mar 90 6:59 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA16611; Fri, 9 Mar 90 04:53:09 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 24 Feb 90 20:50:27 GMT From: Matt Madison Organization: Rensselaer Polytechnic Institute, Troy, NY Subject: Mild flame about (some) UNIX mailers Message-Id: <00932CA6.30EE8E00@vms.ecs.rpi.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Having just finished writing some new E-mail software for our VMS system, I have spent several hours studying both RFC 821 and RFC 822 to ensure that this software complies with these standards. After all, these standards are used by all the systems on the Internet, right? As soon as this software went into production use, we started experiencing problems exchanging mail with (you guessed it) some UNIX systems on our network (and elsewhere). There have been three problems so far, and trivial though they may be, they have been rather aggravating. Problem 1. In implementing a gateway between VMS MAIL coming in over DECnet and SMTP, my software generates return addresses of the form <"node::user"@domain>. The quotation marks are necessary because colons are considered "special" by RFC 822. This immediately started to cause problems because (I'm told) sendmail by default strips quotation marks from the user portion of an address. So when UNIX users tried to reply to messages sent from my system, the replies would be rejected by my SMTP server becuase is not valid RFC 822. Problem 2. RFC 821 states that all lines sent should be terminated with a carriage return/line feed sequence. It turns out that some UNIX-based SMTP implementations do not adhere to this and by default terminate lines simply with line feeds. Now, I can understand this behaviour in older UNIX implementations. But we're talking recent versions of ULTRIX and SGI's UNIX (whatever it's called)! Problem 3. Some UNIX mail systems appear to generate return addresses of the form real name Where "real name" is simply pulled from the passwd file (or wherever this information is obtained on UNIX systems), without verifying that it can be left unquoted and still comply with RFC 822. This means that anyone who has included their middle initial with their name, with a dot, will have a return address that violates the standard (dots are not allowed in the leading phrase before the address). Parsing 822-compliant addresses is complicated enough without having to deal with crap like this. What really burns me up about this, is that it's considered _my_ fault that this stuff doesn't work! Argh. -- Matthew Madison, Systems Programmer | "First they built the world's standard. Engineering Computing Services | Then they added standards no one else Rensselaer Polytechnic Institute | had." - an ad for SCO Xenix Troy, New York 12180-3590 USA | madison@vms.ecs.rpi.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 08:23:35 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa27024; 9 Mar 90 8:00 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA21197; Fri, 9 Mar 90 07:41:20 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Feb 90 20:18:49 GMT From: Kyle Jones Subject: message encapsulation in returned mail: a plea Message-Id: <1990Feb12.201849.28525@talos.uu.net> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu If any of you are writing a new mail delivery agent, and this agent returns a copy of a message upon unsuccessful delivery, please take a look at RFC 934, "Proposed Standard for Message Encapsulation", before inventing another way to encapsulate messages. I'm maintaing a mail reader that tries to recognize and extract returned mail. At present an if-clause is required for every different delivery agent, because they all have a different way of heralding the beginning of an undelivered message. I'd love to see existing delivery agents adopt the standard as well, but at the very least I hope no new mailers will ignore it.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 9 Mar 90 09:58:38 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa01764; 9 Mar 90 9:53 EST Date: Fri 9 Mar 90 09:48:21-EST From: John C Klensin Subject: Re: message encapsulation in returned mail: a plea To: rti!talos!kjones@mcnc.org Cc: header-people@MC.lcs.mit.edu Message-ID: <636994101.340000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <1990Feb12.201849.28525@talos.uu.net> Mail-System-Version: >If any of you are writing a new mail delivery agent, and this agent >returns a copy of a message upon unsuccessful delivery, please take a >look at RFC 934, "Proposed Standard for Message Encapsulation", before >inventing another way to encapsulate messages. Kyle, I don't know what transformations you are seeing on the far side of the gateway to UUCP (which I infer from the headers that you are using), but note that, if your objective is to separate messages sent to report errors from original messages, and either (i) you were running SMTP or (ii) your gateway were to preserve all relevant information, then-- you can determine, unambiguously, which is which using the following envelope rule: - Messages use MAIL FROM transactions that identify the sending SMTP and user. - Error/non-delivery messges not have that information; their MAIL FROM transactions be exactly MAIL FROM: <> This should be much more reliable than heuristics about emcapsulation styles, partially because the latter are often also used in (non-error) forwarded or relayed mail. If your gateway, or other gateways, don't deliver adequate information about what they received in the envelopes, it would seem to me that the place to start a campaign is at the gateway and its transformations, not at the far-larger number of delivery agents. --john klensin Klensin@MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 11 Mar 90 22:58:56 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12933; 11 Mar 90 22:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA00475; Sun, 11 Mar 90 22:21:56 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Mar 90 19:18:40 GMT From: Michael Richardson Organization: Fountain Technical Services, Ottawa, ON Subject: Re: Replacing colons with periods in To-addresses Message-Id: <155@fts1.UUCP> References: <18538.25edbe1d@ccavax.camb.com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <18538.25edbe1d@ccavax.camb.com> tinkelman@ccavax.camb.com writes: >I have a question about a sendmail.cf rule. But first the background. > >Recently I received mail from a friend at Digital who was using a new >mail system. It arrived with an illegal return address, albeit one that >I, as a human, could understand. It was > > I'd really like to know why uunet insists on playing with the the internal (not envelope) From: and To: at all! (Usually deleting the (name) portion of the From: so that I may have an address but no name to associate it with...) My machine has all the maps, I understand @ addresses. And so do all the machines from myself to uunet. This wouldn't be such a problem if every little bit of mail didn't go through uunet because of their screwed up `DEMAND' markings in their map entries. Do they really dial all these people? My solution is to to `pathalias -d uunet' On some entries it adds a hop, on many it actually removes a redundant hop through uunet. -- :!mcr!: Michael C. Richardson HOME: mcr@julie.UUCP SCHOOL: mcr@doe.carleton.ca WORK: michael@fts1.UUCP I never liked staying in one place too long, but this is getting silly...  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Mar 90 03:02:36 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa29387; 13 Mar 90 2:56 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA04739; Tue, 13 Mar 90 02:08:36 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Mar 90 02:21:02 GMT From: Amanda Walker Organization: InterCon Systems Corporation, Sterling, VA Subject: Re: Replacing colons with periods in To-addresses Message-Id: <1990Mar13.022102.14408@intercon.com> References: <18538.25edbe1d@ccavax.camb.com>, <155@fts1.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <155@fts1.UUCP>, michael@fts1.UUCP (Michael Richardson) writes: > I'd really like to know why uunet insists on playing with the the > internal (not envelope) From: and To: at all! (Usually deleting the > (name) portion of the From: so that I may have an address but no name > to associate it with...) As I understand it, uunet's sendmail.cf rewrites domain-style addresses into bang paths whenever it thinks it's talking to a site that only understands UUCP mail, whether that site in fact does or not. A while back I asked much the same question and they said, "Oh, we'll change you from UUCP to INTERNET" or some such. Since then, no more header munging. Perhaps some site along the way is mistakenly listed as UUCP-style... -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 13 Mar 90 04:01:48 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa02508; 13 Mar 90 3:55 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA09046; Tue, 13 Mar 90 03:55:00 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Mar 90 08:34:22 GMT From: Dan Heller Subject: Re: Replacing colons with periods in To-addresses Message-Id: <132861@sun.Eng.Sun.COM> References: <18538.25edbe1d@ccavax.camb.com>, <155@fts1.UUCP>, <1990Mar13.022102.14408@intercon.com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <1990Mar13.022102.14408@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > In article <155@fts1.UUCP>, michael@fts1.UUCP (Michael Richardson) writes: > > I'd really like to know why uunet insists on playing with the the > > internal (not envelope) From: and To: at all! (Usually deleting the > > (name) portion of the From: so that I may have an address but no name > > to associate it with...) > > As I understand it, uunet's sendmail.cf rewrites domain-style addresses into > bang paths whenever it thinks it's talking to a site that only understands > UUCP mail, whether that site in fact does or not. A while back I asked > much the same question and they said, "Oh, we'll change you from UUCP to > INTERNET" or some such. Since then, no more header munging. Perhaps some > site along the way is mistakenly listed as UUCP-style... there seems to be a lot of problems with uunet in this respect. For example, mail going thru uunet gets all bang paths stripped off. I tested this by having someone at a site that talks to both sun and uunet via uucp send me mail to dheller@monet.berkeley.edu. She added a return-receipt-to header as well. Lines got changed, but the two that "really mattered" for delivery purposes were From: and the return-reciept. They were changed to something like: From: uunet!user Return-Receipt-To: user@uunet.UU.NET I considered these important differently than the munging it did to the To: and return-* lines since the destination machine cannot return receipt reliably. The mail going thru sun got the entire path retained properly. [%] When I got my friend to configure the mail headers to use @-style domain paths, it worked by virtue of the fact that uunet didn't touch the headers. Granted this is "correct", but I don't think this has anything to do with why it does things "wrong" with the non-domain style paths. Who maintains the mail at uunet and if s/he reds this group(s) can there be a comment of rationale for this behavior? [%] Sun is poorly configured as well -- for example, it doesn't understand "uunet.uu.net", but it *does* undersatnd "uunet.UU.NET". I didn't know you could configure sendmail to be case sensitive... and why would you? dan ----------------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com 632 Petaluma Ave, Sebastopol, CA 95472 800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104 Opinions expressed reflect those of the author only.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Mar 90 19:42:05 EST Received: by mintaka.lcs.mit.edu id aa11666; 15 Mar 90 19:23 EST Received: from BERLIN-EMH1.ARMY.MIL by mintaka.lcs.mit.edu id aa10822; 15 Mar 90 19:04 EST Date: Thu, 15 Mar 90 20:53:23 CET From: "Kendrick J. Gibson" To: header-people%mc@MINTAKA.lcs.mit.edu Subject: Address problem Message-ID: <9003151904.aa10822@mintaka.lcs.mit.edu> Could you Header People please help us with an address that is giving us a problem? We received mail from his!bang!address@ncar.ucar.edu Our system is running MMDF II and we download a host table that the MMDF software must use to check addresses before our host will forward the mail (if you weren't already familiar with MMDF). The problem is that ncar.ucar.edu is not a host, or at least, it's not listed in the table we download from sri-nic.arpa. Therefore, we get a bad host error when we attempt to send mail to it. Could you please inform us as to how we might answer mail from ncar.ucar.edu ? Thanx, Ken Gibson Asst System Administrator   Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Mar 90 22:24:13 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa19574; 15 Mar 90 22:22 EST Date: Thu 15 Mar 90 22:15:38-EST From: John C Klensin Subject: Re: Address problem To: aeba-im-o-e2@berlin-emh1.army.mil Cc: header-people@mc.lcs.mit.edu Message-ID: <637557338.740000.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9003151904.aa10822@mintaka.lcs.mit.edu> Mail-System-Version: On Thu, 15 Mar 90 20:53:23 CET, Ken Gibson wrote, in part: >We received mail from his!bang!address@ncar.ucar.edu >Our system is running MMDF II and we download a host table that the >MMDF software must use to check addresses before our host will forward >the mail (if you weren't already familiar with MMDF). >The problem is that ncar.ucar.edu is not a host, or at least, it's not >listed in the table we download from sri-nic.arpa. Therefore, we get >a bad host error when we attempt to send mail to it. Ken, the rules, as I understand them, now require that even Milnet sites be running Domain Name System (DNS) resolvers, or be moving to that *very* quickly. Until you do, you are going to have these problems with increasing frequency, especially with .EDU sites in the USA and with sites in other countries not belonging to the US Government. As a general rule, new sites in those categories are not going to appear in the sri-nic.arpa (now properly nic.ddn.mil) host table. Ever. This means that you are going to have problems with sites that have IP addresses but that don't appear in the NIC tables, and worse problems with sites that don't have IP addresses but that have DNS "Mail eXchanger" records, so can be reached from the Internet. For the latter, "host table" records are meaningless. >Could you please inform us as to how we might answer mail from >ncar.ucar.edu ? Until you devise a better solution--i.e., implementing DNS support--the easiest solution is probably to modify your local copy of the host table to include its address, which is 128.117.64.4. Alternately, if this is a one- time thing, and your software accepts dotted-decimal addresses for mail, try addressing to his!bang!address@[128.117.64.4]. FYI, there is a server maintained by CSNET that will give you information from the DNS until you have a more automatic way to obtain it. To use it, send mail to 'nslookup@sh.cs.net' (subject line ignored) whose body contains one or more host names, one per line. Explanatory information, and the records obtained from the DNS, are returned. Be patient; sometimes it takes a while. Also, questions of this type (this is not a header problem) are usually best addressed to the 'info-nets' list. To subscribe, send mail to info-nets-request@THINK.COM . john klensin Klensin@MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 16 Mar 90 08:20:43 EST Received: from WS6.NNSC.NSF.NET by mintaka.lcs.mit.edu id aa12814; 16 Mar 90 8:19 EST From: "Kendrick J. Gibson" cc: header-people@mc.lcs.mit.edu Subject: re: Address problem Date: Fri, 16 Mar 90 08:19:00 -0500 Sender: craig@nnsc.nsf.net Message-ID: <9003160819.aa12814@mintaka.lcs.mit.edu> Kendrick: You will probably get many notes telling you that the NIC host table is no longer accurate. It lists only about 8,000 hosts out of the 150,000 on the Internet. You need to get the version of MMDF II which uses the Domain Name System. A distribution was on the BSD tape, and updates to that distribution can be FTPed from sh.cs.net:mmdf/update* Craig  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 23 Mar 90 05:07:22 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa12340; 23 Mar 90 5:02 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA11456; Fri, 23 Mar 90 04:03:51 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 22 Mar 90 14:59:05 GMT From: Christian Huitema Organization: INRIA Sophia Antipolis Subject: Re: "X.400" articles with >To:, Message-Version:, etc Message-Id: <656@mirsa.inria.fr> References: <10613@hoptoad.uucp>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article , Craig_Everhart@TRANSARC.COM writes: |>I don't think there's anything out-and-out illegal about what you quoted |>in the gatewayed-from-X.400 header. You may not *like* the |> >To: |>and |> >From: |>headers, but RFC822 says they're OK. (Whether B-news likes them is |>another matter, but that's a ``small matter of programming.'') The two |>additional IDs will doubtless be useful to you three years hence when |>you're debugging your own installation of X.400. |> |> Craig Humm... I have been through all that process, and our X.400 mail is gatewaying more than 1000 messages per day. And we have never felt the need for such variations... I believe that the ">To" and ">From" field are probably a transcription of the X.400 enveloppe. This is redundant, as the enveloppe fields get translated in the SMTP "From:" and "To:" headers anyhow; but if one insists on using them, then the conventions of RFC-1148 should be followed, i.e. using "X400-Originator:" and "X400-Recipients:". Christian Huitema  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 24 Mar 90 21:04:42 EST Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa14661; 24 Mar 90 21:02 EST Received: by BLOOM-BEACON.MIT.EDU (5.61/25-eef) id AA22166; Sat, 24 Mar 90 20:21:47 EST Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 24 Mar 90 15:31:11 GMT From: Yintien Wang Organization: University of Pennsylvania Subject: telnet to a machine Message-Id: <22136@netnews.upenn.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu All you netters out there : I've been trying to get on a machine in N.J. I do have that machine e-mail address ( of my friend) but I can't telnet it. My friend work for a major firm which required that machine to go through a *.com ( gateway ? ) before the mail reached me. Here is the question for all you wizer out there 1. Is there a way I can look up the machine node's name under telnet ? I would like to see what in the world my machine is connected to. 2. Is there a way my friend could do in his machine to find out his internet address number in order for me to telnet to his machine. Thanks you guys in advance for your time and help..... yintien@grasp.cis.upenn.edu  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 25 Mar 90 11:02:25 EST Received: from INFOODS.MIT.EDU by mintaka.lcs.mit.edu id aa10476; 25 Mar 90 10:58 EST Date: Sun 25 Mar 90 11:00:26-EST From: John C Klensin Subject: 'How to reach machine X' question To: header-people@mc.lcs.mit.edu Message-ID: <638380826.830000.KLENSIN@INFOODS.MIT.EDU> Mail-System-Version: For the information of readers of this list who don't know, the optimum place to ask questions about how to reach one host from another is on the info-nets list (subscription requests to info-nets-request@think.com or, for BITNET subscribers, to INFONETS via your local LISTSERV). header-people is really the wrong place and amounts to a call for help to people who aren't interested (even when the subcribers lists overlap). --john klensin Klensin@MIT.EDU -------  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Mar 90 18:30:58 EST Received: from sh.cs.net by mintaka.lcs.mit.edu id aa27812; 28 Mar 90 18:27 EST To: HEADER-PEOPLE@mc.lcs.mit.edu Subject: RELAY.CS.NET's hiding of host names Date: Wed, 28 Mar 90 18:20:23 -0500 From: Daniel Long Message-ID: <9003281827.aa27812@mintaka.lcs.mit.edu> For a long time, RELAY.CS.NET has been rewriting outgoing addresses as: local-part%domain@relay.cs.net to accomodate folks who don't understand how to do MX lookups. The question is whether this practise is still necessary these days. How many folks out there don't yet understand how to do MX lookups? For example, is all of MILNET still using only host tables? Would it be reasonable to have an "exception" list to enable the %-hack for certain destinations but default to no %-hack? If so, any suggestions on how to build such a list? Thanks, Dan Long CSNET CIC  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Mar 90 20:21:14 EST Received: from garnet.Berkeley.EDU by mintaka.lcs.mit.edu id aa03504; 28 Mar 90 20:18 EST Received: by garnet.berkeley.edu (5.57/1.33) id AA23208; Wed, 28 Mar 90 17:18:09 PST Date: Wed, 28 Mar 90 17:18:09 PST From: Postmaster & BITINFO Message-Id: <9003290118.AA23208@garnet.berkeley.edu> To: HEADER-PEOPLE@mc.lcs.mit.edu, long@sh.cs.net Subject: Re: RELAY.CS.NET's hiding of host names I have the same problem with having to do: local-part%domain@host.berkeley.edu We are doing this not only for MX only domains but also for domains not in the host table. I think we going to have to force the issue by using only local-part@domain where domain is a valid internet domain name (A record) in the DNS. We may want to wait on doing this for MX only domains for another year or so to allow software with MX support to stabilize. We have given the MILNET sites 2 years to convert to DNS: MIGRATION TIMETABLE (from RFC 1031) Table 1 shows the events and dates involved in the MILNET transition from host table to domain system. The operational testing of the root server software has been completed. Voluntary conversion can begin immediately, with mandatory conversion required by October 1989. After this date, hosts not converted need to obtain the host table equivalent by private arrangement (see "Migration Path" above). Start End Milestone Date Date =========================================== ====== ====== Root server operational testing Dec 86 Jul 87 Policy announced in DDN Management Bulletin Oct 87 Host conversion Oct 87 Oct 89 Host table discontinued Oct 89 MILNET Name Domain Timetable Table 1 (It should be noted that NIC.DDN.MIL is still providing the host table, though it has been trimmed down some.) Bill Wells postmaster@jade.berkeley.edu netinfo@garnet.berkeley.edu NETINFO@UCBGARNE.BITNET  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 28 Mar 90 22:25:17 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa08896; 28 Mar 90 22:13 EST Received: from slembe.uio.no by ifi.uio.no (5.61+IDA/KTH/LTH/1.15) with SMTP id AAifi06870; Thu, 29 Mar 90 05:12:16 +0200 Received: by slembe.uio.no (5.61+IDA/KTH/LTH/SMI-3.2) id AAslembe26457; Thu, 29 Mar 90 05:12:12 +0200 Date: Thu, 29 Mar 90 05:12:12 +0200 Message-Id: <9003290312.AAslembe26457@slembe.uio.no> From: Erik Naggum Sender: enag@ifi.uio.no To: long@sh.cs.net Cc: HEADER-PEOPLE@mc.lcs.mit.edu In-Reply-To: <9003281827.aa27812@mintaka.lcs.mit.edu> "long@sh.cs.net" Subject: Re: RELAY.CS.NET's hiding of host names I dislike the local-part munging in which the like of relay.cs.net engages vehemently. At some point, I got so disgusted with "known mungers" that I put them in a list, and "undid" their work, but then the list got so long it impared mail delivery. Mail delivered to my mailbox is now devoid of most of those %'s, iff I (think I) can reach the hosts so hidden. This is ugly and by standards decreed wrong. I agree with those standards, but still feel the need to undo other people's work. I would like relay.cs.net to be more selective in which addresses is munges, if you are going to continue this practice. ONLY those domains for which an MX lookup results in a pointer to "relay.cs.net", should be rewritten. The problem I see is that too many valid domains end up embedded in a local-part. Also, I would favor removal of this practice entirely. Better to make the non-MX mailers find a willing gateway to help them and force-route mail they can't deliver there in an interim. Even in the case of hosts for which RELAY.CS.NET is MX and such gateway, the headers should not be munged. It's a transport problem, not an addressing problem. Locally configurably mailers should be configured to take care of this problem while it exists. Disclaimer: I've made a bunch of money configuring sendmail.cf files and my view may be slightly slanted in favor of other consultants in the field. :-) [Erik]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 29 Mar 90 08:32:53 EST Received: from MIT.MIT.EDU by mintaka.lcs.mit.edu id aa01614; 29 Mar 90 8:27 EST Received: from STL-07SIMA.ARMY.MIL by MIT.EDU with SMTP id AA06175; Thu, 29 Mar 90 08:26:05 EST Message-Id: <9003291326.AA06175@MIT.EDU> Date: Thu, 29 Mar 90 7:27:47 CST From: Rich Zellich To: Daniel Long Cc: HEADER-PEOPLE@MC.lcs.mit.edu Subject: Re: RELAY.CS.NET's hiding of host names I think I can guarantee that there are a *lot* of .army.mil sites still running MMDF, using host tables. Many of these machines are not directly connected to the net, but are hung off of a subnet behind one kind or another of a gateway - some of the gateways will pass only mail...you can't get out onto the net through them to do *anything*.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 29 Mar 90 18:02:04 EST Received: from sh.cs.net by mintaka.lcs.mit.edu id aa24656; 29 Mar 90 17:49 EST To: HEADER-PEOPLE@mc.lcs.mit.edu Subject: Re: RELAY.CS.NET's hiding of host names Date: Thu, 29 Mar 90 17:39:31 -0500 From: Daniel Long Message-ID: <9003291749.aa24656@mintaka.lcs.mit.edu> Thanks for all the responses. From the sounds of it, MILNET is the main MX holdout. In particular, MILNET sites not running TOPS-20 and not at BRL are the culprits. MILNET machines that cannot do MX's can sometimes (but not always) forward undeliverable mail to a "smart" gateway. There's some sentiment to just stop doing the %-hack altogether and let the poor have-not's suffer so much that they get off their....um...so that they put up MX-capable software. There's additional sentiment to drop the %-hack but to soften the blow by adding a header field like: "X-Suggested-Reply-Path-For-Folks-Who-Have-Broken-Mailers: send to user%domain@relay.cs.net" I'm not interested in disrupting email connectivity to CSNET PhoneNet members but I *would* like to help encourage MX usage and the resulting simplification of address syntax. So, my options seem to be: 1) Keep things as they are today (and for n years to come). 2) Convert to user@domain and forget the poor have-nots. 3) Convert to user@domain and add the header warning. 4) Convert to user@domain except when mailing to a specific group of hosts (e.g. *.MIL less *.BRL.MIL less TOPS20's) 5) Others? Send your votes to me and I'll summarize! Thanks, Dan  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 29 Mar 90 23:46:07 EST Received: from MITVMA.MIT.EDU by mintaka.lcs.mit.edu id ab08902; 29 Mar 90 23:41 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1000; Thu, 29 Mar 90 23:40:24 EDT Received: from USCMVSA.BITNET by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 3185; Thu, 29 Mar 90 23:40:23 EST Date: Thu, 29 Mar 90 20:41 PST To: Daniel Long CC: HEADER-PEOPLE@MC.lcs.mit.edu From: Leonard D Woren Subject: Re: RELAY.CS.NET's hiding of host names Message-ID: <9003292341.ab08902@mintaka.lcs.mit.edu> On Thu, 29 Mar 90 17:39:31 -0500, Daniel Long said: > There's some sentiment to just stop doing the %-hack altogether and let the > poor have-not's suffer so much that they get off their....um...so that they pu > up MX-capable software. Normally, I agree with things like that, but I'm now caught on the other side of the fence. We desperately need to have a DNS mailer here, but what can I do when the vendor of our software just can't supply the required functionality? (The problem is that some sites run vendor-(un)supported software like Acces/MVS. ACC was so incapable of supporting this product that they just sold it to Interlink. Acces/MVS Release 3 supposedly has DNS support, but ACC has not met the promised dates for shipping Release 3. Let's see if Interlink does better.) /Leonard  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 30 Mar 90 11:02:29 EST Received: from MIT.MIT.EDU by mintaka.lcs.mit.edu id aa06563; 30 Mar 90 11:00 EST Received: from STL-07SIMA.ARMY.MIL by MIT.EDU with SMTP id AA10915; Fri, 30 Mar 90 10:59:08 EST Message-Id: <9003301559.AA10915@MIT.EDU> Date: Fri, 30 Mar 90 9:59:29 CST From: Rich Zellich To: long%sh.cs.net@usc.edu Cc: header-people@MC.lcs.mit.edu Subject: Milnet hosts and support of MX records, etc. The .army.mil sites I mentioned in my earlier reply are running "supported" MMDF software, but that support is out of Ft. Huachuca these days, and we are entirely at their mercy as far as when we get upgrades and what they put in them. We are *required* to run the standard MMDF software by our HQs (HQ Army Materiel Command, in my case), and the folks at Huachuca don't seem to be very responsive to anyone else (the management people, that is; I have no knowledge of the actual programer(s) - if any - assigned to the MMDF system). -Rich  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 5 Apr 90 06:26:18 EDT Received: from KAUAI.MCL.UNISYS.COM by mintaka.lcs.mit.edu id aa21495; 5 Apr 90 6:24 EDT Received: from LANAI.MCL.UNISYS.COM by kauai.MCL.Unisys.COM (4.1/Domain/jpb/mls/2.9) id AA14912; Thu, 5 Apr 90 06:25:23 EDT Received: by LANAI.MCL.UNISYS.COM [4.1/Domain/jbp/2.4] id AA20336; Thu, 5 Apr 90 06:23:29 EDT Date: Thu, 5 Apr 90 06:23:29 EDT From: Dennis Perry Message-Id: <9004051023.AA20336@LANAI.MCL.UNISYS.COM> To: header-people@mc.lcs.mit.edu Subject: help with header understanding Cc: perry@mcl.unisys.com The following headers appear to have loops in them. Why? Also, the From: line has a machine which is not in the header list. Can someone explain to me in simple terms what takes place with these messages. Thanks, dennis ------------- From wheaton!perryl@yclept.chi.il.us Wed Apr 4 21:14:08 1990 Received: from kauai.MCL.Unisys.COM by LANAI.MCL.UNISYS.COM [4.1/Domain/jbp/2.4] id AA19762; Wed, 4 Apr 90 21:14:05 EDT Received: from rutgers.edu by kauai.MCL.Unisys.COM (4.1/Domain/jpb/mls/2.9) id AA13960; Wed, 4 Apr 90 21:15:45 EDT Received: from gargoyle.uchicago.edu by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP id AA00778; Wed, 4 Apr 90 19:50:51 EDT Received: from gargoyle.uchicago.edu by oddjob.uchicago.edu Wed, 4 Apr 90 17:21:22 CDT Received: by gargoyle.uchicago.edu (5.59/1.14) id AA01302; Wed, 4 Apr 90 17:21:16 199 Received: by homebru.chi.il.us (smail2.5) id AA03204; 4 Apr 90 16:58:24 EDT (Wed) Received: by obdient.chi.il.us (smail2.5) id AA28008; 4 Apr 90 14:54:36 CST (Wed) Received: by wheaton.UUCP (1.2/UUCP-Wheaton/Hack 12/21/87)) id AA14855; Wed, 4 Apr 90 14:17:03 cdt Date: Wed, 4 Apr 90 14:17:03 cdt From: wheaton!perryl@yclept.chi.il.us (Lynellen Perry) Message-Id: <9004041917.AA14855@wheaton.UUCP> To: perry@mcl.unisys.com Subject: returning your test Status: R _____________________________________________________ >From obdient!mcdchg!homebru!gargoyle!clout!gargoyle!oddjob!homebru!gargoyle!clout!Stars.Reston.Unisys.COM!perry Wed Apr 4 07:09:06 1990 Received: by wheaton.UUCP (1.2/UUCP-Wheaton/Hack 12/21/87)) id AA06648; Wed, 4 Apr 90 07:09:00 cdt Received: by obdient.chi.il.us (smail2.5) id AA17692; 4 Apr 90 07:09:02 EST (Wed) Received: by chg.mcd.mot.com (smail2.5) id AA25714; 4 Apr 90 06:53:14 CDT (Wed) Received: by homebru.chi.il.us (smail2.5) id AA01413; 4 Apr 90 04:10:16 CDT (Wed) Received: by homebru.chi.il.us (smail2.5) id AA01293; 4 Apr 90 03:25:21 CDT (Wed) Received: by gargoyle.uchicago.edu (5.59/1.14) id AA13631; Wed, 4 Apr 90 00:45:30 199 Received: by clout.chi.il.us (smail2.5 - gargoyle) id AA13524; 4 Apr 90 00:40:30 CDT (Wed) Received: by gargoyle.uchicago.edu from oddjob.uchicago.edu (5.59/1.14) id AA13324; Wed, 4 Apr 90 00:30:10 199 Received: by oddjob.uchicago.edu Wed, 4 Apr 90 00:30:06 CDT Received: by homebru.chi.il.us (smail2.5) id AA00784; 3 Apr 90 23:17:28 CDT (Tue) Received: by gargoyle.uchicago.edu (5.59/1.14) id AA09486; Tue, 3 Apr 90 21:20:58 199 Received: by clout.chi.il.us (smail2.5 - gargoyle) id AA09392; 3 Apr 90 21:15:40 CDT (Tue) Received: from gargoyle.uchicago.edu by oddjob.uchicago.edu Tue, 3 Apr 90 20:35:08 CDT Received: by gargoyle.uchicago.edu from aviary.stars.reston.unisys.com (5.59/1.14) id AA08765; Tue, 3 Apr 90 20:35:00 199 Received: by aviary.Stars.Reston.Unisys.COM (4.0/Domain/jpb/2.9) id AA15755; Tue, 3 Apr 90 21:33:36 EDT Date: Tue, 3 Apr 90 21:33:36 EDT From: gargoyle!oddjob!Stars.Reston.Unisys.COM!perry (Dennis Perry - Unisys) Message-Id: <9004040133.AA15755@aviary.Stars.Reston.Unisys.COM> To: wheaton!perryl Subject: test Cc: perry@mcl.unisys.com Status: RO this is a test  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Apr 90 01:13:48 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa21926; 17 Apr 90 1:14 EDT Received: by bloom-beacon.MIT.EDU (5.61/25-eef) id AA07591; Sat, 14 Apr 90 04:38:31 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Apr 90 14:17:19 GMT From: Robert Story Organization: AFS Ltd., London, Ontario, CANADA Subject: Mailer Standards Message-Id: <506@avcocan.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Where can I find out about mail standards? I would specifically like to know about RFC 822 and MHS. Is RFC 822 the standard that the Unix mail system uses? Perhaps, this should be a new book from Nutshell! Thanks. -- [ Robert Story ..uunet!{jtsv16!geac!censor, mnetor!lsuc}!avcocan!bounder ] [ SnailMail : AFS 201 Queens Avenue London Ontario Canada N6G 4M5 ] [ Voice : +1 519 672-4220 xtn 642 or Direct Line +1 519 660-2642 ]  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Apr 90 02:23:30 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa24508; 17 Apr 90 2:21 EDT Received: by bloom-beacon.MIT.EDU (5.61/25-eef) id AA18374; Sat, 14 Apr 90 12:37:30 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 14 Apr 90 08:28:54 GMT From: "Oberman, Kevin" Organization: Lawrence Livermore National Laboratory-Engineering Subject: Re: Mailer Standards Message-Id: <55987@lll-winken.LLNL.GOV> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <506@avcocan.UUCP>, bounder@avcocan.UUCP (Robert Story) writes... >Where can I find out about mail standards? I would specifically like to >know about RFC 822 and MHS. Is RFC 822 the standard that the Unix mail >system uses? Perhaps, this should be a new book from Nutshell! RFC 822 and RFC 1123 are the closest thing to standards that exist, but I've never seen a Unix(tm) mailer that follows it completely. Most notaable is the addition of fields to the header that violate the "standards". R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Apr 90 11:36:14 EDT Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa12504; 17 Apr 90 11:25 EDT Received: from svarte.uio.no by ifi.uio.no (5.61+IDA/KTH/LTH/1.15) with SMTP id AAifi07473; Tue, 17 Apr 90 16:28:32 +0200 Date: Tue, 17 Apr 90 16:28:32 +0200 Message-Id: <9004171428.AAsvarte28797@svarte.uio.no> From: Erik Naggum Sender: enag@ifi.uio.no To: rogue.llnl.gov!oberman@lll-winken.llnl.gov Cc: header-people@mc.lcs.mit.edu In-Reply-To: <55987@lll-winken.LLNL.GOV> "rogue.llnl.gov!oberman@lll-winken.llnl.gov" Subject: Mailer Standards In article <506@avcocan.UUCP>, bounder@avcocan.UUCP (Robert Story) >writes... Where can I find out about mail standards? I would >specifically like to know about RFC 822 and MHS. Is RFC 822 the >standard that the Unix mail system uses? Perhaps, this should be >a new book from Nutshell! It would have to be an awfully large nutshell, in my opinion. "Unix mail" doesn't exist per se, there are only lots of variations over a more or less common theme, which, by the way, has nothing whatsoever to do with RFC 822. (It only looks like it does, which confuses people.) RFC 822 and RFC 1123 are the closest thing to standards that exist, but I've never seen a Unix(tm) mailer that follows it completely. Most notaable is the addition of fields to the header that violate the "standards". RFC 822 (with updates in RFC 1123) is the _Internet_ message format specification. What you see in the Unix mailboxes is a user agent format, which RFC822 expressly does not talk about. Those "extra" fields that certain user agents add for their own book-keeping are legal as long as they don't enter the Internet. Also, RFC 822 (++) is pretty lax on unspecified headers, so the locally added headers are not in violation of the standard, as such. (Certain headers are hashed into mush to retrofit the old Unix mailbox format, and those are, of course, in violation of the standard.) Also, the UUCP relic "From_" line which "separates" message in the standard (?) Unix mailbox format, is a clear violation. RFC822 (with the updates in RFC 1123) are, however, routinely ignored by that nefarious Unix system mail delivery agent, sendmail. I would positively hate having the gross errors and circumventions of sendmail become an inofficial standard, anywhere. What we need is a tool to validate sendmail.cf files, so that headers on the Internet side are according to the standards. I've tried to do that, and ended up writing my own delivery and user agents... "Unix" mail systems have a long way to go to measure up to the standards they purportedly follow. It's the part of Unix systems I have real problems with. Finally, MHS (if you think about MOTIS) is covered by a huge International Standard, ISO 10020, and by CCITT Recommandation series X.400 (1988). I suggest you take a long vacation if you plan to touch those documents. You also need to buy them for an incredible load of money, and you can get nice "introductions" to these standards in your favorite academic bookstore for another incredibly mass of money. [Erik], the mail standards guy  Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 17 Apr 90 15:31:09 EDT Received: from Xerox.COM by mintaka.lcs.mit.edu id aa23542; 17 Apr 90 15:28 EDT Received: from Concord.ms by ArpaGateway.ms ; 17 APR 90 12:22:07 PDT Sender: Samuel_S_Jones.dlosLV300@xerox.com Date: 17 Apr 90 12:22:04 PDT (Tuesday) Subject: REMOVE FROM DL. (EOM) From: Samuel_S_Jones.dlosLV300@xerox.com To: header-people@mc.lcs.mit.edu cc: sjone.dlosLV300@xerox.com Message-ID: <900417-122207-4272@Xerox> THANK YOU. SAM S 8*736-3127,,214-420-3127,,vmx:736-3127 Central Time Samuel S Jones:DLOSLV300:XEROX 41032.25220222116.0 FAX--8*736-3344,,214-420-3344 A XEROX CORPORATION 1301 RIDGEVEIW DR LEWISVILLE,TEXAS 75067 MAIL STOP::R380-301