From bblue Sat Sep 19 11:19:49 1987 Date: Sat, 19 Sep 87 11:19:45 PDT From: bblue (Bill Blue) To: jeh Subject: Re: an addressing question You write: >How are ! and @ operators handled when there are both pre-@ and post-@ >!'s in the address? For instance, suppose someone gives me an address >of > system!user@dept.company.COM > >I've gotten some like this, and been able to send mail to them from >pnet just by saying > > crash!system!user@dept.company.COM > >What I think is happening is that you can go from a bang-path, >through domain, to another bang-path. The first machine in the >bang-path that understands @'s (in this case crash) processes the >@, and what's left of the bang-path is processed at the target >machine of the @-path. True? > > --- Jamie You seem to have a good mental picture of things. The key to understanding what happens is routing is having a general idea which machines give precendence to !'s and which to @'s. If you go crash!user@site, crash gets user@site and converts it to site!user for delivery to site. Sites that do @ to ! conversion, always produce a full ! path as far as their conversion is concerned. The exceptions would be if there is more than one @ in a path. It's not exactly legal syntax, but does occur. For example, the path crash!user@site2@site1 would go to crash as user@site2@site1 and get converted to site1!user@site2 for delivery to site1. Then site1 would do further conversions if it understands @ routing. I do this occasionally if I want a different site to 'smartroute' for me, 'cause I know the route they'll produce will be different from what crash's router would produce. The only fly in the ointment in all of this is machines that optimize even specific routes. If you had something like crash!site1!site2!user@site3, crash would get site1!site2!user@site3 and convert to site3!site1!site2!user for delivery to site3. Now, if site1 was an optimizer when it gets the path site2!user from site3 it might very well change the path. But it will always do so in standard ! syntax by inserting the new path in front of site2. Oh, and in case it isn't obvious, crash!somesite.bozo.com!user is perfectly legal, and is the same as crash!user@somesite.bozo.com. In fact, that's how the conversion would take place. Say if bozo.com was gotten to by the route of hp-sdd!hplabs!rutgers, crash would convert the path to hp-sdd!hplabs!rutgers!somesite.bozo.com!user. --Bill From ncr-sd!hp-sdd!hplabs!decwrl!pyramid!uccba!hal!mandrill!chet Thu Sep 24 10:54:25 PDT 1987 In article <2281@ihlpf.ATT.COM> taizoon@ihlpf.UUCP (T Chinwalla) writes: >I am a novice at this newfangled electronic mail and so is my friend >at Digital in Boston. Can someone either direct me to a document that >explains how to send Email to anyone outside my system or specifically >to him at DEC or tell me how to do it? His internal id is: > >yvesp::vish Try this to send it with Internet-style addressing: vish%yvesp.DEC@decwrl.DEC.COM - or - vish@yvesp.DEC.COM (I'm not sure this will work) To send it with uucp-style routing: path!to!decwrl!yvesp.dec.com!vish This assumes that his username is "vish" and his easynet (DEC's internal corporate network) node is "yvesp". To take the mystery out of the "newfangled electronic mail", look at the article "Notable Computer Networks" by John Quarterman and Josiah Hoskins in Communications of the ACM, v29, #10 (Oct., 1986), pp. 932-971. Chet Ramey CSNet/Internet: chet@mandrill.cwru.edu UUCP: {...}!cbosgd!mandrill!chet BITNET: ramey@cwru20.cwru.edu He was a sharp guy...He lived on the edge of town... From ncr-sd!hp-sdd!hplabs!decwrl!pyramid!uccba!hal!mandrill!chet Thu Sep 24 10:54:25 PDT 1987 In article <2281@ihlpf.ATT.COM> taizoon@ihlpf.UUCP (T Chinwalla) writes: >I am a novice at this newfangled electronic mail and so is my friend >at Digital in Boston. Can someone either direct me to a document that >explains how to send Email to anyone outside my system or specifically >to him at DEC or tell me how to do it? His internal id is: > >yvesp::vish Try this to send it with Internet-style addressing: vish%yvesp.DEC@decwrl.DEC.COM - or - vish@yvesp.DEC.COM (I'm not sure this will work) To send it with uucp-style routing: path!to!decwrl!yvesp.dec.com!vish This assumes that his username is "vish" and his easynet (DEC's internal corporate network) node is "yvesp". To take the mystery out of the "newfangled electronic mail", look at the article "Notable Computer Networks" by John Quarterman and Josiah Hoskins in Communications of the ACM, v29, #10 (Oct., 1986), pp. 932-971. Chet Ramey CSNet/Internet: chet@mandrill.cwru.edu UUCP: {...}!cbosgd!mandrill!chet BITNET: ramey@cwru20.cwru.edu He was a sharp guy...He lived on the edge of town... From ncr-sd!ncrcae!hubcap!gatech!hao!woods Sat Jan 16 01:15:40 PST 1988 In article <2987@hall.cray.com> dwd@hall.cray.com (Dave DeHerder_Jr.) writes: >WELL... I got some mail with a from that looked like: >"From: texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!onion.SanDiego.NCR.COM!bethh@tundra.UUCP" >First it is confusing because all the sites are in order except that >"tundra.UUCP" is our nearest neighbor. Why that is at the end is a >mystery to me. OK. So I figure that this is just a foible of the >conventions and try to create a return path and come up with: >"To: tundra!texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!bethh@onion.SanDiego.NCR.COM" >Is this correct or am I all screwed up? You have now changed the ultimate destination of the message. The problem is, an address like host1!user@host2 is inherently ambiguous. Does it mean send to host1, for a user who is on host2, or send to host2, for a user that is on host1? The official mail addressing standard (I think it's RFC822) does not even officially recognize bangs (!) as addressing characters. Technically, address@host should always be sent to the host on the left of the @-sign first. How "address" is interpreted there is not specified (which allows things like the % kludge to work). In this case, the first address above is perfectly valid since it means send to tundra via UUCP and let tundra worry about interpreting the bang path. Unfortunately, the second address says something different. It says send to onion.SanDeigo.NCR.COM for eventual delivery to "bethh" on host "ncr-sd", which is not where this user is. From the first path, the user "bethh" appears to be at onion.SanDiego.NCR.COM. Therefore the second path is incorrect. If you'd left it in pure bang form, i.e. tundra!texsun!...!ncr-ds!onion.SanDiego.NCR.COM!bethh it MIGHT have worked. At least it would have gotten sent to tundra which is the first hop in the path. > >This mail gets bounced back to me with: >"554 texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!bethh@onion.SanDiego.NCR.COM... Unknown domain COM" > ..which confirms what I said earlier: it was trying to send to onion directly, which isn't what is intended. It looks to me as though your site does not have a domain-compatible mailer. If it doesn't even know about ".COM" that is very likely to be the case, in which case a pure bang path is most likely to work from your site. Not having a domain-compatible mailer at YOUR site does not mean you can't use domains at all; it does mean that an address of the form "user@host.domain" isn't going to work. What you will have to do is something like bang!path!to!smarthost!host.domain!user, which looks like a pure bang path until it gets to smarthost, which will turn it into a domain address. If "ncr-sd" is such a host, then the above suggested path would work in this case. --Greg From ncr-sd!ncrcae!hubcap!gatech!hao!woods Sat Jan 16 01:17:39 PST 1988 In article <1091@hao.ucar.edu> woods@hao.UUCP (Greg Woods) writes: >Technically, address@host should always be sent to the host on the left >of the @-sign first. Of course, that should be "sent to the host on the RIGHT of the @-sign first". Sorry, it's one of those days. --Greg From bblue Mon Jan 4 15:23:32 1988 Date: Mon, 4 Jan 88 15:23:31 PST From: bblue (Bill Blue) To: jeh Subject: Re: more bounced mail That IS interesting. Well, remember that we're going through two stages here. If nieland#falcon@wpafb-aamrl.arpa in entered at pnet, it's going to pass crash wpafb-aamrl.arpa!nieland@falcon. But if that same address was entered on crash it would be fed the @ address and never see the %. You might try, just for grins, sending that address from the crash side and see if it bounces. From bblue Mon Jan 4 15:26:05 1988 Date: Mon, 4 Jan 88 15:26:03 PST From: bblue (Bill Blue) To: jeh Subject: Re: re: Matt's message re. mixed mode return addresses It's supposed to be insignificant for internet traffic. However, in uucp, crash is a different site from CRASH when a route is handed off to the uux program. So by the same token, any part of an internet address which is a uucp component (!'s in it) should be lower case. With smarter mailers like smail, it shouldn't matter, but the world doesn't have those yet. From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!husc6!necntc!ima!think!barmar Sun Dec 20 14:55:41 PST 1987 In article <569@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >To: personA,personB,personC@machine1.smalldomain.largedomain > > If the above address is attached to a message whic is received >at a machine which is a member of "largedomain", that machine will >look for "machine1" and if not found "smalldomain". If neither is >found then the message will be frowarded to the top of "largedomain". >If this is the top of large domain, the message will bounce [fail]. >This domain-resolution will continue through each seccussive domain >until the machine is found or the samllest domain is encountered and >fails to resolve the machine refrence. Domains are name registries; a machine is not a member of a domain, but its name can be. I'll presume this is what you mean when you say "a machine which is a member of 'largedomain'". Now that I've cleared that up, I'll tell you that it doesn't matter what domain the receiving machine's name is a member of. Binding a domain name to a machine is independent of the local machine's domain. What happens is that when a machine wants to send mail to an address whose domain part (the part after the @) is of the form name1.name2.name3 it tries to contact the nameserver for the name2.name3 domain, and asks it for the information on how to send mail to name1.name2.name3. If it doesn't know the address of the name2.name3 nameserver (possibly because there isn't one) it makes the query of the nameserver for name3, and so on up the domain hierarchy. When it finally gets to a point where it knows the appropriate nameserver (the process must end because everyone is supposed to know the addresses of the root nameservers, although it is conceivable that all of them could be down simultaneously), the nameserver will either give it the information or tell it to ask the server for a subdomain (and hopefully it will include the address of the server). This could be repeated when the machine queries the specified nameserver, etc., but eventually it will find out how to send mail to name1.name2.name3. The message would never actually be transmitted to name2.name3 or name3 unless the mail information for name1.name2.name3 specifically says that one of these hosts should be used for mail addressed to it. But it is just as possible for the mail information for name1.name2.name3 to specify that its mail should be delivered to other1.other2.other3. But if no nameserver has ever heard of name1.name2.name3 the message will be returned. > Upon reaching "machine1" the message will be delivered to >three seperate accounts "personA" "personB" and "personC" If any of >these accounts do not exist then those messages will bounce without >interfeering with deleivery to the accounts which do exist. This is wrong. First of all, the above header is invalid, because all addresses must be of the form @. There is no automatic grouping. If your mail-sending program allows the above To: line and interprets all the addresses as being on machine1.smalldomain.largedomain, then it must translate them to the standard format before transmitting the message over the network. When the SMTP protocol is being used to transfer mail between computers the header isn't actually used, though; the recipients are specified as part of the SMTP protocol, and the header is just part of the data portion. >To: personA@sdomain.mdomain.ldomain > > The top of "sdomain" will be sought [as above] if it can be >found, it will search it's accounts, aliases, mailing-lists, and >group-lists [as exist] for an account or refrence to "personA" and >send the message to that [those] accounts. A list of accounts [as >above] may exist in place of "personA" [i.e. >"group1,group2,list1,personB,personC"] How a message is delivered once it is received by the destination mailer is completely up to that host. Your description above is typical of most systems, though. >To: personA@machine1%machine2%machine3 > > The sending machine will send to "machine1" and remove >"machine1%" from the address [netting personA@machine2%machine3%]. >machine1 will similarly forward to "machine2" removing "machine2%" >[netting personA@machine3]. Machine2 will forward to "machine3" >leaving the header unchainged. Machine3 seeing "personA@machine3" >will deliver to that/those account/list/group. No. Everything to the right of the @ MUST be a domain name. There are some machines that recognize %, but it must be to the LEFT of the @. The syntax of an address is @. The syntax of is arbitrary, and this is what permits hosts to treat some characters within it as routing information. The use of % is completely unsanctioned by standards, but it has become extremely common. The way the above would usually be written is To: personA%machine3%machine2@machine1 The important point is that the host sending to machine1 doesn't have to recognize % for this to work; as far as it is concerned, it is sending to a user whose name contains a bunch of % characters (and there's no reason why some computer system couldn't have users with such names). When machine1 receives it, it presumably replaces the last % in the with an @ and drops its own name, resulting in "personA%machine3@machine2" and reprocesses this normally, by sending it to machine2. >To: personA@machine1%machine2@machine3%machine4 > > This one I am not shure about. My best guess would be: >machine3->machine4->machine1->machine2. It is clear that the "%" >[percent] symbols can be used like a bang path for explicit routing. >It is also clear that the "@" [at] sign has higher precidence, and >that the "@" groups right to left, leading me to read this as "personA >(at machine1 then machine2 (at machine3 then machine4))". Of course >"personA" may again be a list [as above]. Multiple "@" are not permitted in an address. However, this can be permitted by using quoting, e.g. To: "personA@machine1"@machine2 The quoting removes the special interpretation of the first @, so this becomes an address whose is personA@machine1 and whose is machine2, so the message would be delivered to machine2. If machine2 happens to treat an @ embedded in the as routing information (like % above) then this is a way to force routing; however, again, the interpretation of is completely unspecified. > IS THIS CORRECT?? > >To: machine3!personA@machine1%machine2 > > This again is a guess: machine1->machine2->machine3->personA > IS THIS CORRECT? First, I'll treat the above as "machine3!personA%machine2@machine1", correcting your earlier error. The interpretation of an address that contains both ! (the UUCP routing character) and @ (the SMTP routing character) depends on the way the host processing the address is configured. A host that only knows about UUCP will most likely not recognize the @ at all, so it will treat the above as the user "personA%machine2@machine1" on host "machine3", so the message will probably take the path machine3->machine-1->machine2->personA. A host that doesn't know about UUCP will ignore the !, so it will treat it as user "machine3!personA%machine2" on host "machine1", and the actual path will depend on how machine1 deal with ! and %. If a host recognizes both then one of them will have to have a higher precedence than the other, to resolve the ambiguity, and quoting could be used to force grouping. Some systems adjust the precedence based on the protocol used to receive the message, so that if a message is received using UUCP protocol the UUCP addressing style will be favored. >To: machine2!personA,personB@machine1 > > Another Guess: machine1->personB > >machine2->personA > IS THIS CORRECT? IS IT LEGAL? Well, I would treat this as machine2->personA and machine1->personB, because none of the mail sending programs I use automatically group comma-separated addresses as being for the same host. In other words, To: personA,personB@machine1 is equivalent to To: personA To: personB@machine1 and most systems interpret the first line as meaning personA on the local system. >To: (text) > > The material within the "(" [lparen] and ")" [rparen] is a >comment, and generates NO delivery address or forwarding at all. > IS A COMMENT ALONE ON A LINE LEGAL? The only address field that may contain no addresses is the BCC: field. All the rest require at least one address. >Also, any of the above formats may occur on the same line as any other >as long as there is at least one unit of whitespace seperating each >form of address. The order of such combination, or multiple >occuarances of the "To:" "Cc:" and "Bcc:" header lines are immaterial >to the delivery, and should be processed on a first come first served >basis. Well, since the header isn't used to determine delivery information, the order is obviously immaterial. A message may be delivered to people no listed in the header at all. This can often happen when using blind-carbon-copy, since it is permitted to leave the BCC: field empty. The SMTP protocol looks like: MAIL FROM: RCPT TO: RCPT TO: ... DATA
. The message is delivered to user2 and user3, regardless of the names specified in the header. I am aware that there are other mail delivery protocols that do actually use the addresses in the header. >Precidence map: > > "(" ")" Grouping L->R MAtched Pairs required. Since parentheses are not binary operators, I don't know what you mean by "grouping L->R". > "," "@" Grouping R->L > "%" Grouping L->R > "!" Grouping L->R The actual precedence is more like: double-quotes No grouping Matched Pairs required ( ) No grouping Matched Pairs required , No grouping @ ! ! groups L->R only one @ permitted % groups R->L >Finally, a question: I have seen ";" [semicolon] refrenced in some of >what I have read on mail addressing. What is the ";" for and have I >missed any other symbols? There is a special address syntax allowed instead of @, called named groups, whose syntax is: : ; where is 0 or more @ addresses (if is empty then this is just a placeholder for an unenumerated mailing list). This syntax only exists in headers, it isn't allowed in the SMTP delivery protocol. The complete specification of the format of message headers is in RFC-822. SMTP is described in RFC-821. If you have access to the Internet these can be copied from SRI-NIC.ARPA, from the files RFC:RFCnnn.TXT. You can get hardcopy from the DDN Network Information Center; for information on this, call (800) 235-3155 between 7am and 4pm Pacific time. Of course, neither of the above standards will mention % or !, since they aren't officially part of the protocol. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar From ncr-sd!hp-sdd!ucsdhub!esosun!seismo!mcvax!cernvax!ethz!peter Tue Aug 11 11:24:23 PDT 1987 Introduction: I manage mail on a cluster of 5 vaxen, 36 sun3's and 2 symbolics work stations with about 12 links and gateways to 3 disparate networks. Internal mail is via HoneyDanBer UUCP on ethernet. External mail is via uucp, ACSnet and x400. We threw away sendmail about a year ago and replaced it with upas (which at least has human readable rewrite files and a name server). At the same time we forcably switched to doamin addressing for uucp. Debate: I have never seen smail, we can't run it for political reasons (Switzerland lacks a top level domain name and somone to administer the data base) so I think I am eminently qualified to coment about it. The problem is that people still can't seperate the network transport level from the mail system. UUCP and UUX (which actually does the work) copy a file from one unix machine to another and optionally run a command on the remote machine. That is all they do. Somone a long time ago thought "why don't I run the mail program on the remote machine so I can mail between machines". This worked fine at Bell Labs with about the same number of machines we have (43). Unfortunately the world is a big place. More than 10 years on, smail and the whole uucp map project is an attempt to introduce a routing layer between the the transport layer (uucp) and the network application (mail). Hopefully one day it will extend to file transfer and remote job execution like some other more modern systems. Smail replaces the rmail link to the mail program with a system that takes the address on the incoming mail and returns a path route to the system the mail is destined for from the current host. A "sensible" system would then send the mail with its address unchanged to the first host in the path route where the process would be repeated. The mail you send to eiger!peter will remain addressed to eiger!peter even though smail says to route it to seismo!mcvax!cernvax!ethz!eiger!peter. It will be dispatched from your system with a call to uux like: uux - -a dhesi seismo!rmail \(eiger!peter\) We have had a system similar to this working for about 1 year. Explicit routes go through unchanged so the problem of unregistered machines and multiple machine names goes away. They are disambiguated by using an explicit route from a registered host (ethz!tardis!peter works even though tardis is a machine in sothern california, not Zuerich Switzerland). No additional meta characters are introduced. Routing round dead links becomes easy because you don't have to rip appart the address to do it. The only problem of course is that routing has to be done at each node and each node then has to know at least the first step of how to get to every other node. This problem was solved long ago with hierarchical domain addresses such as rfc822. We finished the system by encoraging people to use rfc822 addresses instead of ! addressed uucp so we could have minimal routing information at each node. Of the 3611 remote delivery mail items sent from our gateway machine since July 7, only 1818 have been ! addressed (90% of the ! addressed mesages were generated by the nameserver data base because local ! addresses are marginally faster than rfc addresses). Some questions: 1. Is what I have described the original intent of the uucp map/smail project? 2. If it wasn't the original intent, what way? Thanks to Rahul Dhesi for raising the problem. Peter Beadle From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!hao!oddjob!gargoyle!ihnp4!cbosgd!clyde!watmath!orchid!egisin Tue Aug 11 11:27:25 PDT 1987 |Now consider that we have reached a Catch-22: the general consensus has been |reached that if an incoming `rmail' invocation contains a qualified bang |path, then one should not re-route it, and we should assume that the |raison-d'etre for the full bang path was that the originator knew where |he/she wished the mail route to take. Meanwhile, I was just struck with |the rememberance that one of the reasons for the development of smart |mailers in the first place was to get around the fact that replies to news |articles were using the incoming Path: to generate the return path, which |thus occasionally became many, many hostnames long!! Using smart mailers |enabled using the From: line to generate single RFC822 `user@host.UUCP' or |`user@some.do.MAIN' paths. Now, the sentiment for `leaving bang paths alone' |is all well and good; but given that replies to Usenet news articles probably |account for a healthy proportion of mail traffic, it seems that taking this |attitude isn't really doing any good in the long run. 6 of one, half a dozen |of the other as the saying goes ... | |No, I don't have any solutions, either. Just thought I'd point this out. Is there any need to support the reply-to-Path mechanism of news anymore? I'm assuming sites without a smart mailer are small and have one uucp link to the outside world and a few local links. Is that reasonable? I think anyone with a number of long-distance links would install a smart mailer for the obvious economic benefits. If my assumption is correct, a simple mailer could be put into future news readers that used the From: address. It would only have to recognize local domains (or local-host.uucp), and pass everything thing else to link-to-rest-of-world!domain!user. Of course that assumes link-to-rest-of-world, or someone down the way, is running smail or some other domain mailer. I'm probably being overly optimistic that most major sites running a domain mailer. Message-ID: #584.pnet01.digest/info-nets 67 lines, 2435 chars. Reply-To: crash!decwrl.DEC.COM!sdchem!!MC.LCS.MIT.EDU:!OZ.AI.MIT.EDU:!MC.LCS.MIT.EDU:shimono%tkov58.DEC Date: 10-May-1987 1758 From: crash!decwrl.DEC.COM!sdchem!shimono%tkov58.DEC (Takao 'Ta?i' Shimono) To: Info-Nets@mc.lcs.mit.edu, shimono%tkov58.DEC@decwrl.DEC.COM Subject: FYI: Address for Japanese sites (JUNET) The following below is a recent Info-Japan article on the e-mail address to Japanese JUNET site. JUNET stands for Japan Uni? NETwork as well. forwarded to Info-Nets without permission by -Ta?i (Takao shimono%tkov58.DEC@decwrl.DEC.COM) ..................... ? is a trademark of Project Hatena in Japan. ......................?........................................... From: RHEA::DECWRL::"Hiroshi "Gitchang" Okuno Okuno@SUMEX-AIM.STANFORD.EDU" "Hiroshi GITCHANG Okuno" 18-APR-1987 13:22 To: stuart%hwalhw50%WISCVM.WISC.EDU@SUMEX-AIM.STANFORD.EDU Subj: RE: hiroshima university address [ some header lines deleted by -Ta?i] Date: Thu, 16 Apr 87 11:17:52 PDT Cc: info-japan@MC.LCS.MIT.EDU, nishimura@SUMEX-AIM.STANFORD.EDU Message-Id: <12295015606.13.OKUNO@SUMEX-AIM.STANFORD.EDU> As far as I know, there is no host of Hiroshima University on the JUNET (Japanese University NETwork). Hiroshima may be on the BITNET, but I don't know. JUNET consists of university and non-university members and each group has its own international gateway: To send a message to a university, use CSNET: %.junet%utokyo-relay.csnet@relay.cs.net To send a message to a non-university, use UUCP: kddlab!.junet!@seismo.CSS.GOV or {ihnp4, seismo, hplabs, mcvax}!kddlab!.junet! The university subdomains are u-tokyo, waseda, keio, titech, uec, tsukuba, tsuda, shizuoka, nagano, tokoku-u, kyushu-u, kyoto-u, sophia, hokkaido, osaka, kobe, seikei, toyohashi, ulis, yamanashi, yokohama and so on. Hiroshima and nagoya are not on the JUNET. If you have a qustion, you may contact the postmaster of each domain. [Note 1] According to Mr. Takagi, ICOT, the following addresses are valid, but I have no experience: %.junet%japan.csnet@relay.cs.net and %.junet@seismo.CSS.GOV [Note 2] ICOT is a member of CSNET and its address is %icot.jp@relay.cs.net [Note 3] NTT is *not* a member of JUNET and has its own international gateway. The address to the NTT-domain is #.ntt%nttca.uucp@shasta.stanford.edu (to univ.) or ...!shasta.stanford.edu!nttca!.ntt! (to non-univ.) NTT will become a member of CSNET soon and its address is %ntt.jp@relay.cs.net or %.ntt%ntt.jp@relay.cs.net [Note 3] MITI's Lab, ETL, is not a university site. - Gitchang - ------- Message-ID: #602.pnet01.digest/info-nets 16 lines, 442 chars. Reply-To: crash!ATHENA.MIT!sdchem!!MC.LCS.MIT.EDU:!OZ.AI.MIT.EDU:!MC.LCS.MIT.EDU:henry To: "David D. Story" Subject: Re: Path to Woods Hole Oceanographic Institute ...UUCP Date: Fri, 22 May 87 13:07:21 EDT From: Henry Mensch >> Anyone on in net land have a path to Woods Hole. Woods Hole Oceanographic Institution (WHOI-DOM) 150 Clark Laboratory Woods Hole, MA 02543 Domain Name: WHOI.EDU Administrative Contact, Technical Contact, Zone Contact: Maffei, Andrew R. (ARM5) mit-erl!aqua!arm@EDDIE.MIT.EDU (617) 548-1400 ext 2764 Domain servers: AQUA.WHOI.EDU 128.128.16.1 POLAR.WHOI.EDU 128.128.24.5 Message-ID: #609.pnet01.digest/info-nets 23 lines, 1244 chars. Reply-To: crash!XX.LCS.MIT.EDU!xrjjm%scint.span%JPL-VLSI.ARPA Date: Tue, 26 May 87 10:05:09 PDT From: crash!Jpl-VLSI.ARPA!sdchem!xrjjm%scint.span Subject: Woods Hole... Part 2... To: Info-Nets@Oz.Ai.Mit.Edu Comment: Begin User Supplied Mail Headers. *Site: NASA Goddard Space Flight Center - Greenbelt, Maryland, USA. *Position: 76 Deg. 52' 28.5" West, 38 Deg. 59' 59.8" North. *From: John J. McMahon, Systems Programmer, STX - ST Systems Corporation. *Project: COBE Science Data Room (CSDR), Code 401.1 *Reply-To: (Arpa-Internet) XRJJM%CSDR.SPAN@JPL-VLSI.ARPA [Old Format] *Reply-To: (Arpa-Internet) XRJJM%CSDR.SPAN@VLSI.JPL.NASA.GOV [New Format] *Reply-To: (Bitnet) ZMJJM@SCFVM *Reply-To: (Span/Physnet/Hepnet) 6173::XRJJM = CSDR::XRJJM (Node 6.29) *Reply-To: (TEXnet) UTADNX::UTSPAN::CSDR::XRJJM In addition to the info posted about Wood's Hole previously, they have several Vaxes on the Nasa Space Physics Analysis Net (SPAN). These nodes include "RED", "BLUE", "AQUA", "RSVP", "SLATE"... a few other colors.. etc. Arpa-Internet mail to these nodes can be routed thusly: userid%node.SPAN@VLSI.JPL.NASA.GOV (or @JPL-VLSI.ARPA) Regards, ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v John J. McMahon (Fast-Eddie) Disclaimer: Views expressed in this letter are my own, and are not meant to represent the views of my employers. From ncr-sd!ncrcae!hubcap!gatech!seismo!mcvax!enea!liuida!lel Mon May 18 08:59:09 PDT 1987 In article <588@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > The solution is trivial though it would need a change in most > software. Introduce symbols that allow you to group address > components. I have used parentheses above, but they are already > taken. Perhaps square brackets could be used. The solution is NOT to introduce more symbols. There are many enough already, thank you. What is needed is the conformance to a single standard, whenever possible, and for the Mail Transfer Agents to otherwise do intelligent full translations from the transmitting net's standard to the receiving net's. In article <958@xanth.UUCP> kyle@xanth.UUCP (kyle jones) writes: > What we DO need are some rules on how to interpret the wild mixes of the > non-standard operators such as "%", "!", and "::". The precedences we use > here are "@ then "!" then "%". "::" is a horror from some network of which > we're (apparently) not a member. Also I've seen addresses with "@!" and "!@" > in them. Any ideas on what to do with these??? OK, let's see: "!" is used as a routing operator in the UUCP world. "%" on top of "@" is a de facto routing operator in the ARPANET world. "::" is a routing operator for VAX/VMS mail. "!@" can appear on RFC822 routes embedded in UUCP paths, as in: node!node!@domain,@domain:user@domain Let's then assume that you are a Domainist, ie. you will give "@" precedence before "!" by parsing routes like: node2!node1!user@node3 as: node3 -> node2 -> node1 -> user Now, since "%" is the natural routing operator on top of "@", an address like: node1!user@node2 that is autorouted through "node3" will probably end up looking as: node1!user%node2@node3 meaning: node3 -> node2 -> node1 -> user Giving "!" priority over "%" is clearly an error in this case. However, if you have a "!" path address ending with a "user%node", you can safely prioritize "!" over "%", since this cannot be interpreted as a domain address. Thus, node3!node2!user%node1 should be read as: node3 -> node2 -> node1 -> user One thing that *could* complicate this, is VAX/VMS mail that uses "%" as special operator delimiting a "Foreign Mail Protocol" from the host name, as in: PSI%24020010040403::LISBET::L-LOVSTRAND meaning: to host 24020010040403 using the Packet Switched Interface, then -> LISBET -> L-LOVSTRAND Fortunately, I haven't seem much of them on the net. Their forwarding MTAs seems to be intelligent enough to properly translate them into the receiving net's standard. I just wish more MTAs would do the same thing with "!" addresses going into domain land... Oh well, just wishing. --Lennart (Or perhaps not, see "Electronic Mail Addressing in Theory and Practice with the IDA Sendmail Enhancement Kit" being released to you on this net (very) shortly) From ncr-sd!ncrcae!hubcap!gatech!rutgers!ames!ucbcad!ucbvax!hplabs!hpcea!hpfcdc!hpfclp!diamant Mon May 18 09:01:36 PDT 1987 > Also I've seen addresses with "@!" and "!@" > in them. Any ideas on what to do with these??? > > kyle jones > old dominion university, norfolk, va The first form ("@!") is total trash and I haven't the faintest idea what you could do with it (I've never seen one either). The second form ("!@") occurs when mail is sent from RFC-822 world into UUCP and the From: line had a source route in it and the gateway doesn't know what to do with it. I regularly see mail coming from hplabs (my ARPANET gateway) of the form: hplabs!@foo:user@bar If this is the kind of thing you are talking about, you can ignore everything up to the first @ and treat it like a standard RFC-822 source route. Of course, you aren't allowed to do that by RFC-822, since this address is already illegal and no standard is going to tell you what to do with an illegal address. John Diamant SCO UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO From ncr-sd!ncrcae!hubcap!gatech!rutgers!ames!ptsfa!ihnp4!meccts!ahby Mon May 18 09:02:17 PDT 1987 In article <559@smidefix.liu.se> lel@ida.liu.se (Lennart Lovstrand) writes: All sorts of excellent information about routing and routing symbols... >Now, since "%" is the natural routing operator on top of "@", an >address like: > node1!user@node2 >that is autorouted through "node3" will probably end up looking as: > node1!user%node2@node3 >meaning: > node3 -> node2 -> node1 -> user It seems to me that undef RFC 976, something autorouted through "node3" should be transmitted as: node2!node1!user@node3 Also, since "node2" started life after an @, it must by definition have a domain suffix attached to it. So, if th initial address had been: node1!user@node2.edu it would be autorouted as: node2.edu!node1!user@node3 which, under RFC 976 and UUCP would be translated for forwarding as: node3!node2.edu!node1!user -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby@MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 (C) Copyright 1987 Shane P. McCarron Redistribution allowed only if your recipients can redistribute From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!ptsfa!vixie!paul Mon May 18 09:03:13 PDT 1987 Since I've already come out for leaving the From: line alone, it won't surprise anyone that I totally disapprove of adding .UUCP to an address. My own domain name is currently vixie.UUCP, because I'm in between installing smail and registering the domain. .UUCP is "used for testing only"... (giggle) I'd previously said that a host shouldn't use .UUCP because sendmail.cf's often use it as a mock domain (instead of the newer ".UUX"). This is true, but misleading. You shouldn't use .UUCP because it is not a registered domain -- there is no "authoritative site" for it, no domain administrator, no MX records, no nothing. The UUCP domain is being split (has been split) into the .COM, .EDU, .ORG, etc. domains. There is no .UUCP domain. In <771@mcgill-vision.UUCP> (ugh), Der Mouse says: >Something that seems to be getting commoner is interpretation of >foo.bar!user as meaning the same thing as user@foo.bar - the .uucp gets >added only if there are no dots in the "host" part. This allows two >intelligent hosts to speak to one another using a dumb !-only host as >their link. I think he may be confused. Some sendmail.cf files will use a .UUCP or .UUX internally to mark an address which either came from or is destined for a UUCP-linked neighbor. The .UUCP (.UUX) should be stripped off before the mail is actually queued. In practice, this is often not done; thus many sendmail.cf's will strip it off of incoming mail, hopefully before adding their own magic cookies to it. >What I shudder to see are things like netnews postings with messes like > >From: user@host.dept.univ.edu.UUCP Since the news software is older than the UUCP domain breakup, I can't really blame it for adding ".UUCP" to addresses without "."'s in them. Since they do this, the above address is not likely to be seen. What news software OUGHT to do is just leave the darned addresses alone, with provision for the news admin to force their full domain name to be added instead of just their host or UUCP name. Mail software, same policy: don't add .UUCP to anything leaving your machine. ("Smail test-mode sites excepted, of course," said paul@vixie.UUCP) -- Paul A. Vixie {ptsfa, crash, winfree}!vixie!paul 329 Noe Street dual!ptsfa!vixie!paul@ucbvax.Berkeley.EDU San Francisco CA 94116 paul@vixie.UUCP (415) 864-7013 From ncr-sd!ncrcae!hubcap!gatech!seismo!rutgers!mit-eddie!jbs Thu Apr 16 18:08:42 PST 1987 In article <149@4gl.UUCP> honzo@4gl.UUCP (Honzo Svasek) writes: > I am working on a gateway Usenet <-> Fidonet, and like to know > what type of addressing this gateway should accept according > to the Usenet communitie. > > Honzo.Svasek@333.500.FIDO > In order to conform to the standards, this should be: Honzo.Svasek@333.500.FIDO.NET > This is totally in line with current Usenet practice, but might > need a registration of the domains. (And I hate filling in > registration forms (Any Volunteers :)). I'll fill out the forms; you pay the $150/year (1/4 a :-)) > > The other way (quick and dirty) would be > > mcvax!4gl!FIDO!500_333!Honzo.Svasek > > but this would prevent getting the mail to the nearest fido > gateway (there must be more people interested in providing > such a service). > > Comments please! The syntax you should use is: ...!4gl!333.500.FIDO.NET!Honzo.Svasek since this would be compatible with how mail would be addressed (in the envelope) under the domain scheme. 4gl should recognize that it is processing a FIDO-bound message by the FIDO.NET at the end of the hostname. What you need to do: Get the person who maintains the map entry for the UUCP machine 4gl, and get them to add a line like this to their map entry: 4gl .FIDO.NET($COST$) Where you would replace "$COST$" with one of the standard UUCP map link cost values (e.g. HOURLY, DAILY, etc.) indicating how expensive it is to get the message from 4gl into FIDONET. Then they should send their uucp map entry to uucpmap@cbosgd.ATT.COM. If there are any other FIDONET gateways on uucp, they should also send such an line to their map entries (and send in their updated entry) Once this is done, mail would then be routed from UUCP hosts to the nearest (to the sender) FIDOnet gateway. I don't know the specifics of FIDONET topology, but if the subnets are organized according to low-cost communications (i.e. local calls), it makes sense to also put in a line like: 4gl .500.FIDO.NET($COST$) (again, replace $COST$ with a valid UUCP cost). With lines like this for each UUCP->FIDO gateway (indicating which FIDO subnet it talks to--if it talks to more than one, you'd have more than one such line), the mail will be routed via UUCP to a UUCP->FIDO gateway on the same subnet as the destination address, if one exists, otherwise to a general UUCP->FIDO gateway (one with a .FIDO.NET($COST$) line) closest to the sender. The next step is to apply to register your domain. Having the domain registered will extend FIDO mail accessiblilty to the Internet (including the ARPAnet, the MILNET, CSnet, etc.). It will also guarantee you exclusive use of the FIDO.NET name, preventing someone else from 1) using it and screwing you up or 2) registering it and forcing you to give it up. Hope this answers your questions. Jeff Siegal From ncr-sd!hp-sdd!hplabs!sri-unix!rutgers!uwvax!uwmacc!hobbes!plocher Thu Apr 16 18:11:23 PST 1987 +---- In article <149@4gl.UUCP> Honzo Svasek writes: | | How to address a Fido node! | =========================== | | I am working on a gateway Usenet <-> Fidonet, and like to know | what type of addressing this gateway should accept according | to the Usenet communitie. +---- The unofficial standard already in use (by Bob Hartman, John Galvin, and others) is to use the following address syntax: ...uucppath!uucpgateway!Fidogateway!NET!NODE!USER_NAME Propogation from the Fido gateway to non-local nets *must* be up to the sysop of the Fido gateway! ie. in Madison, WI, the sysop of 'circle' (aka 121/0) will only propogate mail to machines within net 121. He can not send email to other nets (long distance) unless they make arrangements to poll him for their mail. His address as currently implemented and functioning is: ...rutgers!uwvax!uwmacc!hobbes!circle!121!0!John_Galvin This syntax leaves inter-net mail delivery up to the Fido gateway admin; the uucp node hobbes never worries about it. This gets a bit unwieldy for people wanting to send email to Fido. They must remember the uucp path, the uucp name of the Fido node (circle), the Fido net number of that node (121), and the node/name of the recipient (0!John_Galvin). It might be better for the Fidonet gateways to be known to Usenet by their net numbers instead of a fanciful name like 'circle'. Thus the address would be: ...rutgers!uwvax!uwmacc!hobbes!121!0!John_Galvin This leaves the inter-net mail delivery up to the admin of hobbes. Mail delivery then would depend on the Unix gateway calling up the receiving fidonet gateways when mail was waiting for them. ...rutgers!uwvax!uwmacc!hobbes!1!0!FidoNews ...rutgers!uwvax!uwmacc!hobbes!121!10!Joe_Blow ...rutgers!uwvax!uwmacc!hobbes!132!42!Georgette_Public The problem, you see, is that FidoNet is not really a store-and-forward network like Bitnet and Usenet/uucp. The FidoNet is more of a wide area network where each node can comunicate directly with any other node, albeit with quite a bit of delay built into the system. If there was some way of setting up a node which would act as a clearinghouse for email, then every node (or hub) could poll it for mail on a daily basis. In this case, the address: uucppath!FIDO!121!0!John_Galvin would work out for everyone. Just as 'psuvax1' is the uucp <=> BITNET gateway, 'FIDO' could be the uucp <=> FidoNet gateway. Alternitively, some uucp site could maintain the FIDO domain as a second level domain under UUCP: John_Galvin@0.121.FIDO.UUCP This site would have a database of those uucp sites which were acting as uucp <=> FidoNet gateways, and route the email to the appropriate gateway. John_Galvin@0.121.FIDO.UUCP -- would become -- John_Galvin%0.121.FIDO@hobbes.UUCP (or some such) Hope that this hasn't been too long... :-) BTW, the link between hobbes and circle is based on uuslave and a set of utilities to integrate News and email into the _familier_ Fido message areas. These utilities are almost ready for distribution, send email to me if you are interested. -- John Plocher UUCP: !uwvax!uwmacc!hobbes!plocher ============== Internet: plocher%hobbes.UUCP@uwvax.WISC.EDU FidoNet: 121/0 BITNET: uwvax!uwmacc!hobbes!plocher@psuvax1 From ncr-sd!ncrcae!hubcap!gatech!seismo!rutgers!ames!ucbcad!ucbvax!hplabs!hplabsc!taylor Thu Apr 16 18:12:07 PST 1987 A lot of people seem to be confused about how to address different systems that have different address notations (e.g. Fidonet). I've seen suggestions that range from having each part of the Fido address being a different ``hostname'' (e.g. gateway!node!net!user), ones that suggest .FIDO should be a top-level domain (joe@44.24.FIDO), that should be a second-level domain under .ORG (joe@44.24.FIDO.ORG) and a second-level domain under .UUCP (!) (as in joe@44,24.FIDO.UUCP). Well . . . . As Tim Pozar pointed out in his message on this subject, there are a number of existing standards that need to be considered, not only on OUR end (e.g. RFC-822, RFC-976, etc), but on the other end too, on the FIDO systems. As he pointed out, the Fido system is most likely going to be changing to a point and zone address notation since TJ never anticipated it catching on this well and crushing the original addressing scheme. So what does this all mean? It means that: 1. All fidonet gateways should speak the same address format for mail TO fidonet (and from Fidonet too, but that's a subject we haven't talked about much yet in this group). This address should allow for future expansion of the Fidonet system and be a legal set of domains in the UUCP/ARPA world. 2. Since the conceptual model of Fido addresses is a heirarchical domain system (e.g. local-user/local-host-number/host-network) (or something like that) it is needlessly confusing to change the notation to appear to be a series of hostnames (e.g. gateway!host-network!local-host-num!user). This is a *BAD* scheme... 3. The existing heirarchical system is designed to have a *very* small number of different top-level domains (including .COM, .EDU, .MIL, and .ORG). One of the existing domains is ".NET" and is meant to denote a gateway to a different network. For example, the CSNET gateway for the ARPA Internet is at "RELAY.CS.NET". There is *NO* reason why we shouldn't fit in with this scheme (e.g. .FIDO.NET) and this not only means we're compatible, but that the routing software (e.g. smail) will know what to do with mail to Fidonet (it will, correctly, send it to the 'cheapest route' Fido gateway on the system). 4. As far as the individual node addresses and all, I strongly agree with Tim that we need to identify WHICH PART of the address each part is. So this means that, for example, his address is: Tim_Pozar@NODE137.ZONE65.FIDO.NET and we let the local mail system route the mail appropriately. (Cheap plug: the Elm system supports the "domains" database too, so you can have a simple one-line entry to allow users to directly type in this sort of address and have it routed as needed!) I think that the other existing Fido gateways are great, but that we really DO need to at least keep a consistent addressing format. -- Dave Taylor ps: I don't think we should have a "FIDO" host - we do *NOT* want to tie the entire network into having a single gateway, do we?? From ncr-sd!ncrcae!hubcap!gatech!hao!ames!ptsfa!ihnp4!inuxc!iuvax!bsu-cs!dhesi Fri Jun 12 11:04:18 PDT 1987 In article <788@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) quotes somebody who says: >> There is no such thing as a bang address. with: >Gee, what's that thing on the command line after "mail"? > >% mail snarf\!mumble\!scream\!person This is a good time to recapitulate. I originally posted an article suggesting that one ought to be able to specify precedence within a mail address, so [a!b]@c.EDU would be different from a![b@c.EDU] and neither would be ambiguous. Here is a summary of the objections that were raised to my suggestion and my response. Objection: We would have to add another special character to mail addresses and there is no point in complicating things. Response: Actually, we already have three pairs of characters used for bracketing: (), [], and <>. Since () is taken up for comments, that leaves [] and <>. Either set could be used. However, ARPAnet syntax uses [] to hold a numeric address. It would be kinder to ARPAnet software to let it keep the [], although there is not reason why such software could not be modified to recognize the meaning of [] by testing its contents to see whether they included anything other than digits and dots. But <> is already used to specify precedence, although only one level of <> is used. All we need to do is allow the nesting of <>. Objection: There is no such thing as a bang address. Response: Should we dignify this head-in-sand attitude by responding to it? I don't think so. Objection: There is no problem with precedence because @ always has the highest precedence, and anything to the left of that is only interpreted by the site named after the @. Response: This is pure chauvinism. A user of the ! syntax, whose mailer does not understand @ syntax, treats all addresses as made up of components separated by bangs. Even programs that understand both types of addresses may arbitrarily choose one over the other. As far as I can tell from the documentation, smail gives precedence to the ! over the @ when it sees both in the address field of an incoming message. I have encountered messages whose address fields were badly mangled because some sites gave precedence to @ and others gave precedence to !. Think about it, folks. Ken Iverson designed APL to be very regular in its operator precedence. With prefix notation, you ought to be able to dispense with all bracketing symbols. So why did he retain [] and () anyway? -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi From ncr-sd!hp-sdd!hplabs!sri-unix!husc6!think!ames!xanth!kyle Fri Jun 12 11:04:35 PDT 1987 > > There is no such thing as a bang address. > > Gee, what's that thing on the command line after "mail"? > > % mail snarf\!mumble\!scream\!person That thing is a route, not an address. This route to "person" would work for you only if your host talks to snarf. A proper address to this person would be something like person@scream.technisound.com. A user can send mail to an address like that and not have to worry about how the mail will get there. The routing is left up to the mail transport mechanism, whatever it may be. > What should appear on the To: line of this letter? If the UUCP host scream has a domain name (e.g. scream.techisound.com) then that is what should be on the To: line (person@scream.techisound.com). If scream doesn't have a domain name, person@scream.uucp is best, since on smart UUCP hosts replying to this will allow an appropriate path to be generated. Not-so-smart UUCP hosts leave this up to the user and force them to put routes into the mail headers... but there is no longer any need for this! THere is FREE software available to do the routing more or less invisibly. kyle jones old dominion university, norfolk, va From ncr-sd!ncrcae!hubcap!gatech!hao!ames!lll-lcc!ptsfa!ihnp4!inuxc!iuvax!bsu-cs!dhesi Fri Jun 12 11:04:54 PDT 1987 In article <1192@xanth.UUCP> kyle@xanth.UUCP (Kyle Jones) quotes der Mouse: >> Gee, what's that thing on the command line after "mail"? >> >> % mail snarf\!mumble\!scream\!person and claims: >That thing is a route, not an address. This route to "person" would work for >you only if your host talks to snarf. It is both. A route and an address don't have to be mutually exclusive. If site `scream' is on the UUCP map, then scream!person is an address that other sites will recognize and generate a route for. Smart routers will also successfully generate a route for snarf!mumble!scream!person, therefore that is an address too. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi From ncr-sd!hp-sdd!hplabs!decwrl!decvax!ucbvax!ucbcad!ames!ptsfa!vixie!paul Fri Jun 12 11:05:08 PDT 1987 Okay, let's do it again.... sigh... In article <756@bsu-cs.UUCP> dhesi%bsu-cs@iuvax.UUCP (Rahul Dhesi) writes: >This is a good time to recapitulate. I originally posted an article >suggesting that one ought to be able to specify precedence within >a mail address, so [a!b]@c.EDU would be different from a![b@c.EDU] and >neither would be ambiguous. > >Here is a summary of the objections that were raised to my suggestion >and my response. And here are my objections to your responses. >Objection: We would have to add another special character to mail >addresses and there is no point in complicating things. > >Response: [...] All we need to do is allow the nesting of <>. For the various non-recursive finite-state parsers out there, nested <>'s would be a painful thing to support. What I want to point out, though, is that you are suggesting a change to the software of every (or nearly every) node on the internet. At least, those sites that wanted to reply to sites using your new syntax, would have to upgrade their software to understand the new syntax. This is not in itself a bad thing; at this point I only want to point out the scope of the change you are suggesting -- I need it below. >Objection: There is no such thing as a bang address. > >Response: Should we dignify this head-in-sand attitude by responding >to it? I don't think so. This is unprofessional in the extreme. All you do with this kind of a response is to convince the people who have the attitude you are making fun of, that YOU are a jerk and that your ideas are probably worthless. Try to be constructive, okay? Now the fact is that there IS NO SUCH THING as a bang address. Bangs are used in routes, not addresses. At-signs are used in addresses. There is such a thing as a 'route-addr', which uses colons and commas, but I really don't understand much of that (which is too bad, since my sendmail.cf does!) This is a question of terminology. A string consisting of "words" seperated with bangs is CALLED a route. A string with two "words" with an at-sign in between them is CALLED an address. According to the standards adopted by the Internet, "From:" and "To:" lines contain addresses, and addresses are of the form "lhs@rhs", and "rhs" has a syntax making it a domain, and "lhs" can be anything at all. An address (really: a From: or To: line's contents) that does not contain an at-sign is considered a "local" address, subject to whatever meaning the local mailer wants to give it. Usually, it is scanned for bangs and forwarded if appropriate -- but this is a defacto-standard, not an approved one. THIS WORKS. There is no need for precedence operators in a network where every site acts according to the standard. Maybe we need a standard that will transform the defacto handling of bangs in LHS into an approved thing; if this is what you want to to, write an RFC -- the net would canonize you. My point in this part of this article is that there is a standard, and that if all sites adhered to it, it would work well enough to do what you are trying to do with your additional precedence operator(s). Also, I urge you not to brush off this point, or I (and others, no doubt) will think that YOU have YOUR head in the sand. >Objection: There is no problem with precedence because @ always has >the highest precedence, and anything to the left of that is only >interpreted by the site named after the @. > >Response: This is pure chauvinism. Chauvinism = preference of one thing over another for non-objective reasons. There ARE good reasons for doing it this way -- because that's the approved standard, mostly; if you do it this way, you mail will get through, and mail forwarded through your system will get through. This is not chauvinism. >A user of the ! syntax, whose mailer does not understand @ syntax, treats all >addresses as made up of components separated by bangs. Even programs that >understand both types of addresses may arbitrarily choose one over the other. A user of the ! syntax can get SMAIL for free, and join the internet. A program that understands both bangs and at-signs can either do it the way the standards tell us to do it, or do it some other way. If the program adheres to the standard, everybody's mail will get through. Points: internet mail handlers can be had for free (SMAIL). there IS a standard way to handle addresses with both @ and !. >As far as I can tell from the documentation, smail gives precedence to the ! >over the @ when it sees both in the address field of an incoming message. Since SMAIL is advertised as a RFC-compliant mailer, this can't be right. Can a UUCP-Project member comment on this? >I have encountered messages whose address fields were badly mangled because >some sites gave precedence to @ and others gave precedence to !. So have I. And I curse and bitch and moan and send mail to the site admins of the offending systems, and they usually say "oh, sorry, didn't know, let me install smail". Really, that's the usual response. I've been amazed. >Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi You're done, so let me get to my conclusion. Since SMAIL is free, and since it adheres to the published standards, and since if everyone adhered to the published standards mail would be much more reliable, and since you are suggesting that everyone (even currently compliant sites) change their mail handlers to accept your (unneccessary) additions, it follows that you should instead advocate a wider acceptance of SMAIL: it does what you want done (get mail through faster and more reliably); it already exists (so there is no effort involved in designing and coding what you suggest); it is free (obvious benefits); and anyone already compliant with the published stand- ards doesn't have to do anything (fewer people have to upgrade their mailers). Can we let the precedence-character argument drop, now, and get on with the business of bringing the gospel of SMAIL to the heathens(*) :-) ?? (* = stolen from Cal Thixton's outgoing mail headers) -- Paul A Vixie Esq 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul San Francisco ptsfa!vixie!paul@ames.ames.arc.nasa.gov CA 94116 paul@vixie.UUCP (415) 864-7013 From ncr-sd!hp-sdd!hplabs!cae780!amdcad!dopey!jimb Fri Jun 12 11:05:34 PDT 1987 In article <6762@a.ms.uky.csnet> david@ms.uky.csnet (David Herron -- Resident E-mail Hack) writes: >>2. REROUTE believes that there are no duplicate UUCP names. ... >> >> To use Phil Ngai's example, there is an AT&T site named neptune >> and an AMD site named neptune. But there's no name conflict; >> the AMD site neptune does not appear in the UUCP map and its official >> name is neptune.amd.com. If someone mails to amdcad!neptune!user, >> this is a different neptune than the AT&T one, and mailers shouldn't >> be f*king with the address. > >This is the part I couldn't let pass by. Why not? > >If amdcad wants to have their neptune able to send and receive mail >without hassles, then they should arrange it so that mail will be sent >to amdcat!neptune.amd.com!user. (i.e. putting that out in headers when It said the official name was neptune.amd.com. >mail is sent out, announcing in the maps either the existance of a >gateway for .amd.com or the existance of neptune.amd.com itself, etc). Try uuhosts 'amd.com'. Registered, mapped, gatewayed, and sendmail configured to know about the .AMD.COM long ago. > >If they do anything else, they're asking for trouble. You mean like the user who places amdcad!neptune!joe in his .signature :-)? +--------------- We do all of the above, but I still believe that ...!amdcad!dopey!... in a path should always refer to OUR dopey (dopey.amd.com). A path of the form ...!amdcad!dopey!jimb which passes through any site which has defined REROUTE will be sent to dopey, a machine in Ohio rather than to OUR dopey. ( You'll note the change of the example from neptune to dopey, above. This is for the simple reason that, with the removal of att internal machines from the maps a couple of months ago, there is no longer any non-domainized neptune in the map. But there is a dopey.) -- + Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 + + Compuserve: 72415,1200; Delphi: JIMBUDLER; Usenet: jimb@amdcad.AMD.COM + From ncr-sd!hp-sdd!hplabs!sri-unix!husc6!seismo!mcnc!xanth!kyle Fri Jun 12 11:06:36 PDT 1987 In article <355@dopey.AMD.COM>, jimb@dopey.AMD.COM (Jim Budler) writes: > A path of the form ...!amdcad!dopey!jimb which passes through any > site which has defined REROUTE will be sent to dopey, a machine in Ohio > rather than to OUR dopey. This is as it should be. The occurrance of a name such as "dopey" in a bang route should have a unique meaning on all UUCP sites. Therefore "dopey" = "dopey.UUCP" = the "dopey" in the UUCP maps. If a site along the way knows a cheaper way to get to the machine in Ohio, more power to them... they are presumably saving themselves and maybe a few other sites some $$. However, such a site must be careful not to route mail back to a site where it has already been, and possible cause looping. kyle jones old dominion university, norfolk, va From ncr-sd!hp-sdd!hplabs!pyramid!oliveb!epimass!jbuck Sat Jun 13 19:32:00 PDT 1987 In article <1209@xanth.UUCP> kyle@xanth.UUCP (Kyle Jones) writes: >In article <355@dopey.AMD.COM>, jimb@dopey.AMD.COM (Jim Budler) writes: >> A path of the form ...!amdcad!dopey!jimb which passes through any >> site which has defined REROUTE will be sent to dopey, a machine in Ohio >> rather than to OUR dopey. >This is as it should be. The occurrance of a name such as "dopey" in a bang >route should have a unique meaning on all UUCP sites. Therefore "dopey" = >"dopey.UUCP" = the "dopey" in the UUCP maps. If a site along the way knows a >cheaper way to get to the machine in Ohio, more power to them... they are >presumably saving themselves and maybe a few other sites some $$. This is NOT as it should be. The maps are not completely accurate and the net is not static. Sites go down or get overloaded. If the user wanted you to generate a route, he or she would have said user@dopey rather than amdcad!dopey!user. With the domainizing of the world, I suspect that the non-domainized portion of the UUCP map will reflect a smaller and smaller portion of the UUCP world; more and more sites will have domainized names in the From: line but still use six-or-seven-letter names in the From_ line. REROUTE is wrong now, and it will be a disaster soon. You have the right to generate a route to the first host in the chain, but not to the last. This is because the route alpha!beta!gamma!user means alpha!(beta according to alpha)!(gamma according to beta)!user and if the alpha!beta connection is expensive, alpha has a right to get the message to beta a cheaper way. But alpha cannot know whether the gamma in the path is the same gamma as the one it knows. This will become more true as the number of UUCP-reachable sites increases by another factor of 10. However, if the path is alpha!beta!gamma.foo.com!user alpha may generate a route, because domain names are absolute. But I'm not so sure it's a good idea even then. -- - Joe Buck jbuck@epimass.EPI.COM (in the brave new world of domains!) {seismo,ucbvax,sun,decwrl,}!epimass.epi.com!jbuck From ncr-sd!ncrcae!hubcap!gatech!hao!husc6!mit-eddie!genrad!panda!teddy!jpn Tue Jun 16 13:57:11 PDT 1987 >>Objection: There is no problem with precedence because @ always has >>the highest precedence, and anything to the left of that is only >>interpreted by the site named after the @. >> >>Response: This is pure chauvinism. > >There ARE good reasons for doing it this way -- because that's the approved >standard, mostly; if you do it this way, you mail will get through, and mail >forwarded through your system will get through. This is not chauvinism. I think it's chauvinism. Your internet standard/software may talk '@' addresses, but my software may not, and arbitrary sites between me and my desired destination may not. How about an example. I need to send '@' mail to a site (call it site3) three uucp hops away which is a gateway to an '@' network: There is one site in the middle (call it "site2") which doesn't understand '@' addresses (bear with me a moment!). The site immediately next to us (call it site1) interprets '@' addresses. My first guess at an address would be: site1!site2!site3!user@foo.NETWORK This won't work, because site1 interprets that '@', and tries to send relay mail to foo.NETWORK, with the username site2!site3!user. This fails. If I send an address like user@foo.NETWORK to site1, and assuming IT understands that it needs to relay to site2 (a big assumption, but nevermind), then site2 gets an address like user@foo.NETWORK, and dies. What is "smail" supposed to generate, if I give it an address like user@foo.NETWORK if we are not on that network? Would site3!user@foo.NETWORK@site2.UUCP@site1.UUCP work? Unlikely, or unreadable, at best. What if MY site ONLY talks bang. Will site!site3!user@foo.NETWORK@site2.UUCP work? I doubt it! Now, suppose that all of site1, site2, and site3 talk '@' addresses, but site1 and site2 only know UUCP domain, and site3 is still the NETWORK gateway. HOW do I send mail now? Does site1 HAVE to understand .NETWORK? I think this is unreasonable, especially when I already KNOW how to get mail to .NETWORK (I relay through site1, site2, and site3!). Can I say: user@foo.NETWORK@site3.UUCP@site2.UUCP@site1.UUCP? Does this work? It this really the approved way to send mail over non fully-connected networks (i.e. where some path components MUST be specified)? Maybe I'm just confused... From ncr-sd!hp-sdd!hplabs!cae780!amdcad!amdahl!ptsfa!vixie!paul Wed Jun 17 14:00:09 PDT 1987 In article <4106@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: >[...] >Now, suppose that all of site1, site2, and site3 talk '@' addresses, but >site1 and site2 only know UUCP domain, and site3 is still the NETWORK gateway. A gateway is allowed (maybe required, I'm not sure) to rewrite as neccessary when forwarding messages between networks. Therefore you could send to site1!site2!site3!foo.network!user and the dest addr will be rewritten to be user@foo.network when site3 forwards it. What to set the From: line to in that situation, I don't know. As I weary of this whole discussion, I begin to wish that the RFCs would recognize bangs as a low-precedence operator, since the route-addr form with all the colons and commas looks really really ugly. But there is a way to do even that -- routing in the ARPAnet. Something like :site3.network,:site2,:site1,you@home but don't quote me. Whatever form it takes, site3 as the gateway could rewrite from that to the bang-form. That will make replies to the message work okay; getting the original message through is the easy part, and that's all you asked about. >HOW do I send mail now? Does site1 HAVE to understand .NETWORK? I think >this is unreasonable, especially when I already KNOW how to get mail to >.NETWORK (I relay through site1, site2, and site3!). Can I say: >user@foo.NETWORK@site3.UUCP@site2.UUCP@site1.UUCP? Does this work? Nope, only one @ per address. But there IS a route-form, I promise! I just don't remember the syntax. Help? >Maybe I'm just confused... You and me and everybody else, too. -- Paul A Vixie Esq 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul San Francisco ptsfa!vixie!paul@ames.ames.arc.nasa.gov CA 94116 paul@vixie.UUCP (415) 864-7013 From ncr-sd!hp-sdd!hplabs!cae780!amdcad!amdahl!ptsfa!vixie!paul Wed Jun 17 14:01:15 PDT 1987 In article <995@killer.UUCP> elg@killer.UUCP (* Airwick *) writes: >in article <654@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) says: >> Now the fact is that there IS NO SUCH THING as a bang address. Bangs are >> used in routes, not addresses. At-signs are used in addresses. There is >> such a thing as a 'route-addr', which uses colons and commas, but I really >> don't understand much of that (which is too bad, since my sendmail.cf does!) > >Gee, I'll have to tell that to the mailer here at machine "killer". It doesn't >understand @ signs at ALL. Doesn't ihnp4!foo!bar mean the same thing as >bar@foo, as far as differentiating the machine and ID of the reciever goes? >The only difference is that ihnp4!foo!bar also includes a little routing >info.... As far as identifying the host and user of the recipient, both forms have that information, yes. The extra routing information is usually wrong, since the From: line is not supposed to be modified, and the UUCP From_ line is usually not used for replies (not by mailx, anyway, and if there's an option for this it ought to be the default, or at least prominently displayed in the documentation). >If we define an "address" as a "unique identifier identifying a) the machine >of the recipient, and b), the ID of the recipient", then it's obvious that >both "bang" paths and "at" addresses are, in fact, both addresses, even though >one includes more information than the other. If you define "address" that way, yes, both forms are an address. The point I've been making is that the Internet _doesn't_ define an address that way, and there's less work involved in using the existing meaning of "address" than in changing all the Internet sites to use a different definition. >>A user of the ! syntax can get SMAIL for free, and join the internet. A >>program that understands both bangs and at-signs can either do it the way >>the standards tell us to do it, or do it some other way. If the program >>adheres to the standard, everybody's mail will get through. > >There's one problem with this. The vast majority of system operators out there >are NOT mail gurus. Their machine comes with /bin/mail and /bin/mailx, their >mailer is rmail (which talks to uux), and they're busy doing their JOB instead >of trying to keep up with the latest "standards" to come out. Call it "head in >the sand" if you will, but most of these people don't even KNOW that SMAIL >exists. Yeah, I know. Whatever vendors ship to clients, becomes the unofficial standard. People support it because it exists, and often it's an accident, not intended for the wide support it eventually receives. I don't know how to solve this. I do consulting work, and I've set up SMAIL for money before -- it takes about 30 minutes once you know what to do. For the vast majority of people who will only use what their vendor supplies, I have no immediate answer. I think that X.400 will get wide support, since ISO standards are very popular with vendors; unfortunately, an X.400 mailer is a salable product, and will probably be an extra-cost option in future UNIX(tm) releases, which means that UNIX and e-mail will probably stop going hand-in-hand. Whether X.400 is a good thing technically or not, I can't comment -- I don't know. -- Paul A Vixie Esq 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul San Francisco ptsfa!vixie!paul@ames.ames.arc.nasa.gov CA 94116 paul@vixie.UUCP (415) 864-7013 From bigbang!pyramid!ncc!lyndon Wed Jun 17 14:01:58 PDT 1987 You should be able to specify a route like site1!site2!host.domain!user as an alternate to site1!site2!user@host.domain Sites that gateway between @ and ! networks should be able to grok host.domain!user for this very reason (according to the RFC you love to hate :-) If you look at the paths generated by smail, they will use the host.domain!next_part convention in preference to user@... to enable these type of addresses to be routed through hosts that understand @ as well as ! without any confusion arising. From ncr-sd!ncrcae!ece-csc!mcnc!xanth!john Wed Jun 17 14:02:47 PDT 1987 In article <4106@teddy.UUCP>, jpn@teddy.UUCP (John P. Nelson) writes: > How about an example. I need to send '@' mail to a site (call it > site3) three uucp hops away which is a gateway to an '@' network: > ... [and sites along the way handle @ differently] ... > site1!site2!site3!user@foo.NETWORK > user@foo.NETWORK, and dies. What is "smail" supposed to generate, if I > give it an address like user@foo.NETWORK if we are not on that > network? Would site3!user@foo.NETWORK@site2.UUCP@site1.UUCP work? > Unlikely, or unreadable, at best. What if MY site ONLY talks bang. > Will site!site3!user@foo.NETWORK@site2.UUCP work? I doubt it! > [etc.] First of all, you can *never* have more than one @-sign per address if you want to preserve any sanity at all. [Exception: route-addrs.] This is what RFC976 and smail take care of! A "class 3" UUCP site, including all sites running smail, will accept do.ma.in!user, not just user@domain. So in the first scenario above, your mail transport agent should generate the address site1!site2!site3!foo.NETWORK!user Now with an intelligent user agent, or even a not so intelligent user agent that just passes the address along to smail, you should just be able to say mail user@foo.NETWORK and have smail generate the above all-bang address for you. The RFC822 mail headers (To: line, etc.) should only have the user@foo.NETWORK address, and the rmail commands that get passed from uucico to uucico will only have bangs. I've been using ".NETWORK" since that's what you used in your examples, but you should be aware that what you're going to see on the right side of the @-sign is almost always a domain address, which might or might not imply any particular network. Addresses that explicitly indicate a network (".ARPA", ".UUCP", ".BITNET", etc.) are using "pseudo-domains", and are becoming increasingly more rare, in favor of network independent domain names (ending in ".COM", ".EDU", ".UK", or whatever). You (and anyone else interested) should read RFC976 (and maybe the "What is a Domain?" paper), included with the smail documentation. -- John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 4529 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john From bigbang!ncr-sd!matt Thu Jul 16 11:01:04 PDT 1987 In article <1113@mtune.ATT.COM> jhc@mtune.UUCP (Jonathan Clark) writes: >In article <700@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >>You can probably be reached at: p.g.fox@mtune.ATT.COM >> pgfox@mtune.ATT.COM >> mtune.ATT.COM!pgfox >> mtung!pgfox >> pgfox@mtung.UUCP >p.g.fox@mtune.att.com will work, (via forwarding to mtung!pgf) but >anything with "pgfox" in it won't. I didn't process all my 22 machines >user's names into smail2.5's fullnames database, and I was lazy >putting them into the aliases database. Someday I'll put a smart >search into smail (unless I get lucky and someone else does it first). >Until then it's exact string matches only. The version of smail that I developed has the concept of a Information Source, which is currently used for three different types of information: HOSTINFO contains host and domain names (pathalias) NEXTINFO used to look up "adjacent" host names in UUCP paths ALIASFILE to handle "local" names One possible type of information source is a program, so that the lines: HOSTINFO SanDiego.NCR.COM nameserver:SanDiego.NCR.COM!%s DOTMAILER nameserver # user names with periods processed here MAILER nameserver ALIAS postmaster,matt ALIASFILE "cache.rolo",normal,noneok ALIASFILE "/usr/local/bin/rolo -U 8 -11 -p email -n ",prog,cache=cache.rolo ABORT "User %I is not in the user directory" cause local names with a dot in them and any local names addressed to our domain name (a virtual machine) to be processed using the "nameserver" mailer. The real useful line is the second ALIASFILE which defines the information source to be a program which does a database lookup. The released version of the rolo program does substring matching with various fudge factors thrown in. The new version does a very general closeness matching that allows lots of leeway in the name. In particular the name Bob.Raight will match Robert.Wrights, but with a very high cost. If the closest match is better than the next closest by enough margin then the name is matched, otherwise the lookup fails and the closest 8 matches are listed instead. -- Matt Costello +1 619 485 2926 {sdcsvax,cbosgd,pyramid,nosc.ARPA,ihnp4}!ncr-sd!matt From bigbang!ncr-sd!matt Thu Jul 16 11:21:11 PDT 1987 In article <1113@mtune.ATT.COM> jhc@mtune.UUCP (Jonathan Clark) writes: >In article <700@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >>You can probably be reached at: p.g.fox@mtune.ATT.COM >> pgfox@mtune.ATT.COM >> mtune.ATT.COM!pgfox >> mtung!pgfox >> pgfox@mtung.UUCP >p.g.fox@mtune.att.com will work, (via forwarding to mtung!pgf) but >anything with "pgfox" in it won't. I didn't process all my 22 machines >user's names into smail2.5's fullnames database, and I was lazy >putting them into the aliases database. Someday I'll put a smart >search into smail (unless I get lucky and someone else does it first). >Until then it's exact string matches only. The version of smail that I developed has the concept of a Information Source, which is currently used for three different types of information: HOSTINFO contains host and domain names (pathalias) NEXTINFO used to look up "adjacent" host names in UUCP paths ALIASFILE to handle "local" names One possible type of information source is a program, so that the lines: HOSTINFO SanDiego.NCR.COM nameserver:SanDiego.NCR.COM!%s DOTMAILER nameserver # user names with periods processed here MAILER nameserver ALIAS postmaster,matt ALIASFILE "cache.rolo",normal,noneok ALIASFILE "/usr/local/bin/rolo -U 8 -11 -p email -n ",prog,cache=cache.rolo ABORT "User %I is not in the user directory" cause local names with a dot in them and any local names addressed to our domain name (a virtual machine) to be processed using the "nameserver" mailer. The real useful line is the second ALIASFILE which defines the information source to be a program which does a database lookup. The released version of the rolo program does substring matching with various fudge factors thrown in. The new version does a very general closeness matching that allows lots of leeway in the name. In particular the name Bob.Raight will match Robert.Wrights, but with a very high cost. If the closest match is better than the next closest by enough margin then the name is matched, otherwise the lookup fails and the closest 8 matches are listed instead. -- Matt Costello +1 619 485 2926 {sdcsvax,cbosgd,pyramid,nosc.ARPA,ihnp4}!ncr-sd!matt From bigbang!ncr-sd!matt Thu Jul 16 11:21:24 PDT 1987 In article <790@nu3b2.UUCP> rwhite@nu3b2 writes: >My mail program "mailx" has a option to produce internet addresses >from the "regular" addressing system useing "!". > >I am by no means an expert, but all this "conversion" seems to do >is hack off the last system name and addressed account name of the >end of sys1!sys2!sys3!sys12!othersys!whathaveyou!thatguy [or whatever] >and give me as the return address. > >Is this enough for the "internet" mail sites to deliver these messages >to the correct systems? It is if you've got a "real" internet system. The problem you find is that systems (such as nu3b2) that aren't registered. When this happens the "set conv=internet" of mailx is a big lose. For this reason you don't want to turn it on. A better option for replying to usenet articles is a mail router that supports a safe form of re-routing. >My system is not actually able to deliver messages with these addresses >but it does have hooks to run other programs from inside the "mailx" >system... Is there a mailer program I can/should be running? Mail addressing is going towards domains and you'll need a mail router that can handle domains (and internet addressing). I'd suggest you get smail, either mine or theirs. I'm going to be prejudiced and say that you should use my version of smail. It is set up to handle the configuration and maintenance automatically, and also centralizes administration at a single site for multiple-site domains. You will find that most other mail routers preclude running the identical binary on multiple machines because they compile-in the configuration. Find out if National University has a domain name registered; if it does it will probably be something line "natu.edu". Note that none of the mail routers (smail/uumail/hpmail/sendmail/mmdf) require that you change the program that a user runs, so that your users can continue to use mailx. >The reason I ask is that If someone sends me mail from usenet I get >a Reply-To: string that starts at my backbone site and goes from >there. > >I get: sdcsvax!... >instead of: man!jack!ucsdhub!sdcsvax!... > >I need the latter, or some solution. According to my manual you can >only set an alias for the last recepiant, not an intervening machine >name. Almost any mail router can fix this problem. With my version of smail the normal fix would be the line NEXTINFO sdcsvax sdcsvax.ucsd.edu!%s in the configuration file, although the PUSHYROUTE option will also fix it. -- Matt Costello +1 619 485 2926 {sdcsvax,cbosgd,pyramid,nosc.ARPA,ihnp4}!ncr-sd!matt From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucbvax!cbosgd!stargate!pleasant Fri Jul 31 13:23:50 PDT 1987 This is a *MUST READ* announcement for all site administrators maintaining map entries published in the comp.mail.maps newsgroup. Please read the entire message carefully before attempting to modify your entry. In an attempt to comply with RFC822, RFC976 and other mail standards documents, The UUCP Mapping Project will no longer publish map entries that contain certain types of constructs. Since most of these constructs have not been accepted in new map entries for quite some time, most of you will not be affected by this announcement. Sites that currently have these constructs were allowed to keep them through grandfather clauses that can no longer be invoked. One currently accepted construct, involving the use of pathalias network characters, will unfortunately no longer be accepted. So, with your current map entry at your side, I urge you to read the entire announcement, make corrections as appropriate, any send in your update. Since I'll be on vacation until the end of August, questions will be fielded by Mark Horton (stargate!mark). o - site and domain names may contain the following characters: a through z, 0 through 9 and dash (-). Fully qualified domain names may contain the character dot (.). No other characters, including uppercase alphabetics and underscore will be accepted anywhere in the name. In addition, site names and each section of the domain name must begin with a lowercase alphabetic and may *not* end with a dash. The above applies to all names given on the #N and #F lines as well as all names that appear in the link description portion of your map entry. It does *not* apply to pseudo network names used to help describe internal networks, as defined in the pathalias documentation. o - The link description of your entry as published by the UUCP Mapping Project must generate pure "bang" paths. Essentially, the only network character (as documented in the pathalias man page) allowed in a published map entry will be the bang (!). RFC976 defines the @ network character as having precedence over the bang (!) when both appear in mixed mode addresses. This essentially invalidates the use of the @ and other network characters as they were commonly used in the UUCP community, except at the local level. As stated earlier, this announcement will have no effect on the vast majority of you. However, it can have a profound effect on those who wish to have their entry published but do not currently comply. For one, a small percentage of you will have to change your site name. In doing so, you'll have to contact all of your uucp neighbors and co-ordinate the change with them. An even smaller percentage will have to change domain names. We recognize that, for those of you who have to make some change, doing so can be a vast undertaking. To that end, we do not plan to publish another set of maps to the comp.mail.maps newsgroup until September 11th. We hope that everyone will be able to affect the necessary changes within the next 5 1/2 weeks. We recognize that domain name changes will have to be co-ordinated with the NIC and will not take any default action while that effort is working its way through the mill. Members of the UUCP Zone having to make a domain name change due to this announcement will not incur any additional fees or charges. At posting time (September 11), the following default actions will take place for any site or domain name that does not comply (except as previously noted): o - All uppercase characters in a sitename will be converted to lowercase. o - Any sitename that begins with other than a lowercase alphabetic, ends in other than a lowercase alphanumeric, or contains underscores will cause either a link or an entire map entry to be dropped. If the offending name is the map entry's name (#N) or the name of the forwarder (#F) the entire map entry will be dropped. In all other cases, the particular construct will be dropped. In general, this will be the link in which the name is involved. EFFECTIVE IMMEDIATELY, names containing dashes that *would* match existing names containing underscores are now placed on reserve i.e. the name "why-not" is on reserve for the site "why_not" and will remain so until September 11th. Note, we will not actually make this type of change for you. We're simply setting aside the most obvious name that you might want to use for your site. o - Any links that will cause pathalias to generate other than a pure bang path will be modified such that a pure bang path will be produced. Note that we will make an educated guess here. If you don't want us guessing, update your map entry. In most cases, our guess will consist of dropping the network character involved. -Mel Pleasant (cbosgd!uucpmap) -UUCP Mapping Project Message-ID: #532.pnet01.digest/info-nets 27 lines, 1052 chars. Reply-To: crash!XX.LCS.MIT.EDU!LDW%USCMVSA.bitnet%UCBVAX.BERKELEY.EDU.#Internet Date: Thu, 16 Apr 87 00:14 PDT To: Zvika Bar-Deroma From: Leonard D. Woren 213 743-5391 > Well - I have the feeling that it has to do with the "============" > used as seperators of some mail programs. > If I recall correctly, RFC 822 states that a line of equal sign (========) > should seperate the header of the message (the envelope ) from it's body. I was hoping someone else would respond to this. (The message I'm replying to is a month old.) The line of '====' is *not* an RFC822 defined separator. It is used by UCLA/Mail and possibly other user agents to separate messages stored in a notebook. RFC822 states that the header is separated from the body by a null (blank, to those of us on IBM systems) line. > ...goes for this list too (any cooments from the moderator to that?). To the best of my knowledge, this is an unmoderated list. > I think this calls for one major thing - don't use lines with =============== Reasonably good advice... > If you want to include a part of a mesage sent to you, DELETE that line. Well, just changing the first few === to blanks should fix it. Leonard D. Woren LDW@USCMVSA.BITNET From bblue Fri Apr 17 18:00:36 1987 Date: Fri, 17 Apr 87 18:00:35 PST From: bblue (Bill Blue) To: jeh Subject: Re: moron (more on) addresses Probably you mean the Reply-To: field, though both are pretty munged with. The address you'd actually end up using would be the last of the string. crash!ldw@uscmvsa.bitnet would work just fine. Forget most of that other nonsense. The other file looked like correspondence mostly with chuq. Only a small part of it seemed directed to Frank - the part about vms. I don't envy your undertaking, is about all that comes to mind after reading it. That's reinventing the wheel personified. Sorry, but I don't have anything too enlightening about any of this. I wish I did. The smart mailer I have refered to is 'smail'. The full source code to it is in /usr1/src/smail23 (in Unix). You're welcome to take whatever of it you like. --Bill Message-ID: #569.pnet01.digest/info-nets 81 lines, 3218 chars. Reply-To: crash!MC.LCS.MIT.EDU:!OZ.AI.MIT.EDU:!MC.LCS.MIT.EDU:god3%sphinx.UChicago.BITNET To: info-nets%mit-oz@mc.lcs.mit.edu Subject: HELP me... gateway prob Date: 04 May 87 16:14:38 CDT (Mon) From: Peter Godwin Help... I have been receiving mail from a friend who is at oberlin but can't seem to get stuff to him.. Here's the info I have on him in the form of mail he sent me and info he sent me: ------------------------------------- Return-Path: <"OCVAXA::STG8384"@CMCCVB.BITNET> Received: from UCHIMVS1 (not validated) by CHIP.UChicago; Thu 2 Apr 87 17:12:01-CST Received: (from NETMAIL@CMCCVB for UCHIMVS1 via NJE) (GATEWAY-2194; 48 LINES); Thu, 02 Apr 87 17:10:49 CST Date: Thu, 2 Apr 87 17:48 EST From: "OCVAXA::STG8384"@CMCCVB.BITNET Subject: This is T. Geller from Oberlin. I stayed with you a few weeks ago. Am I getting through? My username is STG8384. (Also sent through Pyramid/ Unix) To: x9.xpg@UCHICAGO X-VMS-To: CMCCVB::IN%"x9.xpg@uchicago" I. NETWORKING. Get usernames and nodenames of friends at other schools! We can send and receive almost anywhere in the world. Make sure their node, e.g. the computer they can get an account on, is on a major network. For those of you who don't know networking, I am creating detailed instructions that will be released shortly after Break. Stay tuned to this mailing list for the announcement. One of the following network addresses should allow remote users to reach Oberlin. "_______" stands for your username. cmccvb::in%"@_______@ocvaxa" cmccvb::in%"@_______@ocvaxb" cmccvb::in%"@_______%ocvaxa" cmccvb::in%"@_______%ocvaxb" _______@ocvaxa.ccnet _______@ocvaxb.ccnet _______%ocvaxa@vb.cc.cmu.edu _______%ocvaxb@vb.cc.cmu.edu _______%ocvaxa@cmccvb.bitnet _______%ocvaxb@cmccvb.bitnet _______%ocvaxa%cmccvb.bitnet@wiscvm.wisc.edu _______%ocvaxb%cmccvb.bitnet@wiscvm.wisc.edu Received: (from POSTMAST@VASSAR for XX9GOD3@UCHIMVS1 via NJE) (RSCS5384-5384; 25 LINES); Tue, 17 Feb 87 08:26:46 CST Date: Mon, 16-FEB-1987 20:16 EST Original_From: OCVAXB::STG8384 Comments: This is gatewayed mail. Warning: Mail may not necessarily be returnable through this path. From: General Delivery Subject: Is it in? Is it in? To: xx9god3 All right! FINALLY I was allowed through (I think) This is T. (Tom) Geller, the student who stayed with you at UC this past weekend, testing out the gateway at VASSAR. According to my instructions, the only way that you could get back to me is NOT through VASSAR, but through a node at Columbia called CUCHM. However, according to my system, there is no such node. If CUCHM will not let you through (or doesn't exist), I would suggest trying a node at Vassar, Case Western, or Carnegie Mellon. ----------------------------------------------- I've tried lotsa combinations of the above but still am having trouble. ANY ONE who can help me please lend a hand... my addresses are below. Peter Godwin | ...ihnp4!gargoyle!sphinx!god3 Univ. of Chicago Comp Ctr | x9.xpg@uchicago 5824 S. Kimbark Ave, #2419 | god3%sphinx@uchicago Chicago, IL 60637 | Phone #: 312-288-1816 Message-ID: #568.pnet01.digest/info-nets 40 lines, 1199 chars. Reply-To: crash!MC.LCS.MIT.EDU:!OZ.AI.MIT.EDU:!MC.LCS.MIT.EDU:jshaver Date: Mon, 4 May 87 11:00:08 EDT From: John Science Fiction & Resume Service Shaver To: info-nets%mit-oz@mc.lcs.mit.edu Subject: [APG-5 Memo Service: Waiting mail (msg.a001432)] Is there a description of that the ! % etc stand for or cause to happen in the address line? Could you help me find the address on the original message? Thanks in advance John ----- Forwarded message # 1: Date: Sun, 3 May 87 4:10:07 EDT From: APG-5 Memo Service (MMDF 4/84) Subject: Waiting mail (msg.a001432) Sender: mmdf@APG-5 To: jshaver@apg-5 After 3 days (61 hours), your message has not yet been fully delivered. Attempts to deliver the message will continue for 8 more days. No further action is required by you. Delivery attempts are still pending for the following address(es): @cs.ucl.ac.uk,@cs.ucl.ac.uk:music-research-request%prg.oxford.ac.uk@cs.ucl.ac.uk (host: cs.ucl.ac.uk) (queue: smtp) Problems usually are due to service interruptions at the receiving machine. Less often, they are caused by the communication system. Your message begins as follows: Date: Thu, 30 Apr 87 14:25:55 EDT From: John "Science Fiction & Resume Service" Shaver To: music-research-request%prg.oxford.ac.uk@cs.ucl.ac.uk Subject: Add to list Please add me to the list. Thanks ... ----- End of forwarded messages Message-ID: #570.pnet01.digest/info-nets 26 lines, 1396 chars. Date: 4 May 87 18:26:00 EST From: "1159-DIRECTOR/OVERSEAS OP" Subject: Internet Mail To: "jshaver" Reply-To: "1159-DIRECTOR/OVERSEAS OP" Reference: Date: Mon, 4 May 87 11:00:08 EDT From: John Science Fiction & Resume Service Shaver To: info-nets%mit-oz@mc.lcs.mit.edu Subject: [APG-5 Memo Service: Waiting mail (msg.a001432)] Q:Is there a description of that the ! % etc stand for or cause to happen in the address line? A:Can't find "!" in any address line of your message. It is most likely an internal signal to your host computer, as it is to mine. The "%" is a divider between a username or mailbox (music-research-request) and a hostname (prg.oxford.ac.uk). Since that host is not on the ARPANET, the address calls for routing your mail via another host (cs.ucl.ac.uk, at the Dept. of Computer Science, University College, London) which can be reached via ARPANET. Q:Could you help me find the address on the original message? A:The address on the original message is the entry on the "To:" line, to wit, To: music-research-request%prg.oxford.ac.uk@cs.ucl.ac.uk If you have more questions about the address format, as opposed to address content, of internet mail, suggest you first communicate directly with your host administrator, Robin DeFranks, who is probably best equipped to connect you with sources of information on your particular host. As the header of this message will probably tell you, a copy has been sent to . ------ Message-ID: #571.pnet01.digest/info-nets 31 lines, 1333 chars. Date: 4 May 87 21:01:00 EST From: "1159-DIRECTOR/OVERSEAS OP" Subject: Path to Oberlin To: "god3" Reply-To: "1159-DIRECTOR/OVERSEAS OP" REFERENCE: Subject: HELP me... gateway prob Date: 04 May 87 16:14:38 CDT (Mon) From: Peter Godwin >I have been receiving mail from a friend who is at oberlin but can't seem to >get stuff to him. CUCHM is a listed (as of early April) BITNET node at the Columbia U. Chemistry Dept. but since all of his mail has come to you through the Carnegie Mellon Computation Center node CMCCVB, it would seem more productive to work on that. Your mail to Info-Nets came through BITNET, and one of his messages had an entry reading Return-Path: <"OCVAXA::STG8384"@CMCCVB.BITNET>, so suggest you first try either STG8384%ocvaxa@cmccvb.bitnet STG8384%ocvaxb@cmccvb.bitnet or STG8384@ocvaxa.cmccvb.bitnet STG8384@ocvaxb.cmccvb.bitnet If they don't work, then, since one of the messages you got from him had the line X-VMS-To: CMCCVB::IN%"x9.xpg@uchicago", you might try cmccvb::in%"STG8384@ocvaxa" cmccvb::in%"STG8384@ocvaxb" Unfortunately, host tables available to me show little about a node "vb" at CMU-CC, although they show several others, such as "vd", "ta"-"tf", etc. If none of the above work, then try sending a query to Eric.Crane@c.cs.cmu.edu or else calling him at (412)268-3568. ------ Message-ID: #572.pnet01.digest/info-nets 15 lines, 320 chars. Date: 4 May 87 21:51:00 EST From: "1159-DIRECTOR/OVERSEAS OP" Subject: Path to Oberlin, Part II To: "god3" Reply-To: "1159-DIRECTOR/OVERSEAS OP" REFERENCE: My message of a few minutes ago. One other combination to try would be STG8384@ocvaxa@cmccvb.bitnet STG8384@ocvaxb@cmccvb.bitnet or you could send an inquiry to one of the following postmaster@cmccvb.bitnet netmgr@cmccvb.bitnet ------ From ncr-sd!ncrcae!ece-csc!mcnc!seismo!ll-xn!mit-eddie!jbs Mon May 11 06:46:11 PDT 1987 In article <749@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >Smail uses sendmail, right? How does smail persuade sendmail to put >different things in the From_ and From: lines? I never managed to make >sendmail change the From_ line without changing the From: line at the >same time. It doesn't. The fix is to change sendmail.cf so that it _doesn't_ do anything to either the From_ or From: lines. The message then goes through smail, which doesn't touch the From: line. If you are a uucp-only site, there is an option to smail to skip sendmail altogether (smail replaces rmail, so it can process incoming message directly if they aren't going to go somewhere other than uucp). >What if it isn't in domain format originally? What happens to mail >that was really truly sent to a bang address? If your machine processes mail from/to a network that adheres to the rfc822 mail standard, then mail that originates at your host, but is transported elsewhere on the net should contain a From: line of the form: From: localpart@domainpart Where domainpart is your hostname, and localpart is something that can be interpreted by your mail software. So mail coming from uucp, in non-domain format, going to the other net should have its From: line modified by appending an "@" and your hostname: From: uucp-path-from-host-abc.com@abc.com If the mail is coming from uucp, and going to uucp (through your machine), you have the option of using a From: line of the above form, or prepending your hostname and a "!". As long as the message stays within uucp, path-format From: lines are fine. At sites like this one, where many networks are involved, we chose put non-domain format >From: lines into domain format (i.e. append @hostname) whenever they are leaving the machine, which is legal according to everybody's standards. >Wheredo we get a fix to just this problem, without dragging in all the >rest of smail? You don't. At least not with sendmail. Smail isn't that bad, though (and doesn't take very long to install): % size /bin/smail text data bss dec hex 23552 5120 15844 44516 ade4 % Jeff From ncr-sd!ncrcae!ece-csc!mcnc!xanth!kyle Mon May 11 06:46:43 PDT 1987 In <749@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes: > Smail uses sendmail, right? How does smail persuade sendmail to put > different things in the From_ and From: lines? I never managed to make > sendmail change the From_ line without changing the From: line at the > same time. No persuasion is necessary. Let's think this through... General Scenario: UUCP thru mail arrives at site snarf. rmail invokes sendmail as sendmail -ffoo!bar!sender mumble!scream!recipient The relevant message headers are: From foo!bar!sender From: sender@sushi.bar.com It is sendmail's job to convert this combined input into a call to uux: /usr/bin/uux - mumble!rmail '(scream!recipient)' with the relevant headers modifed to be From foo!bar!sender remote from snarf From: sender@sushi.bar.com Notice is that NOWHERE is snarf! prepended to an address. (!) It will be prepended to the From_ address by the NEXT host's (mumble's) rmail. Thus sendmail can leave the addresses in both From_ and From: alone. All sendmail has to do is add the "remote from host" part, and indeed there is a mailer flag that causes sendmail to do just that. > > All the standards (822, 976) explicitly say you leave the From: line > > in domain format - it is not and was never a bang path. > > What if it isn't in domain format originally? What happens to mail > that was really truly sent to a bang address? There is no such thing as a bang address. Bang syntax is a form of ROUTING, and as such belongs in the message envelope, not in the message headers. The From_ line is not a header, it is part of the message envelope. > Where do we get a fix to just this problem, without dragging in all the > rest of smail? Again, sendmail will already generate the From_ lines with the "remote from host" stuff on the end, so what else is there to do? All you have to do is make sure your configuration does not alter bang routes and be sure the 'U' flag is part of the mailer definition that invokes uux (I'm sure it is already). So you don't HAVE to have smail to be able to conform to the standard. But the program is already written, works, and is GREAT! Why NOT use it?? Could it be that you enjoy hand-routing all your UUCP mail? kyle jones old dominion university, norfolk, va From ncr-sd!hp-sdd!hplabs!sri-unix!rutgers!ames!ptsfa!vixie!paul Mon May 11 06:49:11 PDT 1987 In article <748@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <600@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) writes: >>In article <16238@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes: >>>[just tack on host! and use rmail and] [M]ail will go through >>>because it's worked this way for years. > >> Mail *may* go through because of all the people between you and your >> mailee who are running broken and non-standard software. > >Is software "broken" because it accepts some things which do not >Conform to the Standard? (Note: "accepts", not "does".) We are having a communication problem, I think. If u1@a sends mail to u2@d, and the mailer decides to route the message as b!c!d!u2 because 'd' is a UUCP site and b!c!d is the shortest path... First, let's say that a, b, and d all conform to the RFC pseudo-standards, and do not modify 'From:' addresses, but that 'c' is running some mailer that prepends hostname! onto the front of the address in the From: lines. Further assume that of all these hosts, only 'a' has an autorouter running. Last, let's leave operator precedence out of this for a moment, and assume that h!u were acceptable in place of u@h. Ok? So, at each host, the From: address LEAVES THE MACHINE looking like this: host From: From_ ---- ----- ----- 'a' a!u1 a!u1 'b' a!u1 b!a!u1 'c' c!a!u1 c!b!a!u1 'd' c!a!u1 (n/a) When u2@d tries to REPLY to this message, the mail will bounce back from 'c' since 'c' doesn't speak to 'a'... "Bad system name: 'a'". Note that the From_ line is in *fine* shape, usually. Replying to that will usually work well, if inefficiently. Gateways can be a pain, too, but on the whole: it will work. If the From: line would just arrive in it's original form, and the replying machine (either the final destination or some complainer along the path) can do a path lookup on the From: address and send the mail back. If it doesn't run an autorouter, it can use the From_ address. Since the From: line will normally arrive bungled and mangled, direct routing will usually not work, and autorouting to the first (or last) host in the path is very likely to result in more bungling and mangling. So, yeah, you can accept non-conforming mail and do constructive things with it -- without violating the spirit of the standard. I don't know what the standards say you are supposed to do with evil addresses -- but I personally feel that an evil address should be stopped where discovered, and sent home to momma to get dressed right before being sent out into the world. Yes, this would result in more mail being returned undeliverable even than occurs in the current mixed-mode mailing scheme we have -- but we would see more mailers standardized in less time under such a policy than under any other I've heard suggested. -- Paul A. Vixie {ptsfa, crash, winfree}!vixie!paul 329 Noe Street dual!ptsfa!vixie!paul@ucbvax.Berkeley.EDU San Francisco CA 94116 paul@vixie.UUCP (415) 864-7013 From ncr-sd!ncrcae!ece-csc!mcnc!seismo!ll-xn!mit-eddie!jbs Mon May 11 06:51:48 PDT 1987 In article <749@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >Smail uses sendmail, right? How does smail persuade sendmail to put >different things in the From_ and From: lines? I never managed to make >sendmail change the From_ line without changing the From: line at the >same time. It doesn't. The fix is to change sendmail.cf so that it _doesn't_ do anything to either the From_ or From: lines. The message then goes through smail, which doesn't touch the From: line. If you are a uucp-only site, there is an option to smail to skip sendmail altogether (smail replaces rmail, so it can process incoming message directly if they aren't going to go somewhere other than uucp). >What if it isn't in domain format originally? What happens to mail >that was really truly sent to a bang address? If your machine processes mail from/to a network that adheres to the rfc822 mail standard, then mail that originates at your host, but is transported elsewhere on the net should contain a From: line of the form: From: localpart@domainpart Where domainpart is your hostname, and localpart is something that can be interpreted by your mail software. So mail coming from uucp, in non-domain format, going to the other net should have its From: line modified by appending an "@" and your hostname: From: uucp-path-from-host-abc.com@abc.com If the mail is coming from uucp, and going to uucp (through your machine), you have the option of using a From: line of the above form, or prepending your hostname and a "!". As long as the message stays within uucp, path-format From: lines are fine. At sites like this one, where many networks are involved, we chose put non-domain format >From: lines into domain format (i.e. append @hostname) whenever they are leaving the machine, which is legal according to everybody's standards. >Wheredo we get a fix to just this problem, without dragging in all the >rest of smail? You don't. At least not with sendmail. Smail isn't that bad, though (and doesn't take very long to install): % size /bin/smail text data bss dec hex 23552 5120 15844 44516 ade4 % Jeff From ncr-sd!ncrcae!ece-csc!mcnc!xanth!kyle Mon May 11 06:52:58 PDT 1987 In <749@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes: > Smail uses sendmail, right? How does smail persuade sendmail to put > different things in the From_ and From: lines? I never managed to make > sendmail change the From_ line without changing the From: line at the > same time. No persuasion is necessary. Let's think this through... General Scenario: UUCP thru mail arrives at site snarf. rmail invokes sendmail as sendmail -ffoo!bar!sender mumble!scream!recipient The relevant message headers are: From foo!bar!sender From: sender@sushi.bar.com It is sendmail's job to convert this combined input into a call to uux: /usr/bin/uux - mumble!rmail '(scream!recipient)' with the relevant headers modifed to be From foo!bar!sender remote from snarf From: sender@sushi.bar.com Notice is that NOWHERE is snarf! prepended to an address. (!) It will be prepended to the From_ address by the NEXT host's (mumble's) rmail. Thus sendmail can leave the addresses in both From_ and From: alone. All sendmail has to do is add the "remote from host" part, and indeed there is a mailer flag that causes sendmail to do just that. > > All the standards (822, 976) explicitly say you leave the From: line > > in domain format - it is not and was never a bang path. > > What if it isn't in domain format originally? What happens to mail > that was really truly sent to a bang address? There is no such thing as a bang address. Bang syntax is a form of ROUTING, and as such belongs in the message envelope, not in the message headers. The From_ line is not a header, it is part of the message envelope. > Where do we get a fix to just this problem, without dragging in all the > rest of smail? Again, sendmail will already generate the From_ lines with the "remote from host" stuff on the end, so what else is there to do? All you have to do is make sure your configuration does not alter bang routes and be sure the 'U' flag is part of the mailer definition that invokes uux (I'm sure it is already). So you don't HAVE to have smail to be able to conform to the standard. But the program is already written, works, and is GREAT! Why NOT use it?? Could it be that you enjoy hand-routing all your UUCP mail? kyle jones old dominion university, norfolk, va From ncr-sd!hp-sdd!hplabs!sri-unix!rutgers!ames!ptsfa!vixie!paul Mon May 11 06:53:49 PDT 1987 In article <748@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <600@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) writes: >>In article <16238@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes: >>>[just tack on host! and use rmail and] [M]ail will go through >>>because it's worked this way for years. > >> Mail *may* go through because of all the people between you and your >> mailee who are running broken and non-standard software. > >Is software "broken" because it accepts some things which do not >Conform to the Standard? (Note: "accepts", not "does".) We are having a communication problem, I think. If u1@a sends mail to u2@d, and the mailer decides to route the message as b!c!d!u2 because 'd' is a UUCP site and b!c!d is the shortest path... First, let's say that a, b, and d all conform to the RFC pseudo-standards, and do not modify 'From:' addresses, but that 'c' is running some mailer that prepends hostname! onto the front of the address in the From: lines. Further assume that of all these hosts, only 'a' has an autorouter running. Last, let's leave operator precedence out of this for a moment, and assume that h!u were acceptable in place of u@h. Ok? So, at each host, the From: address LEAVES THE MACHINE looking like this: host From: From_ ---- ----- ----- 'a' a!u1 a!u1 'b' a!u1 b!a!u1 'c' c!a!u1 c!b!a!u1 'd' c!a!u1 (n/a) When u2@d tries to REPLY to this message, the mail will bounce back from 'c' since 'c' doesn't speak to 'a'... "Bad system name: 'a'". Note that the From_ line is in *fine* shape, usually. Replying to that will usually work well, if inefficiently. Gateways can be a pain, too, but on the whole: it will work. If the From: line would just arrive in it's original form, and the replying machine (either the final destination or some complainer along the path) can do a path lookup on the From: address and send the mail back. If it doesn't run an autorouter, it can use the From_ address. Since the From: line will normally arrive bungled and mangled, direct routing will usually not work, and autorouting to the first (or last) host in the path is very likely to result in more bungling and mangling. So, yeah, you can accept non-conforming mail and do constructive things with it -- without violating the spirit of the standard. I don't know what the standards say you are supposed to do with evil addresses -- but I personally feel that an evil address should be stopped where discovered, and sent home to momma to get dressed right before being sent out into the world. Yes, this would result in more mail being returned undeliverable even than occurs in the current mixed-mode mailing scheme we have -- but we would see more mailers standardized in less time under such a policy than under any other I've heard suggested. -- Paul A. Vixie {ptsfa, crash, winfree}!vixie!paul 329 Noe Street dual!ptsfa!vixie!paul@ucbvax.Berkeley.EDU San Francisco CA 94116 paul@vixie.UUCP (415) 864-7013 From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!ll-xn!husc6!seismo!mcvax!enea!liuida!lel Thu May 21 11:24:48 PDT 1987 In article <2767@meccts.MECC.MN.ORG> ahby@meccts.UUCP (Shane P. McCarron) writes: > In article <559@smidefix.liu.se> lel@ida.liu.se (Lennart Lovstrand) writes: > All sorts of excellent information about routing and routing > symbols... > > Now, since "%" is the natural routing operator on top of "@", an > > address like: > > node1!user@node2 > > that is autorouted through "node3" will probably end up looking as: > > node1!user%node2@node3 > > meaning: > > node3 ->node2 ->node1 ->user > > It seems to me that undef RFC 976, something autorouted through "node3" > should be transmitted as: > node2!node1!user@node3 Not if node2 is an ARPANET node, say, that doesn't subscribe to RFC976. Remember that RFC976 means "UUCP Mail Interchange Format". Even though neither "!" nor "%" is an official routing operator for RFC822 complying nodes, I would say that the latter is much more frequent than the former. > Also, since "node2" started life after an @, it must by definition have a > domain suffix attached to it. So, if th initial address had been: > [...] Well, yes, I was thinking of both node2 and node3 as domains, thanks for pointing it out. Still, that doesn't necessarily mean that they have a dot in them. RFC920 explictly states that a multiorganization could become a top level domain, which means that you might wind up with addresses like "TheSecretaryGeneral@UN". Cheers, --Lennart -- Dept of Computer and Information Science, University of Linkoping, Sweden Internet: Lennart.Lovstrand@IDA.LiU.SE EAN/X.400: lel@ida.liu.sunet UUCP: {mcvax,munnari,seismo}!enea!liuida!lel EARN/BITNET: LEL@SELIUI51 -- Dept of Computer and Information Science, University of Linkoping, Sweden Internet: Lennart.Lovstrand@IDA.LiU.SE EAN/X.400: lel@ida.liu.sunet UUCP: {mcvax,munnari,seismo}!enea!liuida!lel EARN/BITNET: LEL@SELIUI51 From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!ucbcad!ucbvax!BINGVAXA.BITNET!TBLAKE Thu May 21 11:39:47 PDT 1987 Net-Landers, I am sending this note ... To: info_vax Before getting into mail I issued ... $ ASSIGN info_vax "ARPA%""info-vax@sri-kl.ARPA""" Usually for BITNET friends I do $ ASSIGN friend's-name "JNET%""UserID@Node""" It took a little experimenting, but if you think about it, it makes sense. Thomas R. Blake SUNY Binghamton From ncr-sd!ncrcae!hubcap!gatech!hao!husc6!think!ames!ucbcad!ucbvax!MITRE-BEDFORD.ARPA!m18171%mbvms Mon Jun 1 13:15:52 PDT 1987 Here's another solution to the VMS long mail address problem. 1) Create a distribution file: mail_distribution_dir:info-vax.dis which contains the line netmail::"info-vax@kl.sri.com" 2) Define a logical pointing to the distribution file: $ define info-vax "@mail_distribution_dir:info-vax.dis" NOTE: you must use the "" in the log def due to the '@' Including the "@" in the logical def allows users to send mail as if they are sending it down the hall. By putting the long address in a file, I get around the quotes problem in the address while making a logical def. One of duties is to manage a CAE facility, and little items like this help to lessen the load of answering questions for a group of engineers that in some cases don't have a lot of computer expertise. Especially since I have a lot of engineering duties myself. joek -- Joe Kagenski jjk@mitre-bedford.arpa (alt: jjk%vhsic@mitre-bedford.arpa or {decvax, ...}linus!jjk ) (Tel: 617-271-7745 (lab: 3460)) The MITRE Corporation; VHSIC Technical Center - CAE Section MS E095; Burlington Road; Bedford, Ma. 01730 From ncr-sd!ncrcae!ece-csc!mcnc!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!NMFECC.ARPA!MCCALPIN%FSU.MFENET Mon Jun 1 13:21:24 PDT 1987 We have a VMS machine acting as a communications gateway between our many mostly incompatible campus nets, and we have an ULTRIX machine to act as a DECNET to TCP/IP gateway. The ULTRIX machine is running the standard (DEC supplied ?) generic ARPA sendmail configuration file. I have figured out how to send mail from DECNET to SMTP mailers: ULTRIX_host::"name@UNIX_host" (An extra set of quotes is needed if this is to be used as a forwarding address). The big question is how to send mail the other way. I have tried every conceivable combination of "DECNET_host::name"@ULTRIX_host that I can think of, but the ARPA address parser converts the :: to .. before it can realize that it wants to send the address to the Mail-11 program. Any helpful hints would be appreciated. Please reply directly, as I do not usually read this list. john d mccalpin mccalpin@fsu.mfenet mcalpin@fsu.bitnet (mccalpin%fsu.mfenet@nmfecc.arpa) From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!ucbcad!ucbvax!NMFECC.ARPA!MCCALPIN%FSU.MFENET Mon Jun 1 13:31:54 PDT 1987 Thanks for the many helpful replies. I got the system working by the following tricks: (1) I turned off the : to . conversion in the sendmail.cf files of the SMTP (non-gateway) machines. (I have never seen the : used in an ARPANET address, maybe it is an old syntax) (2) I added a rule in the gateway machines sendmail.cf like # Mail-11 rules R$+::$+@gateway_name $@$1::$2 # strip gateway name Now from SMTP to DECNET goes like: decnet_node::user_name@ultrix_gateway and mail from DECNET to SMTP goes like ultrix_gateway::"user_name@unix_node" Amazingly enough, REPLY works in both directions. I just hope that I don't need that : to . translation when our gateway comes up on the ARPANET in a few months.... john mccalpin mccalpin@fsu.mfenet mcalpin@fsu.bitnet (mccalpin%fsu.mfenet@nmfecc.arpa) From ncr-sd!ncrcae!hubcap!gatech!ukma!david Sat Jun 6 22:00:43 PDT 1987 In article <1217@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >1. ... > the UUCP Project does not keep the map current (I'm not blaming > them, it's a tough job), it is out of date on the day it's posted. *grin*, we try... There's times I'm glad I only take care of KY. :-) >2. REROUTE believes that there are no duplicate UUCP names. ... > > To use Phil Ngai's example, there is an AT&T site named neptune > and an AMD site named neptune. But there's no name conflict; > the AMD site neptune does not appear in the UUCP map and its official > name is neptune.amd.com. If someone mails to amdcad!neptune!user, > this is a different neptune than the AT&T one, and mailers shouldn't > be f*king with the address. This is the part I couldn't let pass by. If amdcad wants to have their neptune able to send and receive mail without hassles, then they should arrange it so that mail will be sent to amdcat!neptune.amd.com!user. (i.e. putting that out in headers when mail is sent out, announcing in the maps either the existance of a gateway for .amd.com or the existance of neptune.amd.com itself, etc). If they do anything else, they're asking for trouble. >3. You make it impossible for users to avoid machines that are down. > ihnp4, for example. Somebody posts a message "avoid ihnp4" but > there's no way any of your users can. My own strategy is to route to the first host mentioned in the path which I am given. This is merely a convenience, so that if I have some address from a well-known-site, then I don't *have* to find the path to that well-known-site. Looking down the path beyond the first site is not kosher because you don't *know* if those names you see there actually refer to the ones you have in your database. That is, unless you do some edge analysis a la peter honeyman. To be honest tho.... I don't quite practice what I just preached. I run MMDF here, and the uucp channel sort-of breaks those rules. When it receives a message it collapses the From_'s, looks down that path for sites in its' data base (assuming only .uucp places) and stops at the first one it doesn't know. Then it re-writes the header so that the From: says unk1!unk2!...!user@known.UUCP. For the rmail arguments it does exactly what I describe above. I don't quite agree with its strategy, but I don't have the time to change it... >4. You make it impossible to test specific UUCP connections with loop > tests. I would go along with this, however I haven't needed to do this for at least a year. I can't even remember the last time I had to do this. And I am a heavy user of e-mail. -- ----- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet ----- (also "postmaster", "news", and the Usenet map maintainer for Kentucky.) ----- bsmtp-users@ms.uky.csnet for bsmtp discussion ----- bsmtp-users-request@ms.uky.csnet for administrivia From crash!bblue Wed Oct 14 15:56:14 1987 Received: by crash.CTS.COM (5.54/UUCP-Project/rel-1.0/09-14-86) id AA29864; Wed, 14 Oct 87 15:45:47 PDT Date: Wed, 14 Oct 87 15:45:47 PDT From: crash!bblue (Bill Blue) Reply-To: crash!bblue X-Mailer: Mail User's Shell (Vers 5.7) Sun Sep 6 19:10:48 PDT 1987 Ppath: pnet01!jeh To: pnet01!jeh Subject: double checks My comments: Hi, Tom, You write: > RFC822 describes headers which must be present, in a particular order... It was my understanding that the order was not completely significant, that mailers were just supposed to slurp all the headers in and then parse them to see what's there, and that we usually see headers in the same order because most mailers generate them that way. But of course I could be mistaken. I think this is basically correct. There is supposed to be a general order to follow, but in practice nothing much matters except the From_ lines. > UUCP is a "user specified route" type of system ... > I assume that PMDF is writing RFC822 format messages yes, it is > and presenting the addresses as-is to the network agent (channel?). No, it has a rather elaborate address rewriter, based mostly on @-notation but with support for !- and ::- and %- conventions as well. It can pass the addresses as-is, but also can do rewrites. BUT, I'm not sure yet if it'll do everything that pathalias will do; even if it will, I'm not sure if it should replace pathalias. Its configuration file looks different from pathalias's -- since the code to translate uucp maps into pathalias maps already exists, why should we rewrite it to generate PMDF rewrite rules, if you've already got pathalias working on VMS? All that pathalias does is produce a database. That database is consulted only for simple path lookup to find a complete route to a given site. The guy that actually does syntax resolving, integrates pathing with the pathalias database, and all that happy stuff, is 'smail'. > When we present anything to uucico we must have already figured out the entire > path to `host'. Not so, according to my understanding of things. We must only tell uucico the next hop in the path. For instance, the public-access system I live on (crash.cts.com) can readily accept mail with incomplete addresses from other nodes. Smail (at least I think it's running smail) can expand incomplete addresses, translate domain addresses to bang-path, etc., whether the mail originated at crash or is just passing through. You're both right. uucico expects to have sufficient information present for it to pass mail on to the site to which the mail is queued. So as far as this goes, he is correct. You are correct that the remainder of the path doesn't have to be complete, but that isn't really what he was asking, as viewed from uucico's perspective. This makes things very convenient if you don't want to bother running pathalias and all of that -- just find a neighboring site who does, and let them do routing for you (hopefully you've asked them first :-)). You can then send to anybody [who's in their map] by sending to While it's polite to ask, it isn't mandatory unless huge amounts of traffic are expected. A site that does such routing will have the routing software installed. By that much alone, they are accepting a role of their connectivity. Since routes that are in the database will undoubtedly include them and their connectivity, by providing that information, they have accepted the likelihood that their machine will gateway for others. router!ultimate-destination!user This also works if you need to specify a few intermediate hops to get to router, e.g. neighbor!n2!n3!router!ultimate-destination!user the node called router will expand the rest of the address if it doesn't have a direct path to ultimate-destination. There's another rule that applies if there's an internet address in the bangpath. If you send to an address like a!b!c!d!user@system.site.domain it goes to a, then b, etc., until it hits a site that understands @-addresses. If this happens to be b, the address effectively becomes a!b!system.site.domain!c!d!user Which is to say, b hands it to internet; eventually it reaches system.site.domain, who then sends it to c, etc. If we had grouping operators, the address would look like a!b!(c!d!user@system.site.domain) but only because it's b who interprets the internet address. All correct. > 2) we need to expand mail addresses so that they may be delivered to > the appropriate place. PMDF probably doesn't do this since that is > really the job of the network agent. > >This would indicate that even for PMDF, our uucp channel will have to do >the path rewriting. Well, as noted above, it may not HAVE to, but it might be less work in the long run if it did. The transport mechanism, whatever it is, should be handed a complete route by some other service provider. It should (blindly) follow the routing information provided. >smail's approach is to replace rmail performing a) path rewriting and b) RFC822 >header insertion when the headers are not present. It would seem that what I >want to do is to port smail to VMS as a replacement for rmail. I assume that >gnuuucp is constructed similarly to Unix uucp - ie there is an rmail task. Yep, there sure is. You know better than I in this... >smail would write the RFC822 headers only when they came from the gnu mail >interface, not from the PMDF interface since PMDF already put them there. >In either case, it would expand the domain style addressing into the >appropriate path. As far as I know, smail is PD but I will recheck that fact. I'm pretty sure it is. Bill Blue can tell me. I don't know if it's pd, but it's free and its circulation and use is encouraged. >Am I making any sense? Are my assumptions about PMDF and gnuuucp correct? I think so. I'm going to copy Bill Blue, proprietor of crash and local uucp guru, on all this stuff and see what he thinks. He shouldn't mind too much, because the sooner we get this stuff going the sooner I won't be tying up his phone line for hours reading news and and mail. [Hi, Bill!] Uh, hello! GET BACK TO WORK!! (sound of whip snapping) >This whole thing gets somewhat confusing. You're telling me!!! I'm not even sure of the relationship between smail and pathalias... I assume that smail invokes pathalias? No. smail and rmail are the same program with different names (one is linked to the other). In a normal mode, smail is invisible, it acts like rmail and tries to deliver to uucico via uux in its normal mail delivery mode. If uux fails because the site is unknown, it comes back, invokes smail and does a database lookup substituting the derived path for the defective one and resends. This is true for a pure ! path. However, if the path is originally named as a @ path, smail is called for lookup before delivery attempt, and substitutes a correctly formatted pure ! path. On a site that understands @ routing and is running smail, only ! paths are ever produced in a transport route. Now, pathalias's only job in life is to produce the routing database that smail uses. You feed it the worlds (2.5mb) worth of map info and it spits out a database. (mine is in /usr/lib/uucp/paths). Pathalias only needs to be invoked when a new bunch of maps are present, to update the local database. --Bill From crash!edison.GE.COM!ta2 Tue Oct 13 21:45:42 1987 Received: by crash.CTS.COM (5.54/UUCP-Project/rel-1.0/09-14-86) id AA23868; Tue, 13 Oct 87 21:38:12 PDT Reply-To: crash!edison.GE.COM!ta2 Received: from seismo.CSS.GOV by uxc.cso.uiuc.edu with SMTP (UIUC-5.52/9.7) id AA01675; Tue, 13 Oct 87 14:23:02 CDT Received: from uunet.UU.NET by seismo.CSS.GOV (5.54/1.14) id AA00330; Tue, 13 Oct 87 15:22:29 EDT Received: from hadron.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA06975; Tue, 13 Oct 87 15:22:20 EDT Received: by hadron.UUCP (4.12/4.7) id AA05184; Tue, 13 Oct 87 15:19:00 est Received: by decuac.dec.com (1.2/smail2.2/03-11-87) id AA07402; Mon, 12 Oct 87 07:26:33 edt Received: by edison.GE.COM (4.12/UUCP-Project/rel-1.0/edison.GE.COM/1.8) id AA18986; Mon, 12 Oct 87 07:25:10 edt Date: Mon, 12 Oct 87 07:25:10 edt From: tom allebrandi Message-Id: <8710121125.AA18986@edison.GE.COM> Ppath: pnet01!jeh To: jeh@pnet01.cts.com Subject: RFC822 Jamie - I remembered last night that RFC822 is more than just a way of formatting mail addresses; it's a way of life :=). Seriously, while the addressing format is important to RFC822, so is the format of the entire message. RFC822 describes headers which must be present, in a particular order, and the format of the message body (ends with a . in column 1 unless it there are two .'s in 1/2.) Presenting a mail message to an internet gateway without the requisite headers is supposed to cause the mail to be punted. It if hits ARPAnet without the headers it will definitely be punted. (At least this is my understanding of what is supposed to happen.) ===== The problem with UUCP is that it is a "user specified route" type of system as opposed to DECnet and ARPAnet which have the network do the routing. I assume that PMDF is writing RFC822 format messages and presenting the addresses as-is to the network agent (channel?). As I noted above, for DECnet, ARPAnet, CSnet, TCP/IP networks there is no such thing as a path from the users point of view. user-address-or-path@host is delivered to `host' who then figures out what to do with `user-address-or-path'. When we present anything to uucico we must have already figured out the entire path to `host'. As you know, the next intermediate host is given in the name of the C.HOSTnnnn file, with the rest of the path being specified in the commands therein. (IE mail a!b!c!s creates C.a1234 containing a reference to an X.a1234 file that contains an `rmail b!c!s' command. I think that this is right) ===== This means that we have two problems to resolve for RFC822 compatability - 1) we need the mail messages in RFC822 format - which PMDF will do. 2) we need to expand mail addresses so that they may be delivered to the appropriate place. PMDF probably doesn't do this since that is really the job of the network agent. This would indicate that even for PMDF, our uucp channel will have to do the path rewriting. smail's approach is to replace rmail performing a) path rewriting and b) RFC822 header insertion when the headers are not present. It would seem that what I want to do is to port smail to VMS as a replacement for rmail. I assume that gnuuucp is constructed similarly to Unix uucp - ie there is an rmail task. smail would write the RFC822 headers only when they came from the gnu mail interface, not from the PMDF interface since PMDF already put them there. In either case, it would expand the domain style addressing into the appropriate path. As far as I know, smail is PD but I will recheck that fact. ===== Am I making any sense? Are my assumptions about PMDF and gnuuucp correct? This whole thing gets somewhat confusing. ====== Tom ta2@edison.ge.com Hi, Tom, Thanks for your mail. I too grabbed the new pathalias code (incidentally, there was a repost that appeared here this morning, since part 2 of the original post was apparently munged at some point in the net; do you need the repost/did you get it?). As for your second letter... > RFC822 describes headers which must be present, in a particular order... It was my understanding that the order was not completely significant, that mailers were just supposed to slurp all the headers in and then parse them to see what's there, and that we usually see headers in the same order because most mailers generate them that way. But of course I could be mistaken. > UUCP is a "user specified route" type of system ... > I assume that PMDF is writing RFC822 format messages yes, it is > and presenting the addresses as-is to the network agent (channel?). No, it has a rather elaborate address rewriter, based mostly on @-notation but with support for !- and ::- and %- conventions as well. It can pass the addresses as-is, but also can do rewrites. BUT, I'm not sure yet if it'll do everything that pathalias will do; even if it will, I'm not sure if it should replace pathalias. Its configuration file looks different from pathalias's -- since the code to translate uucp maps into pathalias maps already exists, why should we rewrite it to generate PMDF rewrite rules, if you've already got pathalias working on VMS? > When we present anything to uucico we must have already figured out the entire > path to `host'. Not so, according to my understanding of things. We must only tell uucico the next hop in the path. For instance, the public-access system I live on (crash.cts.com) can readily accept mail with incomplete addresses from other nodes. Smail (at least I think it's running smail) can expand incomplete addresses, translate domain addresses to bang-path, etc., whether the mail originated at crash or is just passing through. This makes things very convenient if you don't want to bother running pathalias and all of that -- just find a neighboring site who does, and let them do routing for you (hopefully you've asked them first :-)). You can then send to anybody [who's in their map] by sending to router!ultimate-destination!user This also works if you need to specify a few intermediate hops to get to router, e.g. neighbor!n2!n3!router!ultimate-destination!user the node called router will expand the rest of the address if it doesn't have a direct path to ultimate-destination. There's another rule that applies if there's an internet address in the bangpath. If you send to an address like a!b!c!d!user@system.site.domain it goes to a, then b, etc., until it hits a site that understands @-addresses. If this happens to be b, the address effectively becomes a!b!system.site.domain!c!d!user Which is to say, b hands it to internet; eventually it reaches system.site.domain, who then sends it to c, etc. If we had grouping operators, the address would look like a!b!(c!d!user@system.site.domain) but only because it's b who interprets the internet address. > 2) we need to expand mail addresses so that they may be delivered to > the appropriate place. PMDF probably doesn't do this since that is > really the job of the network agent. > >This would indicate that even for PMDF, our uucp channel will have to do >the path rewriting. Well, as noted above, it may not HAVE to, but it might be less work in the long run if it did. >smail's approach is to replace rmail performing a) path rewriting and b) RFC822 >header insertion when the headers are not present. It would seem that what I >want to do is to port smail to VMS as a replacement for rmail. I assume that >gnuuucp is constructed similarly to Unix uucp - ie there is an rmail task. Yep, there sure is. >smail would write the RFC822 headers only when they came from the gnu mail >interface, not from the PMDF interface since PMDF already put them there. >In either case, it would expand the domain style addressing into the >appropriate path. As far as I know, smail is PD but I will recheck that fact. > >Am I making any sense? Are my assumptions about PMDF and gnuuucp correct? I think so. I'm going to copy Bill Blue, proprietor of crash and local uucp guru, on all this stuff and see what he thinks. He shouldn't mind too much, because the sooner we get this stuff going the sooner I won't be tying up his phone line for hours reading news and and mail. [Hi, Bill!] >This whole thing gets somewhat confusing. You're telling me!!! Another note on pathalias: Far be it from me to dictate work style to a volunteer, but the ideal way to fix it up would be to isolate the VMS-specific stuff into its own modules; where this isn't possible, leave the original code alone and use #ifdef vms . (not vax11c, as that's defined by DEC's Ultrix C compiler as well as their VMS C compiler.) Then when we get it all working we should ship it back to the original authors and see if we can't get the vms stuff at least tacitly recognized, so that every new version of pathalias won't have to be adapted from VMS from scratch. But I'm sure you've thought of this already. Thanks again for your efforts! From ncr-sd!ncrcae!ece-csc!mcnc!rutgers!sri-spam!ames!hc!beta!cmcl2!brl-adm!adm!OWENSJ%VTVM1.BITNET@MITVMA.MIT.EDU Wed Nov 18 14:28:02 PST 1987 >I have noticed at least one mail gateway for a UUCP zone domain name that >does not do domain to uucp address conversion, but expects the non-domain >name address mail transport agents down the line to be able to interpret >domain names. Please, if you are setting up a mail exchanger (MX) entry >in an Internet domain server, remember that your mail gateway is also >responsible for doing any needed address conversion. Please be more specific about what you expect to happen, and what you're seeing. If, as I suspect, you're seeing the Internet->UUCP gateway leave the From: address in a pure domain form, then what the gateway is doing is (arguably) correct. The standard which most of the UUCP gatewaying world tried to conform to, RFC 976, specifies that the headers within the message should always remain in domain, @, form, and that only the *envelope* (the arguments to the rmail command, or the address in an SMTP RCPT TO:<...>) should be modified by the gatewaying system to adapt to network transport considerations. The receiving (UUCP) site is expected to be able to interpret domain addresses; there is widely available public domain software to do this.... There are a number of reasons that this is somewhat controversial: 1- Many mail installations set up between the advent of sendmail and the general acceptance of RFC976 would rewrite header addresses (in violation of RFC822), doing such things as prepending hostname!, creating hybrid addresses (a!b!c%d@e), etc. Many of these hosts still do so. 2- There are a large number of UUCP sites that have not installed any domain-handling software, but use programs like Berkeley Mail or System V mailx which use the From: field instead of the UUCP From_ line to reply to messages; these sites cannot reply to a pure domain address. 3- Some gateways do not agree with RFC976, preferring to use something that is more likely to work, namely rewriting addresses coming from the Internet from user@do.ma.in to gateway!do.ma.in!user, which is what you (Bill) seem to prefer. This doesn't always work, anyway, since some intermediate UUCP sites will not prepend their hostname (either they follow RFC976 or they are a truly pure UUCP site - no sendmail), and others will (sites with sendmail using the configuration file provided with the system). What I and others see as the solution is for gatewaying sites to leave addresses alone coming from the Internet to UUCP, leave addresses coming from UUCP to the Internet that are already in domain form alone, and to only change pure bang addresses coming from UUCP to the Internet, either by appending the gateway domain (host!user@gateway.org), stripping the bang path down to the last two components and turning them around to avoid hybrid addresses (user%host.UUCP@gateway.org for host!user or user%do.ma.in@gateway.org for do.ma.in!user). A variant of the latter is to turn do.ma.in!user into user@do.ma.in, and only add the gateway domain for the host!user case. All but the first of these can be dangerous, however, if the message has passed through too many gateways that have rewritten the address in too many different ways. If everyone that forwards mail via UUCP and runs sendmail, Internet gateway or not, would adopt RFC976 (and use programs like smail to help in this), we wouldn't have this mess. Since this isn't going to happen any time soon, we just have to live with it as best we can. -John Owens Virginia Tech Communications Network Services OWENSJ@VTVM1.BITNET owens@vtopus.cs.vt.edu +1 703 961 7827 john@xanth.UUCP P.S. For those of you who aren't confused enough yet :-), here's an example of the problems caused by the incompatibilities. I saw this address recently in a mailing list: From: Tom Allebrandi This originated as From: Tom Allebrandi and was sent to info-ibmpc@simtel20.arpa via UUCP: rmail unipress!rutgers!simtel20.arpa!info-ibmpc Unipress, running a vanilla 4.2BSD sendmail.cf, prepended its address, giving From: Tom Allebrandi which is already ambiguous. Rutgers, when sending it to the Internet, converted the @ to a % and added its domain, giving the address seen in the list. If USER@HOST.ARPA replied to this address, the message would go to rutgers.edu, which would most likely convert the % to an @ and give it precedence, then send to unipress!ta2 at edison.ge.com via UUCP: rmail unipress!edison!unipress!ta2 From: Joe User Unipress again prepends its address, giving rmail edison!unipress!ta2 From: Joe User Edison, since it runs smail and sees that the mail is just passing through, leaves it alone and sends it on to unipress!ta2. When unipress sees rmail ta2 the mail fails. In this example, the failure message would get back to the originator, but it is easy to find situations where it wouldn't and would end up in the mailbox of some postmaster somewhere, or, worse, in the "uucp" user's incoming mailbox on a system without an observant administator.... From ncr-sd!ncrcae!hubcap!gatech!rutgers!umd5!brl-adm!adm!OWENSJ%VTVM1.BITNET@MITVMA.MIT.EDU Wed Nov 18 14:31:19 PST 1987 >However, many (most?) of the intermediate sites are also on >the arpanet, and take @ at higher presidence than ! when routing >mail. The mail gets to my site, but the address is not correct >(contians multiple !) and gets rejected. > . . . >Here is an example header: (The @ and % are reversed in the original >To: address, but I've got others without that problem.) The problem in this case is that while there are ways to handle @-form addresses over UUCP (mail to R.LARSON@FNS1.USC.EDU, if that were a valid address, would be sent via rmail sun!lll-lcc!rutgers!cit-vax!oberon!fns1.usc.edu!r.larson and there would be no problem with it arriving (although what the headers would look like when it got there....)), there's not yet a good way to handle mixed %-@ addresses (or route-addrs). R.LARSON%FNS1@ECLA.USC.EDU would become rmail sun!lll-lcc!rutgers!cit-vax!oberon!ecla.usc.edu!r.larson%fns1 and while there are rules about !-vs-@ (@ takes precedence), there are no rules about !-vs-%. If anyone along the way gives the % precendence, it's lost. With the @-% switch in the message you gave, it gets even worse. I can't tell whether the original user typed in like that or perhaps typed multiple @-signs or something, but since the path was still in the envelope recipient, complete with its first part, sun, we can tell that the rmail command passed from portal to sun ended in either @ecla.usc.edu or %ecla.usc.edu, causing sun to send it via SMTP, never stripping anything off of the path, *and never sending it through any intermediate sites*. (If it had, those parts of the path would have been successively stripped off of the rmail line.) The fix here would have to be in portal's handling of %'s and @'s.... -John Owens Virginia Tech Communications Network Services OWENSJ@VTVM1.BITNET owens@vtopus.cs.vt.edu +1 703 961 7827 john@xanth.UUCP From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucbvax!husc6!rutgers!ukma!david Tue Nov 24 01:38:38 PST 1987 In article <408@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Hello. I'm interested in characterizing the sorts of damage that the >existing electronic mail systems can do to mail as they move it about. > > 1. Any occurrence of the string "\nFrom " has '>' inserted before > the 'F'. Actually, the "From " line at the beginning of the file is a misfeature (in this day and age ... when they came up with mail back then they weren't connected to the arpanet, rfc822 hadn't been written, and all sorts of fun things). > 2. If the string "\n.\n" occurs, the tail end of the file (starting > at the '.') is discarded. geeee ... >In addition, I know of mailers that do the following: > > 3. High-order bits are turned off (or set to parity). > 4. Null bytes are dropped. eh? both of those things aren't part of normal ascii text. Why would you expect a system which is designed for passing normal ascii text to do something reasonable with strange things. If you wanna do something like this then uuencode the file before mailing it. > 5. If a backspace occurs, it and the preceding character are deleted. > 6. ASCII tabs are expanded to some number of spaces. Weeeell... my comment above sort-of counts here. Also, different operating systems treat tabs in different ways. There is one OS around which sets tab stops at 10 columns rather than 8. Also, for some reason tabs MUST be expanded with mail (I dunno why ... it simply must). I have a vague memory that the system in question is Multics, but may be mistaken. 7. Prepending "host!" to the From: lines of mail passing through the site and going out through UUCP. This is a problem because it creates unreplyable mail. For instance, we are on the mtxinu-users@emory.edu mailing list. Before we joined the Internet we were getting our mail from the list via uucp. The mail would arrive here with headers like: From: emory!someone@utah.edu And the From: should have just been "someone@utah.edu". Depending on how we interpret the address, it will behave differently. I suppose that the people at emory wanted us to interpret ! first. However we're running MMDF and it's fairly tightly conformant to RFC-822. It'll interpret the @ first. So the message trundles off to utah.edu who is told to deliver the mail to emory!someone, which is almost certainly not right because it'll cause the mail to be delivered to Georgia! Note that I'm only mentioning the problem at emory because it was the first one which came to mind. Many sites have this problem ... It's a severe problem which should be fixed. 8. Truncation of long lines. For instance, mail on BITNET is 80 column PUNCH files sent to people's virtual reader. 9. Silent discarding (or any other sort of discarding) of mail which is "too long". SendMail has a limit (configurable) of message size ... it's usually set to something like 100K. BUT the mail system on the main instructional system here has a limit of 200 lines. (!) Further, it drops the message silently if it's too long. One of the common things to do here is print files at cluster sites by mailing them from a unix machine to "printer-name@ukpr.bitnet". It works and happens to be fairly fast ... however, if someone isn't careful the file could be too long and you'd never know it. -- <---- David Herron -- Resident E-Mail Hack <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- "The market doesn't drop hundreds of points on a normal day..." -- <---- Fidelity Investments Corporation From ncr-sd!hp-sdd!hplabs!sri-unix!husc6!hao!boulder!forys Mon Oct 26 12:46:38 PST 1987 In article <1885@killer.UUCP> billw@killer.UUCP (Bill Wisner) writes: > Foreign sites use the country abbreviation for the top-level domain, > i.e. .UK for the United Kingdom. Quite correct, given that you are looking at the address from the "domain system" point of view (which, I'm sure you are). However, all the world is not the same! If you step into the United Kingdom their top level becomes "UK.". The NRS decided to use names like "UK.AC.Ucl.Cs" (note the reverse order). While this makes for more work in gateways between the two systems, the result is *almost* always transparent to the end user (i.e. under our "domain system", you would still use "Cs.Ucl.AC.UK"). Just adding a little dirt to the clear water... :-) --- Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991) forys@boulder.Colorado.EDU -or- ..!{hao|nbires}!boulder!forys From ncr-sd!hp-sdd!hplabs!decwrl!sun!pitstop!sundc!seismo!uunet!mnetor!utzoo!utgpu!utcsri!utegc!lamy Thu Oct 29 10:57:00 PST 1987 The world has been partitioned in a number of top-level domains, and absolute addresses are defined in relation to these domains. As of this writing, top-level domains include at least au Australia jp Japan ca Canada kr Republic of Korea ch Switzerland mil Internet Military com Internet Commercial net Internet Networks de West Germany nl Netherlands edu Internet Educational org Internet Organizations fi Finland se Sweden fr France uk United Kingdom Network gov Internet Government us Internet Unites States il Israel Until the transition to network-independent domains is complete, the following pseudo top-level domains are often seen. Their purpose is to allow the specification of addresses independently of the actual route: arpa DARPA Internet irl Irish Research Network bitnet Because It's There Network isanet Iceland cdn Canadian Research Network mailnet EDUCOM Network (dead) cern CERN, Switzerland mlnet University of Western Ontario chunet Swiss University Network osiride Italian Research Networks csnet Computer Science Network oz Australian University Network dfn German Research Network sunet Swedish University Network dunet Danish University Network surfnet Netherlands Research Network funet Finnish University Network uninett Norwegian University Network iris Spanish Research Network uucp Unix Network Jean-Francois Lamy lamy@ai.toronto.edu, lamy@ai.utoronto AI Group, Dept of Computer Science lamy%ai.toronto.edu@relay.cs.net University of Toronto, Canada M5S 1A4 {uunet,watmath}!ai.toronto.edu!lamy From ncr-sd!ncrcae!hubcap!gatech!ukma!rutgers!umd5!brl-adm!adm!netinfo%garnet.Berkeley.EDU@violet.berkeley.EDU Tue Nov 17 10:34:07 PST 1987 I have noticed at least one mail gateway for a UUCP zone domain name that does not do domain to uucp address conversion, but expects the non-domain name address mail transport agents down the line to be able to interpret domain names. Please, if you are setting up a mail exchanger (MX) entry in an Internet domain server, remember that your mail gateway is also responsible for doing any needed address conversion. Bill Wells postmaster@jade.berkeley.edu From ncr-sd!hp-sdd!hplabs!sri-unix!husc6!hao!boulder!forys Mon Oct 26 12:46:38 PST 1987 In article <1885@killer.UUCP> billw@killer.UUCP (Bill Wisner) writes: > Foreign sites use the country abbreviation for the top-level domain, > i.e. .UK for the United Kingdom. Quite correct, given that you are looking at the address from the "domain system" point of view (which, I'm sure you are). However, all the world is not the same! If you step into the United Kingdom their top level becomes "UK.". The NRS decided to use names like "UK.AC.Ucl.Cs" (note the reverse order). While this makes for more work in gateways between the two systems, the result is *almost* always transparent to the end user (i.e. under our "domain system", you would still use "Cs.Ucl.AC.UK"). Just adding a little dirt to the clear water... :-) --- Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991) forys@boulder.Colorado.EDU -or- ..!{hao|nbires}!boulder!forys From ncr-sd!hp-sdd!hplabs!decwrl!sun!pitstop!sundc!seismo!uunet!mnetor!utzoo!utgpu!utcsri!utegc!lamy Thu Oct 29 10:57:00 PST 1987 The world has been partitioned in a number of top-level domains, and absolute addresses are defined in relation to these domains. As of this writing, top-level domains include at least au Australia jp Japan ca Canada kr Republic of Korea ch Switzerland mil Internet Military com Internet Commercial net Internet Networks de West Germany nl Netherlands edu Internet Educational org Internet Organizations fi Finland se Sweden fr France uk United Kingdom Network gov Internet Government us Internet Unites States il Israel Until the transition to network-independent domains is complete, the following pseudo top-level domains are often seen. Their purpose is to allow the specification of addresses independently of the actual route: arpa DARPA Internet irl Irish Research Network bitnet Because It's There Network isanet Iceland cdn Canadian Research Network mailnet EDUCOM Network (dead) cern CERN, Switzerland mlnet University of Western Ontario chunet Swiss University Network osiride Italian Research Networks csnet Computer Science Network oz Australian University Network dfn German Research Network sunet Swedish University Network dunet Danish University Network surfnet Netherlands Research Network funet Finnish University Network uninett Norwegian University Network iris Spanish Research Network uucp Unix Network Jean-Francois Lamy lamy@ai.toronto.edu, lamy@ai.utoronto AI Group, Dept of Computer Science lamy%ai.toronto.edu@relay.cs.net University of Toronto, Canada M5S 1A4 {uunet,watmath}!ai.toronto.edu!lamy From ncr-sd!ncrcae!hubcap!gatech!ukma!rutgers!umd5!brl-adm!adm!netinfo%garnet.Berkeley.EDU@violet.berkeley.EDU Tue Nov 17 10:34:07 PST 1987 I have noticed at least one mail gateway for a UUCP zone domain name that does not do domain to uucp address conversion, but expects the non-domain name address mail transport agents down the line to be able to interpret domain names. Please, if you are setting up a mail exchanger (MX) entry in an Internet domain server, remember that your mail gateway is also responsible for doing any needed address conversion. Bill Wells postmaster@jade.berkeley.edu Another way to look at the Internet is by upper-level domains. There is one of these for each country in the world (e.g\. ".uk" for United Kingdom), plus several "meta-countries" within the United States: .com (commercial organizations), .edu (educational institutions), .gov (government agencies), \.org (other organizations), There are numerous commercial organizations having no connection with DoD that are officially registered Internet sites in the .com domain. Any organization (or person) can register their system as a domain within a suitable existing zone; for instance, there is a public-access Unix system here in San Diego which is registered as cts.com . More information on Internet and its components^-- zones, domains, subdomains, parks, etc.^-- will appear soon in this space. From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!husc6!necntc!ima!think!barmar Sun Dec 20 14:55:41 PST 1987 In article <569@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >To: personA,personB,personC@machine1.smalldomain.largedomain > > If the above address is attached to a message whic is received >at a machine which is a member of "largedomain", that machine will >look for "machine1" and if not found "smalldomain". If neither is >found then the message will be frowarded to the top of "largedomain". >If this is the top of large domain, the message will bounce [fail]. >This domain-resolution will continue through each seccussive domain >until the machine is found or the samllest domain is encountered and >fails to resolve the machine refrence. Domains are name registries; a machine is not a member of a domain, but its name can be. I'll presume this is what you mean when you say "a machine which is a member of 'largedomain'". Now that I've cleared that up, I'll tell you that it doesn't matter what domain the receiving machine's name is a member of. Binding a domain name to a machine is independent of the local machine's domain. What happens is that when a machine wants to send mail to an address whose domain part (the part after the @) is of the form name1.name2.name3 it tries to contact the nameserver for the name2.name3 domain, and asks it for the information on how to send mail to name1.name2.name3. If it doesn't know the address of the name2.name3 nameserver (possibly because there isn't one) it makes the query of the nameserver for name3, and so on up the domain hierarchy. When it finally gets to a point where it knows the appropriate nameserver (the process must end because everyone is supposed to know the addresses of the root nameservers, although it is conceivable that all of them could be down simultaneously), the nameserver will either give it the information or tell it to ask the server for a subdomain (and hopefully it will include the address of the server). This could be repeated when the machine queries the specified nameserver, etc., but eventually it will find out how to send mail to name1.name2.name3. The message would never actually be transmitted to name2.name3 or name3 unless the mail information for name1.name2.name3 specifically says that one of these hosts should be used for mail addressed to it. But it is just as possible for the mail information for name1.name2.name3 to specify that its mail should be delivered to other1.other2.other3. But if no nameserver has ever heard of name1.name2.name3 the message will be returned. > Upon reaching "machine1" the message will be delivered to >three seperate accounts "personA" "personB" and "personC" If any of >these accounts do not exist then those messages will bounce without >interfeering with deleivery to the accounts which do exist. This is wrong. First of all, the above header is invalid, because all addresses must be of the form @. There is no automatic grouping. If your mail-sending program allows the above To: line and interprets all the addresses as being on machine1.smalldomain.largedomain, then it must translate them to the standard format before transmitting the message over the network. When the SMTP protocol is being used to transfer mail between computers the header isn't actually used, though; the recipients are specified as part of the SMTP protocol, and the header is just part of the data portion. >To: personA@sdomain.mdomain.ldomain > > The top of "sdomain" will be sought [as above] if it can be >found, it will search it's accounts, aliases, mailing-lists, and >group-lists [as exist] for an account or refrence to "personA" and >send the message to that [those] accounts. A list of accounts [as >above] may exist in place of "personA" [i.e. >"group1,group2,list1,personB,personC"] How a message is delivered once it is received by the destination mailer is completely up to that host. Your description above is typical of most systems, though. >To: personA@machine1%machine2%machine3 > > The sending machine will send to "machine1" and remove >"machine1%" from the address [netting personA@machine2%machine3%]. >machine1 will similarly forward to "machine2" removing "machine2%" >[netting personA@machine3]. Machine2 will forward to "machine3" >leaving the header unchainged. Machine3 seeing "personA@machine3" >will deliver to that/those account/list/group. No. Everything to the right of the @ MUST be a domain name. There are some machines that recognize %, but it must be to the LEFT of the @. The syntax of an address is @. The syntax of is arbitrary, and this is what permits hosts to treat some characters within it as routing information. The use of % is completely unsanctioned by standards, but it has become extremely common. The way the above would usually be written is To: personA%machine3%machine2@machine1 The important point is that the host sending to machine1 doesn't have to recognize % for this to work; as far as it is concerned, it is sending to a user whose name contains a bunch of % characters (and there's no reason why some computer system couldn't have users with such names). When machine1 receives it, it presumably replaces the last % in the with an @ and drops its own name, resulting in "personA%machine3@machine2" and reprocesses this normally, by sending it to machine2. >To: personA@machine1%machine2@machine3%machine4 > > This one I am not shure about. My best guess would be: >machine3->machine4->machine1->machine2. It is clear that the "%" >[percent] symbols can be used like a bang path for explicit routing. >It is also clear that the "@" [at] sign has higher precidence, and >that the "@" groups right to left, leading me to read this as "personA >(at machine1 then machine2 (at machine3 then machine4))". Of course >"personA" may again be a list [as above]. Multiple "@" are not permitted in an address. However, this can be permitted by using quoting, e.g. To: "personA@machine1"@machine2 The quoting removes the special interpretation of the first @, so this becomes an address whose is personA@machine1 and whose is machine2, so the message would be delivered to machine2. If machine2 happens to treat an @ embedded in the as routing information (like % above) then this is a way to force routing; however, again, the interpretation of is completely unspecified. > IS THIS CORRECT?? > >To: machine3!personA@machine1%machine2 > > This again is a guess: machine1->machine2->machine3->personA > IS THIS CORRECT? First, I'll treat the above as "machine3!personA%machine2@machine1", correcting your earlier error. The interpretation of an address that contains both ! (the UUCP routing character) and @ (the SMTP routing character) depends on the way the host processing the address is configured. A host that only knows about UUCP will most likely not recognize the @ at all, so it will treat the above as the user "personA%machine2@machine1" on host "machine3", so the message will probably take the path machine3->machine-1->machine2->personA. A host that doesn't know about UUCP will ignore the !, so it will treat it as user "machine3!personA%machine2" on host "machine1", and the actual path will depend on how machine1 deal with ! and %. If a host recognizes both then one of them will have to have a higher precedence than the other, to resolve the ambiguity, and quoting could be used to force grouping. Some systems adjust the precedence based on the protocol used to receive the message, so that if a message is received using UUCP protocol the UUCP addressing style will be favored. >To: machine2!personA,personB@machine1 > > Another Guess: machine1->personB > >machine2->personA > IS THIS CORRECT? IS IT LEGAL? Well, I would treat this as machine2->personA and machine1->personB, because none of the mail sending programs I use automatically group comma-separated addresses as being for the same host. In other words, To: personA,personB@machine1 is equivalent to To: personA To: personB@machine1 and most systems interpret the first line as meaning personA on the local system. >To: (text) > > The material within the "(" [lparen] and ")" [rparen] is a >comment, and generates NO delivery address or forwarding at all. > IS A COMMENT ALONE ON A LINE LEGAL? The only address field that may contain no addresses is the BCC: field. All the rest require at least one address. >Also, any of the above formats may occur on the same line as any other >as long as there is at least one unit of whitespace seperating each >form of address. The order of such combination, or multiple >occuarances of the "To:" "Cc:" and "Bcc:" header lines are immaterial >to the delivery, and should be processed on a first come first served >basis. Well, since the header isn't used to determine delivery information, the order is obviously immaterial. A message may be delivered to people no listed in the header at all. This can often happen when using blind-carbon-copy, since it is permitted to leave the BCC: field empty. The SMTP protocol looks like: MAIL FROM: RCPT TO: RCPT TO: ... DATA
. The message is delivered to user2 and user3, regardless of the names specified in the header. I am aware that there are other mail delivery protocols that do actually use the addresses in the header. >Precidence map: > > "(" ")" Grouping L->R MAtched Pairs required. Since parentheses are not binary operators, I don't know what you mean by "grouping L->R". > "," "@" Grouping R->L > "%" Grouping L->R > "!" Grouping L->R The actual precedence is more like: double-quotes No grouping Matched Pairs required ( ) No grouping Matched Pairs required , No grouping @ ! ! groups L->R only one @ permitted % groups R->L >Finally, a question: I have seen ";" [semicolon] refrenced in some of >what I have read on mail addressing. What is the ";" for and have I >missed any other symbols? There is a special address syntax allowed instead of @, called named groups, whose syntax is: : ; where is 0 or more @ addresses (if is empty then this is just a placeholder for an unenumerated mailing list). This syntax only exists in headers, it isn't allowed in the SMTP delivery protocol. The complete specification of the format of message headers is in RFC-822. SMTP is described in RFC-821. If you have access to the Internet these can be copied from SRI-NIC.ARPA, from the files RFC:RFCnnn.TXT. You can get hardcopy from the DDN Network Information Center; for information on this, call (800) 235-3155 between 7am and 4pm Pacific time. Of course, neither of the above standards will mention % or !, since they aren't officially part of the protocol. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!hc!beta!cmcl2!rutgers!sunybcs!boulder!hao!oddjob!gargoyle!ihnp4!homxb!mtuxo!mtune!codas!killer!billw Fri Oct 23 10:24:03 PDT 1987 There are, basically, two groups of top-level domains. The first are pretty obsolete, and are simply the name of the network that machine is on. The site I'm posting this from, killer.UUCP, is on USENET exclusively. Similarly, foo.ARPA denotes an ARPA Internet site, and foo.BITNET means that the machine is on bitnet. Domains now are more descriptive. The "real" type of domain is something like sgistl.SGI.COM -- the machine is sgistl, it is at SGI, and SGI is a COMpany. Other top-level domains are .EDU for Universities (EDUcational institution) and .ORG for organizations. Foreign sites use the country abbreviation for the top-level domain, i.e. .UK for the United Kingdom. The big advantage with this type of site domain name is that it is the same regardless of how many networks a machine is on; a message sent to aramis.rutgers.edu is likely to arrive whether send from a UUCP-only site with smail or an Internet-only site with sendmail. -- Bill Wisner, HASA 'A' Division ..ihnp4!killer!billw "It's the coarse feel of the rope that I don't like." From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucbvax!ucbcad!ames!elroy!cit-vax!oberon!bloom-beacon!mit-eddie!rutgers!princeton!udel!rochester!PT.CS.CMU.EDU!sei!sei.cmu.edu!pdb Fri Oct 23 10:24:13 PDT 1987 In article <5533@sgistl.SGI.COM> larry@sgistl.SGI.COM (Larry Autry) writes: >I have noticed different suffixes in the mail addresses on the net. Some are >.COM, and others are .UUCP. What are the different suffixes and domain types? >I have seen other suffixes besides the two mentioned. The current list of top level domains is (at the moment): .COM - Commercial organizations .EDU - Educational institutions .GOV - Government organizations .MIL - Military sites .NET - Network administration sites .ORG - Other random "organizations" that don't fit in any other domain plus, the ISO country codes (like .UK, .AU, etc.) are top-level domains for the associated countries. The .ARPA domain is a temporary top-level domain for old ARPANET/MILNET sites who haven't converted to the domain system yet. There is no such thing as the .UUCP domain (at least, as far as the root nameservers are concerned); it is a "fake" domain that some mailers happen to know how to deal with. --Pat. From ncr-sd!hp-sdd!hplabs!ucbvax!CITHEX.CALTECH.EDU!carl Fri Aug 28 14:10:11 PDT 1987 We've got yet another entry in the competition for the world's most brain-damaged mailer, this one from: PMDF Mail Server The situation: There's an account (NSMCC) on a BITNET (where else would you look for a truly brain-damaged mailer?) node (UHRCC2) that's being used for redistribution. One of the addresses (HOWARD@CRCC) refers to a non-existent (at least as of July first) BITnet node (CRCC). The mailer now goes looking for somebody to complain to. Given the header: -------------------------------------------------------------------------------- Date: Wed, 26 Aug 87 16:24 CDT >From: "Alan J. Kaufman" Subject: RE: FREQUENCY, a spelling aid Sender: INFO-VAX Discussion To: Howard Jares Reply-to: INFO-VAX@KL.SRI.COM Comments: To: INFO-VAX@KL.SRI.COM -------------------------------------------------------------------------------- the mailer picks up (what else but the worst choice possible?) the Reply-To: line. That is, it posts it back to the teleconference. I'm willing to bet that when it gets a copy of its complaint, node CRCC STILL won't exist, and it will complain (to the list) that it was unable to deliver a copy of its complaint about its inability to deliver a copy of the original posting. It's obvious that we need at least two things here: 1) An easily accessible, clearly worded statement regarding what the various header lines mean (for example, just what does the Sender: line mean?); and 2) A convention for routing of error messages to appropriate places. I thought I once saw a mail header that included a line starting with "Errors-To: ", and something of the sort is needed here. That way, the guys who manage INFO-VAX could, for example, have error messages directed to INFO-VAX-REQUESTS@KL.SRI.COM, or better still, each agent doing redistribution could have all the inferior machines report back to itself rather than the master list. Even if the people managing the TC didn't want all the errors coming back, they could maybe have them sent to the bit bucket. From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!ll-xn!mit-eddie!bloom-beacon!ptt.lcs.mit.edu!markl Fri Dec 4 13:18:09 PST 1987 Originating-Client: thyme From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) Keywords: GNU Emacs, sendmail Date: 1 Dec 87 16:21:47 GMT Reply-To: davidsen@crdos1.UUCP (bill davidsen) Distribution: na One of the other burning questions is, should the "Reply-to:" field override all others and be used instead of any from field. That would solve your problem, if only everybody's mailers did the same thing. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me Depends on whose brand of standard you like. If you follow the Internet RFC-822 standard, there is a specific hierarchy of fields to reply to. It is, in priority order, "reply-to:", followed by "from:", followed by "sender:" (if present). markl Internet: markl@ptt.lcs.mit.edu Mark L. Lambert MIT Laboratory for Computer Science Distributed Systems Group ---------- From ncr-sd!ncrcae!ece-csc!mcnc!rutgers!clyde!watmath!utgpu!utzoo!lsuc!ncrcan!brian Tue Dec 1 13:25:22 PST 1987 In article <8991@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> Actually, the "From " line at the beginning of the file is a misfeature >> (in this day and age ... > >Unfortunately, when Unix mail got RFC822ized (at Berkeley, I believe), it >did not occur to the people doing it that RFC822 format and the old Unix >format ("From " lines at the beginning) were two *different* formats and >that they should convert between them rather than smushing them together. >There is just no excuse for having the sender's address appear in two >different places in two different forms. (Well, actually, nowadays it can >be handy to have a domainized address in "From:" and a bang form in "From ", >but that is a kludge if there ever was one.) I agree! I hate those "From " lines and "remote from" lines in mail messages. I have been giving serious thought to hacking on smail so that it removes those lines. As long as we have a domain mailer, I don't care how the mail got here. Of course this means that all sites that mess with the "From: " line will have to refrain from doing this :-). Anyone have any reasons (besides the obvious one above) as to why I should not go ahead and do this? Brian. -- +-------------------+--------------------------------------------------------+ | Brian Onn | UUCP:..!{uunet!mnetor, watmath!utai}!lsuc!ncrcan!brian | | NCR Canada Ltd. | INTERNET: Brian.Onn@Toronto.NCR.COM | +-------------------+--------------------------------------------------------+ From ncr-sd!matt Sat Dec 5 02:43:32 PST 1987 In article <471@ncrcan.Toronto.NCR.COM> brian@ncrcan.Toronto.NCR.COM (Brian Onn) writes: >I agree! I hate those "From " lines and "remote from" lines in mail messages. >I have been giving serious thought to hacking on smail so that it removes >those lines. As long as we have a domain mailer, I don't care how the mail >got here. > >Of course this means that all sites that mess with the "From: " line will >have to refrain from doing this :-). > >Anyone have any reasons (besides the obvious one above) as to why I should >not go ahead and do this? At least one From_ line is necessary at the beginning of a mail message for the normal mailbox format. The first one (without the '>') is used to denote the start of a mail message in a mailbox file. This convention is used by /bin/mail, mailx, elm, etc. If you are willing to use a different scheme such as that used by MH then getting rid of the From_ lines might be reasonble. As it it you'd just be cutting your throat. I have to agree that there can be too many From_ lines. The solution is to let smail (i.e. the message tranport agent) collapse all the From_ lines to a single line. Smail has supported this from at least version 1.3. In smail2.5 the function rline() is defined at line 373 of the file headers.c; this function collapses all the From_ lines into a single line and also removes redundant host information. -- Matt Costello +1 619 485 2926 {sdcsvax,cbosgd,pyramid,nosc.ARPA}!ncr-sd!matt From ncr-sd!hp-sdd!hplabs!sri-unix!rutgers!mtune!jhc Thu Aug 13 11:17:19 PDT 1987 In article <2707@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: :There are two optimizations that we should be able to safely make for :rerouting bang-path mail. (If I'm wrong, please post a polite correction.) : :(1) The uucp domain mail design was such that if a smart mailer : finds a path like foo!bar!a.b.c!anything, and it knows how to : get to a.b.c, it can throw away the foo!bar! part. Furthermore, : if there are multiple dotted addresses (e.g. foo!a.b.c!d.e.f!g), : it can take the rightmost one it knows. This is because domain : addresses are UNIQUE by design. (People who invent their own, : and put them on mail, deserve what they get.) I don't think that this poses any problems, in general, apart from the usual 'should I fiddle with a bang path?' question. I certainly agree with the last point! :(2) I've been planning to put in a rerouter here that just shortens : paths that go through sites ALL OF WHICH ARE KNOWN TO ME. That's : not to say that I have a link to them, but e.g. : ptsfa!ames!ihnp4!cbosgd!ncoast!allbery : can be cut down to ncoast!allbery because I have links to ptsfa, This is very close to something I've thought of putting into smail, the FAVOURED-HOST list. This would be a list of sites that my site is flat out guaranteed to be able to talk to (cbosgd, ihnp4, rutgers, codas, clyde and a couple of others in my world), and consequently I could do a rightmost scan until I hit a site I know, then short-circuit the lefthand part of the path. Useful for netnews paths! Comments, anyone? : ihnp4, and cbosgd, and can add "ames" to a short list of sites : that my neighbors talk to. Personally I think that's dangerous, quite apart from being unsure about exactly which "ames" the mail is going to go to. Given the number of mail and net neophytes around these days, the original sender very likely knows much less well than a properly maintained database how to *really* route hir mail. Earlier today I saw a pile of large articles in transit through this machine going to a site which I talk to at 9600 baud, but it was going via 2 1200-baud links. I let it go... -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose. From crash!bblue Tue Mar 31 19:57:18 1987 Received: by crash.CTS.COM (5.54/UUCP-Project/rel-1.0/09-14-86) id AA14677; Tue, 31 Mar 87 19:20:26 PST Date: Tue, 31 Mar 87 19:20:26 PST From: crash!bblue (Bill Blue) Ppath: pnet01!jeh To: jeh@pnet01 Subject: misc An address of the form a!b!user@gateway-site.domain Is up for grabs depending on how the local site handles things. If that address was entered on crash, or any other site that understands domainized addressing, the @ stuff will be processed first, expanded, and then the a!b!user stuck to the end. The equivalent would be gateway-site.domain!a!b!user, and gateway-site.domain would be replaced by a real route if they are not one hop from the originating site. The only places where the a!b would be processed first would be on a site that does not understand @'s. Under normal circumstances a site that does understand @'s will not produce a path with any @'s left in it - pure !'s are supposed to be for transports. There are some systems that allow "" for grouping, but I have no idea who they are. When you deal with or write hybrid addresses such as your above example, you should be very sure about what sites understand @'s and what ones don't. Trick: If I wanted to get some @ syntax out, say, to hp-sdd for it to process, I could do user@sitename@hp-sdd. Crash would send user@sitename to hp-sdd who would then look things up and substitute. The % operator is also used in that fashion, but should only be used in specific places where it is a known host that gets the resulting syntax and knows to convert it to @ and continue processing. Happens most frequently across networks. You are correct about the nameserver lookup for domains if they are not known locally. And any site that cts.com (for example) knows about could currently be addressed via that domain. jeh@jehsystem.cts.com would work if jehsystem was known to crash. Yes, crash.cts.com is redundant, but is included for overall clarity since it may not be clear to all that crash is cts.com. In the mapping database you can name sites and domains that crash is the same as, but also is knowledgable of. So crash=.cts.com, but crash is also knowledgable of cts.com, .cts.com and crash.cts.com. The net result is that all variations of the syntax work, redundant or not, since crash IS the domain cts.com. The usability of jeh@pnet01.cts.com depends on the NIC nameserver knowing who the forwarder for cts.com is (in this case it is uiucuxc), uiucuxc knowing how to contact crash (which it does, directly), and crash knowing of pnet01. Even if the nameserver didn't know of cts.com, it still does know of .com (seismo) and seismo would know of .cts.com since that's all part of the uucpmap postings. So there can be a large amount of error in uucp sites databases and it won't affect the domain address as long as the forwarder and the nameserver are knowledgable. Within the uucp world (not across networks), for a site to know directly how to get to crash.cts.com, it would have to have an up to date database. Otherwise it would have to know how to get to either cts.com or .com in the hopes that one of them can resolve the path. If a site had no such database, a route would have to be expressley provided, or the path passed on to a relay site - one that did know routing. This is all sort of confusing, I know. I had a heck of a time getting the whole thing to sink in. Hope I didn't confuse you more. Here comes the newsgroups list. It (btw) can be found in /news/lib/news/newsgroups on crash. --Bill From ncr-sd!hp-sdd!hplabs!decwrl!decvax!ima!cfisun!lakart!dg Wed Oct 19 19:55:37 PDT 1988 >From article <211@obie.UUCP>, by wes@obie.UUCP (Barnacle Wes): > In article <2164@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: >> There are several lines of my pathalias output that I know better >> (geographically, at least) paths for, and after attempting various >> more "elegant" methods, I just have my pathalias script that runs nightly >> pipe the output through sed, replacing the desired lines. Ugly, but >> it works. > > Another, perhaps slightly more elegant :-) way to do this is to have the > sed script lower the cost on the links you want to use to some > (ridiculously) low value. Obie, myth, and wsccs all use this to force > certain paths that sp7040 allows us to use, but does not broadcast to > the net.at.large :-). Yet another (IMHO "elegant") solution is to take advantage of the fact that pathalias utilises data IN THE ORDER IT FINDS IT with respect to multiple entries. So, for example, if there was a link between my machine at home (pallio) and system blurf on the west coast (lakart & pallio are in Boston) that I want to be able to use from lakart and pallio, but I dont want anyone else to know about I do the following: create a u.PALLIO file with the following two lines: pallio blurf(HOURLY) blurf pallio(HOURLY) Now when I run pathalias (every night :-) ) I invoke it as follows: pathalias u.[A-Z]* [ud].* which causes the u.PALLIO (and u.LAKART - we have one) information to be read first, hence it takes precedence over real information. I think this may well do what you want. -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@harvard.harvard.edu +---+ From ncr-sd!ncrlnk!uunet!jetson!john Wed Oct 19 20:00:59 PDT 1988 In article <10357@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) asks: > Why *wouldn't* you want such a thing? [as "fernwood .fernwood.mpk.ca.us" in your map entry] Then provides the seed of the answer: > declaring the gateway *does* handle the routing for fernwood...us. > In *addition* it gives you the flexibility of having other > hosts 'under' the fernwood name. Yes, it does, but by the definition of the .US domain, there can be no names under the fernwood.mpk.ca.us domain. anything.fernwood.mpk.ca.us (or anything.jetson.upma.md.us) is illegal. You can argue whether that should or shouldn't be true, but it simply is. (The idea is that anyone who needs more than one name should get a name in .COM, .EDU, .ORG, etc., perhaps through uunet or the UUCP Project.) > If there is to be a difference between domains and host names, why > isn't the difference made explicit in the way they are represented? I > put forward that since the representation is the same in either case, > then neither human nor software is able to tell a difference. If there > is no difference, then they are the same thing. Well, from what I hear, there will be a difference in the way smail 3.X handles fernwood .fernwood.mpk.ca.us and fernwood = fernwood.mpk.ca.us smail 2.x will still gateway mail to xyz.fernwood.mpk.ca.us to fernwood given the second form; smail 3.X will (correctly) reject this gateway (and eventually hit a general .US gateway which will bounce the message since no MX exists for *.fernwood.mpk.ca.us). -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net