rfc1123.txt
上传用户:horngjaan
上传日期:2009-12-12
资源大小:2882k
文件大小:234k
源码类别:

Email服务器

开发平台:

C#

  1. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  2.          CNAME.
  3.       5.2.3  VRFY and EXPN Commands: RFC-821 Section 3.3
  4.          A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
  5.          (this requirement overrides RFC-821).  However, there MAY be
  6.          configuration information to disable VRFY and EXPN in a
  7.          particular installation; this might even allow EXPN to be
  8.          disabled for selected lists.
  9.          A new reply code is defined for the VRFY command:
  10.               252 Cannot VRFY user (e.g., info is not local), but will
  11.                   take message for this user and attempt delivery.
  12.          DISCUSSION:
  13.               SMTP users and administrators make regular use of these
  14.               commands for diagnosing mail delivery problems.  With the
  15.               increasing use of multi-level mailing list expansion
  16.               (sometimes more than two levels), EXPN has been
  17.               increasingly important for diagnosing inadvertent mail
  18.               loops.  On the other hand,  some feel that EXPN represents
  19.               a significant privacy, and perhaps even a security,
  20.               exposure.
  21.       5.2.4  SEND, SOML, and SAML Commands: RFC-821 Section 3.4
  22.          An SMTP MAY implement the commands to send a message to a
  23.          user's terminal: SEND, SOML, and SAML.
  24.          DISCUSSION:
  25.               It has been suggested that the use of mail relaying
  26.               through an MX record is inconsistent with the intent of
  27.               SEND to deliver a message immediately and directly to a
  28.               user's terminal.  However, an SMTP receiver that is unable
  29.               to write directly to the user terminal can return a "251
  30.               User Not Local" reply to the RCPT following a SEND, to
  31.               inform the originator of possibly deferred delivery.
  32.       5.2.5  HELO Command: RFC-821 Section 3.5
  33.          The sender-SMTP MUST ensure that the <domain> parameter in a
  34.          HELO command is a valid principal host domain name for the
  35.          client host.  As a result, the receiver-SMTP will not have to
  36.          perform MX resolution on this name in order to validate the
  37.          HELO parameter.
  38.          The HELO receiver MAY verify that the HELO parameter really
  39. Internet Engineering Task Force                                [Page 50]
  40. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  41.          corresponds to the IP address of the sender.  However, the
  42.          receiver MUST NOT refuse to accept a message, even if the
  43.          sender's HELO command fails verification.
  44.          DISCUSSION:
  45.               Verifying the HELO parameter requires a domain name lookup
  46.               and may therefore take considerable time.  An alternative
  47.               tool for tracking bogus mail sources is suggested below
  48.               (see "DATA Command").
  49.               Note also that the HELO argument is still required to have
  50.               valid <domain> syntax, since it will appear in a Received:
  51.               line; otherwise, a 501 error is to be sent.
  52.          IMPLEMENTATION:
  53.               When HELO parameter validation fails, a suggested
  54.               procedure is to insert a note about the unknown
  55.               authenticity of the sender into the message header (e.g.,
  56.               in the "Received:"  line).
  57.       5.2.6  Mail Relay: RFC-821 Section 3.6
  58.          We distinguish three types of mail (store-and-) forwarding:
  59.          (1)  A simple forwarder or "mail exchanger" forwards a message
  60.               using private knowledge about the recipient; see section
  61.               3.2 of RFC-821.
  62.          (2)  An SMTP mail "relay" forwards a message within an SMTP
  63.               mail environment as the result of an explicit source route
  64.               (as defined in section 3.6 of RFC-821).  The SMTP relay
  65.               function uses the "@...:" form of source route from RFC-
  66.               822 (see Section 5.2.19 below).
  67.          (3)  A mail "gateway" passes a message between different
  68.               environments.  The rules for mail gateways are discussed
  69.               below in Section 5.3.7.
  70.          An Internet host that is forwarding a message but is not a
  71.          gateway to a different mail environment (i.e., it falls under
  72.          (1) or (2)) SHOULD NOT alter any existing header fields,
  73.          although the host will add an appropriate Received: line as
  74.          required in Section 5.2.8.
  75.          A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
  76.          explicit source route using the "@...:" address form.  Thus,
  77.          the relay function defined in section  3.6 of RFC-821 should
  78.          not be used.
  79. Internet Engineering Task Force                                [Page 51]
  80. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  81.          DISCUSSION:
  82.               The intent is to discourage all source routing and to
  83.               abolish explicit source routing for mail delivery within
  84.               the Internet environment.  Source-routing is unnecessary;
  85.               the simple target address "user@domain" should always
  86.               suffice.  This is the result of an explicit architectural
  87.               decision to use universal naming rather than source
  88.               routing for mail.  Thus, SMTP provides end-to-end
  89.               connectivity, and the DNS provides globally-unique,
  90.               location-independent names.  MX records handle the major
  91.               case where source routing might otherwise be needed.
  92.          A receiver-SMTP MUST accept the explicit source route syntax in
  93.          the envelope, but it MAY implement the relay function as
  94.          defined in section 3.6 of RFC-821.  If it does not implement
  95.          the relay function, it SHOULD attempt to deliver the message
  96.          directly to the host to the right of the right-most "@" sign.
  97.          DISCUSSION:
  98.               For example, suppose a host that does not implement the
  99.               relay function receives a message with the SMTP command:
  100.               "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
  101.               GAMMA represent domain names.  Rather than immediately
  102.               refusing the message with a 550 error reply as suggested
  103.               on page 20 of RFC-821, the host should try to forward the
  104.               message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
  105.               Since this host does not support relaying, it is not
  106.               required to update the reverse path.
  107.               Some have suggested that source routing may be needed
  108.               occasionally for manually routing mail around failures;
  109.               however, the reality and importance of this need is
  110.               controversial.  The use of explicit SMTP mail relaying for
  111.               this purpose is discouraged, and in fact it may not be
  112.               successful, as many host systems do not support it.  Some
  113.               have used the "%-hack" (see Section 5.2.16) for this
  114.               purpose.
  115.       5.2.7  RCPT Command: RFC-821 Section 4.1.1
  116.          A host that supports a receiver-SMTP MUST support the reserved
  117.          mailbox "Postmaster".
  118.          The receiver-SMTP MAY verify RCPT parameters as they arrive;
  119.          however, RCPT responses MUST NOT be delayed beyond a reasonable
  120.          time (see Section 5.3.2).
  121.          Therefore, a "250 OK" response to a RCPT does not necessarily
  122. Internet Engineering Task Force                                [Page 52]
  123. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  124.          imply that the delivery address(es) are valid.  Errors found
  125.          after message acceptance will be reported by mailing a
  126.          notification message to an appropriate address (see Section
  127.          5.3.3).
  128.          DISCUSSION:
  129.               The set of conditions under which a RCPT parameter can be
  130.               validated immediately is an engineering design choice.
  131.               Reporting destination mailbox errors to the Sender-SMTP
  132.               before mail is transferred is generally desirable to save
  133.               time and network bandwidth, but this advantage is lost if
  134.               RCPT verification is lengthy.
  135.               For example, the receiver can verify immediately any
  136.               simple local reference, such as a single locally-
  137.               registered mailbox.  On the other hand, the "reasonable
  138.               time" limitation generally implies deferring verification
  139.               of a mailing list until after the message has been
  140.               transferred and accepted, since verifying a large mailing
  141.               list can take a very long time.  An implementation might
  142.               or might not choose to defer validation of addresses that
  143.               are non-local and therefore require a DNS lookup.  If a
  144.               DNS lookup is performed but a soft domain system error
  145.               (e.g., timeout) occurs, validity must be assumed.
  146.       5.2.8  DATA Command: RFC-821 Section 4.1.1
  147.          Every receiver-SMTP (not just one that "accepts a message for
  148.          relaying or for final delivery" [SMTP:1]) MUST insert a
  149.          "Received:" line at the beginning of a message.  In this line,
  150.          called a "time stamp line" in RFC-821:
  151.          *    The FROM field SHOULD contain both (1) the name of the
  152.               source host as presented in the HELO command and (2) a
  153.               domain literal containing the IP address of the source,
  154.               determined from the TCP connection.
  155.          *    The ID field MAY contain an "@" as suggested in RFC-822,
  156.               but this is not required.
  157.          *    The FOR field MAY contain a list of <path> entries when
  158.               multiple RCPT commands have been given.
  159.          An Internet mail program MUST NOT change a Received: line that
  160.          was previously added to the message header.
  161. Internet Engineering Task Force                                [Page 53]
  162. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  163.          DISCUSSION:
  164.               Including both the source host and the IP source address
  165.               in the Received: line may provide enough information for
  166.               tracking illicit mail sources and eliminate a need to
  167.               explicitly verify the HELO parameter.
  168.               Received: lines are primarily intended for humans tracing
  169.               mail routes, primarily of diagnosis of faults.  See also
  170.               the discussion under 5.3.7.
  171.          When the receiver-SMTP makes "final delivery" of a message,
  172.          then it MUST pass the MAIL FROM: address from the SMTP envelope
  173.          with the message, for use if an error notification message must
  174.          be sent later (see Section 5.3.3).  There is an analogous
  175.          requirement when gatewaying from the Internet into a different
  176.          mail environment; see Section 5.3.7.
  177.          DISCUSSION:
  178.               Note that the final reply to the DATA command depends only
  179.               upon the successful transfer and storage of the message.
  180.               Any problem with the destination address(es) must either
  181.               (1) have been reported in an SMTP error reply to the RCPT
  182.               command(s), or (2) be reported in a later error message
  183.               mailed to the originator.
  184.          IMPLEMENTATION:
  185.               The MAIL FROM: information may be passed as a parameter or
  186.               in a Return-Path: line inserted at the beginning of the
  187.               message.
  188.       5.2.9  Command Syntax: RFC-821 Section 4.1.2
  189.          The syntax shown in RFC-821 for the MAIL FROM: command omits
  190.          the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
  191.          15).  An empty reverse path MUST be supported.
  192.       5.2.10  SMTP Replies:  RFC-821 Section 4.2
  193.          A receiver-SMTP SHOULD send only the reply codes listed in
  194.          section 4.2.2 of RFC-821 or in this document.  A receiver-SMTP
  195.          SHOULD use the text shown in examples in RFC-821 whenever
  196.          appropriate.
  197.          A sender-SMTP MUST determine its actions only by the reply
  198.          code, not by the text (except for 251 and 551 replies); any
  199.          text, including no text at all, must be acceptable.  The space
  200.          (blank) following the reply code is considered part of the
  201.          text.  Whenever possible, a sender-SMTP SHOULD test only the
  202. Internet Engineering Task Force                                [Page 54]
  203. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  204.          first digit of the reply code, as specified in Appendix E of
  205.          RFC-821.
  206.          DISCUSSION:
  207.               Interoperability problems have arisen with SMTP systems
  208.               using reply codes that are not listed explicitly in RFC-
  209.               821 Section 4.3 but are legal according to the theory of
  210.               reply codes explained in Appendix E.
  211.       5.2.11  Transparency: RFC-821 Section 4.5.2
  212.          Implementors MUST be sure that their mail systems always add
  213.          and delete periods to ensure message transparency.
  214.       5.2.12  WKS Use in MX Processing: RFC-974, p. 5
  215.          RFC-974 [SMTP:3] recommended that the domain system be queried
  216.          for WKS ("Well-Known Service") records, to verify that each
  217.          proposed mail target does support SMTP.  Later experience has
  218.          shown that WKS is not widely supported, so the WKS step in MX
  219.          processing SHOULD NOT be used.
  220.       The following are notes on RFC-822, organized by section of that
  221.       document.
  222.       5.2.13  RFC-822 Message Specification: RFC-822 Section 4
  223.          The syntax shown for the Return-path line omits the possibility
  224.          of a null return path, which is used to prevent looping of
  225.          error notifications (see Section 5.3.3).  The complete syntax
  226.          is:
  227.              return = "Return-path"  ":" route-addr
  228.                     / "Return-path"  ":" "<" ">"
  229.          The set of optional header fields is hereby expanded to include
  230.          the Content-Type field defined in RFC-1049 [SMTP:7].  This
  231.          field "allows mail reading systems to automatically identify
  232.          the type of a structured message body and to process it for
  233.          display accordingly".  [SMTP:7]  A User Agent MAY support this
  234.          field.
  235.       5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
  236.          The syntax for the date is hereby changed to:
  237.             date = 1*2DIGIT month 2*4DIGIT
  238. Internet Engineering Task Force                                [Page 55]
  239. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  240.          All mail software SHOULD use 4-digit years in dates, to ease
  241.          the transition to the next century.
  242.          There is a strong trend towards the use of numeric timezone
  243.          indicators, and implementations SHOULD use numeric timezones
  244.          instead of timezone names.  However, all implementations MUST
  245.          accept either notation.  If timezone names are used, they MUST
  246.          be exactly as defined in RFC-822.
  247.          The military time zones are specified incorrectly in RFC-822:
  248.          they count the wrong way from UT (the signs are reversed).  As
  249.          a result, military time zones in RFC-822 headers carry no
  250.          information.
  251.          Finally, note that there is a typo in the definition of "zone"
  252.          in the syntax summary of appendix D; the correct definition
  253.          occurs in Section 3 of RFC-822.
  254.       5.2.15  RFC-822 Syntax Change: RFC-822 Section 6.1
  255.          The syntactic definition of "mailbox" in RFC-822 is hereby
  256.          changed to:
  257.             mailbox =  addr-spec            ; simple address
  258.                     / [phrase] route-addr   ; name & addr-spec
  259.          That is, the phrase preceding a route address is now OPTIONAL.
  260.          This change makes the following header field legal, for
  261.          example:
  262.              From: <craig@nnsc.nsf.net>
  263.       5.2.16  RFC-822  Local-part: RFC-822 Section 6.2
  264.          The basic mailbox address specification has the form: "local-
  265.          part@domain".  Here "local-part", sometimes called the "left-
  266.          hand side" of the address, is domain-dependent.
  267.          A host that is forwarding the message but is not the
  268.          destination host implied by the right-hand side "domain" MUST
  269.          NOT interpret or modify the "local-part" of the address.
  270.          When mail is to be gatewayed from the Internet mail environment
  271.          into a foreign mail environment (see Section 5.3.7), routing
  272.          information for that foreign environment MAY be embedded within
  273.          the "local-part" of the address.  The gateway will then
  274.          interpret this local part appropriately for the foreign mail
  275.          environment.
  276. Internet Engineering Task Force                                [Page 56]
  277. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  278.          DISCUSSION:
  279.               Although source routes are discouraged within the Internet
  280.               (see Section 5.2.6), there are non-Internet mail
  281.               environments whose delivery mechanisms do depend upon
  282.               source routes.  Source routes for extra-Internet
  283.               environments can generally be buried in the "local-part"
  284.               of the address (see Section 5.2.16) while mail traverses
  285.               the Internet.  When the mail reaches the appropriate
  286.               Internet mail gateway, the gateway will interpret the
  287.               local-part and build the necessary address or route for
  288.               the target mail environment.
  289.               For example, an Internet host might send mail to:
  290.               "a!b!c!user@gateway-domain".  The complex local part
  291.               "a!b!c!user" would be uninterpreted within the Internet
  292.               domain, but could be parsed and understood by the
  293.               specified mail gateway.
  294.               An embedded source route is sometimes encoded in the
  295.               "local-part" using "%" as a right-binding routing
  296.               operator.  For example, in:
  297.                  user%domain%relay3%relay2@relay1
  298.               the "%" convention implies that the mail is to be routed
  299.               from "relay1" through "relay2", "relay3", and finally to
  300.               "user" at "domain".  This is commonly known as the "%-
  301.               hack".  It is suggested that "%" have lower precedence
  302.               than any other routing operator (e.g., "!") hidden in the
  303.               local-part; for example, "a!b%c" would be interpreted as
  304.               "(a!b)%c".
  305.               Only the target host (in this case, "relay1") is permitted
  306.               to analyze the local-part "user%domain%relay3%relay2".
  307.       5.2.17  Domain Literals: RFC-822 Section 6.2.3
  308.          A mailer MUST be able to accept and parse an Internet domain
  309.          literal whose content ("dtext"; see RFC-822) is a dotted-
  310.          decimal host address.  This satisfies the requirement of
  311.          Section 2.1 for the case of mail.
  312.          An SMTP MUST accept and recognize a domain literal for any of
  313.          its own IP addresses.
  314. Internet Engineering Task Force                                [Page 57]
  315. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  316.       5.2.18  Common Address Formatting Errors: RFC-822 Section 6.1
  317.          Errors in formatting or parsing 822 addresses are unfortunately
  318.          common.  This section mentions only the most common errors.  A
  319.          User Agent MUST accept all valid RFC-822 address formats, and
  320.          MUST NOT generate illegal address syntax.
  321.          o    A common error is to leave out the semicolon after a group
  322.               identifier.
  323.          o    Some systems fail to fully-qualify domain names in
  324.               messages they generate.  The right-hand side of an "@"
  325.               sign in a header address field MUST be a fully-qualified
  326.               domain name.
  327.               For example, some systems fail to fully-qualify the From:
  328.               address; this prevents a "reply" command in the user
  329.               interface from automatically constructing a return
  330.               address.
  331.               DISCUSSION:
  332.                    Although RFC-822 allows the local use of abbreviated
  333.                    domain names within a domain, the application of
  334.                    RFC-822 in Internet mail does not allow this.  The
  335.                    intent is that an Internet host must not send an SMTP
  336.                    message header containing an abbreviated domain name
  337.                    in an address field.  This allows the address fields
  338.                    of the header to be passed without alteration across
  339.                    the Internet, as required in Section 5.2.6.
  340.          o    Some systems mis-parse multiple-hop explicit source routes
  341.               such as:
  342.                   @relay1,@relay2,@relay3:user@domain.
  343.          o    Some systems over-qualify domain names by adding a
  344.               trailing dot to some or all domain names in addresses or
  345.               message-ids.  This violates RFC-822 syntax.
  346.       5.2.19  Explicit Source Routes: RFC-822 Section 6.2.7
  347.          Internet host software SHOULD NOT create an RFC-822 header
  348.          containing an address with an explicit source route, but MUST
  349.          accept such headers for compatibility with earlier systems.
  350.          DISCUSSION:
  351. Internet Engineering Task Force                                [Page 58]
  352. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  353.               In an understatement, RFC-822 says "The use of explicit
  354.               source routing is discouraged".  Many hosts implemented
  355.               RFC-822 source routes incorrectly, so the syntax cannot be
  356.               used unambiguously in practice.  Many users feel the
  357.               syntax is ugly.  Explicit source routes are not needed in
  358.               the mail envelope for delivery; see Section 5.2.6.  For
  359.               all these reasons, explicit source routes using the RFC-
  360.               822 notations are not to be used in Internet mail headers.
  361.               As stated in Section 5.2.16, it is necessary to allow an
  362.               explicit source route to be buried in the local-part of an
  363.               address, e.g., using the "%-hack", in order to allow mail
  364.               to be gatewayed into another environment in which explicit
  365.               source routing is necessary.  The vigilant will observe
  366.               that there is no way for a User Agent to detect and
  367.               prevent the use of such implicit source routing when the
  368.               destination is within the Internet.  We can only
  369.               discourage source routing of any kind within the Internet,
  370.               as unnecessary and undesirable.
  371.    5.3  SPECIFIC ISSUES
  372.       5.3.1  SMTP Queueing Strategies
  373.          The common structure of a host SMTP implementation includes
  374.          user mailboxes, one or more areas for queueing messages in
  375.          transit, and one or more daemon processes for sending and
  376.          receiving mail.  The exact structure will vary depending on the
  377.          needs of the users on the host and the number and size of
  378.          mailing lists supported by the host.  We describe several
  379.          optimizations that have proved helpful, particularly for
  380.          mailers supporting high traffic levels.
  381.          Any queueing strategy MUST include:
  382.          o    Timeouts on all activities.  See Section 5.3.2.
  383.          o    Never sending error messages in response to error
  384.               messages.
  385.          5.3.1.1 Sending Strategy
  386.             The general model of a sender-SMTP is one or more processes
  387.             that periodically attempt to transmit outgoing mail.  In a
  388.             typical system, the program that composes a message has some
  389.             method for requesting immediate attention for a new piece of
  390.             outgoing mail, while mail that cannot be transmitted
  391. Internet Engineering Task Force                                [Page 59]
  392. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  393.             immediately MUST be queued and periodically retried by the
  394.             sender.  A mail queue entry will include not only the
  395.             message itself but also the envelope information.
  396.             The sender MUST delay retrying a particular destination
  397.             after one attempt has failed.  In general, the retry
  398.             interval SHOULD be at least 30 minutes; however, more
  399.             sophisticated and variable strategies will be beneficial
  400.             when the sender-SMTP can determine the reason for non-
  401.             delivery.
  402.             Retries continue until the message is transmitted or the
  403.             sender gives up; the give-up time generally needs to be at
  404.             least 4-5 days.  The parameters to the retry algorithm MUST
  405.             be configurable.
  406.             A sender SHOULD keep a list of hosts it cannot reach and
  407.             corresponding timeouts, rather than just retrying queued
  408.             mail items.
  409.             DISCUSSION:
  410.                  Experience suggests that failures are typically
  411.                  transient (the target system has crashed), favoring a
  412.                  policy of two connection attempts in the first hour the
  413.                  message is in the queue, and then backing off to once
  414.                  every two or three hours.
  415.                  The sender-SMTP can shorten the queueing delay by
  416.                  cooperation with the receiver-SMTP.  In particular, if
  417.                  mail is received from a particular address, it is good
  418.                  evidence that any mail queued for that host can now be
  419.                  sent.
  420.                  The strategy may be further modified as a result of
  421.                  multiple addresses per host (see Section 5.3.4), to
  422.                  optimize delivery time vs. resource usage.
  423.                  A sender-SMTP may have a large queue of messages for
  424.                  each unavailable destination host, and if it retried
  425.                  all these messages in every retry cycle, there would be
  426.                  excessive Internet overhead and the daemon would be
  427.                  blocked for a long period.  Note that an SMTP can
  428.                  generally determine that a delivery attempt has failed
  429.                  only after a timeout of a minute or more; a one minute
  430.                  timeout per connection will result in a very large
  431.                  delay if it is repeated for dozens or even hundreds of
  432.                  queued messages.
  433. Internet Engineering Task Force                                [Page 60]
  434. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  435.             When the same message is to be delivered to several users on
  436.             the same host, only one copy of the message SHOULD be
  437.             transmitted.  That is, the sender-SMTP should use the
  438.             command sequence: RCPT, RCPT,... RCPT, DATA instead of the
  439.             sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
  440.             Implementation of this efficiency feature is strongly urged.
  441.             Similarly, the sender-SMTP MAY support multiple concurrent
  442.             outgoing mail transactions to achieve timely delivery.
  443.             However, some limit SHOULD be imposed to protect the host
  444.             from devoting all its resources to mail.
  445.             The use of the different addresses of a multihomed host is
  446.             discussed below.
  447.          5.3.1.2  Receiving strategy
  448.             The receiver-SMTP SHOULD attempt to keep a pending listen on
  449.             the SMTP port at all times.  This will require the support
  450.             of multiple incoming TCP connections for SMTP.  Some limit
  451.             MAY be imposed.
  452.             IMPLEMENTATION:
  453.                  When the receiver-SMTP receives mail from a particular
  454.                  host address, it could notify the sender-SMTP to retry
  455.                  any mail pending for that host address.
  456.       5.3.2  Timeouts in SMTP
  457.          There are two approaches to timeouts in the sender-SMTP:  (a)
  458.          limit the time for each SMTP command separately, or (b) limit
  459.          the time for the entire SMTP dialogue for a single mail
  460.          message.  A sender-SMTP SHOULD use option (a), per-command
  461.          timeouts.  Timeouts SHOULD be easily reconfigurable, preferably
  462.          without recompiling the SMTP code.
  463.          DISCUSSION:
  464.               Timeouts are an essential feature of an SMTP
  465.               implementation.  If the timeouts are too long (or worse,
  466.               there are no timeouts), Internet communication failures or
  467.               software bugs in receiver-SMTP programs can tie up SMTP
  468.               processes indefinitely.  If the timeouts are too short,
  469.               resources will be wasted with attempts that time out part
  470.               way through message delivery.
  471.               If option (b) is used, the timeout has to be very large,
  472.               e.g., an hour, to allow time to expand very large mailing
  473.               lists.  The timeout may also need to increase linearly
  474. Internet Engineering Task Force                                [Page 61]
  475. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  476.               with the size of the message, to account for the time to
  477.               transmit a very large message.  A large fixed timeout
  478.               leads to two problems:  a failure can still tie up the
  479.               sender for a very long time, and very large messages may
  480.               still spuriously time out (which is a wasteful failure!).
  481.               Using the recommended option (a), a timer is set for each
  482.               SMTP command and for each buffer of the data transfer.
  483.               The latter means that the overall timeout is inherently
  484.               proportional to the size of the message.
  485.          Based on extensive experience with busy mail-relay hosts, the
  486.          minimum per-command timeout values SHOULD be as follows:
  487.          o    Initial 220 Message: 5 minutes
  488.               A Sender-SMTP process needs to distinguish between a
  489.               failed TCP connection and a delay in receiving the initial
  490.               220 greeting message.  Many receiver-SMTPs will accept a
  491.               TCP connection but delay delivery of the 220 message until
  492.               their system load will permit more mail to be processed.
  493.          o    MAIL Command: 5 minutes
  494.          o    RCPT Command: 5 minutes
  495.               A longer timeout would be required if processing of
  496.               mailing lists and aliases were not deferred until after
  497.               the message was accepted.
  498.          o    DATA Initiation: 2 minutes
  499.               This is while awaiting the "354 Start Input" reply to a
  500.               DATA command.
  501.          o    Data Block: 3 minutes
  502.               This is while awaiting the completion of each TCP SEND
  503.               call transmitting a chunk of data.
  504.          o    DATA Termination: 10 minutes.
  505.               This is while awaiting the "250 OK" reply. When the
  506.               receiver gets the final period terminating the message
  507.               data, it typically performs processing to deliver the
  508.               message to a user mailbox.  A spurious timeout at this
  509.               point would be very wasteful, since the message has been
  510. Internet Engineering Task Force                                [Page 62]
  511. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  512.               successfully sent.
  513.          A receiver-SMTP SHOULD have a timeout of at least 5 minutes
  514.          while it is awaiting the next command from the sender.
  515.       5.3.3  Reliable Mail Receipt
  516.          When the receiver-SMTP accepts a piece of mail (by sending a
  517.          "250 OK" message in response to DATA), it is accepting
  518.          responsibility for delivering or relaying the message.  It must
  519.          take this responsibility seriously, i.e., it MUST NOT lose the
  520.          message for frivolous reasons, e.g., because the host later
  521.          crashes or because of a predictable resource shortage.
  522.          If there is a delivery failure after acceptance of a message,
  523.          the receiver-SMTP MUST formulate and mail a notification
  524.          message.  This notification MUST be sent using a null ("<>")
  525.          reverse path in the envelope; see Section 3.6 of RFC-821.  The
  526.          recipient of this notification SHOULD be the address from the
  527.          envelope return path (or the Return-Path: line).  However, if
  528.          this address is null ("<>"),  the receiver-SMTP MUST NOT send a
  529.          notification.  If the address is an explicit source route, it
  530.          SHOULD be stripped down to its final hop.
  531.          DISCUSSION:
  532.               For example, suppose that an error notification must be
  533.               sent for a message that arrived with:
  534.               "MAIL FROM:<@a,@b:user@d>".  The notification message
  535.               should be sent to: "RCPT TO:<user@d>".
  536.               Some delivery failures after the message is accepted by
  537.               SMTP will be unavoidable.  For example, it may be
  538.               impossible for the receiver-SMTP to validate all the
  539.               delivery addresses in RCPT command(s) due to a "soft"
  540.               domain system error or because the target is a mailing
  541.               list (see earlier discussion of RCPT).
  542.          To avoid receiving duplicate messages as the result of
  543.          timeouts, a receiver-SMTP MUST seek to minimize the time
  544.          required to respond to the final "." that ends a message
  545.          transfer.  See RFC-1047 [SMTP:4] for a discussion of this
  546.          problem.
  547.       5.3.4  Reliable Mail Transmission
  548.          To transmit a message, a sender-SMTP determines the IP address
  549.          of the target host from the destination address in the
  550.          envelope.  Specifically, it maps the string to the right of the
  551. Internet Engineering Task Force                                [Page 63]
  552. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  553.          "@" sign into an IP address.  This mapping or the transfer
  554.          itself may fail with a soft error, in which case the sender-
  555.          SMTP will requeue the outgoing mail for a later retry, as
  556.          required in Section 5.3.1.1.
  557.          When it succeeds, the mapping can result in a list of
  558.          alternative delivery addresses rather than a single address,
  559.          because of (a) multiple MX records, (b) multihoming, or both.
  560.          To provide reliable mail transmission, the sender-SMTP MUST be
  561.          able to try (and retry) each of the addresses in this list in
  562.          order, until a delivery attempt succeeds.  However, there MAY
  563.          also be a configurable limit on the number of alternate
  564.          addresses that can be tried.  In any case, a host SHOULD try at
  565.          least two addresses.
  566.          The following information is to be used to rank the host
  567.          addresses:
  568.          (1)  Multiple MX Records -- these contain a preference
  569.               indication that should be used in sorting.  If there are
  570.               multiple destinations with the same preference and there
  571.               is no clear reason to favor one (e.g., by address
  572.               preference), then the sender-SMTP SHOULD pick one at
  573.               random to spread the load across multiple mail exchanges
  574.               for a specific organization; note that this is a
  575.               refinement of the procedure in [DNS:3].
  576.          (2)  Multihomed host -- The destination host (perhaps taken
  577.               from the preferred MX record) may be multihomed, in which
  578.               case the domain name resolver will return a list of
  579.               alternative IP addresses.  It is the responsibility of the
  580.               domain name resolver interface (see Section 6.1.3.4 below)
  581.               to have ordered this list by decreasing preference, and
  582.               SMTP MUST try them in the order presented.
  583.          DISCUSSION:
  584.               Although the capability to try multiple alternative
  585.               addresses is required, there may be circumstances where
  586.               specific installations want to limit or disable the use of
  587.               alternative addresses.  The question of whether a sender
  588.               should attempt retries using the different addresses of a
  589.               multihomed host has been controversial.  The main argument
  590.               for using the multiple addresses is that it maximizes the
  591.               probability of timely delivery, and indeed sometimes the
  592.               probability of any delivery; the counter argument is that
  593.               it may result in unnecessary resource use.
  594.               Note that resource use is also strongly determined by the
  595. Internet Engineering Task Force                                [Page 64]
  596. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  597.               sending strategy discussed in Section 5.3.1.
  598.       5.3.5  Domain Name Support
  599.          SMTP implementations MUST use the mechanism defined in Section
  600.          6.1 for mapping between domain names and IP addresses.  This
  601.          means that every Internet SMTP MUST include support for the
  602.          Internet DNS.
  603.          In particular, a sender-SMTP MUST support the MX record scheme
  604.          [SMTP:3].  See also Section 7.4 of [DNS:2] for information on
  605.          domain name support for SMTP.
  606.       5.3.6  Mailing Lists and Aliases
  607.          An SMTP-capable host SHOULD support both the alias and the list
  608.          form of address expansion for multiple delivery.  When a
  609.          message is delivered or forwarded to each address of an
  610.          expanded list form, the return address in the envelope
  611.          ("MAIL FROM:") MUST be changed to be the address of a person
  612.          who administers the list, but the message header MUST be left
  613.          unchanged; in particular, the "From" field of the message is
  614.          unaffected.
  615.          DISCUSSION:
  616.               An important mail facility is a mechanism for multi-
  617.               destination delivery of a single message, by transforming
  618.               or "expanding" a pseudo-mailbox address into a list of
  619.               destination mailbox addresses.  When a message is sent to
  620.               such a pseudo-mailbox (sometimes called an "exploder"),
  621.               copies are forwarded or redistributed to each mailbox in
  622.               the expanded list.  We classify such a pseudo-mailbox as
  623.               an "alias" or a "list", depending upon the expansion
  624.               rules:
  625.               (a)  Alias
  626.                    To expand an alias, the recipient mailer simply
  627.                    replaces the pseudo-mailbox address in the envelope
  628.                    with each of the expanded addresses in turn; the rest
  629.                    of the envelope and the message body are left
  630.                    unchanged.  The message is then delivered or
  631.                    forwarded to each expanded address.
  632.               (b)  List
  633.                    A mailing list may be said to operate by
  634.                    "redistribution" rather than by "forwarding".  To
  635. Internet Engineering Task Force                                [Page 65]
  636. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  637.                    expand a list, the recipient mailer replaces the
  638.                    pseudo-mailbox address in the envelope with each of
  639.                    the expanded addresses in turn. The return address in
  640.                    the envelope is changed so that all error messages
  641.                    generated by the final deliveries will be returned to
  642.                    a list administrator, not to the message originator,
  643.                    who generally has no control over the contents of the
  644.                    list and will typically find error messages annoying.
  645.       5.3.7  Mail Gatewaying
  646.          Gatewaying mail between different mail environments, i.e.,
  647.          different mail formats and protocols, is complex and does not
  648.          easily yield to standardization.  See for example [SMTP:5a],
  649.          [SMTP:5b].  However, some general requirements may be given for
  650.          a gateway between the Internet and another mail environment.
  651.          (A)  Header fields MAY be rewritten when necessary as messages
  652.               are gatewayed across mail environment boundaries.
  653.               DISCUSSION:
  654.                    This may involve interpreting the local-part of the
  655.                    destination address, as suggested in Section 5.2.16.
  656.                    The other mail systems gatewayed to the Internet
  657.                    generally use a subset of RFC-822 headers, but some
  658.                    of them do not have an equivalent to the SMTP
  659.                    envelope.  Therefore, when a message leaves the
  660.                    Internet environment, it may be necessary to fold the
  661.                    SMTP envelope information into the message header.  A
  662.                    possible solution would be to create new header
  663.                    fields to carry the envelope information (e.g., "X-
  664.                    SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
  665.                    require changes in mail programs in the foreign
  666.                    environment.
  667.          (B)  When forwarding a message into or out of the Internet
  668.               environment, a gateway MUST prepend a Received: line, but
  669.               it MUST NOT alter in any way a Received: line that is
  670.               already in the header.
  671.               DISCUSSION:
  672.                    This requirement is a subset of the general
  673.                    "Received:" line requirement of Section 5.2.8; it is
  674.                    restated here for emphasis.
  675.                    Received: fields of messages originating from other
  676. Internet Engineering Task Force                                [Page 66]
  677. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  678.                    environments may not conform exactly to RFC822.
  679.                    However, the most important use of Received: lines is
  680.                    for debugging mail faults, and this debugging can be
  681.                    severely hampered by well-meaning gateways that try
  682.                    to "fix" a Received: line.
  683.                    The gateway is strongly encouraged to indicate the
  684.                    environment and protocol in the "via" clauses of
  685.                    Received field(s) that it supplies.
  686.          (C)  From the Internet side, the gateway SHOULD accept all
  687.               valid address formats in SMTP commands and in RFC-822
  688.               headers, and all valid RFC-822 messages.  Although a
  689.               gateway must accept an RFC-822 explicit source route
  690.               ("@...:" format) in either the RFC-822 header or in the
  691.               envelope, it MAY or may not act on the source route; see
  692.               Sections 5.2.6 and 5.2.19.
  693.               DISCUSSION:
  694.                    It is often tempting to restrict the range of
  695.                    addresses accepted at the mail gateway to simplify
  696.                    the translation into addresses for the remote
  697.                    environment.  This practice is based on the
  698.                    assumption that mail users have control over the
  699.                    addresses their mailers send to the mail gateway.  In
  700.                    practice, however, users have little control over the
  701.                    addresses that are finally sent; their mailers are
  702.                    free to change addresses into any legal RFC-822
  703.                    format.
  704.          (D)  The gateway MUST ensure that all header fields of a
  705.               message that it forwards into the Internet meet the
  706.               requirements for Internet mail.  In particular, all
  707.               addresses in "From:", "To:", "Cc:", etc., fields must be
  708.               transformed (if necessary) to satisfy RFC-822 syntax, and
  709.               they must be effective and useful for sending replies.
  710.          (E)  The translation algorithm used to convert mail from the
  711.               Internet protocols to another environment's protocol
  712.               SHOULD try to ensure that error messages from the foreign
  713.               mail environment are delivered to the return path from the
  714.               SMTP envelope, not to the sender listed in the "From:"
  715.               field of the RFC-822 message.
  716.               DISCUSSION:
  717.                    Internet mail lists usually place the address of the
  718.                    mail list maintainer in the envelope but leave the
  719. Internet Engineering Task Force                                [Page 67]
  720. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  721.                    original message header intact (with the "From:"
  722.                    field containing the original sender).  This yields
  723.                    the behavior the average recipient expects: a reply
  724.                    to the header gets sent to the original sender, not
  725.                    to a mail list maintainer; however, errors get sent
  726.                    to the maintainer (who can fix the problem) and not
  727.                    the sender (who probably cannot).
  728.          (F)  Similarly, when forwarding a message from another
  729.               environment into the Internet, the gateway SHOULD set the
  730.               envelope return path in accordance with an error message
  731.               return address, if any, supplied by the foreign
  732.               environment.
  733.       5.3.8  Maximum Message Size
  734.          Mailer software MUST be able to send and receive messages of at
  735.          least 64K bytes in length (including header), and a much larger
  736.          maximum size is highly desirable.
  737.          DISCUSSION:
  738.               Although SMTP does not define the maximum size of a
  739.               message, many systems impose implementation limits.
  740.               The current de facto minimum limit in the Internet is 64K
  741.               bytes.  However, electronic mail is used for a variety of
  742.               purposes that create much larger messages.  For example,
  743.               mail is often used instead of FTP for transmitting ASCII
  744.               files, and in particular to transmit entire documents.  As
  745.               a result, messages can be 1 megabyte or even larger.  We
  746.               note that the present document together with its lower-
  747.               layer companion contains 0.5 megabytes.
  748. Internet Engineering Task Force                                [Page 68]
  749. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  750.    5.4  SMTP REQUIREMENTS SUMMARY
  751.                                                |          | | | |S| |
  752.                                                |          | | | |H| |F
  753.                                                |          | | | |O|M|o
  754.                                                |          | |S| |U|U|o
  755.                                                |          | |H| |L|S|t
  756.                                                |          |M|O| |D|T|n
  757.                                                |          |U|U|M| | |o
  758.                                                |          |S|L|A|N|N|t
  759.                                                |          |T|D|Y|O|O|t
  760. FEATURE                                        |SECTION   | | | |T|T|e
  761. -----------------------------------------------|----------|-|-|-|-|-|--
  762.                                                |          | | | | | |
  763. RECEIVER-SMTP:                                 |          | | | | | |
  764.   Implement VRFY                               |5.2.3     |x| | | | |
  765.   Implement EXPN                               |5.2.3     | |x| | | |
  766.     EXPN, VRFY configurable                    |5.2.3     | | |x| | |
  767.   Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
  768.   Verify HELO parameter                        |5.2.5     | | |x| | |
  769.     Refuse message with bad HELO               |5.2.5     | | | | |x|
  770.   Accept explicit src-route syntax in env.     |5.2.6     |x| | | | |
  771.   Support "postmaster"                         |5.2.7     |x| | | | |
  772.   Process RCPT when received (except lists)    |5.2.7     | | |x| | |
  773.       Long delay of RCPT responses             |5.2.7     | | | | |x|
  774.                                                |          | | | | | |
  775.   Add Received: line                           |5.2.8     |x| | | | |
  776.       Received: line include domain literal    |5.2.8     | |x| | | |
  777.   Change previous Received: line               |5.2.8     | | | | |x|
  778.   Pass Return-Path info (final deliv/gwy)      |5.2.8     |x| | | | |
  779.   Support empty reverse path                   |5.2.9     |x| | | | |
  780.   Send only official reply codes               |5.2.10    | |x| | | |
  781.   Send text from RFC-821 when appropriate      |5.2.10    | |x| | | |
  782.   Delete "." for transparency                  |5.2.11    |x| | | | |
  783.   Accept and recognize self domain literal(s)  |5.2.17    |x| | | | |
  784.                                                |          | | | | | |
  785.   Error message about error message            |5.3.1     | | | | |x|
  786.   Keep pending listen on SMTP port             |5.3.1.2   | |x| | | |
  787.   Provide limit on recv concurrency            |5.3.1.2   | | |x| | |
  788.   Wait at least 5 mins for next sender cmd     |5.3.2     | |x| | | |
  789.   Avoidable delivery failure after "250 OK"    |5.3.3     | | | | |x|
  790.   Send error notification msg after accept     |5.3.3     |x| | | | |
  791.     Send using null return path                |5.3.3     |x| | | | |
  792.     Send to envelope return path               |5.3.3     | |x| | | |
  793.     Send to null address                       |5.3.3     | | | | |x|
  794.     Strip off explicit src route               |5.3.3     | |x| | | |
  795.   Minimize acceptance delay (RFC-1047)         |5.3.3     |x| | | | |
  796. -----------------------------------------------|----------|-|-|-|-|-|--
  797. Internet Engineering Task Force                                [Page 69]
  798. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  799.                                                |          | | | | | |
  800. SENDER-SMTP:                                   |          | | | | | |
  801.   Canonicalized domain names in MAIL, RCPT     |5.2.2     |x| | | | |
  802.   Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
  803.   Send valid principal host name in HELO       |5.2.5     |x| | | | |
  804.   Send explicit source route in RCPT TO:       |5.2.6     | | | |x| |
  805.   Use only reply code to determine action      |5.2.10    |x| | | | |
  806.   Use only high digit of reply code when poss. |5.2.10    | |x| | | |
  807.   Add "." for transparency                     |5.2.11    |x| | | | |
  808.                                                |          | | | | | |
  809.   Retry messages after soft failure            |5.3.1.1   |x| | | | |
  810.     Delay before retry                         |5.3.1.1   |x| | | | |
  811.     Configurable retry parameters              |5.3.1.1   |x| | | | |
  812.     Retry once per each queued dest host       |5.3.1.1   | |x| | | |
  813.   Multiple RCPT's for same DATA                |5.3.1.1   | |x| | | |
  814.   Support multiple concurrent transactions     |5.3.1.1   | | |x| | |
  815.     Provide limit on concurrency               |5.3.1.1   | |x| | | |
  816.                                                |          | | | | | |
  817.   Timeouts on all activities                   |5.3.1     |x| | | | |
  818.     Per-command timeouts                       |5.3.2     | |x| | | |
  819.     Timeouts easily reconfigurable             |5.3.2     | |x| | | |
  820.     Recommended times                          |5.3.2     | |x| | | |
  821.   Try alternate addr's in order                |5.3.4     |x| | | | |
  822.     Configurable limit on alternate tries      |5.3.4     | | |x| | |
  823.     Try at least two alternates                |5.3.4     | |x| | | |
  824.   Load-split across equal MX alternates        |5.3.4     | |x| | | |
  825.   Use the Domain Name System                   |5.3.5     |x| | | | |
  826.     Support MX records                         |5.3.5     |x| | | | |
  827.     Use WKS records in MX processing           |5.2.12    | | | |x| |
  828. -----------------------------------------------|----------|-|-|-|-|-|--
  829.                                                |          | | | | | |
  830. MAIL FORWARDING:                               |          | | | | | |
  831.   Alter existing header field(s)               |5.2.6     | | | |x| |
  832.   Implement relay function: 821/section 3.6    |5.2.6     | | |x| | |
  833.     If not, deliver to RHS domain              |5.2.6     | |x| | | |
  834.   Interpret 'local-part' of addr               |5.2.16    | | | | |x|
  835.                                                |          | | | | | |
  836. MAILING LISTS AND ALIASES                      |          | | | | | |
  837.   Support both                                 |5.3.6     | |x| | | |
  838.   Report mail list error to local admin.       |5.3.6     |x| | | | |
  839.                                                |          | | | | | |
  840. MAIL GATEWAYS:                                 |          | | | | | |
  841.   Embed foreign mail route in local-part       |5.2.16    | | |x| | |
  842.   Rewrite header fields when necessary         |5.3.7     | | |x| | |
  843.   Prepend Received: line                       |5.3.7     |x| | | | |
  844.   Change existing Received: line               |5.3.7     | | | | |x|
  845.   Accept full RFC-822 on Internet side         |5.3.7     | |x| | | |
  846.   Act on RFC-822 explicit source route         |5.3.7     | | |x| | |
  847. Internet Engineering Task Force                                [Page 70]
  848. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  849.   Send only valid RFC-822 on Internet side     |5.3.7     |x| | | | |
  850.   Deliver error msgs to envelope addr          |5.3.7     | |x| | | |
  851.   Set env return path from err return addr     |5.3.7     | |x| | | |
  852.                                                |          | | | | | |
  853. USER AGENT -- RFC-822                          |          | | | | | |
  854.   Allow user to enter <route> address          |5.2.6     | | | |x| |
  855.   Support RFC-1049 Content Type field          |5.2.13    | | |x| | |
  856.   Use 4-digit years                            |5.2.14    | |x| | | |
  857.   Generate numeric timezones                   |5.2.14    | |x| | | |
  858.   Accept all timezones                         |5.2.14    |x| | | | |
  859.   Use non-num timezones from RFC-822           |5.2.14    |x| | | | |
  860.   Omit phrase before route-addr                |5.2.15    | | |x| | |
  861.   Accept and parse dot.dec. domain literals    |5.2.17    |x| | | | |
  862.   Accept all RFC-822 address formats           |5.2.18    |x| | | | |
  863.   Generate invalid RFC-822 address format      |5.2.18    | | | | |x|
  864.   Fully-qualified domain names in header       |5.2.18    |x| | | | |
  865.   Create explicit src route in header          |5.2.19    | | | |x| |
  866.   Accept explicit src route in header          |5.2.19    |x| | | | |
  867.                                                |          | | | | | |
  868. Send/recv at least 64KB messages               |5.3.8     |x| | | | |
  869. Internet Engineering Task Force                                [Page 71]
  870. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  871. 6. SUPPORT SERVICES
  872.    6.1 DOMAIN NAME TRANSLATION
  873.       6.1.1 INTRODUCTION
  874.          Every host MUST implement a resolver for the Domain Name System
  875.          (DNS), and it MUST implement a mechanism using this DNS
  876.          resolver to convert host names to IP addresses and vice-versa
  877.          [DNS:1, DNS:2].
  878.          In addition to the DNS, a host MAY also implement a host name
  879.          translation mechanism that searches a local Internet host
  880.          table.  See Section 6.1.3.8 for more information on this
  881.          option.
  882.          DISCUSSION:
  883.               Internet host name translation was originally performed by
  884.               searching local copies of a table of all hosts.  This
  885.               table became too large to update and distribute in a
  886.               timely manner and too large to fit into many hosts, so the
  887.               DNS was invented.
  888.               The DNS creates a distributed database used primarily for
  889.               the translation between host names and host addresses.
  890.               Implementation of DNS software is required.  The DNS
  891.               consists of two logically distinct parts: name servers and
  892.               resolvers (although implementations often combine these
  893.               two logical parts in the interest of efficiency) [DNS:2].
  894.               Domain name servers store authoritative data about certain
  895.               sections of the database and answer queries about the
  896.               data.  Domain resolvers query domain name servers for data
  897.               on behalf of user processes.  Every host therefore needs a
  898.               DNS resolver; some host machines will also need to run
  899.               domain name servers.  Since no name server has complete
  900.               information, in general it is necessary to obtain
  901.               information from more than one name server to resolve a
  902.               query.
  903.       6.1.2  PROTOCOL WALK-THROUGH
  904.          An implementor must study references [DNS:1] and [DNS:2]
  905.          carefully.  They provide a thorough description of the theory,
  906.          protocol, and implementation of the domain name system, and
  907.          reflect several years of experience.
  908. Internet Engineering Task Force                                [Page 72]
  909. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  910.          6.1.2.1  Resource Records with Zero TTL: RFC-1035 Section 3.2.1
  911.             All DNS name servers and resolvers MUST properly handle RRs
  912.             with a zero TTL: return the RR to the client but do not
  913.             cache it.
  914.             DISCUSSION:
  915.                  Zero TTL values are interpreted to mean that the RR can
  916.                  only be used for the transaction in progress, and
  917.                  should not be cached; they are useful for extremely
  918.                  volatile data.
  919.          6.1.2.2  QCLASS Values: RFC-1035 Section 3.2.5
  920.             A query with "QCLASS=*" SHOULD NOT be used unless the
  921.             requestor is seeking data from more than one class.  In
  922.             particular, if the requestor is only interested in Internet
  923.             data types, QCLASS=IN MUST be used.
  924.          6.1.2.3  Unused Fields: RFC-1035 Section 4.1.1
  925.             Unused fields in a query or response message MUST be zero.
  926.          6.1.2.4  Compression: RFC-1035 Section 4.1.4
  927.             Name servers MUST use compression in responses.
  928.             DISCUSSION:
  929.                  Compression is essential to avoid overflowing UDP
  930.                  datagrams; see Section 6.1.3.2.
  931.          6.1.2.5  Misusing Configuration Info: RFC-1035 Section 6.1.2
  932.             Recursive name servers and full-service resolvers generally
  933.             have some configuration information containing hints about
  934.             the location of root or local name servers.  An
  935.             implementation MUST NOT include any of these hints in a
  936.             response.
  937.             DISCUSSION:
  938.                  Many implementors have found it convenient to store
  939.                  these hints as if they were cached data, but some
  940.                  neglected to ensure that this "cached data" was not
  941.                  included in responses.  This has caused serious
  942.                  problems in the Internet when the hints were obsolete
  943.                  or incorrect.
  944. Internet Engineering Task Force                                [Page 73]
  945. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  946.       6.1.3  SPECIFIC ISSUES
  947.          6.1.3.1  Resolver Implementation
  948.             A name resolver SHOULD be able to multiplex concurrent
  949.             requests if the host supports concurrent processes.
  950.             In implementing a DNS resolver, one of two different models
  951.             MAY optionally be chosen: a full-service resolver, or a stub
  952.             resolver.
  953.             (A)  Full-Service Resolver
  954.                  A full-service resolver is a complete implementation of
  955.                  the resolver service, and is capable of dealing with
  956.                  communication failures, failure of individual name
  957.                  servers, location of the proper name server for a given
  958.                  name, etc.  It must satisfy the following requirements:
  959.                  o    The resolver MUST implement a local caching
  960.                       function to avoid repeated remote access for
  961.                       identical requests, and MUST time out information
  962.                       in the cache.
  963.                  o    The resolver SHOULD be configurable with start-up
  964.                       information pointing to multiple root name servers
  965.                       and multiple name servers for the local domain.
  966.                       This insures that the resolver will be able to
  967.                       access the whole name space in normal cases, and
  968.                       will be able to access local domain information
  969.                       should the local network become disconnected from
  970.                       the rest of the Internet.
  971.             (B)  Stub Resolver
  972.                  A "stub resolver" relies on the services of a recursive
  973.                  name server on the connected network or a "nearby"
  974.                  network.  This scheme allows the host to pass on the
  975.                  burden of the resolver function to a name server on
  976.                  another host.  This model is often essential for less
  977.                  capable hosts, such as PCs, and is also recommended
  978.                  when the host is one of several workstations on a local
  979.                  network, because it allows all of the workstations to
  980.                  share the cache of the recursive name server and hence
  981.                  reduce the number of domain requests exported by the
  982.                  local network.
  983. Internet Engineering Task Force                                [Page 74]
  984. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  985.                  At a minimum, the stub resolver MUST be capable of
  986.                  directing its requests to redundant recursive name
  987.                  servers.  Note that recursive name servers are allowed
  988.                  to restrict the sources of requests that they will
  989.                  honor, so the host administrator must verify that the
  990.                  service will be provided.  Stub resolvers MAY implement
  991.                  caching if they choose, but if so, MUST timeout cached
  992.                  information.
  993.          6.1.3.2  Transport Protocols
  994.             DNS resolvers and recursive servers MUST support UDP, and
  995.             SHOULD support TCP, for sending (non-zone-transfer) queries.
  996.             Specifically, a DNS resolver or server that is sending a
  997.             non-zone-transfer query MUST send a UDP query first.  If the
  998.             Answer section of the response is truncated and if the
  999.             requester supports TCP, it SHOULD try the query again using
  1000.             TCP.
  1001.             DNS servers MUST be able to service UDP queries and SHOULD
  1002.             be able to service TCP queries.  A name server MAY limit the
  1003.             resources it devotes to TCP queries, but it SHOULD NOT
  1004.             refuse to service a TCP query just because it would have
  1005.             succeeded with UDP.
  1006.             Truncated responses MUST NOT be saved (cached) and later
  1007.             used in such a way that the fact that they are truncated is
  1008.             lost.
  1009.             DISCUSSION:
  1010.                  UDP is preferred over TCP for queries because UDP
  1011.                  queries have much lower overhead, both in packet count
  1012.                  and in connection state.  The use of UDP is essential
  1013.                  for heavily-loaded servers, especially the root
  1014.                  servers.  UDP also offers additional robustness, since
  1015.                  a resolver can attempt several UDP queries to different
  1016.                  servers for the cost of a single TCP query.
  1017.                  It is possible for a DNS response to be truncated,
  1018.                  although this is a very rare occurrence in the present
  1019.                  Internet DNS.  Practically speaking, truncation cannot
  1020.                  be predicted, since it is data-dependent.  The
  1021.                  dependencies include the number of RRs in the answer,
  1022.                  the size of each RR, and the savings in space realized
  1023.                  by the name compression algorithm.  As a rule of thumb,
  1024.                  truncation in NS and MX lists should not occur for
  1025.                  answers containing 15 or fewer RRs.
  1026. Internet Engineering Task Force                                [Page 75]
  1027. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1028.                  Whether it is possible to use a truncated answer
  1029.                  depends on the application.  A mailer must not use a
  1030.                  truncated MX response, since this could lead to mail
  1031.                  loops.
  1032.                  Responsible practices can make UDP suffice in the vast
  1033.                  majority of cases.  Name servers must use compression
  1034.                  in responses.  Resolvers must differentiate truncation
  1035.                  of the Additional section of a response (which only
  1036.                  loses extra information) from truncation of the Answer
  1037.                  section (which for MX records renders the response
  1038.                  unusable by mailers).  Database administrators should
  1039.                  list only a reasonable number of primary names in lists
  1040.                  of name servers, MX alternatives, etc.
  1041.                  However, it is also clear that some new DNS record
  1042.                  types defined in the future will contain information
  1043.                  exceeding the 512 byte limit that applies to UDP, and
  1044.                  hence will require TCP.  Thus, resolvers and name
  1045.                  servers should implement TCP services as a backup to
  1046.                  UDP today, with the knowledge that they will require
  1047.                  the TCP service in the future.
  1048.             By private agreement, name servers and resolvers MAY arrange
  1049.             to use TCP for all traffic between themselves.  TCP MUST be
  1050.             used for zone transfers.
  1051.             A DNS server MUST have sufficient internal concurrency that
  1052.             it can continue to process UDP queries while awaiting a
  1053.             response or performing a zone transfer on an open TCP
  1054.             connection [DNS:2].
  1055.             A server MAY support a UDP query that is delivered using an
  1056.             IP broadcast or multicast address.  However, the Recursion
  1057.             Desired bit MUST NOT be set in a query that is multicast,
  1058.             and MUST be ignored by name servers receiving queries via a
  1059.             broadcast or multicast address.  A host that sends broadcast
  1060.             or multicast DNS queries SHOULD send them only as occasional
  1061.             probes, caching the IP address(es) it obtains from the
  1062.             response(s) so it can normally send unicast queries.
  1063.             DISCUSSION:
  1064.                  Broadcast or (especially) IP multicast can provide a
  1065.                  way to locate nearby name servers without knowing their
  1066.                  IP addresses in advance.  However, general broadcasting
  1067.                  of recursive queries can result in excessive and
  1068.                  unnecessary load on both network and servers.
  1069. Internet Engineering Task Force                                [Page 76]
  1070. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1071.          6.1.3.3  Efficient Resource Usage
  1072.             The following requirements on servers and resolvers are very
  1073.             important to the health of the Internet as a whole,
  1074.             particularly when DNS services are invoked repeatedly by
  1075.             higher level automatic servers, such as mailers.
  1076.             (1)  The resolver MUST implement retransmission controls to
  1077.                  insure that it does not waste communication bandwidth,
  1078.                  and MUST impose finite bounds on the resources consumed
  1079.                  to respond to a single request.  See [DNS:2] pages 43-
  1080.                  44 for specific recommendations.
  1081.             (2)  After a query has been retransmitted several times
  1082.                  without a response, an implementation MUST give up and
  1083.                  return a soft error to the application.
  1084.             (3)  All DNS name servers and resolvers SHOULD cache
  1085.                  temporary failures, with a timeout period of the order
  1086.                  of minutes.
  1087.                  DISCUSSION:
  1088.                       This will prevent applications that immediately
  1089.                       retry soft failures (in violation of Section 2.2
  1090.                       of this document) from generating excessive DNS
  1091.                       traffic.
  1092.             (4)  All DNS name servers and resolvers SHOULD cache
  1093.                  negative responses that indicate the specified name, or
  1094.                  data of the specified type, does not exist, as
  1095.                  described in [DNS:2].
  1096.             (5)  When a DNS server or resolver retries a UDP query, the
  1097.                  retry interval SHOULD be constrained by an exponential
  1098.                  backoff algorithm, and SHOULD also have upper and lower
  1099.                  bounds.
  1100.                  IMPLEMENTATION:
  1101.                       A measured RTT and variance (if available) should
  1102.                       be used to calculate an initial retransmission
  1103.                       interval.  If this information is not available, a
  1104.                       default of no less than 5 seconds should be used.
  1105.                       Implementations may limit the retransmission
  1106.                       interval, but this limit must exceed twice the
  1107.                       Internet maximum segment lifetime plus service
  1108.                       delay at the name server.
  1109.             (6)  When a resolver or server receives a Source Quench for
  1110. Internet Engineering Task Force                                [Page 77]
  1111. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1112.                  a query it has issued, it SHOULD take steps to reduce
  1113.                  the rate of querying that server in the near future.  A
  1114.                  server MAY ignore a Source Quench that it receives as
  1115.                  the result of sending a response datagram.
  1116.                  IMPLEMENTATION:
  1117.                       One recommended action to reduce the rate is to
  1118.                       send the next query attempt to an alternate
  1119.                       server, if there is one available.  Another is to
  1120.                       backoff the retry interval for the same server.
  1121.          6.1.3.4  Multihomed Hosts
  1122.             When the host name-to-address function encounters a host
  1123.             with multiple addresses, it SHOULD rank or sort the
  1124.             addresses using knowledge of the immediately connected
  1125.             network number(s) and any other applicable performance or
  1126.             history information.
  1127.             DISCUSSION:
  1128.                  The different addresses of a multihomed host generally
  1129.                  imply different Internet paths, and some paths may be
  1130.                  preferable to others in performance, reliability, or
  1131.                  administrative restrictions.  There is no general way
  1132.                  for the domain system to determine the best path.  A
  1133.                  recommended approach is to base this decision on local
  1134.                  configuration information set by the system
  1135.                  administrator.
  1136.             IMPLEMENTATION:
  1137.                  The following scheme has been used successfully:
  1138.                  (a)  Incorporate into the host configuration data a
  1139.                       Network-Preference List, that is simply a list of
  1140.                       networks in preferred order.  This list may be
  1141.                       empty if there is no preference.
  1142.                  (b)  When a host name is mapped into a list of IP
  1143.                       addresses, these addresses should be sorted by
  1144.                       network number, into the same order as the
  1145.                       corresponding networks in the Network-Preference
  1146.                       List.  IP addresses whose networks do not appear
  1147.                       in the Network-Preference List should be placed at
  1148.                       the end of the list.
  1149. Internet Engineering Task Force                                [Page 78]
  1150. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1151.          6.1.3.5  Extensibility
  1152.             DNS software MUST support all well-known, class-independent
  1153.             formats [DNS:2], and SHOULD be written to minimize the
  1154.             trauma associated with the introduction of new well-known
  1155.             types and local experimentation with non-standard types.
  1156.             DISCUSSION:
  1157.                  The data types and classes used by the DNS are
  1158.                  extensible, and thus new types will be added and old
  1159.                  types deleted or redefined.  Introduction of new data
  1160.                  types ought to be dependent only upon the rules for
  1161.                  compression of domain names inside DNS messages, and
  1162.                  the translation between printable (i.e., master file)
  1163.                  and internal formats for Resource Records (RRs).
  1164.                  Compression relies on knowledge of the format of data
  1165.                  inside a particular RR.  Hence compression must only be
  1166.                  used for the contents of well-known, class-independent
  1167.                  RRs, and must never be used for class-specific RRs or
  1168.                  RR types that are not well-known.  The owner name of an
  1169.                  RR is always eligible for compression.
  1170.                  A name server may acquire, via zone transfer, RRs that
  1171.                  the server doesn't know how to convert to printable
  1172.                  format.  A resolver can receive similar information as
  1173.                  the result of queries.  For proper operation, this data
  1174.                  must be preserved, and hence the implication is that
  1175.                  DNS software cannot use textual formats for internal
  1176.                  storage.
  1177.                  The DNS defines domain name syntax very generally -- a
  1178.                  string of labels each containing up to 63 8-bit octets,
  1179.                  separated by dots, and with a maximum total of 255
  1180.                  octets.  Particular applications of the DNS are
  1181.                  permitted to further constrain the syntax of the domain
  1182.                  names they use, although the DNS deployment has led to
  1183.                  some applications allowing more general names.  In
  1184.                  particular, Section 2.1 of this document liberalizes
  1185.                  slightly the syntax of a legal Internet host name that
  1186.                  was defined in RFC-952 [DNS:4].
  1187.          6.1.3.6  Status of RR Types
  1188.             Name servers MUST be able to load all RR types except MD and
  1189.             MF from configuration files.  The MD and MF types are
  1190.             obsolete and MUST NOT be implemented; in particular, name
  1191.             servers MUST NOT load these types from configuration files.
  1192. Internet Engineering Task Force                                [Page 79]
  1193. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1194.             DISCUSSION:
  1195.                  The RR types MB, MG, MR, NULL, MINFO and RP are
  1196.                  considered experimental, and applications that use the
  1197.                  DNS cannot expect these RR types to be supported by
  1198.                  most domains.  Furthermore these types are subject to
  1199.                  redefinition.
  1200.                  The TXT and WKS RR types have not been widely used by
  1201.                  Internet sites; as a result, an application cannot rely
  1202.                  on the the existence of a TXT or WKS RR in most
  1203.                  domains.
  1204.          6.1.3.7  Robustness
  1205.             DNS software may need to operate in environments where the
  1206.             root servers or other servers are unavailable due to network
  1207.             connectivity or other problems.  In this situation, DNS name
  1208.             servers and resolvers MUST continue to provide service for
  1209.             the reachable part of the name space, while giving temporary
  1210.             failures for the rest.
  1211.             DISCUSSION:
  1212.                  Although the DNS is meant to be used primarily in the
  1213.                  connected Internet, it should be possible to use the
  1214.                  system in networks which are unconnected to the
  1215.                  Internet.  Hence implementations must not depend on
  1216.                  access to root servers before providing service for
  1217.                  local names.
  1218.          6.1.3.8  Local Host Table
  1219.             DISCUSSION:
  1220.                  A host may use a local host table as a backup or
  1221.                  supplement to the DNS.  This raises the question of
  1222.                  which takes precedence, the DNS or the host table; the
  1223.                  most flexible approach would make this a configuration
  1224.                  option.
  1225.                  Typically, the contents of such a supplementary host
  1226.                  table will be determined locally by the site.  However,
  1227.                  a publically-available table of Internet hosts is
  1228.                  maintained by the DDN Network Information Center (DDN
  1229.                  NIC), with a format documented in [DNS:4].  This table
  1230.                  can be retrieved from the DDN NIC using a protocol
  1231.                  described in [DNS:5].  It must be noted that this table
  1232.                  contains only a small fraction of all Internet hosts.
  1233.                  Hosts using this protocol to retrieve the DDN NIC host
  1234.                  table should use the VERSION command to check if the
  1235. Internet Engineering Task Force                                [Page 80]
  1236. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1237.                  table has changed before requesting the entire table
  1238.                  with the ALL command.  The VERSION identifier should be
  1239.                  treated as an arbitrary string and tested only for
  1240.                  equality; no numerical sequence may be assumed.
  1241.                  The DDN NIC host table includes administrative
  1242.                  information that is not needed for host operation and
  1243.                  is therefore not currently included in the DNS
  1244.                  database; examples include network and gateway entries.
  1245.                  However, much of this additional information will be
  1246.                  added to the DNS in the future.  Conversely, the DNS
  1247.                  provides essential services (in particular, MX records)
  1248.                  that are not available from the DDN NIC host table.
  1249.       6.1.4  DNS USER INTERFACE
  1250.          6.1.4.1  DNS Administration
  1251.             This document is concerned with design and implementation
  1252.             issues in host software, not with administrative or
  1253.             operational issues.  However, administrative issues are of
  1254.             particular importance in the DNS, since errors in particular
  1255.             segments of this large distributed database can cause poor
  1256.             or erroneous performance for many sites.  These issues are
  1257.             discussed in [DNS:6] and [DNS:7].
  1258.          6.1.4.2  DNS User Interface
  1259.             Hosts MUST provide an interface to the DNS for all
  1260.             application programs running on the host.  This interface
  1261.             will typically direct requests to a system process to
  1262.             perform the resolver function [DNS:1, 6.1:2].
  1263.             At a minimum, the basic interface MUST support a request for
  1264.             all information of a specific type and class associated with
  1265.             a specific name, and it MUST return either all of the
  1266.             requested information, a hard error code, or a soft error
  1267.             indication.  When there is no error, the basic interface
  1268.             returns the complete response information without
  1269.             modification, deletion, or ordering, so that the basic
  1270.             interface will not need to be changed to accommodate new
  1271.             data types.
  1272.             DISCUSSION:
  1273.                  The soft error indication is an essential part of the
  1274.                  interface, since it may not always be possible to
  1275.                  access particular information from the DNS; see Section
  1276.                  6.1.3.3.
  1277. Internet Engineering Task Force                                [Page 81]
  1278. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1279.             A host MAY provide other DNS interfaces tailored to
  1280.             particular functions, transforming the raw domain data into
  1281.             formats more suited to these functions.  In particular, a
  1282.             host MUST provide a DNS interface to facilitate translation
  1283.             between host addresses and host names.
  1284.          6.1.4.3 Interface Abbreviation Facilities
  1285.             User interfaces MAY provide a method for users to enter
  1286.             abbreviations for commonly-used names.  Although the
  1287.             definition of such methods is outside of the scope of the
  1288.             DNS specification, certain rules are necessary to insure
  1289.             that these methods allow access to the entire DNS name space
  1290.             and to prevent excessive use of Internet resources.
  1291.             If an abbreviation method is provided, then:
  1292.             (a)  There MUST be some convention for denoting that a name
  1293.                  is already complete, so that the abbreviation method(s)
  1294.                  are suppressed.  A trailing dot is the usual method.
  1295.             (b)  Abbreviation expansion MUST be done exactly once, and
  1296.                  MUST be done in the context in which the name was
  1297.                  entered.
  1298.             DISCUSSION:
  1299.                  For example, if an abbreviation is used in a mail
  1300.                  program for a destination, the abbreviation should be
  1301.                  expanded into a full domain name and stored in the
  1302.                  queued message with an indication that it is already
  1303.                  complete.  Otherwise, the abbreviation might be
  1304.                  expanded with a mail system search list, not the
  1305.                  user's, or a name could grow due to repeated
  1306.                  canonicalizations attempts interacting with wildcards.
  1307.             The two most common abbreviation methods are:
  1308.             (1)  Interface-level aliases
  1309.                  Interface-level aliases are conceptually implemented as
  1310.                  a list of alias/domain name pairs. The list can be
  1311.                  per-user or per-host, and separate lists can be
  1312.                  associated with different functions, e.g. one list for
  1313.                  host name-to-address translation, and a different list
  1314.                  for mail domains.  When the user enters a name, the
  1315.                  interface attempts to match the name to the alias
  1316.                  component of a list entry, and if a matching entry can
  1317. Internet Engineering Task Force                                [Page 82]
  1318. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1319.                  be found, the name is replaced by the domain name found
  1320.                  in the pair.
  1321.                  Note that interface-level aliases and CNAMEs are
  1322.                  completely separate mechanisms; interface-level aliases
  1323.                  are a local matter while CNAMEs are an Internet-wide
  1324.                  aliasing mechanism which is a required part of any DNS
  1325.                  implementation.
  1326.             (2)  Search Lists
  1327.                  A search list is conceptually implemented as an ordered
  1328.                  list of domain names.  When the user enters a name, the
  1329.                  domain names in the search list are used as suffixes to
  1330.                  the user-supplied name, one by one, until a domain name
  1331.                  with the desired associated data is found, or the
  1332.                  search list is exhausted.  Search lists often contain
  1333.                  the name of the local host's parent domain or other
  1334.                  ancestor domains.  Search lists are often per-user or
  1335.                  per-process.
  1336.                  It SHOULD be possible for an administrator to disable a
  1337.                  DNS search-list facility.  Administrative denial may be
  1338.                  warranted in some cases, to prevent abuse of the DNS.
  1339.                  There is danger that a search-list mechanism will
  1340.                  generate excessive queries to the root servers while
  1341.                  testing whether user input is a complete domain name,
  1342.                  lacking a final period to mark it as complete.  A
  1343.                  search-list mechanism MUST have one of, and SHOULD have
  1344.                  both of, the following two provisions to prevent this:
  1345.                  (a)  The local resolver/name server can implement
  1346.                       caching  of negative responses (see Section
  1347.                       6.1.3.3).
  1348.                  (b)  The search list expander can require two or more
  1349.                       interior dots in a generated domain name before it
  1350.                       tries using the name in a query to non-local
  1351.                       domain servers, such as the root.
  1352.                  DISCUSSION:
  1353.                       The intent of this requirement is to avoid
  1354.                       excessive delay for the user as the search list is
  1355.                       tested, and more importantly to prevent excessive
  1356.                       traffic to the root and other high-level servers.
  1357.                       For example, if the user supplied a name "X" and
  1358.                       the search list contained the root as a component,
  1359. Internet Engineering Task Force                                [Page 83]
  1360. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1361.                       a query would have to consult a root server before
  1362.                       the next search list alternative could be tried.
  1363.                       The resulting load seen by the root servers and
  1364.                       gateways near the root would be multiplied by the
  1365.                       number of hosts in the Internet.
  1366.                       The negative caching alternative limits the effect
  1367.                       to the first time a name is used.  The interior
  1368.                       dot rule is simpler to implement but can prevent
  1369.                       easy use of some top-level names.
  1370.       6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
  1371.                                                |           | | | |S| |
  1372.                                                |           | | | |H| |F
  1373.                                                |           | | | |O|M|o
  1374.                                                |           | |S| |U|U|o
  1375.                                                |           | |H| |L|S|t
  1376.                                                |           |M|O| |D|T|n
  1377.                                                |           |U|U|M| | |o
  1378.                                                |           |S|L|A|N|N|t
  1379.                                                |           |T|D|Y|O|O|t
  1380. FEATURE                                        |SECTION    | | | |T|T|e
  1381. -----------------------------------------------|-----------|-|-|-|-|-|--
  1382. GENERAL ISSUES                                 |           | | | | | |
  1383.                                                |           | | | | | |
  1384. Implement DNS name-to-address conversion       |6.1.1      |x| | | | |
  1385. Implement DNS address-to-name conversion       |6.1.1      |x| | | | |
  1386. Support conversions using host table           |6.1.1      | | |x| | |
  1387. Properly handle RR with zero TTL               |6.1.2.1    |x| | | | |
  1388. Use QCLASS=* unnecessarily                     |6.1.2.2    | |x| | | |
  1389.   Use QCLASS=IN for Internet class             |6.1.2.2    |x| | | | |
  1390. Unused fields zero                             |6.1.2.3    |x| | | | |
  1391. Use compression in responses                   |6.1.2.4    |x| | | | |
  1392.                                                |           | | | | | |
  1393. Include config info in responses               |6.1.2.5    | | | | |x|
  1394. Support all well-known, class-indep. types     |6.1.3.5    |x| | | | |
  1395. Easily expand type list                        |6.1.3.5    | |x| | | |
  1396. Load all RR types (except MD and MF)           |6.1.3.6    |x| | | | |
  1397. Load MD or MF type                             |6.1.3.6    | | | | |x|
  1398. Operate when root servers, etc. unavailable    |6.1.3.7    |x| | | | |
  1399. -----------------------------------------------|-----------|-|-|-|-|-|--
  1400. RESOLVER ISSUES:                               |           | | | | | |
  1401.                                                |           | | | | | |
  1402. Resolver support multiple concurrent requests  |6.1.3.1    | |x| | | |
  1403. Full-service resolver:                         |6.1.3.1    | | |x| | |
  1404.   Local caching                                |6.1.3.1    |x| | | | |
  1405. Internet Engineering Task Force                                [Page 84]
  1406. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1407.   Information in local cache times out         |6.1.3.1    |x| | | | |
  1408.   Configurable with starting info              |6.1.3.1    | |x| | | |
  1409. Stub resolver:                                 |6.1.3.1    | | |x| | |
  1410.   Use redundant recursive name servers         |6.1.3.1    |x| | | | |
  1411.   Local caching                                |6.1.3.1    | | |x| | |
  1412.   Information in local cache times out         |6.1.3.1    |x| | | | |
  1413. Support for remote multi-homed hosts:          |           | | | | | |
  1414.   Sort multiple addresses by preference list   |6.1.3.4    | |x| | | |
  1415.                                                |           | | | | | |
  1416. -----------------------------------------------|-----------|-|-|-|-|-|--
  1417. TRANSPORT PROTOCOLS:                           |           | | | | | |
  1418.                                                |           | | | | | |
  1419. Support UDP queries                            |6.1.3.2    |x| | | | |
  1420. Support TCP queries                            |6.1.3.2    | |x| | | |
  1421.   Send query using UDP first                   |6.1.3.2    |x| | | | |1
  1422.   Try TCP if UDP answers are truncated         |6.1.3.2    | |x| | | |
  1423. Name server limit TCP query resources          |6.1.3.2    | | |x| | |
  1424.   Punish unnecessary TCP query                 |6.1.3.2    | | | |x| |
  1425. Use truncated data as if it were not           |6.1.3.2    | | | | |x|
  1426. Private agreement to use only TCP              |6.1.3.2    | | |x| | |
  1427. Use TCP for zone transfers                     |6.1.3.2    |x| | | | |
  1428. TCP usage not block UDP queries                |6.1.3.2    |x| | | | |
  1429. Support broadcast or multicast queries         |6.1.3.2    | | |x| | |
  1430.   RD bit set in query                          |6.1.3.2    | | | | |x|
  1431.   RD bit ignored by server is b'cast/m'cast    |6.1.3.2    |x| | | | |
  1432.   Send only as occasional probe for addr's     |6.1.3.2    | |x| | | |
  1433. -----------------------------------------------|-----------|-|-|-|-|-|--
  1434. RESOURCE USAGE:                                |           | | | | | |
  1435.                                                |           | | | | | |
  1436. Transmission controls, per [DNS:2]             |6.1.3.3    |x| | | | |
  1437.   Finite bounds per request                    |6.1.3.3    |x| | | | |
  1438. Failure after retries => soft error            |6.1.3.3    |x| | | | |
  1439. Cache temporary failures                       |6.1.3.3    | |x| | | |
  1440. Cache negative responses                       |6.1.3.3    | |x| | | |
  1441. Retries use exponential backoff                |6.1.3.3    | |x| | | |
  1442.   Upper, lower bounds                          |6.1.3.3    | |x| | | |
  1443. Client handle Source Quench                    |6.1.3.3    | |x| | | |
  1444. Server ignore Source Quench                    |6.1.3.3    | | |x| | |
  1445. -----------------------------------------------|-----------|-|-|-|-|-|--
  1446. USER INTERFACE:                                |           | | | | | |
  1447.                                                |           | | | | | |
  1448. All programs have access to DNS interface      |6.1.4.2    |x| | | | |
  1449. Able to request all info for given name        |6.1.4.2    |x| | | | |
  1450. Returns complete info or error                 |6.1.4.2    |x| | | | |
  1451. Special interfaces                             |6.1.4.2    | | |x| | |
  1452.   Name<->Address translation                   |6.1.4.2    |x| | | | |
  1453.                                                |           | | | | | |
  1454. Abbreviation Facilities:                       |6.1.4.3    | | |x| | |
  1455. Internet Engineering Task Force                                [Page 85]
  1456. RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
  1457.   Convention for complete names                |6.1.4.3    |x| | | | |
  1458.   Conversion exactly once                      |6.1.4.3    |x| | | | |
  1459.   Conversion in proper context                 |6.1.4.3    |x| | | | |
  1460.   Search list:                                 |6.1.4.3    | | |x| | |
  1461.     Administrator can disable                  |6.1.4.3    | |x| | | |
  1462.     Prevention of excessive root queries       |6.1.4.3    |x| | | | |
  1463.       Both methods                             |6.1.4.3    | |x| | | |
  1464. -----------------------------------------------|-----------|-|-|-|-|-|--
  1465. -----------------------------------------------|-----------|-|-|-|-|-|--
  1466. 1.   Unless there is private agreement between particular resolver and
  1467.      particular server.
  1468. Internet Engineering Task Force                                [Page 86]
  1469. RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
  1470.    6.2  HOST INITIALIZATION
  1471.       6.2.1  INTRODUCTION
  1472.          This section discusses the initialization of host software
  1473.          across a connected network, or more generally across an
  1474.          Internet path.  This is necessary for a diskless host, and may
  1475.          optionally be used for a host with disk drives.  For a diskless
  1476.          host, the initialization process is called "network booting"
  1477.          and is controlled by a bootstrap program located in a boot ROM.
  1478.          To initialize a diskless host across the network, there are two
  1479.          distinct phases:
  1480.          (1)  Configure the IP layer.
  1481.               Diskless machines often have no permanent storage in which
  1482.               to store network configuration information, so that
  1483.               sufficient configuration information must be obtained
  1484.               dynamically to support the loading phase that follows.
  1485.               This information must include at least the IP addresses of
  1486.               the host and of the boot server.  To support booting
  1487.               across a gateway, the address mask and a list of default
  1488.               gateways are also required.
  1489.          (2)  Load the host system code.
  1490.               During the loading phase, an appropriate file transfer
  1491.               protocol is used to copy the system code across the
  1492.               network from the boot server.
  1493.          A host with a disk may perform the first step, dynamic
  1494.          configuration.  This is important for microcomputers, whose
  1495.          floppy disks allow network configuration information to be
  1496.          mistakenly duplicated on more than one host.  Also,
  1497.          installation of new hosts is much simpler if they automatically
  1498.          obtain their configuration information from a central server,
  1499.          saving administrator time and decreasing the probability of
  1500.          mistakes.
  1501.       6.2.2  REQUIREMENTS
  1502.          6.2.2.1  Dynamic Configuration
  1503.             A number of protocol provisions have been made for dynamic
  1504.             configuration.
  1505.             o    ICMP Information Request/Reply messages
  1506. Internet Engineering Task Force                                [Page 87]
  1507. RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
  1508.                  This obsolete message pair was designed to allow a host
  1509.                  to find the number of the network it is on.
  1510.                  Unfortunately, it was useful only if the host already
  1511.                  knew the host number part of its IP address,
  1512.                  information that hosts requiring dynamic configuration
  1513.                  seldom had.
  1514.             o    Reverse Address Resolution Protocol (RARP) [BOOT:4]
  1515.                  RARP is a link-layer protocol for a broadcast medium
  1516.                  that allows a host to find its IP address given its
  1517.                  link layer address.  Unfortunately, RARP does not work
  1518.                  across IP gateways and therefore requires a RARP server
  1519.                  on every network.  In addition, RARP does not provide
  1520.                  any other configuration information.
  1521.             o    ICMP Address Mask Request/Reply messages
  1522.                  These ICMP messages allow a host to learn the address
  1523.                  mask for a particular network interface.
  1524.             o    BOOTP Protocol [BOOT:2]
  1525.                  This protocol allows a host to determine the IP
  1526.                  addresses of the local host and the boot server, the
  1527.                  name of an appropriate boot file, and optionally the
  1528.                  address mask and list of default gateways.  To locate a
  1529.                  BOOTP server, the host broadcasts a BOOTP request using
  1530.                  UDP.  Ad hoc gateway extensions have been used to
  1531.                  transmit the BOOTP broadcast through gateways, and in
  1532.                  the future the IP Multicasting facility will provide a
  1533.                  standard mechanism for this purpose.
  1534.             The suggested approach to dynamic configuration is to use
  1535.             the BOOTP protocol with the extensions defined in "BOOTP
  1536.             Vendor Information Extensions" RFC-1084 [BOOT:3].  RFC-1084
  1537.             defines some important general (not vendor-specific)
  1538.             extensions.  In particular, these extensions allow the
  1539.             address mask to be supplied in BOOTP; we RECOMMEND that the
  1540.             address mask be supplied in this manner.
  1541.             DISCUSSION:
  1542.                  Historically, subnetting was defined long after IP, and
  1543.                  so a separate mechanism (ICMP Address Mask messages)
  1544.                  was designed to supply the address mask to a host.
  1545.                  However, the IP address mask and the corresponding IP
  1546.                  address conceptually form a pair, and for operational
  1547. Internet Engineering Task Force                                [Page 88]
  1548. RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
  1549.                  simplicity they ought to be defined at the same time
  1550.                  and by the same mechanism, whether a configuration file
  1551.                  or a dynamic mechanism like BOOTP.
  1552.                  Note that BOOTP is not sufficiently general to specify
  1553.                  the configurations of all interfaces of a multihomed
  1554.                  host.  A multihomed host must either use BOOTP
  1555.                  separately for each interface, or configure one
  1556.                  interface using BOOTP to perform the loading, and
  1557.                  perform the complete initialization from a file later.
  1558.                  Application layer configuration information is expected
  1559.                  to be obtained from files after loading of the system
  1560.                  code.
  1561.          6.2.2.2  Loading Phase
  1562.             A suggested approach for the loading phase is to use TFTP
  1563.             [BOOT:1] between the IP addresses established by BOOTP.
  1564.             TFTP to a broadcast address SHOULD NOT be used, for reasons
  1565.             explained in Section 4.2.3.4.
  1566. Internet Engineering Task Force                                [Page 89]
  1567. RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
  1568.    6.3  REMOTE MANAGEMENT
  1569.       6.3.1  INTRODUCTION
  1570.          The Internet community has recently put considerable effort
  1571.          into the development of network management protocols.  The
  1572.          result has been a two-pronged approach [MGT:1, MGT:6]:  the
  1573.          Simple Network Management Protocol (SNMP) [MGT:4] and the
  1574.          Common Management Information Protocol over TCP (CMOT) [MGT:5].
  1575.          In order to be managed using SNMP or CMOT, a host will need to
  1576.          implement an appropriate management agent.  An Internet host
  1577.          SHOULD include an agent for either SNMP or CMOT.
  1578.          Both SNMP and CMOT operate on a Management Information Base
  1579.          (MIB) that defines a collection of management values.  By
  1580.          reading and setting these values, a remote application may
  1581.          query and change the state of the managed system.
  1582.          A standard MIB [MGT:3] has been defined for use by both
  1583.          management protocols, using data types defined by the Structure
  1584.          of Management Information (SMI) defined in [MGT:2].  Additional
  1585.          MIB variables can be introduced under the "enterprises" and
  1586.          "experimental" subtrees of the MIB naming space [MGT:2].
  1587.          Every protocol module in the host SHOULD implement the relevant
  1588.          MIB variables.  A host SHOULD implement the MIB variables as
  1589.          defined in the most recent standard MIB, and MAY implement
  1590.          other MIB variables when appropriate and useful.
  1591.       6.3.2  PROTOCOL WALK-THROUGH
  1592.          The MIB is intended to cover both hosts and gateways, although
  1593.          there may be detailed differences in MIB application to the two
  1594.          cases.  This section contains the appropriate interpretation of
  1595.          the MIB for hosts.  It is likely that later versions of the MIB
  1596.          will include more entries for host management.
  1597.          A managed host must implement the following groups of MIB
  1598.          object definitions: System, Interfaces, Address Translation,
  1599.          IP, ICMP, TCP, and UDP.
  1600.          The following specific interpretations apply to hosts:
  1601.          o    ipInHdrErrors
  1602.               Note that the error "time-to-live exceeded" can occur in a
  1603.               host only when it is forwarding a source-routed datagram.
  1604. Internet Engineering Task Force                                [Page 90]
  1605. RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
  1606.          o    ipOutNoRoutes
  1607.               This object counts datagrams discarded because no route
  1608.               can be found.  This may happen in a host if all the
  1609.               default gateways in the host's configuration are down.
  1610.          o    ipFragOKs, ipFragFails, ipFragCreates
  1611.               A host that does not implement intentional fragmentation
  1612.               (see "Fragmentation" section of [INTRO:1]) MUST return the
  1613.               value zero for these three objects.
  1614.          o    icmpOutRedirects
  1615.               For a host, this object MUST always be zero, since hosts
  1616.               do not send Redirects.
  1617.          o    icmpOutAddrMaskReps
  1618.               For a host, this object MUST always be zero, unless the
  1619.               host is an authoritative source of address mask
  1620.               information.
  1621.          o    ipAddrTable
  1622.               For a host, the "IP Address Table" object is effectively a
  1623.               table of logical interfaces.
  1624.          o    ipRoutingTable
  1625.               For a host, the "IP Routing Table" object is effectively a
  1626.               combination of the host's Routing Cache and the static
  1627.               route table described in "Routing Outbound Datagrams"
  1628.               section of [INTRO:1].
  1629.               Within each ipRouteEntry, ipRouteMetric1...4 normally will
  1630.               have no meaning for a host and SHOULD always be -1, while
  1631.               ipRouteType will normally have the value "remote".
  1632.               If destinations on the connected network do not appear in
  1633.               the Route Cache (see "Routing Outbound Datagrams section
  1634.               of [INTRO:1]), there will be no entries with ipRouteType
  1635.               of "direct".
  1636.          DISCUSSION:
  1637.               The current MIB does not include Type-of-Service in an
  1638.               ipRouteEntry, but a future revision is expected to make
  1639. Internet Engineering Task Force                                [Page 91]
  1640. RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
  1641.               this addition.
  1642.               We also expect the MIB to be expanded to allow the remote
  1643.               management of applications (e.g., the ability to partially
  1644.               reconfigure mail systems).  Network service applications
  1645.               such as mail systems should therefore be written with the
  1646.               "hooks" for remote management.
  1647.       6.3.3  MANAGEMENT REQUIREMENTS SUMMARY
  1648.                                                |           | | | |S| |
  1649.                                                |           | | | |H| |F
  1650.                                                |           | | | |O|M|o
  1651.                                                |           | |S| |U|U|o
  1652.                                                |           | |H| |L|S|t
  1653.                                                |           |M|O| |D|T|n
  1654.                                                |           |U|U|M| | |o
  1655.                                                |           |S|L|A|N|N|t
  1656.                                                |           |T|D|Y|O|O|t
  1657. FEATURE                                        |SECTION    | | | |T|T|e
  1658. -----------------------------------------------|-----------|-|-|-|-|-|--
  1659. Support SNMP or CMOT agent                     |6.3.1      | |x| | | |
  1660. Implement specified objects in standard MIB    |6.3.1      | |x| | | |
  1661. Internet Engineering Task Force                                [Page 92]
  1662. RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
  1663. 7.  REFERENCES
  1664.    This section lists the primary references with which every
  1665.    implementer must be thoroughly familiar.  It also lists some
  1666.    secondary references that are suggested additional reading.
  1667.    INTRODUCTORY REFERENCES:
  1668.    [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
  1669.         IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
  1670.         October 1989.
  1671.    [INTRO:2]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
  1672.         (three volumes), SRI International, December 1985.
  1673.    [INTRO:3]  "Official Internet Protocols," J. Reynolds and J. Postel,
  1674.         RFC-1011, May 1987.
  1675.         This document is republished periodically with new RFC numbers;
  1676.         the latest version must be used.
  1677.    [INTRO:4]  "Protocol Document Order Information," O. Jacobsen and J.
  1678.         Postel, RFC-980, March 1986.
  1679.    [INTRO:5]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
  1680.         May 1987.
  1681.         This document is republished periodically with new RFC numbers;
  1682.         the latest version must be used.
  1683.    TELNET REFERENCES:
  1684.    [TELNET:1]  "Telnet Protocol Specification," J. Postel and J.
  1685.         Reynolds, RFC-854, May 1983.
  1686.    [TELNET:2]  "Telnet Option Specification," J. Postel and J. Reynolds,
  1687.         RFC-855, May 1983.
  1688.    [TELNET:3]  "Telnet Binary Transmission," J. Postel and J. Reynolds,
  1689.         RFC-856, May 1983.
  1690.    [TELNET:4]  "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
  1691.         May 1983.
  1692.    [TELNET:5]  "Telnet Suppress Go Ahead Option," J. Postel and J.
  1693. Internet Engineering Task Force                                [Page 93]
  1694. RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
  1695.         Reynolds, RFC-858, May 1983.
  1696.    [TELNET:6]  "Telnet Status Option," J. Postel and J. Reynolds, RFC-
  1697.         859, May 1983.
  1698.    [TELNET:7]  "Telnet Timing Mark Option," J. Postel and J. Reynolds,
  1699.         RFC-860, May 1983.
  1700.    [TELNET:8]  "Telnet Extended Options List," J. Postel and J.
  1701.         Reynolds, RFC-861, May 1983.
  1702.    [TELNET:9]  "Telnet End-Of-Record Option," J. Postel, RFC-855,
  1703.         December 1983.
  1704.    [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
  1705.         February 1989.
  1706.         This document supercedes RFC-930.
  1707.    [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
  1708.         October 1988.
  1709.    [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
  1710.         1989.
  1711.    [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
  1712.         December 1988.
  1713.    [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
  1714.         1080, November 1988.
  1715.    SECONDARY TELNET REFERENCES:
  1716.    [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
  1717.         Defense, May 1984.
  1718.         This document is intended to describe the same protocol as RFC-
  1719.         854.  In case of conflict, RFC-854 takes precedence, and the
  1720.         present document takes precedence over both.
  1721.    [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
  1722.    [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
  1723.         1977.
  1724.    [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
  1725. Internet Engineering Task Force                                [Page 94]
  1726. RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
  1727.    [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
  1728.         Implementation," A. Yasuda and T. Thompson, RFC-1043, February
  1729.         1988.
  1730.    FTP REFERENCES:
  1731.    [FTP:1]  "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
  1732.         959, October 1985.
  1733.    [FTP:2]  "Document File Format Standards," J. Postel, RFC-678,
  1734.         December 1974.
  1735.    [FTP:3]  "File Transfer Protocol," MIL-STD-1780, U.S. Department of
  1736.         Defense, May 1984.
  1737.         This document is based on an earlier version of the FTP
  1738.         specification (RFC-765) and is obsolete.
  1739.    TFTP REFERENCES:
  1740.    [TFTP:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
  1741.         1981.
  1742.    MAIL REFERENCES:
  1743.    [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
  1744.         1982.
  1745.    [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
  1746.         D. Crocker, RFC-822, August 1982.
  1747.         This document obsoleted an earlier specification, RFC-733.
  1748.    [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
  1749.         974, January 1986.
  1750.         This RFC describes the use of MX records, a mandatory extension
  1751.         to the mail delivery process.
  1752.    [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
  1753.         February 1988.
  1754. Internet Engineering Task Force                                [Page 95]
  1755. RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
  1756.    [SMTP:5a]  "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
  1757.         June 1986.
  1758.    [SMTP:5b]  "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
  1759.         The two preceding RFC's define a proposed standard for
  1760.         gatewaying mail between the Internet and the X.400 environments.
  1761.    [SMTP:6]  "Simple Mail Transfer Protocol,"  MIL-STD-1781, U.S.
  1762.         Department of Defense, May 1984.
  1763.         This specification is intended to describe the same protocol as
  1764.         does RFC-821.  However, MIL-STD-1781 is incomplete; in
  1765.         particular, it does not include MX records [SMTP:3].
  1766.    [SMTP:7]  "A Content-Type Field for Internet Messages," M. Sirbu,
  1767.         RFC-1049, March 1988.
  1768.    DOMAIN NAME SYSTEM REFERENCES:
  1769.    [DNS:1]  "Domain Names - Concepts and Facilities," P. Mockapetris,
  1770.         RFC-1034, November 1987.
  1771.         This document and the following one obsolete RFC-882, RFC-883,
  1772.         and RFC-973.
  1773.    [DNS:2]  "Domain Names - Implementation and Specification," RFC-1035,
  1774.         P. Mockapetris, November 1987.
  1775.    [DNS:3]  "Mail Routing and the Domain System," C. Partridge, RFC-974,
  1776.         January 1986.
  1777.    [DNS:4]  "DoD Internet Host Table Specification," K. Harrenstein,
  1778.         RFC-952, M. Stahl, E. Feinler, October 1985.
  1779.         SECONDARY DNS REFERENCES:
  1780.    [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
  1781.         RFC-953, October 1985.
  1782.    [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
  1783.         1987.
  1784. Internet Engineering Task Force                                [Page 96]
  1785. RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
  1786.    [DNS:7]  "Domain Administrators Operations Guide," M. Lottor, RFC-
  1787.         1033, November 1987.
  1788.    [DNS:8]  "The Domain Name System Handbook," Vol. 4 of Internet
  1789.         Protocol Handbook, NIC 50007, SRI Network Information Center,
  1790.         August 1989.
  1791.    SYSTEM INITIALIZATION REFERENCES:
  1792.    [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
  1793.         1984.
  1794.    [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
  1795.         951, September 1985.
  1796.    [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
  1797.         1084, December 1988.
  1798.         Note: this RFC revised and obsoleted RFC-1048.
  1799.    [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
  1800.         Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
  1801.    MANAGEMENT REFERENCES:
  1802.    [MGT:1]  "IAB Recommendations for the Development of Internet Network
  1803.         Management Standards," V. Cerf, RFC-1052, April 1988.
  1804.    [MGT:2]  "Structure and Identification of Management Information for
  1805.         TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
  1806.         August 1988.
  1807.    [MGT:3]  "Management Information Base for Network Management of
  1808.         TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
  1809.         August 1988.
  1810.    [MGT:4]  "A Simple Network Management Protocol," J. Case, M. Fedor,
  1811.         M. Schoffstall, and C. Davin, RFC-1098, April 1989.
  1812.    [MGT:5]  "The Common Management Information Services and Protocol
  1813.         over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
  1814.    [MGT:6]  "Report of the Second Ad Hoc Network Management Review
  1815.         Group," V. Cerf, RFC-1109, August 1989.
  1816. Internet Engineering Task Force                                [Page 97]
  1817. RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
  1818. Security Considerations
  1819.    There are many security issues in the application and support
  1820.    programs of host software, but a full discussion is beyond the scope
  1821.    of this RFC.  Security-related issues are mentioned in sections
  1822.    concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
  1823.    EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
  1824.    SMTP DATA command (Section 5.2.8).
  1825. Author's Address
  1826.    Robert Braden
  1827.    USC/Information Sciences Institute
  1828.    4676 Admiralty Way
  1829.    Marina del Rey, CA 90292-6695
  1830.    Phone: (213) 822 1511
  1831.    EMail: Braden@ISI.EDU
  1832. Internet Engineering Task Force                                [Page 98]