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