RFC 1123 Internet Standard Architecture

Requirements for Internet Hosts - Application and Support

This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]

Status
Internet Standard. The top of the standards track. An old document can hold this label while the document that replaced it holds a lower one, which is the single most misleading thing about RFC status.
Published
October 1989
Authors
R. Braden
Read it
rfc-editor.org · errata · DOI

This document is current and has been amended. 6 later RFCs have changed part of it. Nothing on the RFC itself tells you this.

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 119 must, 90 should, 30 may.

1 INTRODUCTION

  • REQUIREDThis word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification.
  • RECOMMENDEDThis word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
  • OPTIONALThis word or the adjective "OPTIONAL" means that this item is truly optional.
  • MUSTAn implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements.
  • MUSTAn implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant".

1 Unless there is private agreement between particular resolver and

  • SHOULD NOTTFTP to a broadcast address SHOULD NOT be used, for reasons explained in Section 4.2.3.4.
  • SHOULDAn Internet host SHOULD include an agent for either SNMP or CMOT.
  • SHOULDEvery protocol module in the host SHOULD implement the relevant MIB variables.
  • SHOULDA host SHOULD implement the MIB variables as defined in the most recent standard MIB, and MAY implement other MIB variables when appropriate and useful.
  • MUSTA host that does not implement intentional fragmentation (see "Fragmentation" section of [INTRO:1]) MUST return the value zero for these three objects.
  • MUSTFor a host, this object MUST always be zero, since hosts do not send Redirects.
  • MUSTFor a host, this object MUST always be zero, unless the host is an authoritative source of address mask information.
  • SHOULDWithin each ipRouteEntry, ipRouteMetric1...4 normally will have no meaning for a host and SHOULD always be -1, while ipRouteType will normally have the value "remote".

2 GENERAL ISSUES

  • MUSTHost software MUST support this more liberal syntax.
  • MUSTHost software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters.
  • SHOULDWhenever a user inputs the identity of an Internet host, it SHOULD be possible to enter either (1) a host domain name or (2) an IP address in dotted-decimal ("#.#.#.#") form.
  • SHOULDThe host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System.
  • MUSTHost domain names MUST be translated to IP addresses as described in Section 6.1.
  • MUSTApplications using domain name services MUST be able to cope with soft error conditions.
  • MUSTApplications MUST wait a reasonable interval between successive retries due to a soft error, and MUST
  • SHOULD NOTAn application SHOULD NOT rely on the ability to locate a WKS record containing an accurate listing of all services at a particular host address, since the WKS RR type is not often used by Internet sites.
  • SHOULDApplication protocol implementations SHOULD be prepared to try multiple addresses from the list until success is obtained.
  • SHOULDWhen the local host is multihomed, a UDP-based request/response application SHOULD send the response with an IP source address that is the same as the specific destination address of the UDP request datagram.
  • SHOULDSimilarly, a server application that opens multiple TCP connections to the same client SHOULD use the same local IP address for all.
  • MUSTApplications MUST select appropriate TOS values when they invoke transport layer services, and these values MUST be configurable.
  • MUSTNote that a TOS value contains 5 bits, of which only the most- significant 3 bits are currently defined; the other two bits MUST be zero.

