vixie@decwrl.dec.com (Paul A Vixie) (06/30/90)
>> My friend, who worked there, just gave me the DEC internal email address >> which has the following form: GROUP_NAME::USERID >this conversion sometimes works: > userid@group_name.enet.dec.com Here's gatekeeper.dec.com:~ftp/gateway.doc (also DECWRL::"/gateway.doc to internal Easynet people and decwrl!~/gateway.doc to our UUCP neighbors): Comments welcome. --vix ========================================================================== THE DECWRL MAIL GATEWAY Last updated 20 September 1989 at 11:03 This document is also available as a PostScript file DECWRL::"GATEWAY.PS" INTRODUCTION DECWRL is a mail gateway computer operated by Digital's Western Research Laboratory in Palo Alto, California. Its purpose is to support the interchange of electronic mail between Digital and the "outside world". decwrl is connected to Digital's Easynet, and also to a number of different outside electronic mail networks. Digital users can send outside mail by sending to DECWRL::"outside-address", and digital users can also receive mail by having your correspondents route it through decwrl. The details of incoming mail are more complex, and are discussed below. It is vitally important that Digital employees be good citizens of the networks to which we are connected. We depend on the integrity of our user community to ensure that tighter controls over the use of the gateway are not required. The most important rule is "no chain letters", but there are other rules depending on whether the connected network that you are using is commercial or non-commercial. The current traffic volume (September 1989) is about 10,000 mail messages per day and about 3,000 USENET messages per day. Gatewayed mail traffic has doubled every year since 1983. decwrl is currently a Vax 8530 computer with 48 megabytes of main memory, 2500 megabytes of disk space, 8 9600-baud (Telebit) modem ports, and various network connections. We will shortly be upgrading to a Vax 8650 system. We run Ultrix 3.0 as the base operating system. ADMINISTRATION The gateway has engineering staff, but no administrative or clerical staff. We work hard to keep it running, but we do not have the resources to answer telephone queries or provide tutorials in its use. We post periodic status reports to the USENET newsgroup dec.general. Various helpful people usually copy these reports to the VAXNOTES "gateways" conference within a day or two. If you have technical problems with the gateway, please send electronic mail to the mailing list DECWRL::ADMIN (admin@decwrl.dec.com from IP sites). We ask that you consider the telephone to be an instrument of desperate last resort in trying to contact us. All of the gateway staff keep unusual schedules, are not often at their desks, and when a call comes through, the secretary or guard who answers it must decide whether the call is urgent enough to have one of us tracked down or paged. If the problem that you would like to report is that you cannot get electronic mail to decwrl, please try sending to the mailing list "gatekeepers" at one of the other major nodes in the Palo Alto cluster. If you cannot reach JOVE::GATEKEEPERS or GILROY::GATEKEEPERS or DECSRC::GATEKEEPERS, the problem is almost certainly not in Palo Alto, so talking to us on the phone isn't going to help solve it. HOW TO SEND MAIL DECWRL is connected to quite a number of different mail networks. If you were logged on directly to it, you could type addresses directly, e.g. To: strange!foreign!address. But since you are not logged on directly to the gateway, you must send mail so that when it arrives at the gateway, it will be sent as if that address had been typed locally. Sending from VMS If you are a VMS user, you should use NMAIL, because VMS mail does not know how to requeue and retry mail when the network is congested or disconnected. From VMS, address your mail like this: To: nm%DECWRL::"strange!foreign!address" The quote characters (") are important, to make sure that VMS doesn't try to interpret strange!foreign!address itself. If you are typing such an address inside a mail program, it will work as advertised. If you are using DCL and typing directly to the command line, you should beware that DCL likes to remove quotes, so you will have to enclose the entire address in quotes, and then put two quotes in every place that one quote should appear in the address: $ mail test.msg "nm%DECWRL::""foreign!addr""" /subj="hello" Note the three quotes in a row after foreign!addr. The first two of them are doubled to produce a single quote in the address, and the third ends the address itself (balancing the quote in front of the nm%). Here are some typical outgoing mail addresses as used from a VMS system: To: nm%DECWRL::"ucbvax!mtxinu!rjz" To: nm%DECWRL::"postmaster@g.gp.cs.cmu.edu" To: nm%DECWRL::"posix!george@uunet.uu.net" To: nm%DECWRL::"listsrv@CUNYVM.bitnet" To: nm%DECWRL::"Bob.Jones@f654.n987.z1.fidonet.org" Sending from Ultrix If your Ultrix system has been configured for it, then you can, from your Ultrix system, just send directly to the foreign address, and the mail software will take care of all of the gateway routing for you. Most Ultrix syustems in Corporate Research and in the Palo Alto cluster are configured this way. To find out whether your Ultrix system has been so configured, just try it and see what happens. If it doesn't work, you will receive notification almost instantly. NOTE: The Ultrix mail system is extremely flexible; it is almost completely configurable by the customer. While this is valuable to customers, it makes it very difficult to write global instructions for the use of Ultrix mailers, because it is possible that the local changes have produced something quite unlike the vendor-delivered mailer. One of the popular changes is to tinker with the meaning of quote characters (") in Ultrix addresses. Some systems consider that these two addresses are the same: site1!site2!user@host.dec.com and "site1!site2!user"@host.dec.com while others are configured so that one form will work and the other will not. All of our examples use the quotes. If you have trouble getting the examples to work, please try them again without the quotes. Perhaps your Ultrix system is interpreting the quotes differently. If your Ultrix system has an IP link to Palo Alto (type "/etc/ping decwrl.dec.com" to find out if it does), then you can route your mail to the gateway via IP. This has the advantage that your Ultrix mail headers will reach the gateway directly, instead of being translated into DECNET mail headers and then back into Ultrix at the other end. Do this as follows: To: "alien!address"@decwrl.dec.com The quotes are necessary only if the alien address contains a ! character, but they don't hurt if you use them unnecessarily. If the alien address contains an "@" character, you will need to change it into a "%" character. For example, to send via IP to joe@widget.org, you should address the mail To: "joe%widget.org"@decwrl.dec.com If your Ultrix system has only a DECNET link to Palo Alto, then you should address mail in much the same way that VMS users do, save that you should not put the nm% in front of the address: To: DECWRL::"strange!foreign!address" Here are some typical outgoing mail addresses as used from an Ultrix system that has IP access. Ultrix systems without IP access should use the same syntax as VMS users, except that the nm% at the front of the address should not be used. To: "ucbvax!mtxinu!rjz"@decwrl.dec.com To: "postmaster%g.gp.cs.cmu.edu"@decwrl.dec.com To: "listsrv%CUNYVM.bitnet"@decwrl.dec.com To: "posix!george%uunet.uu.net"@decwrl.dec.com To: "Bob.Jones@f654.n987.z1.fidonet.org"@decwrl.dec.com Sending from All-in-1 We actually don't know a thing about All-in-1, and would be grateful if somebody who was expert in its use could send us some instructions for All-in-1 use of our gateway. DETAILS OF USING OTHER NETWORKS All of the world's computer networks are connected together, more or less, so it is hard to draw exact boundaries between them. Precisely where the Internet ends and UUCP begins is a matter of interpretation. For purposes of sending mail, though, it is convenient to divide the network universe into these categories: Easynet Digital's internal DECNET network. Characterized by addresses of the form NODE::USER. Easynet can be used for commercial purposes. Internet A collection of networks including the old ARPAnet, the NSFnet, the CSnet, and others. Most international research, development, and educational organizations are connected in some fashion to the Internet. Characterized by addresses of the form user@site.subdomain.domain. The Internet itself cannot be used for commercial purposes. UUCP A very primitive network with no management, built with auto-dialers phoning one computer from another. Characterized by addresses of the form place1!place2!user. The UUCP network can be used for commercial purposes provided that none of the sites through which the message is routed objects to that. USENET Not a network at all, but a layer of software built on top of UUCP and Internet. BITNET An IBM-based network linking primarily educational sites. Digital users can send to BITNET as if it were part of Internet, but BITNET users need special instructions for reversing the process. BITNET cannot be used for commercial purposes. Fidonet A network of personal computers. Some Digital employees have Fidonet computers at home. We are unsure of the status of using Fidonet for commercial purposes, nor are we sure of its efficacy. DOMAINS AND DOMAIN ADDRESSING There is a particular network called "the Internet"; it is somewhat related to what used to be "the ARPAnet". The Internet style of addressing is flexible enough that people use it for addressing other networks as well, with the result that it is quite difficult to look at an address and tell just what network it is likely to traverse. But the phrase "Internet address" does not mean "mail address of some computer on the Internet" but rather "mail address in the style used by the Internet". Terminology is even further confused because the word "address" means one thing to people who build networks and something entirely different to people who use them. In this document an "address" is something like "reid@decwrl.dec.com" and not "192.1.24.177" (which is what network engineers would call an "internet address"). The Internet naming scheme uses hierarchical domains, which despite their title are just a bookkeeping trick. It doesn't really matter whether you say NODE::USER or USER@NODE, but what happens when you connect two companies' networks together and they both have a node ANCHOR?? You must, somehow, specify which ANCHOR you mean. You could say ANCHOR.DEC::USER or DEC.ANCHOR::USER or USER@ANCHOR.DEC or USER@DEC.ANCHOR. The Internet convention is to say USER@ANCHOR.DEC, with the owner (DEC) after the name (ANCHOR). But there could be several different organizations named DEC. You could have Digital Equipment Corporation or Down East College or Disabled Education Committee. The technique that the Internet scheme uses to resolve conflicts like this is to have hierarchical domains. A normal domain isn't DEC or STANFORD, but DEC.COM (commercial) and STANFORD.EDU (educational). These domains can be further divided into ZK3.DEC.COM or CS.STANFORD.EDU. This doesn't resolve conflicts completely, though: both Central Michigan University and Carnegie-Mellon University could claim to be CMU.EDU. The rule is that the owner of the EDU domain gets to decide, just as the owner of the CMU.EDU gets to decide whether the Electrical Engineering department or the Elementary Education department gets subdomain EE.CMU.EDU. The domain scheme, while not perfect, is completely extensible. If you have two addresses that can potentially conflict, you can suffix some domain to the end of them, thereby making, say, DECWRL.UUCP be somehow different from DECWRL.ENET. decwrl's entire mail system is organized according to Internet domains, and in fact we handle all mail internally as if it were Internet mail. Incoming mail is converted into Internet mail, and then routed to the appropriate domain; if that domain requires some conversion, then the mail is converted to the requirements of the outbound domain as it passes through the gateway. For example, we put Easynet mail into the domain ENET.DEC.COM, and we put BITNET mail into the domain BITNET. The "top-level" domains supported by the decwrl gateway are these: .EDU Educational institutions .COM Commercial institutions .GOV Government institutions .MIL Military institutions .ORG Various organizations .NET Network operations .BITNET The BITNET .MAILNET The MAILNET .?? 2-character country code for routing to other countries .OZ Part of the Australian (.AU) name space. 2-character country codes include UK (United Kingdom), FR (France), IT (Italy), CA (Canada), AU (Australia), etc. These are the standard ISO 2-character country codes. MAILING TO EASYNET To mail to user GUEST at node DEMO (which is DECNET address DEMO::GUEST), Internet mail should be addressed to guest@demo.enet.dec.com. Easynet addresses are not case-dependent; DEMO and demo are the same node name and GUEST and guest are the same user name. Sites that are not directly connected to the Internet may have difficulty with Internet addresses like demo.enet.dec.com. They can send into the Easynet by explicitly routing the mail through DECWRL. From domain-based Internet mailers, the address would be guest%demo.enet@decwrl.dec.com. From uucp mailers, the address would be decwrl!demo.enet!guest. Some Internet mailers require the form <@decwrl.dec.com:guest@demo.enet>. (This last form is the only technically correct form of explicit route, but very few Internet sites support it.) The decwrl gateway also supports various obsolete forms of addressing that are left over from the past. In general we support obsolete address forms for two years after the change, and then remove it. MAILING TO DIGITAL ALL-IN-1 USERS Some Easynet users do not have a direct DECNET node address, but instead read their mail with All-in-1, which uses addresses of the form "James Guest @UCO". Here "UCO" is a Digital location code name. To route mail to such people, send to James.Guest@UCO.MTS.DEC.COM. Mail received from the All-in-1 mailer is unreplyable, and in fact unless the respondent tells you his return address in the body of the message, it is not normally possible even to puzzle out the return address by studying the message header. Mail from All-in-1 to Easynet passes through a gateway program that does not produce valid return addresses. MAILING TO THE INTERNET decwrl's mailer is an Internet mailer, so to mail to an Internet site, just use its address. If you are having trouble determining the Internet address, you might find that the Ultrix host table /etc/hosts.txt is useful. If you can't find one anywhere else, there's one on decwrl. See the comments above under "how to send mail" for details about making sure that the mail program you are using has correctly interpreted an address. MAILING TO UUCP UUCP mail is manually routed by the sender, using ! as the separator character. Thus, the address xxx!yyy!zzz!user means to dial machine xxx and relay to it the mail, with the destination address set to yyy!zzz!user. That machine in turn dials yyy, and the process repeats itself. To correctly address uucp mail, you must know a working path through the uucp network. The database is sufficiently chaotic that automatic routing does not work reliably (though many sites perform automatic routing anyhow). The information about uucp connectivity is distributed in the USENET newsgroup comp.mail.maps; many sites collect this data and permit local queries of it. At the end of this file is a list of the uucp nodes to which decwrl currently has a working connection. MAILING TO USENET Usenet is not a network. It's a software layer, and it spans several networks. Many people say "Usenet" when they really mean uucp. You can post a message to a Usenet newsgroup by mailing it to "name@usenet" at decwrl. For example, mailing from VMS to this address: nm%DECWRL::"rec.autos.tech@usenet" causes the mail message to be posted as an article to the Usenet newsgroup rec.autos.tech. It is better to use Usenet software for posting articles, as more features are available that way, such as restricted distributions, crossposting, and cancellation of "wish I hadn't sent that" articles. MAILING TO BITNET Legend has it that the "BIT" in BITNET stands for "Because It's There" or "Because It's Time" It is a network consisting primarily of IBM computers. A native BITNET address is something like "USER at MUMBLEVM", but when translated into our Internet format it becomes user@mumblevm.bitnet. Once translated into Internet form, a BITNET address is used just like any other Internet address. MAILING TO FIDONET By comparison with the other linked networks, Fidonet has an addressing complexity bordering on the bizarre. The Fidonet people have provided us with this description: Each Fidonet node is a member of a "network", and may have subsidiary nodes called "point nodes". A typical Fido address is "1:987/654" or "987/654"; a typical Fido "point node" address is "1:987/654.32" or "987/654.32". This is zone 1, network 987, Fido (node) 654, "point node" 32. If the zone number is missing, assume it is zone 1. The zone number must be supplied in the outgoing message. To send a message to Bob Jones on Fidonet address 1:987/654, use the address Bob.Jones@f654.n987.z1.fidonet.org. To send a message to Fred Smith at Fidonet node 987/654.32, use address Fred.Smith@p32.f654.n987.z1.fidonet.org. Use them just like any other Internet address. Sometimes the return addresses on messages from Fidonet will look different. You may or may not be able to reply to them. ANSWERS TO COMMON QUESTIONS 1. Q: Why does it take mail so long to get through decwrl? My messages typically are delayed 3 or 4 hours, and I find this annoying. A: For precisely the same reason that it takes so long to get from Logan Airport to Marlboro in a car. There's a lot of mail traffic, and the networks are usually pretty congested. Decwrl handles 10,000 or more mail messages on a typical business day; the slightest hiccup in the network causes long backups. Surely you've seen the same phenomenon on a busy highway when there is an accident on the other side of the road. Everybody slows down, just a little, to take a look at the accident, and as a result there is a 10-mile traffic backup. 2. Q: The mail that I receive always has some junk at the end of it, with the label "Internet headers". What does this mean and how can I get rid of it? A: The DECNET mail protocol allows for a very limited amount of information to be sent about a mail message. It supports a "To:", a "From:", an "Subj:", and (sometimes) a "Cc:" field. Any other information must be passed as part of the message body. The Internet mail protocol has many more standard header fields in it, and gives users the ability to add their own header fields. Sometimes there is valuable information contained in these non-DECNET header fields, so they cannot be merely discarded. When you buy a cut-up packaged chicken at the grocery store, the giblets are usually packaged in with it, just on the off chance that you might want them. It's easy for you to throw them away, but very hard for you to recover them if somebody else has already thrown them away. Internet mail headers are not unlike giblets. If we threw them away, there is always the chance that you would come back and ask us for them, which means that we would both have to save them and also would have to answer requests for them. 3. Q: The mail gateway sometimes muddles files that I send through it. For example, it turns copyright symbols into parentheses. Why can't this be fixed? A: There is no such thing as a copyright symbol in most parts of the computer network world. It's part of the DEC character set. Many other vendors don't recognize that character set, even though it is an international standard. The thing about international standards is that there are so many to choose from. The world of electronic mail networks is currently based on the 7-bit ISO 646 (ASCII) character set. There is no such character as Copyright, or Pound, or 1/2, in it. So we can't translate your use of such characters. 4. Q: I have real trouble sending VMS mail through decwrl sometimes. I get error messages like "insufficient resources at remote node" or "object not defined". Could you please fix this? A: Those error messages are symptoms of congestion from too many people using the network at once. To use the decwrl gateway effectively from VMS you must use NMAIL. NMAIL can queue and retry mail during congested periods. If you cannot or will not use NMAIL, then you must keep retrying by hand; you will eventually get through. 5. Q: I had trouble accessing the file GATEWAY.DOC; here is what happened: $ type decwrl::gateway.doc %TYPE-W-OPENIN, error opening DECWRL::/GATEWAY.DOC as input -RMS-F-SYN, file specification syntax error Where did the "/" come from? What is the matter with the directory? A: This is one of those situations that makes you appreciate how well Ultrix and VMS work together when they do work together. This time they don't. The short answer is that you have to quote the "gateway.doc", this way: $ type decwrl::"gateway.doc" For those of you with a penchant for horror stories, here is why the "short way" doesn't work. The VMS "type" command first sends a "directory" command to the remote site. This is so you can do things like type TEST.* First, your computer sends DECWRL a "DIRECTORY TEST.*" command to get a list of the files matching TEST.*, and then it opens and reads each one in turn. DECWRL is an Ultrix machine. Ultrix file names all begin with a "/" character. Just as the "true name" of some VMS file "TEST.LIS" might be "DSK3:[REID.TEMP]TEST.LIS;4", the "true name" of some Ultrix file "test.lst" might be "/usr/users/reid/temp/test.lst". In the case of the file "DECWRL::GATEWAY.DOC", the "true name" of the file is "/gateway.doc". The VMS system sends DECWRL a "directory gateway.doc" command, and gets back a list of the names of the files that match it. This list contains one name: /gateway.doc. The VMS machine then processes the command "type DECWRL::/GATEWAY.DOC", which it parses as a null file name with the /GATEWAY.DOC command qualifier. Failure. But if you quote the file name: type decwrl::"gateway.doc" then it bypasses the file name expansion phase and just uses the name as you type it, whereupon it works fine. Appendix: list of UUCP neighbor sites This table shows most of the sites that decwrl dials directly via uucp. You may find it useful to help you construct a uucp route to a particular destination. Those sites marked with "*" are major uucp routing nodes. You should prefer uucp routes that use these sites as the first hop from decwrl. Case is significant in uucp host names. 3comvax 3Com Corporation, Santa Clara, CA abvax Allen-Bradley Company, Highland Heights, OH acad Autodesk, Inc, Sausalito, CA adobe Adobe Systems Inc., Mountain View, CA alberta University of Alberta, Edmonton, Alberta, Canada allegra AT&T Bell Laboratories, Murray Hill, NJ *amdahl Amdahl Corp., Sunnyvale, CA amdcad Advanced Micro Devices, Sunnyvale, CA ames NASA Ames Research Center, Mountain View, CA *apple Apple Computers, Cupertino, CA ardent Ardent Computer Corp., Sunnyvale, CA argosy MassPar Computer Corp., Sunnyvale, CA atha Athabasca University, Athabasca, Alberta, Canada athertn Atherton Technology, Sunnyvale, CA *att AT&T Bell Laboratories, Columbus, Ohio avsd Ampex Corporation, Redwood City, CA cae780 Tektronix Inc. (Santa Clara Field Office) Santa Clara, CA chip M/A-COM Government Systems, San Diego, CA claris Claris Corporation, Mountain View, CA daisy Daisy Systems, Mountain View, CA decuac DEC/Ultrix Applications Ctr, Landover, MD *decvax DEC/Ultrix Engineering, Nashua, NH dsinc Datacomp Systems, Inc, Huntington Valley, PA eda EDA Systems Inc., Santa Clara, CA emerald Emerald Systems Corp., San Diego, CA escd Evans and Sutherland Computer Division, Mountain View, CA esunix Evans and Sutherland Corp., Salt Lake City, UT fluke John Fluke Manufacturing, Everett, WA gryphon Trailing Edge Technology, Redondo Beach, CA handel Colorodo State Univ., CS Dept., Ft. Collins, CO hoptoad Nebula Consultants, San Francisco, CA *hplabs Hewlett Packard Research Labs, Palo Alto, CA ide Interactive Development Environments, San Francisco, CA idi Intelligent Decisions, Inc., San Jose, CA imagen Imagen Corp., Santa Clara, CA intelca Intel Corp., Santa Clara, CA limbo Intuitive Systems, Los Altos, CA logitech Logitech, Inc., Palo Alto, CA megatest Megatest Corp., San Jose, CA metaphor Metaphor Corp., Mountain View, CA microsoft Microsoft, Bellevue, WA mindcrf Mindcraft Corp., Palo Alto, CA mips MIPS Computer Systems, Mountain View, CA mntgfx Mentor Graphics Corp., Beaverton, OR mordor Lawrence Livermore National Lab, Livermore, CA mtu Michigan Tech Univ., Houghton, MI mtxinu Mt. Xinu, Berkeley, CA nsc National Semiconductor Corp., Sunnyvale, CA oli-stl Olivetti Software Techn. Lab, Menlo Park, CA oracle Oracle Corp., Belmont, CA *pacbell Pacific Bell, San Ramon, CA parcplace Parc Place Systems, Palo Alto, CA purdue Purdue University, West Lafayette, IN *pyramid Pyramid Technology Corporation, Mountain View, CA qubix Qubix Graphic Systems, San Jose, CA quintus Quintus Computer Systems, Mountain View, CA research AT&T Bell Laboratories, Murray Hill, NJ riacs Res.Inst. for Adv. Compu. Sci., Mountain View, CA rtech Relational Technology Inc., Alameda, CA sci Silicon Compilers, San Jose, CA sco Santa Cruz Operation, Santa Cruz, CA sequent Sequent Computer System, Inc., Beaverton, OR sgi Silicon Graphics, Inc., Mountain View, CA shell Shell Development Corp., Houston, TX simpact Simpact Assoc., San Diego, CA sjsca4 Schlumberger Technologies, San Jose, CA sun Sun Microsystems, Mountain View, CA td2cad Intel Corp., Santa Clara, CA teraida Teradyne EDA Inc., Santa Clara, CA theta Process Software Inc., Wellesley, MA turtlevax CIMLINC, Inc, Palo Alto, CA *ucbvax University of California, Berkeley, CA utcsri Univ. of Toronto, Computer Science, Toronto, CA vlsisj VLSI Technology Inc., San Jose, CA wyse Wyse Technology, San Jose, CA zehntel Zehntel, Inc., Walnut Creek, CA -- Paul Vixie DEC Western Research Lab <vixie@wrl.dec.com> Palo Alto, California ...!decwrl!vixie