Return to rfc974.lpr CVS log

Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc

Annotation of 43BSDReno/usr.sbin/named/doc/rfc974.lpr, revision 1.1

1.1     ! root        1: 
        !             2: 
        !             3: Network Working Group                                    Craig Partridge
        !             4: Request for Comments: 974                 CSNET CIC BBN Laboratories Inc
        !             5:                                                             January 1986
        !             6: 
        !             7:                    MAIL ROUTING AND THE DOMAIN SYSTEM
        !             8: 
        !             9: 
        !            10: Status of this Memo
        !            11: 
        !            12:    This RFC presents a description of how mail systems on the Internet
        !            13:    are expected to route messages based on information from the domain
        !            14:    system described in RFCs 882, 883 and 973.  Distribution of this memo
        !            15:    is unlimited.
        !            16: 
        !            17: Introduction
        !            18: 
        !            19:    The purpose of this memo is to explain how mailers are to decide how
        !            20:    to route a message addressed to a given Internet domain name.  This
        !            21:    involves a discussion of how mailers interpret MX RRs, which are used
        !            22:    for message routing.  Note that this memo makes no statement about
        !            23:    how mailers are to deal with MB and MG RRs, which are used for
        !            24:    interpreting mailbox names.
        !            25: 
        !            26:    Under RFC-882 and RFC-883 certain assumptions about mail addresses
        !            27:    have been changed.  Up to now, one could usually assume that if a
        !            28:    message was addressed to a mailbox, for example, at LOKI.BBN.COM,
        !            29:    that one could just open an SMTP connection to LOKI.BBN.COM and pass
        !            30:    the message along.  This system broke down in certain situations,
        !            31:    such as for certain UUCP and CSNET hosts which were not directly
        !            32:    attached to the Internet, but these hosts could be handled as special
        !            33:    cases in configuration files (for example, most mailers were set up
        !            34:    to automatically forward mail addressed to a CSNET host to
        !            35:    CSNET-RELAY.ARPA).
        !            36: 
        !            37:    Under domains, one cannot simply open a connection to LOKI.BBN.COM,
        !            38:    but must instead ask the domain system where messages to LOKI.BBN.COM
        !            39:    are to be delivered. And the domain system may direct a mailer to
        !            40:    deliver messages to an entirely different host, such as SH.CS.NET.
        !            41:    Or, in a more complicated case, the mailer may learn that it has a
        !            42:    choice of routes to LOKI.BBN.COM.  This memo is essentially a set of
        !            43:    guidelines on how mailers should behave in this more complex world.
        !            44: 
        !            45:    Readers are expected to be familiar with RFCs 882, 883, and the
        !            46:    updates to them (e.g., RFC-973).
        !            47: 
        !            48: 
        !            49: 
        !            50: 
        !            51: 
        !            52: 
        !            53: 
        !            54: 
        !            55: 
        !            56: Partridge                                                       [Page 1]
        !            57: 
        !            58: 
        !            59: 
        !            60: RFC 974                                                     January 1986
        !            61: Mail Routing and the Domain System
        !            62: 
        !            63: 
        !            64: What the Domain Servers Know
        !            65: 
        !            66:    The domain servers store information as a series of resource records
        !            67:    (RRs), each of which contains a particular piece of information about
        !            68:    a given domain name (which is usually, but not always, a host).  The
        !            69:    simplest way to think of a RR is as a typed pair of datum, a domain
        !            70:    name matched with relevant data, and stored with some additional type
        !            71:    information to help systems determine when the RR is relevant.  For
        !            72:    the purposes of message routing, the system stores RRs known as MX
        !            73:    RRs. Each MX matches a domain name with two pieces of data, a
        !            74:    preference value (an unsigned 16-bit integer), and the name of a
        !            75:    host.  The preference number is used to indicate in what order the
        !            76:    mailer should attempt deliver to the MX hosts, with the lowest
        !            77:    numbered MX being the one to try first.  Multiple MXs with the same
        !            78:    preference are permitted and have the same priority.
        !            79: 
        !            80:    In addition to mail information, the servers store certain other
        !            81:    types of RR's which mailers may encounter or choose to use.  These
        !            82:    are: the canonical name (CNAME) RR, which simply states that the
        !            83:    domain name queried for is actually an alias for another domain name,
        !            84:    which is the proper, or canonical, name; and the Well Known Service
        !            85:    (WKS) RR, which stores information about network services (such as
        !            86:    SMTP) a given domain name supports.
        !            87: 
        !            88: General Routing Guidelines
        !            89: 
        !            90:    Before delving into a detailed discussion of how mailers are expected
        !            91:    to do mail routing, it would seem to make sense to give a brief
        !            92:    overview of how this memo is approaching the problems that routing
        !            93:    poses.
        !            94: 
        !            95:    The first major principle is derived from the definition of the
        !            96:    preference field in MX records, and is intended to prevent mail
        !            97:    looping.  If the mailer is on a host which is listed as an MX for the
        !            98:    destination host, the mailer may only deliver to an MX which has a
        !            99:    lower preference count than its own host.
        !           100: 
        !           101:    It is also possible to cause mail looping because routing information
        !           102:    is out of date or incomplete.  Out of date information is only a
        !           103:    problem when domain tables are changed.  The changes will not be
        !           104:    known to all affected hosts until their resolver caches time out.
        !           105:    There is no way to ensure that this will not happen short of
        !           106:    requiring mailers and their resolvers to always send their queries to
        !           107:    an authoritative server, and never use data stored in a cache.  This
        !           108:    is an impractical solution, since eliminating resolver caching would
        !           109:    make mailing inordinately expensive.  What is more, the out-of-date
        !           110:    RR problem should not happen if, when a domain table is changed,
        !           111: 
        !           112: 
        !           113: Partridge                                                       [Page 2]
        !           114: 
        !           115: 
        !           116: 
        !           117: RFC 974                                                     January 1986
        !           118: Mail Routing and the Domain System
        !           119: 
        !           120: 
        !           121:    affected hosts (those in the list of MXs) have their resolver caches
        !           122:    flushed. In other words, given proper precautions, mail looping as a
        !           123:    result of domain information should be avoidable, without requiring
        !           124:    mailers to query authoritative servers.  (The appropriate precaution
        !           125:    is to check with a host's administrator before adding that host to a
        !           126:    list of MXs).
        !           127: 
        !           128:    The incomplete data problem also requires some care when handling
        !           129:    domain queries.  If the answer section of a query is incomplete
        !           130:    critical MX RRs may be left out.  This may result in mail looping, or
        !           131:    in a message being mistakenly labelled undeliverable.  As a result,
        !           132:    mailers may only accept responses from the domain system which have
        !           133:    complete answer sections.  Note that this entire problem can be
        !           134:    avoided by only using virtual circuits for queries, but since this
        !           135:    situation is likely to be very rare and datagrams are the preferred
        !           136:    way to interact with the domain system, implementors should probably
        !           137:    just ensure that their mailer will repeat a query with virtual
        !           138:    circuits should the truncation bit ever be set.
        !           139: 
        !           140: Determining Where to Send a Message
        !           141: 
        !           142:    The explanation of how mailers should decide how to route a message
        !           143:    is discussed in terms of the problem of a mailer on a host with
        !           144:    domain name LOCAL trying to deliver a message addressed to the domain
        !           145:    name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically
        !           146:    correct domain names.  Furthermore, LOCAL is assumed to be the
        !           147:    official name for the host on which the mailer resides (i.e., it is
        !           148:    not a alias).
        !           149: 
        !           150: Issuing a Query
        !           151: 
        !           152:    The first step for the mailer at LOCAL is to issue a query for MX RRs
        !           153:    for REMOTE.  It is strongly urged that this step be taken every time
        !           154:    a mailer attempts to send the message.  The hope is that changes in
        !           155:    the domain database will rapidly be used by mailers, and thus domain
        !           156:    administrators will be able to re-route in-transit messages for
        !           157:    defective hosts by simply changing their domain databases.
        !           158: 
        !           159:    Certain responses to the query are considered errors:
        !           160: 
        !           161:       Getting no response to the query.  The domain server the mailer
        !           162:       queried never sends anything back.  (This is distinct from an
        !           163:       answer which contains no answers to the query, which is not an
        !           164:       error).
        !           165: 
        !           166:       Getting a response in which the truncation field of the header is
        !           167: 
        !           168: 
        !           169: 
        !           170: Partridge                                                       [Page 3]
        !           171: 
        !           172: 
        !           173: 
        !           174: RFC 974                                                     January 1986
        !           175: Mail Routing and the Domain System
        !           176: 
        !           177: 
        !           178:       set.  (Recall discussion of incomplete queries above).  Mailers
        !           179:       may not use responses of this type, and should repeat the query
        !           180:       using virtual circuits instead of datagrams.
        !           181: 
        !           182:       Getting a response in which the response code is non-zero.
        !           183: 
        !           184:    Mailers are expected to do something reasonable in the face of an
        !           185:    error.  The behaviour for each type of error is not specified here,
        !           186:    but implementors should note that different types of errors should
        !           187:    probably be treated differently.  For example, a response code of
        !           188:    "non-existent domain" should probably cause the message to be
        !           189:    returned to the sender as invalid, while a response code of "server
        !           190:    failure" should probably cause the message to be retried later.
        !           191: 
        !           192:    There is one other special case.  If the response contains an answer
        !           193:    which is a CNAME RR, it indicates that REMOTE is actually an alias
        !           194:    for some other domain name. The query should be repeated with the
        !           195:    canonical domain name.
        !           196: 
        !           197:    If the response does not contain an error response, and does not
        !           198:    contain aliases, its answer section should be a (possibly zero
        !           199:    length) list of MX RRs for domain name REMOTE (or REMOTE's true
        !           200:    domain name if REMOTE was a alias).  The next section describes how
        !           201:    this list is interpreted.
        !           202: 
        !           203: Interpreting the List of MX RRs
        !           204: 
        !           205:    NOTE: This section only discusses how mailers choose which names to
        !           206:    try to deliver a message to, working from a list of RR's.  It does
        !           207:    not discuss how the mailers actually make delivery.  Where ever
        !           208:    delivering a message is mentioned, all that is meant is that the
        !           209:    mailer should do whatever it needs to do to transfer a message to a
        !           210:    remote site, given a domain name for that site.  (For example, an
        !           211:    SMTP mailer will try to get an address for the domain name, which
        !           212:    involves another query to the domain system, and then, if it gets an
        !           213:    address, connect to the SMTP TCP port).  The mechanics of actually
        !           214:    transferring the message over the network to the address associated
        !           215:    with a given domain name is not within the scope of this memo.
        !           216: 
        !           217:    It is possible that the list of MXs in the response to the query will
        !           218:    be empty.  This is a special case.  If the list is empty, mailers
        !           219:    should treat it as if it contained one RR, an MX RR with a preference
        !           220:    value of 0, and a host name of REMOTE.  (I.e., REMOTE is its only
        !           221:    MX).  In addition, the mailer should do no further processing on the
        !           222:    list, but should attempt to deliver the message to REMOTE.  The idea
        !           223: 
        !           224: 
        !           225: 
        !           226: 
        !           227: Partridge                                                       [Page 4]
        !           228: 
        !           229: 
        !           230: 
        !           231: RFC 974                                                     January 1986
        !           232: Mail Routing and the Domain System
        !           233: 
        !           234: 
        !           235:    here is that if a domain fails to advertise any information about a
        !           236:    particular name we will give it the benefit of the doubt and attempt
        !           237:    delivery.
        !           238: 
        !           239:    If the list is not empty, the mailer should remove irrelevant RR's
        !           240:    from the list according to the following steps.  Note that the order
        !           241:    is significant.
        !           242: 
        !           243:       For each MX, a WKS query should be issued to see if the domain
        !           244:       name listed actually supports the mail service desired.  MX RRs
        !           245:       which list domain names which do not support the service should be
        !           246:       discarded.  This step is optional, but strongly encouraged.
        !           247: 
        !           248:       If the domain name LOCAL is listed as an MX RR, all MX RRs with a
        !           249:       preference value greater than or equal to that of LOCAL's must be
        !           250:       discarded.
        !           251: 
        !           252:    After removing irrelevant RRs, the list can again be empty.  This is
        !           253:    now an error condition and can occur in several ways.  The simplest
        !           254:    case is that the WKS queries have discovered that none of the hosts
        !           255:    listed supports the mail service desired.  The message is thus deemed
        !           256:    undeliverable, though extremely persistent mail systems might want to
        !           257:    try a delivery to REMOTE's address (if it exists) before returning
        !           258:    the message. Another, more dangerous, possibility is that the domain
        !           259:    system believes that LOCAL is handling message for REMOTE, but the
        !           260:    mailer on LOCAL is not set up to handle mail for REMOTE.  For
        !           261:    example, if the domain system lists LOCAL as the only MX for REMOTE,
        !           262:    LOCAL will delete all the entries in the list.  But LOCAL is
        !           263:    presumably querying the domain system because it didn't know what to
        !           264:    do with a message addressed to REMOTE. Clearly something is wrong.
        !           265:    How a mailer chooses to handle these situations is to some extent
        !           266:    implementation dependent, and is thus left to the implementor's
        !           267:    discretion.
        !           268: 
        !           269:    If the list of MX RRs is not empty, the mailer should try to deliver
        !           270:    the message to the MXs in order (lowest preference value tried
        !           271:    first).  The mailer is required to attempt delivery to the lowest
        !           272:    valued MX.  Implementors are encouraged to write mailers so that they
        !           273:    try the MXs in order until one of the MXs accepts the message, or all
        !           274:    the MXs have been tried.  A somewhat less demanding system, in which
        !           275:    a fixed number of MXs is tried, is also reasonable.  Note that
        !           276:    multiple MXs may have the same preference value.  In this case, all
        !           277:    MXs at with a given value must be tried before any of a higher value
        !           278:    are tried.  In addition, in the special case in which there are
        !           279:    several MXs with the lowest preference value,  all of them should be
        !           280:    tried before a message is deemed undeliverable.
        !           281: 
        !           282: 
        !           283: 
        !           284: Partridge                                                       [Page 5]
        !           285: 
        !           286: 
        !           287: 
        !           288: RFC 974                                                     January 1986
        !           289: Mail Routing and the Domain System
        !           290: 
        !           291: 
        !           292: Minor Special Issues
        !           293: 
        !           294:    There are a couple of special issues left out of the preceding
        !           295:    section because they complicated the discussion.  They are treated
        !           296:    here in no particular order.
        !           297: 
        !           298:    Wildcard names, those containing the character '*' in them, may be
        !           299:    used for mail routing.  There are likely to be servers on the network
        !           300:    which simply state that any mail to a domain is to be routed through
        !           301:    a relay. For example, at the time that this RFC is being written, all
        !           302:    mail to hosts in the domain IL is routed through RELAY.CS.NET.  This
        !           303:    is done by creating a wildcard RR, which states that *.IL has an MX
        !           304:    of RELAY.CS.NET.  This should be transparent to the mailer since the
        !           305:    domain servers will hide this wildcard match. (If it matches *.IL
        !           306:    with HUJI.IL for example, a domain server will return an RR
        !           307:    containing HUJI.IL, not *.IL). If by some accident a mailer receives
        !           308:    an RR with a wildcard domain name in its name or data section it
        !           309:    should discard the RR.
        !           310: 
        !           311:    Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
        !           312:    a alias and the alias is listed in the MX records for REMOTE.  (E.g.
        !           313:    REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
        !           314:    can be avoided if aliases are never used in the data section of MX
        !           315:    RRs.
        !           316: 
        !           317:    Implementors should understand that the query and interpretation of
        !           318:    the query is only performed for REMOTE.  It is not repeated for the
        !           319:    MX RRs listed for REMOTE.  You cannot try to support more extravagant
        !           320:    mail routing by building a chain of MXs.  (E.g. UNIX.BBN.COM is an MX
        !           321:    for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
        !           322:    but this does not mean that UNIX.BBN.COM accepts any responsibility
        !           323:    for mail for .IL).
        !           324: 
        !           325:    Finally, it should be noted that this is a standard for routing on
        !           326:    the Internet.  Mailers serving hosts which lie on multiple networks
        !           327:    will presumably have to make some decisions about which network to
        !           328:    route through. This decision making is outside the scope of this
        !           329:    memo, although mailers may well use the domain system to help them
        !           330:    decide.  However, once a mailer decides to deliver a message via the
        !           331:    Internet it must apply these rules to route the message.
        !           332: 
        !           333: 
        !           334: 
        !           335: 
        !           336: 
        !           337: 
        !           338: 
        !           339: 
        !           340: 
        !           341: Partridge                                                       [Page 6]
        !           342: 
        !           343: 
        !           344: 
        !           345: RFC 974                                                     January 1986
        !           346: Mail Routing and the Domain System
        !           347: 
        !           348: 
        !           349: Examples
        !           350: 
        !           351:    To illustrate the discussion above, here are three examples of how
        !           352:    mailers should route messages.  All examples work with the following
        !           353:    database:
        !           354: 
        !           355:       A.EXAMPLE.ORG    IN    MX    10    A.EXAMPLE.ORG
        !           356:       A.EXAMPLE.ORG    IN    MX    15    B.EXAMPLE.ORG
        !           357:       A.EXAMPLE.ORG    IN    MX    20    C.EXAMPLE.ORG
        !           358:       A.EXAMPLE.ORG    IN    WKS   10.0.0.1    TCP    SMTP
        !           359: 
        !           360:       B.EXAMPLE.ORG    IN    MX    0      B.EXAMPLE.ORG
        !           361:       B.EXAMPLE.ORG    IN    MX    10     C.EXAMPLE.ORG
        !           362:       B.EXAMPLE.ORG    IN    WKS   10.0.0.2    TCP    SMTP
        !           363: 
        !           364:       C.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
        !           365:       C.EXAMPLE.ORG    IN    WKS   10.0.0.3    TCP    SMTP
        !           366: 
        !           367:       D.EXAMPLE.ORG    IN    MX    0     D.EXAMPLE.ORG
        !           368:       D.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
        !           369:       D.EXAMPLE.ORG    IN    WKS   10.0.0.4    TCP    SMTP
        !           370: 
        !           371:    In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to
        !           372:    deliver a message addressed to A.EXAMPLE.ORG. From the answer to its
        !           373:    query, it learns that A.EXAMPLE.ORG has three MX RRs.  D.EXAMPLE.ORG
        !           374:    is not one of the MX RRs and all three MXs support SMTP mail
        !           375:    (determined from the WKS entries), so none of the MXs are eliminated.
        !           376:    The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the
        !           377:    lowest valued MX.  If it cannot reach A.EXAMPLE.ORG it can (but is
        !           378:    not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not
        !           379:    responding, it can try C.EXAMPLE.ORG.
        !           380: 
        !           381:    In the second example, the mailer is on B.EXAMPLE.ORG, and is again
        !           382:    trying to deliver a message addressed to A.EXAMPLE.ORG.  There are
        !           383:    once again three MX RRs for A.EXAMPLE.ORG, but in this case the
        !           384:    mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the
        !           385:    MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for
        !           386:    B.EXAMPLE.ORG).  It is left only with the RR for A.EXAMPLE.ORG, and
        !           387:    can only try delivery to A.EXAMPLE.ORG.
        !           388: 
        !           389:    In the third example, consider a mailer on A.EXAMPLE.ORG trying to
        !           390:    deliver a message to D.EXAMPLE.ORG.  In this case there are only two
        !           391:    MX RRs, both with the same preference value.  Either MX will accept
        !           392:    messages for D.EXAMPLE.ORG. The mailer should try one MX first (which
        !           393:    one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable),
        !           394:    and if that delivery fails should try the other MX (e.g.
        !           395:    C.EXAMPLE.ORG).
        !           396: 
        !           397: 
        !           398: Partridge                                                       [Page 7]
        !           399: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.