3 REMOTE LOGIN -- TELNET PROTOCOL

  • MUSTEvery Telnet implementation MUST include option negotiation and subnegotiation machinery [TELNET:2].
  • MUSTA host MUST carefully follow the rules of RFC-854 to avoid option-negotiation loops.
  • MUSTA host MUST refuse (i.e, reply WONT/DONT to a DO/WILL) an unsupported option.
  • SHOULDOption negotiation SHOULD continue to function (even if all requests are refused) throughout the lifetime of a Telnet connection.
  • MUSTIf all option negotiations fail, a Telnet implementation MUST default to, and support, an NVT.
  • MUSTOn a host that never sends the Telnet command Go Ahead (GA), the Telnet Server MUST attempt to negotiate the Suppress Go Ahead option (i.e., send "WILL Suppress Go Ahead").
  • MUSTA User or Server Telnet MUST always accept negotiation of the Suppress Go
  • MAYWhen it is driving a full-duplex terminal for which GA has no meaning, a User Telnet implementation MAY ignore GA commands.
  • MAYBoth User and Server Telnets MAY support the control functions EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP, SB, and SE.
  • MUSTA host MUST be able to receive and ignore any Telnet control functions that it does not support.
  • MUSTWhen it receives "urgent" TCP data, a User or Server Telnet MUST discard all data except Telnet commands until the DM (and end of urgent) is reached.
  • SHOULDWhen it sends Telnet IP (Interrupt Process), a User Telnet SHOULD follow it by the Telnet "Synch" sequence, i.e., send as TCP urgent data the sequence "IAC IP IAC DM".
  • MAYWhen it receives a Telnet IP command, a Server Telnet MAY send a Telnet "Synch" sequence back to the user, to flush the output stream.
  • MUSTWhen it receives a Telnet AO command, a Server Telnet MUST send a Telnet "Synch" sequence back to the user, to flush the output stream.
  • SHOULDA User Telnet SHOULD have the capability of flushing output when it sends a Telnet IP; see also Section 3.4.5.
  • SHOULD NOTIn NVT mode, a Telnet SHOULD NOT send characters with the high-order bit 1, and MUST NOT send it as a parity bit.
  • SHOULDImplementations that pass the high-order bit to applications SHOULD negotiate binary mode (see Section 3.2.6).
  • SHOULDFor this reason, the requirements on the high-order bit are stated as SHOULD, not MUST.
  • MUSTSince options may appear at any point in the data stream, a Telnet escape character (known as IAC, with the value 255) to be sent as data MUST be doubled.
  • MUSTHowever, the data stream MUST still be scanned for IAC characters, any embedded Telnet commands MUST be obeyed, and data bytes equal to IAC MUST be doubled.
  • MUST NOTOther character processing (e.g., replacing CR by CR NUL or by CR LF) MUST NOT be done.
  • MUSTThe Terminal-Type option MUST use the terminal type names officially defined in the Assigned Numbers RFC [INTRO:5], when they are available for the particular terminal.
  • MUSTHowever, the receiver of a Terminal-Type option MUST accept any name.
  • MUSTWhen a Server Telnet receives the Telnet end-of-line sequence CR LF as input from a remote terminal, the effect MUST be the same as if the user had pressed the "end-of-line" key on a local terminal.
  • MUSTThus, CR LF and CR NUL MUST have the same effect on an ASCII server host when received as input over a Telnet connection.
  • MUSTA User Telnet MUST be able to send any of the forms: CR LF, CR NUL, and LF.
  • SHOULDA User Telnet on an ASCII host SHOULD have a user-controllable mode to send either CR LF or CR NUL when the user presses the "end-of-line" key, and CR LF SHOULD be the default.
  • MUSTThe Telnet end-of-line sequence CR LF MUST be used to send Telnet data that is not terminal-to-computer (e.g., for Server Telnet sending output, or the Telnet protocol incorporated another application protocol).
  • MUSTEvery Telnet implementation MUST support the Binary option [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of- Record [TELNET:9], and Extended Options List [TELNET:8] options.
  • SHOULDA User or Server Telnet SHOULD support the Window Size Option [TELNET:12] if the local operating system provides the corresponding capability.
  • SHOULDWhen the Telnet protocol is used in a client/server situation, the server SHOULD initiate negotiation of the terminal interaction mode it expects.
  • SHOULDA client (User Telnet) SHOULD provide a means for users to enable and disable the initiation of option negotiation.
  • SHOULDUser Telnet implementations SHOULD be able to send or receive any 7-bit ASCII character.
  • SHOULDWhere possible, any special character interpretations by the user host's operating system SHOULD be bypassed so that these characters can conveniently be sent and received on the connection.
  • MUSTSome character value MUST be reserved as "escape to command mode"; conventionally, doubling this character allows it to be entered as data.
  • SHOULDThe specific character used SHOULD be user selectable.
  • MAYOn binary-mode connections, a User Telnet program MAY provide an escape mechanism for entering arbitrary 8-bit values, if the host operating system doesn't allow them to be entered directly from the keyboard.
  • MUSTA User Telnet program MUST provide a user the capability of entering any of the Telnet control functions IP, AO, or AYT, and SHOULD provide the capability of entering EC, EL, and Break.
  • SHOULDA User Telnet program SHOULD report to the user any TCP errors that are reported by the transport layer (see "TCP/Application Layer Interface" section in [INTRO:1]).
  • SHOULDA User Telnet program SHOULD allow the user to optionally specify a non-standard contact port number at the Server Telnet host.
  • SHOULDA User Telnet program SHOULD provide the user the ability to specify whether or not output should be flushed when an IP is sent; see Section 3.2.4.
  • SHOULDFor any output flushing scheme that causes the User Telnet to flush output locally until a Telnet signal is received from the Server, there SHOULD be a way for the user to manually restore normal output, in case the Server fails to send the expected signal.

4 FILE TRANSFER

  • MUSTAn FTP program MUST support TYPE I ("IMAGE" or binary type) as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
  • MAYA machine whose memory is organized into m-bit words, where m is not a multiple of 8, MAY also support TYPE L m.
  • SHOULDA host that makes no distinction between TYPE N and TYPE T SHOULD implement TYPE T to be identical to TYPE N.
  • NOT RECOMMENDEDImplementation of page structure is NOT RECOMMENDED in general.
  • MUSTHowever, if a host system does need to implement FTP for "random access" or "holey" files, it MUST use the defined page structure format rather than define a new private FTP format.
  • SHOULDAn FTP transformation between record-structure and file- structure SHOULD be invertible, to the extent possible while making the result useful on the target host.
  • SHOULDA User-FTP that uses STREAM mode SHOULD send a PORT command to assign a non-default data port before each transfer command is issued.
  • MUSTA server-FTP MUST implement the PASV command.
  • MUSTIf multiple third-party transfers are to be executed during the same session, a new PASV command MUST be issued before each transfer command, to obtain a unique port pair.
  • MUSTThe data returned by an NLST command MUST contain only a simple list of legal pathnames, such that the server can use them directly as the arguments of subsequent data transfer commands for the individual files.
  • SHOULDThe data returned by a LIST or NLST command SHOULD use an
  • SHOULDimplied TYPE AN, unless the current type is EBCDIC, in which case an implied TYPE EN SHOULD be used.
  • SHOULDA Server-FTP SHOULD use the SITE command for non-standard features, rather than invent new private commands or unstandardized extensions to existing commands.
  • MUSTWhen it receives an STOU command, a Server-FTP MUST return the actual file name in the "125 Transfer Starting" or the "150 Opening Data Connection" message that precedes the transfer (the 250 reply code mentioned in RFC-959 is incorrect).
  • MUST NOTImplementors MUST NOT assume any correspondence between READ boundaries on the control connection and the Telnet EOL sequences (CR LF).
  • MUSTA Server-FTP MUST send only correctly formatted replies on the control connection.
  • SHOULDA Server-FTP SHOULD use the reply codes defined in RFC-959 whenever they apply.
  • MAYHowever, a server-FTP MAY use a different reply code when needed, as long as the general rules of Section 4.2 are followed.
  • SHOULDWhen the implementor has a choice between a 4xx and 5xx reply code, a Server-FTP SHOULD send a 4xx (temporary failure) code when there is any reasonable possibility that a failed FTP will succeed a few hours later.
  • SHOULDA User-FTP SHOULD generally use only the highest-order digit of a 3-digit reply code for making a procedural decision, to prevent difficulties when a Server-FTP uses non-standard reply codes.
  • MUSTA User-FTP MUST be able to handle multi-line replies.
  • MUSTIf the implementation imposes a limit on the number of lines and if this limit is exceeded, the User-FTP MUST recover, e.g., by ignoring the excess lines until the end of the multi-line reply is reached.
  • SHOULD NOTA User-FTP SHOULD NOT interpret a 421 reply code ("Service not available, closing control connection") specially, but SHOULD detect closing of the control connection by the server.
  • MUSTOn a multihomed server host, the default data transfer port (L-1) MUST be associated with the same local IP address as the corresponding control connection to port L.
  • MUST NOTA user-FTP MUST NOT send any Telnet controls other than SYNCH and IP on an FTP control connection.
  • MUST NOTIn particular, it MUST NOT attempt to negotiate Telnet options on the control connection.
  • MUSTHowever, a server-FTP MUST be capable of accepting and refusing Telnet negotiations (i.e., sending DONT/WONT).
  • MUSTThe following commands and options MUST be supported by every server-FTP and user-FTP, except in cases where the underlying file system or operating system does not allow or support a particular command.
  • REQUIRED*Record structure is REQUIRED only for hosts whose file systems support record structure.
  • SHOULDAll FTP implementations SHOULD recognize both forms of these commands, by simply equating them with extra entries in the command lookup table.
  • SHOULDA Server-FTP process SHOULD have an idle timeout, which will terminate the process and close the control connection if the server is inactive (i.e., no command or data transfer in progress) for a long period of time.
  • SHOULDThe idle timeout time SHOULD be configurable, and the default should be at least 5 minutes.
  • SHOULDWhen an FTP that implements restart receives a Restart Marker in the data stream, it SHOULD force the data to that point to be written to stable storage before encoding the corresponding position rrrr.
  • MUST NOTAn FTP sending Restart Markers MUST NOT assume that 110 replies will be returned synchronously with the data, i.e., it must not await a 110 reply before sending more data.
  • MUSTSince FTP is intended for use in a heterogeneous environment, User-FTP implementations MUST support remote pathnames as arbitrary character strings, so that their form and content are not limited by the conventions of the local operating system.
  • MUSTA User-FTP program MUST implement a "QUOTE" command that will pass an arbitrary character string to the server and display all resulting response messages to the user.
  • SHOULDTo make the "QUOTE" command useful, a User-FTP SHOULD send transfer control commands to the server as the user enters them, rather than saving all the commands and sending them to the server only when a data transfer is started.
  • SHOULDA User-FTP SHOULD display to the user the full text of all error reply messages it receives.
  • SHOULDIt SHOULD have a "verbose" mode in which all commands it sends and the full text and reply codes it receives are displayed, for diagnosis of problems.
  • SHOULDThe state machine in a User-FTP SHOULD be forgiving of missing and unexpected reply messages, in order to maintain command synchronization with the server.
  • SHOULD NOTThe transfer mode "mail" SHOULD NOT be supported.
  • MUSTImplementations MUST contain the fix for this problem: the sender (i.e., the side originating the DATA packets) must never resend the current DATA packet on receipt of a
  • MUSTA TFTP implementation MUST use an adaptive timeout.
  • SHOULDA server TFTP implementation SHOULD include some configurable access control over what pathnames are allowed in TFTP operations.
  • SHOULDA TFTP request directed to a broadcast address SHOULD be silently ignored.

5 ELECTRONIC MAIL -- SMTP and RFC-822

  • MUSTThe domain names that a Sender-SMTP sends in MAIL and RCPT commands MUST have been "canonicalized," i.e., they must be fully-qualified principal names or domain literals, not nicknames or domain abbreviations.
  • MUSTA receiver-SMTP MUST implement VRFY and SHOULD implement EXPN (this requirement overrides RFC-821).
  • MAYHowever, there MAY be configuration information to disable VRFY and EXPN in a particular installation; this might even allow EXPN to be disabled for selected lists.
  • MAYAn SMTP MAY implement the commands to send a message to a user's terminal: SEND, SOML, and SAML.
  • MUSTThe sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host.
  • MAYThe HELO receiver MAY verify that the HELO parameter really
  • MUST NOTHowever, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.
  • SHOULD NOTAn Internet host that is forwarding a message but is not a gateway to a different mail environment (i.e., it falls under (1) or (2)) SHOULD NOT alter any existing header fields, although the host will add an appropriate Received: line as required in Section 5.2.8.
  • SHOULD NOTA Sender-SMTP SHOULD NOT send a RCPT TO: command containing an explicit source route using the "@...:" address form.
  • MUSTA receiver-SMTP MUST accept the explicit source route syntax in the envelope, but it MAY implement the relay function as defined in section 3.6 of RFC-821.
  • SHOULDIf it does not implement the relay function, it SHOULD attempt to deliver the message directly to the host to the right of the right-most "@" sign.
  • MUSTA host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster".
  • MAYThe receiver-SMTP MAY verify RCPT parameters as they arrive; however, RCPT responses MUST NOT be delayed beyond a reasonable time (see Section 5.3.2).
  • MUSTEvery receiver-SMTP (not just one that "accepts a message for relaying or for final delivery" [SMTP:1]) MUST insert a "Received:" line at the beginning of a message.
  • SHOULD* The FROM field SHOULD contain both (1) the name of the source host as presented in the HELO command and (2) a domain literal containing the IP address of the source, determined from the TCP connection.
  • MAY* The ID field MAY contain an "@" as suggested in RFC-822, but this is not required.
  • MAY* The FOR field MAY contain a list of <path> entries when multiple RCPT commands have been given.
  • MUST NOTAn Internet mail program MUST NOT change a Received: line that was previously added to the message header.
  • MUSTWhen the receiver-SMTP makes "final delivery" of a message, then it MUST pass the MAIL FROM: address from the SMTP envelope with the message, for use if an error notification message must be sent later (see Section 5.3.3).
  • MUSTAn empty reverse path MUST be supported.
  • SHOULDA receiver-SMTP SHOULD send only the reply codes listed in section 4.2.2 of RFC-821 or in this document.
  • SHOULDA receiver-SMTP SHOULD use the text shown in examples in RFC-821 whenever appropriate.
  • MUSTA sender-SMTP MUST determine its actions only by the reply code, not by the text (except for 251 and 551 replies); any text, including no text at all, must be acceptable.
  • SHOULDWhenever possible, a sender-SMTP SHOULD test only the
  • MUSTImplementors MUST be sure that their mail systems always add and delete periods to ensure message transparency.
  • SHOULD NOTLater experience has shown that WKS is not widely supported, so the WKS step in MX processing SHOULD NOT be used.
  • MAY[SMTP:7] A User Agent MAY support this field.
  • SHOULDAll mail software SHOULD use 4-digit years in dates, to ease the transition to the next century.
  • SHOULDThere is a strong trend towards the use of numeric timezone indicators, and implementations SHOULD use numeric timezones instead of timezone names.
  • MUSTHowever, all implementations MUST accept either notation.
  • MUSTIf timezone names are used, they MUST be exactly as defined in RFC-822.
  • OPTIONALThat is, the phrase preceding a route address is now OPTIONAL.
  • MUST NOTA host that is forwarding the message but is not the destination host implied by the right-hand side "domain" MUST NOT interpret or modify the "local-part" of the address.
  • MAYWhen mail is to be gatewayed from the Internet mail environment into a foreign mail environment (see Section 5.3.7), routing information for that foreign environment MAY be embedded within the "local-part" of the address.
  • MUSTA mailer MUST be able to accept and parse an Internet domain literal whose content ("dtext"; see RFC-822) is a dotted- decimal host address.
  • MUSTAn SMTP MUST accept and recognize a domain literal for any of its own IP addresses.
  • MUSTA User Agent MUST accept all valid RFC-822 address formats, and MUST NOT generate illegal address syntax.
  • MUSTThe right-hand side of an "@" sign in a header address field MUST be a fully-qualified domain name.
  • SHOULD NOTInternet host software SHOULD NOT create an RFC-822 header containing an address with an explicit source route, but MUST accept such headers for compatibility with earlier systems.
  • MUSTAny queueing strategy MUST include:
  • MUSTimmediately MUST be queued and periodically retried by the sender.
  • MUSTThe sender MUST delay retrying a particular destination after one attempt has failed.
  • SHOULDIn general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the sender-SMTP can determine the reason for non- delivery.
  • MUSTThe parameters to the retry algorithm MUST be configurable.
  • SHOULDA sender SHOULD keep a list of hosts it cannot reach and corresponding timeouts, rather than just retrying queued mail items.
  • SHOULDWhen the same message is to be delivered to several users on the same host, only one copy of the message SHOULD be transmitted.
  • MAYSimilarly, the sender-SMTP MAY support multiple concurrent outgoing mail transactions to achieve timely delivery.
  • SHOULDHowever, some limit SHOULD be imposed to protect the host from devoting all its resources to mail.
  • SHOULDThe receiver-SMTP SHOULD attempt to keep a pending listen on the SMTP port at all times.
  • MAYSome limit MAY be imposed.
  • SHOULDA sender-SMTP SHOULD use option (a), per-command timeouts.
  • SHOULDTimeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code.
  • SHOULDBased on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
  • SHOULDA receiver-SMTP SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender.
  • MUST NOTIt must take this responsibility seriously, i.e., it MUST NOT lose the message for frivolous reasons, e.g., because the host later crashes or because of a predictable resource shortage.
  • MUSTIf there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message.
  • MUSTThis notification MUST be sent using a null ("<>") reverse path in the envelope; see Section 3.6 of RFC-821.
  • SHOULDThe recipient of this notification SHOULD be the address from the envelope return path (or the Return-Path: line).
  • MUST NOTHowever, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification.
  • SHOULDIf the address is an explicit source route, it SHOULD be stripped down to its final hop.
  • MUSTTo avoid receiving duplicate messages as the result of timeouts, a receiver-SMTP MUST seek to minimize the time required to respond to the final "." that ends a message transfer.
  • MUSTTo provide reliable mail transmission, the sender-SMTP MUST be able to try (and retry) each of the addresses in this list in order, until a delivery attempt succeeds.
  • MAYHowever, there MAY also be a configurable limit on the number of alternate addresses that can be tried.
  • SHOULDIn any case, a host SHOULD try at least two addresses.
  • SHOULDIf there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by address preference), then the sender-SMTP SHOULD pick one at random to spread the load across multiple mail exchanges for a specific organization; note that this is a refinement of the procedure in [DNS:3].
  • MUSTIt is the responsibility of the domain name resolver interface (see Section 6.1.3.4 below) to have ordered this list by decreasing preference, and SMTP MUST try them in the order presented.
  • MUSTSMTP implementations MUST use the mechanism defined in Section 6.1 for mapping between domain names and IP addresses.
  • MUSTThis means that every Internet SMTP MUST include support for the Internet DNS.
  • MUSTIn particular, a sender-SMTP MUST support the MX record scheme [SMTP:3].
  • SHOULDAn SMTP-capable host SHOULD support both the alias and the list form of address expansion for multiple delivery.
  • MUSTWhen a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person who administers the list, but the message header MUST be left unchanged; in particular, the "From" field of the message is unaffected.
  • MAY(A) Header fields MAY be rewritten when necessary as messages are gatewayed across mail environment boundaries.
  • MUST(B) When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header.
  • SHOULD(C) From the Internet side, the gateway SHOULD accept all valid address formats in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages.
  • MAYAlthough a gateway must accept an RFC-822 explicit source route ("@...:" format) in either the RFC-822 header or in the envelope, it MAY or may not act on the source route; see Sections 5.2.6 and 5.2.19.
  • MUST(D) The gateway MUST ensure that all header fields of a message that it forwards into the Internet meet the requirements for Internet mail.
  • SHOULD(E) The translation algorithm used to convert mail from the Internet protocols to another environment's protocol SHOULD try to ensure that error messages from the foreign mail environment are delivered to the return path from the SMTP envelope, not to the sender listed in the "From:" field of the RFC-822 message.
  • SHOULD(F) Similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path in accordance with an error message return address, if any, supplied by the foreign environment.
  • MUSTMailer software MUST be able to send and receive messages of at least 64K bytes in length (including header), and a much larger maximum size is highly desirable.

