home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / phrack1 / phrack30.005 < prev    next >
Encoding:
Text File  |  2003-06-11  |  21.4 KB  |  455 lines

  1.  
  2.                 ==Phrack Inc.==
  3.  
  4.              Volume Three, Issue 30, File #5 of 12
  5.  
  6.             ()()()()()()()()()()()()()()()()()()()
  7.             ()                    ()
  8.             ()        The DECWRL Mail Gateway    ()
  9.             ()                    ()
  10.             ()           by Dedicated Link    ()
  11.             ()                    ()
  12.             ()          September 20, 1989    ()
  13.             ()                    ()
  14.             ()()()()()()()()()()()()()()()()()()()
  15.  
  16.  
  17. INTRODUCTION
  18.  
  19. DECWRL is a mail gateway computer operated by Digital's Western Research
  20. Laboratory in Palo Alto, California.  Its purpose is to support the interchange
  21. of electronic mail between Digital and the "outside world."
  22.  
  23. DECWRL is connected to Digital's Easynet, and also to a number of different
  24. outside electronic mail networks.  Digital users can send outside mail by
  25. sending to DECWRL::"outside-address", and digital users can also receive mail
  26. by having your correspondents route it through DECWRL.    The details of incoming
  27. mail are more complex, and are discussed below.
  28.  
  29. It is vitally important that Digital employees be good citizens of the networks
  30. to which we are connected.  They depend on the integrity of our user community
  31. to ensure that tighter controls over the use of the gateway are not required.
  32. The most important rule is "no chain letters," but there are other rules
  33. depending on whether the connected network that you are using is commercial or
  34. non-commercial.
  35.  
  36. The current traffic volume (September 1989) is about 10,000 mail messages per
  37. day and about 3,000 USENET messages per day.  Gatewayed mail traffic has
  38. doubled every year since 1983.    DECWRL is currently a Vax 8530 computer with 48
  39. megabytes of main memory, 2500 megabytes of disk space, 8 9600-baud (Telebit)
  40. modem ports, and various network connections.  They will shortly be upgrading
  41. to a Vax 8650 system.  They run Ultrix 3.0 as the base operating system.
  42.  
  43.  
  44. ADMINISTRATION
  45.  
  46. The gateway has engineering staff, but no administrative or clerical staff.
  47. They work hard to keep it running, but they do not have the resources to answer
  48. telephone queries or provide tutorials in its use.
  49.  
  50. They post periodic status reports to the USENET newsgroup dec.general.    Various
  51. helpful people usually copy these reports to the VAXNOTES "gateways" conference
  52. within a day or two.
  53.  
  54.  
  55. HOW TO SEND MAIL
  56.  
  57. DECWRL is connected to quite a number of different mail networks.  If you were
  58. logged on directly to it, you could type addresses directly, e.g.
  59.  
  60.     To: strange!foreign!address.
  61.  
  62. But since you are not logged on directly to the gateway, you must send mail so
  63. that when it arrives at the gateway, it will be sent as if that address had
  64. been typed locally.
  65.  
  66.  
  67. * Sending from VMS
  68.  
  69. If you are a VMS user, you should use NMAIL, because VMS mail does not know how
  70. to requeue and retry mail when the network is congested or disconnected.  From
  71. VMS, address your mail like this:
  72.  
  73.     To: nm%DECWRL::"strange!foreign!address"
  74.  
  75. The quote characters (") are important, to make sure that VMS doesn't try to
  76. interpret strange!foreign!address itself.  If you are typing such an address
  77. inside a mail program, it will work as advertised.  If you are using DCL and
  78. typing directly to the command line, you should beware that DCL likes to remove
  79. quotes, so you will have to enclose the entire address in quotes, and then put
  80. two quotes in every place that one quote should appear in the address:
  81.  
  82.     $ mail test.msg "nm%DECWRL::""foreign!addr""" /subj="hello"
  83.  
  84. Note the three quotes in a row after foreign!addr.  The first two of them are
  85. doubled to produce a single quote in the address, and the third ends the
  86. address itself (balancing the quote in front of the nm%).
  87.  
  88. Here are some typical outgoing mail addresses as used from a VMS system:
  89.  
  90.     To: nm%DECWRL::"lll-winkin!netsys!phrack"     To:
  91. nm%DECWRL::"postmaster@msp.pnet.sc.edu"     To:
  92. nm%DECWRL::"netsys!phrack@uunet.uu.net"     To:
  93. nm%DECWRL::"phrackserv@CUNYVM.bitnet"     To:
  94. nm%DECWRL::"Chris.Jones@f654.n987.z1.fidonet.org"
  95.  
  96.  
  97. * Sending from Ultrix
  98.  
  99. If your Ultrix system has been configured for it, then you can, from your
  100. Ultrix system, just send directly to the foreign address, and the mail software
  101. will take care of all of the gateway routing for you.  Most Ultrix systems in
  102. Corporate Research and in the Palo Alto cluster are configured this way.
  103.  
  104. To find out whether your Ultrix system has been so configured, just try it and
  105. see what happens.  If it doesn't work, you will receive notification almost
  106. instantly.
  107.  
  108.     NOTE:  The Ultrix mail system is extremely flexible; it is almost
  109. completely configurable by the customer.  While this is valuable to
  110. customers, it makes it very difficult to write global instructions for       the
  111. use of Ultrix mailers, because it is possible that the local changes     have
  112. produced something quite unlike the vendor-delivered mailer.  One of     the
  113. popular changes is to tinker with the meaning of quote characters (")     in
  114. Ultrix addresses.  Some systems consider that these two addresses are      the
  115. same:
  116.  
  117.     site1!site2!user@host.dec.com
  118.  
  119.     and
  120.  
  121.     "site1!site2!user"@host.dec.com
  122.  
  123.     while others are configured so that one form will work and the other
  124. will not.  All of these examples use the quotes.  If you have trouble
  125. getting the examples to work, please try them again without the quotes.
  126. Perhaps your Ultrix system is interpreting the quotes differently.
  127.  
  128. If your Ultrix system has an IP link to Palo Alto (type "/etc/ping
  129. decwrl.dec.com" to find out if it does), then you can route your mail to the
  130. gateway via IP.  This has the advantage that your Ultrix mail headers will
  131. reach the gateway directly, instead of being translated into DECNET mail
  132. headers and then back into Ultrix at the other end.  Do this as follows:
  133.  
  134.     To: "alien!address"@decwrl.dec.com
  135.  
  136. The quotes are necessary only if the alien address contains a ! character, but
  137. they don't hurt if you use them unnecessarily.  If the alien address contains
  138. an "@" character, you will need to change it into a "%" character.  For
  139. example, to send via IP to joe@widget.org, you should address the mail
  140.  
  141.     To: "joe%widget.org"@decwrl.dec.com
  142.  
  143. If your Ultrix system has only a DECNET link to Palo Alto, then you should
  144. address mail in much the same way that VMS users do, save that you should not
  145. put the nm% in front of the address:
  146.  
  147.     To: DECWRL::"strange!foreign!address"
  148.  
  149. Here are some typical outgoing mail addresses as used from an Ultrix system
  150. that has IP access.  Ultrix systems without IP access should use the same
  151. syntax as VMS users, except that the nm% at the front of the address should not
  152. be used.
  153.  
  154.     To: "lll-winken!netsys!phrack"@decwrl.dec.com     To:
  155. "postmaster%msp.pnet.sc.edu"@decwrl.dec.com     To:
  156. "phrackserv%CUNYVM.bitnet"@decwrl.dec.com     To:
  157. "netsys!phrack%uunet.uu.net"@decwrl.dec.com     To:
  158. "Chris.Jones@f654.n987.z1.fidonet.org"@decwrl.dec.com
  159.  
  160.  
  161. DETAILS OF USING OTHER NETWORKS
  162.  
  163. All of the world's computer networks are connected together, more or less, so
  164. it is hard to draw exact boundaries between them.  Precisely where the Internet
  165. ends and UUCP begins is a matter of interpretation.
  166.  
  167. For purposes of sending mail, though, it is convenient to divide the network
  168. universe into these categories:
  169.  
  170. Easynet     Digital's internal DECNET network.  Characterized by addresses
  171.          of the form NODE::USER.  Easynet can be used for commercial
  172.          purposes.
  173.  
  174. Internet    A collection of networks including the old ARPAnet, the NSFnet,
  175.          the CSnet, and others.  Most international research,
  176.          development, and educational organizations are connected in
  177.          some fashion to the Internet.    Characterized by addresses of
  178.          the form user@site.subdomain.domain.  The Internet itself
  179.          cannot be used for commercial purposes.
  180.  
  181. UUCP        A very primitive network with no management, built with
  182.          auto-dialers phoning one computer from another.  Characterized
  183.          by addresses of the form place1!place2!user.  The UUCP network
  184.          can be used for commercial purposes provided that none of the
  185.          sites through which the message is routed objects to that.
  186.  
  187. USENET        Not a network at all, but a layer of software built on top of
  188.          UUCP and Internet.
  189.  
  190. BITNET        An IBM-based network linking primarily educational sites.
  191.         Digital users can send to BITNET as if it were part of
  192.         Internet, but BITNET users need special instructions for
  193.         reversing the process.    BITNET cannot be used for commercial
  194.         purposes.
  195.  
  196. Fidonet     A network of personal computers.  I am unsure of the status of
  197.         using Fidonet for commercial purposes, nor am I sure of its
  198.         efficacy.
  199.  
  200.  
  201. DOMAINS AND DOMAIN ADDRESSING
  202.  
  203. There is a particular network called "the Internet;" it is somewhat related to
  204. what used to be "the ARPAnet."  The Internet style of addressing is flexible
  205. enough that people use it for addressing other networks as well, with the
  206. result that it is quite difficult to look at an address and tell just what
  207. network it is likely to traverse.  But the phrase "Internet address" does not
  208. mean "mail address of some computer on the Internet" but rather "mail address
  209. in the style used by the Internet."  Terminology is even further confused
  210. because the word "address" means one thing to people who build networks and
  211. something entirely different to people who use them.  In this file an "address"
  212. is something like "mike@decwrl.dec.com" and not "192.1.24.177" (which is what
  213. network engineers would call an "internet address").
  214.  
  215. The Internet naming scheme uses hierarchical domains, which despite their title
  216. are just a bookkeeping trick.  It doesn't really matter whether you say
  217. NODE::USER or USER@NODE, but what happens when you connect two companies'
  218. networks together and they both have a node ANCHOR??  You must, somehow,
  219. specify which ANCHOR you mean.    You could say ANCHOR.DEC::USER or
  220. DEC.ANCHOR::USER or USER@ANCHOR.DEC or USER@DEC.ANCHOR.  The Internet
  221. convention is to say USER@ANCHOR.DEC, with the owner (DEC) after the name
  222. (ANCHOR).
  223.  
  224. But there could be several different organizations named DEC.  You could have
  225. Digital Equipment Corporation or Down East College or Disabled Education
  226. Committee.  The technique that the Internet scheme uses to resolve conflicts
  227. like this is to have hierarchical domains.  A normal domain isn't DEC or
  228. STANFORD, but DEC.COM (commercial) and STANFORD.EDU (educational).  These
  229. domains can be further divided into ZK3.DEC.COM or CS.STANFORD.EDU.  This
  230. doesn't resolve conflicts completely, though:  both Central Michigan University
  231. and Carnegie-Mellon University could claim to be CMU.EDU.  The rule is that the
  232. owner of the EDU domain gets to decide, just as the owner of the CMU.EDU gets
  233. to decide whether the Electrical Engineering department or the Elementary
  234. Education department gets subdomain EE.CMU.EDU.
  235.  
  236. The domain scheme, while not perfect, is completely extensible.  If you have
  237. two addresses that can potentially conflict, you can suffix some domain to the
  238. end of them, thereby making, say, decwrl.UUCP be somehow different from
  239. DECWRL.ENET.
  240.  
  241. DECWRL's entire mail system is organized according to Internet domains, and in
  242. fact we handle all mail internally as if it were Internet mail.  Incoming mail
  243. is converted into Internet mail, and then routed to the appropriate domain; if
  244. that domain requires some conversion, then the mail is converted to the
  245. requirements of the outbound domain as it passes through the gateway.  For
  246. example, they put Easynet mail into the domain ENET.DEC.COM, and they put
  247. BITNET mail into the domain BITNET.
  248.  
  249. The "top-level" domains supported by the DECWRL gateway are these:
  250.  
  251. .EDU        Educational institutions.COM    Commercial institutions
  252. .GOV        Government institutions .MIL    Military institutions
  253. .ORG        Various organizations   .NET    Network operations
  254. .BITNET     The BITNET            .MAILNET    The MAILNET
  255. .??        2-character country code for routing to other countries
  256. .OZ        Part of the Australian (.AU) name space.
  257.  
  258. 2-character country codes include UK (United Kingdom), FR (France), IT (Italy),
  259. CA (Canada), AU (Australia), etc.  These are the standard ISO 2-character
  260. country codes.
  261.  
  262.  
  263. MAILING TO EASYNET
  264.  
  265. To mail to user SPRINTER at node WASH (which is DECNET address WASH::SPRINTER),
  266. Internet mail should be addressed to sprinter@wash.enet.dec.com.  Easynet
  267. addresses are not case-dependent; WASH and wash are the same node name and
  268. SPRINTER and sprinter are the same user name.
  269.  
  270. Sites that are not directly connected to the Internet may have difficulty with
  271. Internet addresses like wash.enet.dec.com.  They can send into the Easynet by
  272. explicitly routing the mail through DECWRL.  From domain-based Internet
  273. mailers, the address would be sprinter%wash.enet@decwrl.dec.com.  From UUCP
  274. mailers, the address would be decwrl!wash.enet!sprinter. Some Internet mailers
  275. require the form <@decwrl.dec.com:sprinter@wash.enet>.    (This last form is the
  276. only technically correct form of explicit route, but very few Internet sites
  277. support it.)
  278.  
  279. The DECWRL gateway also supports various obsolete forms of addressing that are
  280. left over from the past.  In general they support obsolete address forms for
  281. two years after the change, and then remove it.
  282.  
  283.  
  284. MAILING TO DIGITAL ALL-IN-1 USERS
  285.  
  286. Some Easynet users do not have a direct DECNET node address, but instead read
  287. their mail with All-in-1, which uses addresses of the form "Nate State @UCA".
  288. Here "UCA" is a Digital location code name.  To route mail to such people, send
  289. to Nate.State@UCA.MTS.DEC.COM.    Mail received from the All-in-1 mailer is
  290. unreplyable, and in fact unless the respondent tells you his return address in
  291. the body of the message, it is not normally possible even to puzzle out the
  292. return address by studying the message header.    Mail from All-in-1 to Easynet
  293. passes through a gateway program that does not produce valid return addresses.
  294.  
  295.  
  296. MAILING TO THE INTERNET
  297.  
  298. DECWRL's mailer is an Internet mailer, so to mail to an Internet site, just use
  299. its address.  If you are having trouble determining the Internet address, you
  300. might find that the Ultrix host table /etc/hosts.txt is useful.  If you can't
  301. find one anywhere else, there's one on DECWRL.  See the comments above under
  302. "how to send mail" for details about making sure that the mail program you are
  303. using has correctly interpreted an address.
  304.  
  305.  
  306. MAILING TO UUCP
  307.  
  308. UUCP mail is manually routed by the sender, using ! as the separator character.
  309. Thus, the address xxx!yyy!zzz!user means to dial machine xxx and relay to it
  310. the mail, with the destination address set to yyy!zzz!user.  That machine in
  311. turn dials yyy, and the process repeats itself.
  312.  
  313. To correctly address UUCP mail, you must know a working path through the UUCP
  314. network.  The database is sufficiently chaotic that automatic routing does not
  315. work reliably (though many sites perform automatic routing anyhow).  The
  316. information about UUCP connectivity is distributed in the USENET newsgroup
  317. comp.mail.maps; many sites collect this data and permit local queries of it.
  318.  
  319. At the end of this file is a list of the UUCP nodes to which DECWRL currently
  320. has a working connection.
  321.  
  322.  
  323. MAILING TO USENET
  324.  
  325. Usenet is not a network.  It's a software layer, and it spans several networks.
  326. Many people say "Usenet" when they really mean UUCP.  You can post a message to
  327. a Usenet newsgroup by mailing it to "name@usenet" at DECWRL.  For example,
  328. mailing from VMS to this address:
  329.  
  330.     nm%DECWRL::"alt.cyberpunk@usenet"
  331.  
  332. causes the mail message to be posted as an article to the Usenet newsgroup
  333. alt.cyberpunk.    It is better to use Usenet software for posting articles, as
  334. more features are available that way, such as restricted distributions,
  335. crossposting, and cancellation of "wish I hadn't sent that" articles.
  336.  
  337.  
  338. MAILING TO BITNET
  339.  
  340. Legend has it that the "BIT" in BITNET stands for "Because It's There" or
  341. "Because It's Time."  It is a network consisting primarily of IBM computers.  A
  342. native BITNET address is something like "OMAR at STANFORD", but when translated
  343. into our Internet format it becomes omar@stanford.bitnet.  Once translated into
  344. Internet form, a BITNET address is used just like any other Internet address.
  345.  
  346.  
  347. MAILING TO FIDONET
  348.  
  349. By comparison with the other linked networks, Fidonet has an addressing
  350. complexity bordering on the bizarre.  The Fidonet people have provided me with
  351. this description:
  352.  
  353. Each Fidonet node is a member of a "network," and may have subsidiary nodes
  354. called "point nodes."  A typical Fido address is "1:987/654" or "987/654"; a
  355. typical Fido "point node" address is "1:987/654.32" or "987/654.32".  This is
  356. zone 1, network 987, Fido (node) 654, "point node" 32.  If the zone number is
  357. missing, assume it is zone 1.  The zone number must be supplied in the outgoing
  358. message.
  359.  
  360. To send a message to Chris Jones on Fidonet address 1:987/654, use the address
  361. Chris.Jones@f654.n987.z1.fidonet.org.  To send a message to Mark Smith at
  362. Fidonet node 987/654.32, use address Mark.Smith@p32.f654.n987.z1.fidonet.org.
  363. Use them just like any other Internet address.
  364.  
  365. Sometimes the return addresses on messages from Fidonet will look different.
  366. You may or may not be able to reply to them.
  367.  
  368. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  369.  
  370. Appendix:  List of UUCP Neighbor Sites
  371.  
  372. This table shows most of the sites that DECWRL dials directly via UUCP.  You
  373. may find it useful to help you construct a UUCP route to a particular
  374. destination.  Those sites marked with "*" are major UUCP routing nodes.  You
  375. should prefer UUCP routes that use these sites as the first hop from DECWRL.
  376. Case is significant in UUCP host names.
  377.  
  378.       3comvax     3Com Corporation, Santa Clara, CA
  379.       abvax     Allen-Bradley Company, Highland Heights, OH
  380.       acad     Autodesk, Inc, Sausalito, CA
  381.       adobe     Adobe Systems Inc., Mountain View, CA
  382.       alberta     University of Alberta, Edmonton, Alberta, Canada
  383.       allegra     AT&T Bell Laboratories, Murray Hill, NJ
  384.       *amdahl      Amdahl Corp., Sunnyvale, CA
  385.       amdcad     Advanced Micro Devices, Sunnyvale, CA
  386.       ames     NASA Ames Research Center, Mountain View, CA
  387.       *apple      Apple Computers, Cupertino, CA
  388.       ardent     Ardent Computer Corp., Sunnyvale, CA
  389.       argosy     MassPar Computer Corp., Sunnyvale, CA
  390.        atha      Athabasca University, Athabasca, Alberta, Canada
  391.       athertn     Atherton Technology, Sunnyvale, CA
  392.       *att      AT&T Bell Laboratories, Columbus, Ohio
  393.       avsd     Ampex Corporation, Redwood City, CA
  394.       cae780     Tektronix Inc. (Santa Clara Field Office) Santa Clara, CA
  395.       chip     M/A-COM Government Systems, San Diego, CA
  396.       claris     Claris Corporation, Mountain View, CA
  397.       daisy     Daisy Systems, Mountain View, CA
  398.       decuac     DEC/Ultrix Applications Ctr, Landover, MD
  399.      *decvax     DEC/Ultrix Engineering, Nashua, NH
  400.       dsinc     Datacomp Systems, Inc, Huntington Valley, PA
  401.       eda     EDA Systems Inc., Santa Clara, CA
  402.       emerald     Emerald Systems Corp., San Diego, CA
  403.       escd     Evans and Sutherland Computer Division, Mountain View, CA
  404.       esunix     Evans and Sutherland Corp., Salt Lake City, UT
  405.       fluke     John Fluke Manufacturing, Everett, WA
  406.       gryphon     Trailing Edge Technology, Redondo Beach, CA
  407.       handel     Colorodo State Univ., CS Dept., Ft. Collins, CO
  408.       hoptoad     Nebula Consultants, San Francisco, CA
  409.      *hplabs     Hewlett Packard Research Labs, Palo Alto, CA
  410.       ide     Interactive Development Environments, San Francisco, CA
  411.       idi     Intelligent Decisions, Inc., San Jose, CA
  412.       imagen     Imagen Corp., Santa Clara, CA
  413.       intelca       Intel Corp., Santa Clara, CA
  414.       limbo     Intuitive Systems, Los Altos, CA
  415.       logitech     Logitech, Inc., Palo Alto, CA
  416.       megatest     Megatest Corp., San Jose, CA
  417.       metaphor     Metaphor Corp., Mountain View, CA
  418.       microsoft  Microsoft, Bellevue, WA
  419.       mindcrf     Mindcraft Corp., Palo Alto, CA
  420.       mips     MIPS Computer Systems, Mountain View, CA
  421.       mntgfx     Mentor Graphics Corp., Beaverton, OR
  422.       mordor     Lawrence Livermore National Lab, Livermore, CA
  423.       mtu     Michigan Tech Univ., Houghton, MI
  424.       mtxinu     Mt. Xinu, Berkeley, CA
  425.       nsc     National Semiconductor Corp., Sunnyvale, CA
  426.       oli-stl     Olivetti Software Techn. Lab, Menlo Park, CA
  427.       oracle     Oracle Corp., Belmont, CA
  428.      *pacbell     Pacific Bell, San Ramon, CA
  429.       parcplace  Parc Place Systems, Palo Alto, CA
  430.       purdue     Purdue University, West Lafayette, IN
  431.      *pyramid     Pyramid Technology Corporation, Mountain View, CA
  432.       qubix     Qubix Graphic Systems, San Jose, CA
  433.       quintus     Quintus Computer Systems, Mountain View, CA
  434.       research     AT&T Bell Laboratories, Murray Hill, NJ
  435.       riacs     Res.Inst. for Adv. Compu. Sci., Mountain View, CA
  436.       rtech     Relational Technology Inc., Alameda, CA
  437.       sci     Silicon Compilers, San Jose, CA
  438.       sco     Santa Cruz Operation, Santa Cruz, CA
  439.       sequent     Sequent Computer System, Inc., Beaverton, OR
  440.       sgi     Silicon Graphics, Inc., Mountain View, CA
  441.       shell     Shell Development Corp., Houston, TX
  442.       simpact     Simpact Assoc., San Diego, CA
  443.       sjsca4     Schlumberger Technologies, San Jose, CA
  444.       sun     Sun Microsystems, Mountain View, CA
  445.       td2cad     Intel Corp., Santa Clara, CA
  446.       teraida     Teradyne EDA Inc., Santa Clara, CA
  447.       theta     Process Software Inc., Wellesley, MA
  448.       turtlevax  CIMLINC, Inc, Palo Alto, CA
  449.      *ucbvax     University of California, Berkeley, CA
  450.       utcsri     Univ. of Toronto, Computer Science, Toronto, CA
  451.       vlsisj     VLSI Technology Inc., San Jose, CA
  452.       wyse     Wyse Technology, San Jose, CA
  453.       zehntel     Zehntel, Inc., Walnut Creek, CA
  454. _______________________________________________________________________________
  455.