home *** CD-ROM | disk | FTP | other *** search
/ A Beginner's Guide to the Internet / INTERNET.ISO / text / faqs / bbsinet1 / mx-rcvrs.faq < prev    next >
Encoding:
Text File  |  1996-05-06  |  11.4 KB  |  234 lines
  1.   An Explanation of MX-Receivers and Their Role in Handling Fido Mail
  2.   ===================================================================
  3.  
  4. Machines which are physically connected to the Internet each have a
  5. unique Internet Protocol address (often called an "IP address"),
  6. 4 decimal numbers between 0 and 254 separated by dots (ie: my workstation,
  7. zeus.ieee.org is 140.98.2.1).  These numbers are used in the headers of
  8. the encapsulated packets (all data is broken up into chunks and eack has
  9. a header showing origination and destination) transmitted over the Internet.
  10.  
  11. The "Domain Name Service" is a distributed system of having the data at
  12. different locations and is effectively a "database" of mappings between
  13. the "names" that machines are known as and their "IP addresses".
  14. In order to communicate with a system one's machine must get the
  15. IP-address of the machine it wants to talk to from the DNS first.
  16. These are stored in the DNS in what are known as "A" records.
  17. Machines which have IP-addresses exchange "mail" using a protocol
  18. called SMTP (Simple Mail Transfer Protocol), communicating on port 25
  19. of the set of IP sockets.
  20.  
  21. However, there are many machines which have "names" but are NOT connected
  22. physically to the Internet, those doing UUCP and other reasons.  In order
  23. to get mail to such a system,  the DNS contains an "MX" record.
  24. The "MX" record, instead of giving a dotted-quad IP-address,  holds the
  25. "name" of the system which *does* have an IP-address and knows how to get
  26. mail to the real destination system.  An "MX" record *must* point to
  27. the *real name* of the machine which is accepting mail for the destination
  28. system.  A machine may have several names, but the "MX" records *must*
  29. point to it's TRUE name (that which is returned by the `hostname` command
  30. on a UNIX system).  The machine which is pointed to by the "MX" record
  31. is known as the "MX-receiver" for the destination system.
  32.  
  33. The reason that the "MX" record *must* point to the TRUE name of the
  34. MX-receiver is that *it* will in turn query the DNS and will compare
  35. its `hostname` with any MX-records found.  The MX-records also have a
  36. number which is a "Precedence" number.  They are tried in order, but
  37. always skipping any MX-records which point to itself.  If the MX-record
  38. with the *lowest* precedence number points to itself, then it *must*
  39. have the proper rules in its mailer configuration to deliver the mail
  40. via means OTHER than SMTP, otherwise an error will result.
  41. This means that an "MX-receiver" system *must* install the proper handling
  42. in its configuration for the destination system *BEFORE* the "MX" record
  43. is installed in the DNS.  Otherwise,  errors can result, mail loops
  44. develop, and the mail cannot be delivered.
  45.  
  46. Here's a couple of examples of the DNS records from  .fidonet.org ...
  47. These are a *PARTIAL LISTING* as EXAMPLES only.
  48. The information shown here is *NOT* current.  For up-to-date DNS
  49. information for the .fidonet.org domain,  obtain the file FIDONET.DNS
  50. either via Anonymous-FTP from ftp.fidonet.org in the /pub/fidonet/info
  51. directory or via File-Request from 1:1/31.
  52.  
  53. ; ====================== begin example DNS ======================
  54. ; Nameserver info for FIDONET.ORG domain
  55. ; the original of this file resides in:
  56. ; zeus.ieee.org:/usr/local/ns/fidonet.org
  57. ;
  58. $ORIGIN fidonet.org.
  59. @       IN      SOA     ZEUS.IEEE.ORG. HOSTMASTER.FIDONET.FIDONET.ORG. (
  60.                         10303   ; serial (version of this file)
  61.                         86400   ; refresh once a day
  62.                         600     ; retry refresh every 10 minutes
  63.                         36000000; expire after 1000 hours (over week)
  64.                         86400   ; 259200        ; minimun TTL of 3 day
  65.                         )
  66.                 IN      NS      ZEUS.IEEE.ORG.
  67.                 IN      NS      POLARIS.LLNL.GOV.
  68. ;
  69. ;           Special Entries and Services
  70. ;           ----------------------------
  71. ;
  72. ns              IN      CNAME   zeus.ieee.org.
  73. fidonet         IN      CNAME   zeus.ieee.org.
  74. ;       an example where an "A" record exists but Mail is handled
  75. ;           by a different machine
  76. ftp             IN      A       140.98.1.1
  77.                 IN      MX      10 zeus.ieee.org.
  78.                 IN      MX      20 rab.ieee.org.
  79. ;
  80. ;           The gateway sites themselves
  81. ;           ----------------------------
  82. ;
  83. ;       if m2xenix is down, rain will queue mail for storage
  84. busker          IN      MX      10 m2xenix.psg.com. ;   1:105/14
  85.                 IN      MX      20 rain.psg.com.
  86. cmhgate         IN      MX      10 cis.OHIO-STATE.EDU. ; 1:226/20
  87. compsol         IN      MX      10 sserve.cc.adfa.oz.au. ; 3:622/407
  88. ehsnet          IN      MX      10 uxc.cso.uiuc.edu. ;  1:233/13
  89. f-454           IN      MX      10 uucp-gw.cc.uh.edu. ; 1:106/1024
  90. ;       mail for 'fidonews' is queued thru 1:1/31 for delivery to 1:1/23
  91. ;           special handling is need in the mailer config on zeus
  92. fidonews        IN      MX      10 zeus.ieee.org. ; re-directed to 1:1/23
  93. ;       these sites are handled specially by zeus which remaps the
  94. ;           mail to a bang!path format and sends it back out via SMTP
  95. ;           these will be phased out over time
  96. fquest          IN      MX      10 zeus.ieee.org. ;     1:19/23
  97. gisatl          IN      MX      10 zeus.ieee.org. ;     1:133/411
  98. gstore          IN      MX      10 zeus.ieee.org. ;     1:103/234
  99. ;       my home needs an Address record for SLIP to function when I use it
  100. ;           mail is specially handled by re-naming to mcastl.ieee.org and
  101. ;           sending thru my gateway at 1:107/10
  102. mcastl          IN      A       140.98.200.3
  103.                 IN      MX      10 ZEUS.IEEE.ORG. ;     1:107/309
  104.                 IN      MX      20 RAB.IEEE.ORG.
  105.                 IN      MX      30 TAB.IEEE.ORG.
  106. mcws            IN      MX      10 elroy.jpl.nasa.gov. ; 1:102/851
  107. mechanic        IN      MX      10 myrddin.sybus.com. ; 1:3603/330
  108. ofa123          IN      MX      10 ics.uci.edu. ;       1:103/208
  109. rochgte         IN      MX      10 valhalla.ee.rochester.edu. ;1:3613/333
  110. ;       David Dodell's Waffle system is actually in between
  111. ;               enuucp and solitud
  112. solitud         IN      MX      10 enuucp.eas.asu.edu. ;1:300/23
  113. ;       Nameserver "authority" is delegated to ns.web.apc.org for the
  114. ;           sub-domain of "webfido"
  115. webfido         IN      NS      ns.web.apc.org. ;       1:250/406
  116.                 IN      NS      ns.uunet.ca.
  117.                 IN      NS      ns.UU.NET.
  118. zorro9          IN      MX      10 talcott.harvard.edu. ;1:16/390
  119. ;
  120. ;
  121. ;   Each Net within FidoNet has a wildcard MX-record.
  122. ;   The IP site which the mail is directed to is expected to have
  123. ;   installed the sendmail or smail rules necessary to queue
  124. ;   ALL mail for  *.nNET.z#.fidonet.org  for pickup by the
  125. ;   appropriate gateway site.
  126. ;
  127. ;   A wildcard MX-record is maintained for each Zone, so that
  128. ;   there is always a "default" gateway for any new Nets which
  129. ;   are placed in the Nodelist by the *C's.
  130. ;   At present, the Zone-1 "default" MX points to zeus.ieee.org,
  131. ;   which queues mail for gating by 1:1/31.
  132. ;
  133. ;   Where possible, the gateway sitename is shown as a Comment
  134. ;   behind a semi-colon after the MX-record.
  135. ;
  136. ;
  137. $ORIGIN z1.fidonet.org.
  138. ;
  139. ;               Zone 1 by Net (examples)
  140. ;               =============
  141. ;
  142. *.n260  IN      MX      10 valhalla.ee.rochester.edu. ; rochgte
  143. *.n261  IN      MX      10 relay1.UU.NET. ; blkcat
  144.         IN      MX      10 relay2.UU.NET. ; blkcat
  145. ;
  146. *.n104  IN      MX      10 ncar.ucar.edu.
  147. *.n300  IN      MX      10 noao.edu.
  148. *.n310  IN      MX      10 ncar.ucar.edu.
  149. *.n312  IN      MX      10 enuucp.eas.asu.edu.
  150. ;
  151. *.n16   IN      MX      10 talcott.harvard.edu. ; zorro9
  152. *.n101  IN      MX      10 talcott.harvard.edu. ; zorro9
  153. *.n141  IN      MX      10 bunker.shel.isc-br.com.
  154. *.n322  IN      MX      10 talcott.harvard.edu. ; zorro9
  155. *.n333  IN      MX      10 talcott.harvard.edu. ; zorro9
  156. *.n325  IN      MX      10 sadye.emba.uvm.edu. ; wsyd
  157. ;
  158. *.n18   IN      MX      10 cybernet.cse.fau.edu. ; branch
  159. *.n112  IN      MX      10 cybernet.cse.fau.edu. ; branch
  160. *.n116  IN      MX      10 cybernet.cse.fau.edu. ; branch
  161. *.n123  IN      MX      10 cybernet.cse.fau.edu. ; branch
  162. *.n3603 IN      MX      10 myrddin.sybus.com. ; mechanic
  163. *.n3604 IN      MX      10 cybernet.cse.fau.edu. ; branch
  164. *.n3605 IN      MX      10 cybernet.cse.fau.edu. ; branch
  165. ;
  166. ;       default Zone-1 forwarding
  167. ;       -------------------------
  168. ;
  169. ;   Wildcard record for *.z1.fidonet.org - handled via 1:1/31
  170. ;           All Nets in Zone-1 which do not have its own MX-record
  171. ;           will fall thru to here
  172. ;
  173. *       IN      MX      10 zeus.ieee.org.
  174.         IN      MX      20 rab.ieee.org.
  175. ;
  176. ; (For Zone-2, Randy gates traffic and sends across the pond to
  177. ;  Henk Wevers for routing.  There seem to be problems in FidoNet
  178. ;  routing on the European side of the pond from there.)
  179. ;
  180. $ORIGIN z2.fidonet.org.
  181. *       IN      MX      10 m2xenix.psg.com.
  182.         IN      MX      20 rain.psg.com.
  183. ;
  184. $ORIGIN z3.fidonet.org.
  185. *.n620  IN      MX      10 sserve.cc.adfa.oz.au.        ; compsol
  186. *.n622  IN      MX      10 sserve.cc.adfa.oz.au.        ; compsol
  187. *       IN      MX      10 jabaru.cec.edu.au.
  188. ;
  189. ;
  190. ; (Note: the Full DNS file is always available via File-Request from
  191. ;       1:1/31 or ; 1:107/309 as the filename FIDONET.ORG)
  192. ;
  193. ; ========================== end of example DNS ========================
  194.  
  195. This is extremely important for the .fidonet.org domain to function
  196. properly, since the "Hostmaster" (me),  maintaining the MX-records for
  197. the domain is very dependent on all the MX-receivers having the proper
  198. configurations.  Many times,  a site will hook up with someone who is
  199. willing to pass mail/news to them via UUCP, but is NOT physically
  200. connected to the Internet (does NOT have an IP-address and running
  201. an SMTP mailer).  Now what?  This machine may also be a hop or two away
  202. from the nearest "IP" node in the Path.  Now we're dependent on *ALL* of
  203. the systems in that path to have the proper configurations for handling
  204. mail for the new site.  Mostly, these systems depend on the "UUCP Maps"
  205. for their path configurations.  Now we have a Catch-22 situation.
  206. I cannot submit the Map until the site is "tested" and the MX-record
  207. installed in the DNS.  Even once I do, it can take weeks or months
  208. before the Map appears in the Newsgroup comp.mail.maps (fully Moderated
  209. and usually comes thru monthly).  In the meantime,  the configurations
  210. on all the systems in the dependent path are "broken" waiting on that
  211. all-important Map for the new site.  Mail goes into a real "loop".
  212.  
  213. To add insult to the whole process, the system names contained in a
  214. UUCP Map (which most new sites will construct and send me) do NOT contain
  215. the "Fully Qualified Domain Name" (the dotted name) of the systems
  216. they connect to.  Now it becomes a matter of guesswork to see if any of
  217. the site(s) they connect to have an IP-address and can qualify as
  218. an MX-receiver.
  219.  
  220. For the reasons outlined in the last two paragraphs,  it is essential
  221. for a new site to hook up with a system that has an IP-address and can
  222. act as their MX-receiver.  It's much easier if the proper Map procedures
  223. were followed and their UUCP Map submission contained the proper
  224. "#F mx.receiver.domain" line in their Maps, giving me the
  225. Fully-Qualified-Domain-Name of their MX-receiver.
  226. It's bad enough that I have to hand-edit each and every Map submitted,
  227. because our wonderful FidoNet editors expand TABS to spaces and the
  228. submission I send to the UUCP Map Coordinators *must* contain the proper
  229. TAB separators, not spaces!
  230.  
  231.                                   Burt Juda
  232.                                   Hostmaster, .fidonet.org
  233.  
  234.