6 SUPPORT SERVICES

  • MUSTEvery host MUST implement a resolver for the Domain Name System (DNS), and it MUST implement a mechanism using this DNS resolver to convert host names to IP addresses and vice-versa [DNS:1, DNS:2].
  • MAYIn addition to the DNS, a host MAY also implement a host name translation mechanism that searches a local Internet host table.
  • MUSTAll DNS name servers and resolvers MUST properly handle RRs with a zero TTL: return the RR to the client but do not cache it.
  • SHOULD NOTA query with "QCLASS=*" SHOULD NOT be used unless the requestor is seeking data from more than one class.
  • MUSTIn particular, if the requestor is only interested in Internet data types, QCLASS=IN MUST be used.
  • MUSTUnused fields in a query or response message MUST be zero.
  • MUSTName servers MUST use compression in responses.
  • MUST NOTAn implementation MUST NOT include any of these hints in a response.
  • SHOULDA name resolver SHOULD be able to multiplex concurrent requests if the host supports concurrent processes.
  • MAYIn implementing a DNS resolver, one of two different models MAY optionally be chosen: a full-service resolver, or a stub resolver.
  • MUSTo The resolver MUST implement a local caching function to avoid repeated remote access for identical requests, and MUST time out information in the cache.
  • SHOULDo The resolver SHOULD be configurable with start-up information pointing to multiple root name servers and multiple name servers for the local domain.
  • MUSTAt a minimum, the stub resolver MUST be capable of directing its requests to redundant recursive name servers.
  • MAYStub resolvers MAY implement caching if they choose, but if so, MUST timeout cached information.
  • MUSTDNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries.
  • MUSTSpecifically, a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first.
  • SHOULDIf the Answer section of the response is truncated and if the requester supports TCP, it SHOULD try the query again using TCP.
  • MUSTDNS servers MUST be able to service UDP queries and SHOULD be able to service TCP queries.
  • MAYA name server MAY limit the resources it devotes to TCP queries, but it SHOULD NOT refuse to service a TCP query just because it would have succeeded with UDP.
  • MUST NOTTruncated responses MUST NOT be saved (cached) and later used in such a way that the fact that they are truncated is lost.
  • MAYBy private agreement, name servers and resolvers MAY arrange to use TCP for all traffic between themselves.
  • MUSTTCP MUST be used for zone transfers.
  • MUSTA DNS server MUST have sufficient internal concurrency that it can continue to process UDP queries while awaiting a response or performing a zone transfer on an open TCP connection [DNS:2].
  • MAYA server MAY support a UDP query that is delivered using an IP broadcast or multicast address.
  • MUST NOTHowever, the Recursion Desired bit MUST NOT be set in a query that is multicast, and MUST be ignored by name servers receiving queries via a broadcast or multicast address.
  • SHOULDA host that sends broadcast or multicast DNS queries SHOULD send them only as occasional probes, caching the IP address(es) it obtains from the response(s) so it can normally send unicast queries.
  • MUST(1) The resolver MUST implement retransmission controls to insure that it does not waste communication bandwidth, and MUST impose finite bounds on the resources consumed to respond to a single request.
  • MUST(2) After a query has been retransmitted several times without a response, an implementation MUST give up and return a soft error to the application.
  • SHOULD(3) All DNS name servers and resolvers SHOULD cache temporary failures, with a timeout period of the order of minutes.
  • SHOULD(4) All DNS name servers and resolvers SHOULD cache negative responses that indicate the specified name, or data of the specified type, does not exist, as described in [DNS:2].
  • SHOULD(5) When a DNS server or resolver retries a UDP query, the retry interval SHOULD be constrained by an exponential backoff algorithm, and SHOULD also have upper and lower bounds.
  • SHOULDa query it has issued, it SHOULD take steps to reduce the rate of querying that server in the near future.
  • MAYA server MAY ignore a Source Quench that it receives as the result of sending a response datagram.
  • SHOULDWhen the host name-to-address function encounters a host with multiple addresses, it SHOULD rank or sort the addresses using knowledge of the immediately connected network number(s) and any other applicable performance or history information.
  • MUSTDNS software MUST support all well-known, class-independent formats [DNS:2], and SHOULD be written to minimize the trauma associated with the introduction of new well-known types and local experimentation with non-standard types.
  • MUSTName servers MUST be able to load all RR types except MD and MF from configuration files.
  • MUST NOTThe MD and MF types are obsolete and MUST NOT be implemented; in particular, name servers MUST NOT load these types from configuration files.
  • MUSTIn this situation, DNS name servers and resolvers MUST continue to provide service for the reachable part of the name space, while giving temporary failures for the rest.
  • MUSTHosts MUST provide an interface to the DNS for all application programs running on the host.
  • MUSTAt a minimum, the basic interface MUST support a request for all information of a specific type and class associated with a specific name, and it MUST return either all of the requested information, a hard error code, or a soft error indication.
  • MAYA host MAY provide other DNS interfaces tailored to particular functions, transforming the raw domain data into formats more suited to these functions.
  • MUSTIn particular, a host MUST provide a DNS interface to facilitate translation between host addresses and host names.
  • MAYUser interfaces MAY provide a method for users to enter abbreviations for commonly-used names.
  • MUST(a) There MUST be some convention for denoting that a name is already complete, so that the abbreviation method(s) are suppressed.
  • MUST(b) Abbreviation expansion MUST be done exactly once, and MUST be done in the context in which the name was entered.
  • SHOULDIt SHOULD be possible for an administrator to disable a DNS search-list facility.
  • MUSTA search-list mechanism MUST have one of, and SHOULD have both of, the following two provisions to prevent this:

Every current email RFC