diff options
| author | Graham Wilson <graham@mknod.org> | 2004-11-29 16:40:04 +0000 |
|---|---|---|
| committer | Graham Wilson <graham@mknod.org> | 2004-11-29 16:40:04 +0000 |
| commit | fdec8d6cf10bfd061d98d8b790bb71985ed36e3a (patch) | |
| tree | 5dcdc4652472a06e8be717237d66b17e74708666 /RFC/rfc1123.txt | |
| parent | 100fa76e5f1675dd18b9d35e5c7e88699a57ba7d (diff) | |
| download | fetchmail-fdec8d6cf10bfd061d98d8b790bb71985ed36e3a.tar.gz fetchmail-fdec8d6cf10bfd061d98d8b790bb71985ed36e3a.tar.bz2 fetchmail-fdec8d6cf10bfd061d98d8b790bb71985ed36e3a.zip | |
Remove RFCs from the trunk, since we don't distribute them anyways. All of the removed RFCs are listed in the design-notes.html file, with the exception of NNTP (RFC977). Also add a link to the "LAN Mail Protocols" document to the design-notes.html file.
svn path=/trunk/; revision=4013
Diffstat (limited to 'RFC/rfc1123.txt')
| -rw-r--r-- | RFC/rfc1123.txt | 5782 |
1 files changed, 0 insertions, 5782 deletions
diff --git a/RFC/rfc1123.txt b/RFC/rfc1123.txt deleted file mode 100644 index 51cdf83c..00000000 --- a/RFC/rfc1123.txt +++ /dev/null @@ -1,5782 +0,0 @@ - - - - - - -Network Working Group Internet Engineering Task Force -Request for Comments: 1123 R. Braden, Editor - October 1989 - - - Requirements for Internet Hosts -- Application and Support - -Status of This Memo - - 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. Distribution - of this document is unlimited. - -Summary - - This RFC is one of a pair that defines and discusses the requirements - for Internet host software. This RFC covers the application and - support protocols; its companion RFC-1122 covers the communication - protocol layers: link layer, IP layer, and transport layer. - - - - Table of Contents - - - - - 1. INTRODUCTION ............................................... 5 - 1.1 The Internet Architecture .............................. 6 - 1.2 General Considerations ................................. 6 - 1.2.1 Continuing Internet Evolution ..................... 6 - 1.2.2 Robustness Principle .............................. 7 - 1.2.3 Error Logging ..................................... 8 - 1.2.4 Configuration ..................................... 8 - 1.3 Reading this Document .................................. 10 - 1.3.1 Organization ...................................... 10 - 1.3.2 Requirements ...................................... 10 - 1.3.3 Terminology ....................................... 11 - 1.4 Acknowledgments ........................................ 12 - - 2. GENERAL ISSUES ............................................. 13 - 2.1 Host Names and Numbers ................................. 13 - 2.2 Using Domain Name Service .............................. 13 - 2.3 Applications on Multihomed hosts ....................... 14 - 2.4 Type-of-Service ........................................ 14 - 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 - - - - -Internet Engineering Task Force [Page 1] - - - - -RFC1123 INTRODUCTION October 1989 - - - 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16 - 3.1 INTRODUCTION ........................................... 16 - 3.2 PROTOCOL WALK-THROUGH .................................. 16 - 3.2.1 Option Negotiation ................................ 16 - 3.2.2 Telnet Go-Ahead Function .......................... 16 - 3.2.3 Control Functions ................................. 17 - 3.2.4 Telnet "Synch" Signal ............................. 18 - 3.2.5 NVT Printer and Keyboard .......................... 19 - 3.2.6 Telnet Command Structure .......................... 20 - 3.2.7 Telnet Binary Option .............................. 20 - 3.2.8 Telnet Terminal-Type Option ....................... 20 - 3.3 SPECIFIC ISSUES ........................................ 21 - 3.3.1 Telnet End-of-Line Convention ..................... 21 - 3.3.2 Data Entry Terminals .............................. 23 - 3.3.3 Option Requirements ............................... 24 - 3.3.4 Option Initiation ................................. 24 - 3.3.5 Telnet Linemode Option ............................ 25 - 3.4 TELNET/USER INTERFACE .................................. 25 - 3.4.1 Character Set Transparency ........................ 25 - 3.4.2 Telnet Commands ................................... 26 - 3.4.3 TCP Connection Errors ............................. 26 - 3.4.4 Non-Default Telnet Contact Port ................... 26 - 3.4.5 Flushing Output ................................... 26 - 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27 - - 4. FILE TRANSFER .............................................. 29 - 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29 - 4.1.1 INTRODUCTION ...................................... 29 - 4.1.2. PROTOCOL WALK-THROUGH ............................ 29 - 4.1.2.1 LOCAL Type ................................... 29 - 4.1.2.2 Telnet Format Control ........................ 30 - 4.1.2.3 Page Structure ............................... 30 - 4.1.2.4 Data Structure Transformations ............... 30 - 4.1.2.5 Data Connection Management ................... 31 - 4.1.2.6 PASV Command ................................. 31 - 4.1.2.7 LIST and NLST Commands ....................... 31 - 4.1.2.8 SITE Command ................................. 32 - 4.1.2.9 STOU Command ................................. 32 - 4.1.2.10 Telnet End-of-line Code ..................... 32 - 4.1.2.11 FTP Replies ................................. 33 - 4.1.2.12 Connections ................................. 34 - 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34 - 4.1.3 SPECIFIC ISSUES ................................... 35 - 4.1.3.1 Non-standard Command Verbs ................... 35 - 4.1.3.2 Idle Timeout ................................. 36 - 4.1.3.3 Concurrency of Data and Control .............. 36 - 4.1.3.4 FTP Restart Mechanism ........................ 36 - 4.1.4 FTP/USER INTERFACE ................................ 39 - - - -Internet Engineering Task Force [Page 2] - - - - -RFC1123 INTRODUCTION October 1989 - - - 4.1.4.1 Pathname Specification ....................... 39 - 4.1.4.2 "QUOTE" Command .............................. 40 - 4.1.4.3 Displaying Replies to User ................... 40 - 4.1.4.4 Maintaining Synchronization .................. 40 - 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41 - 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44 - 4.2.1 INTRODUCTION ...................................... 44 - 4.2.2 PROTOCOL WALK-THROUGH ............................. 44 - 4.2.2.1 Transfer Modes ............................... 44 - 4.2.2.2 UDP Header ................................... 44 - 4.2.3 SPECIFIC ISSUES ................................... 44 - 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44 - 4.2.3.2 Timeout Algorithms ........................... 46 - 4.2.3.3 Extensions ................................... 46 - 4.2.3.4 Access Control ............................... 46 - 4.2.3.5 Broadcast Request ............................ 46 - 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47 - - 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48 - 5.1 INTRODUCTION ........................................... 48 - 5.2 PROTOCOL WALK-THROUGH .................................. 48 - 5.2.1 The SMTP Model .................................... 48 - 5.2.2 Canonicalization .................................. 49 - 5.2.3 VRFY and EXPN Commands ............................ 50 - 5.2.4 SEND, SOML, and SAML Commands ..................... 50 - 5.2.5 HELO Command ...................................... 50 - 5.2.6 Mail Relay ........................................ 51 - 5.2.7 RCPT Command ...................................... 52 - 5.2.8 DATA Command ...................................... 53 - 5.2.9 Command Syntax .................................... 54 - 5.2.10 SMTP Replies ..................................... 54 - 5.2.11 Transparency ..................................... 55 - 5.2.12 WKS Use in MX Processing ......................... 55 - 5.2.13 RFC-822 Message Specification .................... 55 - 5.2.14 RFC-822 Date and Time Specification .............. 55 - 5.2.15 RFC-822 Syntax Change ............................ 56 - 5.2.16 RFC-822 Local-part .............................. 56 - 5.2.17 Domain Literals .................................. 57 - 5.2.18 Common Address Formatting Errors ................. 58 - 5.2.19 Explicit Source Routes ........................... 58 - 5.3 SPECIFIC ISSUES ........................................ 59 - 5.3.1 SMTP Queueing Strategies .......................... 59 - 5.3.1.1 Sending Strategy .............................. 59 - 5.3.1.2 Receiving strategy ........................... 61 - 5.3.2 Timeouts in SMTP .................................. 61 - 5.3.3 Reliable Mail Receipt ............................. 63 - 5.3.4 Reliable Mail Transmission ........................ 63 - 5.3.5 Domain Name Support ............................... 65 - - - -Internet Engineering Task Force [Page 3] - - - - -RFC1123 INTRODUCTION October 1989 - - - 5.3.6 Mailing Lists and Aliases ......................... 65 - 5.3.7 Mail Gatewaying ................................... 66 - 5.3.8 Maximum Message Size .............................. 68 - 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69 - - 6. SUPPORT SERVICES ............................................ 72 - 6.1 DOMAIN NAME TRANSLATION ................................. 72 - 6.1.1 INTRODUCTION ....................................... 72 - 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 - 6.1.2.1 Resource Records with Zero TTL ............... 73 - 6.1.2.2 QCLASS Values ................................ 73 - 6.1.2.3 Unused Fields ................................ 73 - 6.1.2.4 Compression .................................. 73 - 6.1.2.5 Misusing Configuration Info .................. 73 - 6.1.3 SPECIFIC ISSUES ................................... 74 - 6.1.3.1 Resolver Implementation ...................... 74 - 6.1.3.2 Transport Protocols .......................... 75 - 6.1.3.3 Efficient Resource Usage ..................... 77 - 6.1.3.4 Multihomed Hosts ............................. 78 - 6.1.3.5 Extensibility ................................ 79 - 6.1.3.6 Status of RR Types ........................... 79 - 6.1.3.7 Robustness ................................... 80 - 6.1.3.8 Local Host Table ............................. 80 - 6.1.4 DNS USER INTERFACE ................................ 81 - 6.1.4.1 DNS Administration ........................... 81 - 6.1.4.2 DNS User Interface ........................... 81 - 6.1.4.3 Interface Abbreviation Facilities ............. 82 - 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 - 6.2 HOST INITIALIZATION .................................... 87 - 6.2.1 INTRODUCTION ...................................... 87 - 6.2.2 REQUIREMENTS ...................................... 87 - 6.2.2.1 Dynamic Configuration ........................ 87 - 6.2.2.2 Loading Phase ................................ 89 - 6.3 REMOTE MANAGEMENT ...................................... 90 - 6.3.1 INTRODUCTION ...................................... 90 - 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 - 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 - - 7. REFERENCES ................................................. 93 - - - - - - - - - - - - -Internet Engineering Task Force [Page 4] - - - - -RFC1123 INTRODUCTION October 1989 - - -1. INTRODUCTION - - This document is one of a pair that defines and discusses the - requirements for host system implementations of the Internet protocol - suite. This RFC covers the applications layer and support protocols. - Its companion RFC, "Requirements for Internet Hosts -- Communications - Layers" [INTRO:1] covers the lower layer protocols: transport layer, - IP layer, and link layer. - - These documents are intended to provide guidance for vendors, - implementors, and users of Internet communication software. They - represent the consensus of a large body of technical experience and - wisdom, contributed by members of the Internet research and vendor - communities. - - This RFC enumerates standard protocols that a host connected to the - Internet must use, and it incorporates by reference the RFCs and - other documents describing the current specifications for these - protocols. It corrects errors in the referenced documents and adds - additional discussion and guidance for an implementor. - - For each protocol, this document also contains an explicit set of - requirements, recommendations, and options. The reader must - understand that the list of requirements in this document is - incomplete by itself; the complete set of requirements for an - Internet host is primarily defined in the standard protocol - specification documents, with the corrections, amendments, and - supplements contained in this RFC. - - A good-faith implementation of the protocols that was produced after - careful reading of the RFC's and with some interaction with the - Internet technical community, and that followed good communications - software engineering practices, should differ from the requirements - of this document in only minor ways. Thus, in many cases, the - "requirements" in this RFC are already stated or implied in the - standard protocol documents, so that their inclusion here is, in a - sense, redundant. However, they were included because some past - implementation has made the wrong choice, causing problems of - interoperability, performance, and/or robustness. - - This document includes discussion and explanation of many of the - requirements and recommendations. A simple list of requirements - would be dangerous, because: - - o Some required features are more important than others, and some - features are optional. - - o There may be valid reasons why particular vendor products that - - - -Internet Engineering Task Force [Page 5] - - - - -RFC1123 INTRODUCTION October 1989 - - - are designed for restricted contexts might choose to use - different specifications. - - However, the specifications of this document must be followed to meet - the general goal of arbitrary host interoperation across the - diversity and complexity of the Internet system. Although most - current implementations fail to meet these requirements in various - ways, some minor and some major, this specification is the ideal - towards which we need to move. - - These requirements are based on the current level of Internet - architecture. This document will be updated as required to provide - additional clarifications or to include additional information in - those areas in which specifications are still evolving. - - This introductory section begins with general advice to host software - vendors, and then gives some guidance on reading the rest of the - document. Section 2 contains general requirements that may be - applicable to all application and support protocols. Sections 3, 4, - and 5 contain the requirements on protocols for the three major - applications: Telnet, file transfer, and electronic mail, - respectively. Section 6 covers the support applications: the domain - name system, system initialization, and management. Finally, all - references will be found in Section 7. - - 1.1 The Internet Architecture - - For a brief introduction to the Internet architecture from a host - viewpoint, see Section 1.1 of [INTRO:1]. That section also - contains recommended references for general background on the - Internet architecture. - - 1.2 General Considerations - - There are two important lessons that vendors of Internet host - software have learned and which a new vendor should consider - seriously. - - 1.2.1 Continuing Internet Evolution - - The enormous growth of the Internet has revealed problems of - management and scaling in a large datagram-based packet - communication system. These problems are being addressed, and - as a result there will be continuing evolution of the - specifications described in this document. These changes will - be carefully planned and controlled, since there is extensive - participation in this planning by the vendors and by the - organizations responsible for operations of the networks. - - - -Internet Engineering Task Force [Page 6] - - - - -RFC1123 INTRODUCTION October 1989 - - - Development, evolution, and revision are characteristic of - computer network protocols today, and this situation will - persist for some years. A vendor who develops computer - communication software for the Internet protocol suite (or any - other protocol suite!) and then fails to maintain and update - that software for changing specifications is going to leave a - trail of unhappy customers. The Internet is a large - communication network, and the users are in constant contact - through it. Experience has shown that knowledge of - deficiencies in vendor software propagates quickly through the - Internet technical community. - - 1.2.2 Robustness Principle - - At every layer of the protocols, there is a general rule whose - application can lead to enormous benefits in robustness and - interoperability: - - "Be liberal in what you accept, and - conservative in what you send" - - Software should be written to deal with every conceivable - error, no matter how unlikely; sooner or later a packet will - come in with that particular combination of errors and - attributes, and unless the software is prepared, chaos can - ensue. In general, it is best to assume that the network is - filled with malevolent entities that will send in packets - designed to have the worst possible effect. This assumption - will lead to suitable protective design, although the most - serious problems in the Internet have been caused by - unenvisaged mechanisms triggered by low-probability events; - mere human malice would never have taken so devious a course! - - Adaptability to change must be designed into all levels of - Internet host software. As a simple example, consider a - protocol specification that contains an enumeration of values - for a particular header field -- e.g., a type field, a port - number, or an error code; this enumeration must be assumed to - be incomplete. Thus, if a protocol specification defines four - possible error codes, the software must not break when a fifth - code shows up. An undefined code might be logged (see below), - but it must not cause a failure. - - The second part of the principle is almost as important: - software on other hosts may contain deficiencies that make it - unwise to exploit legal but obscure protocol features. It is - unwise to stray far from the obvious and simple, lest untoward - effects result elsewhere. A corollary of this is "watch out - - - -Internet Engineering Task Force [Page 7] - - - - -RFC1123 INTRODUCTION October 1989 - - - for misbehaving hosts"; host software should be prepared, not - just to survive other misbehaving hosts, but also to cooperate - to limit the amount of disruption such hosts can cause to the - shared communication facility. - - 1.2.3 Error Logging - - The Internet includes a great variety of host and gateway - systems, each implementing many protocols and protocol layers, - and some of these contain bugs and mis-features in their - Internet protocol software. As a result of complexity, - diversity, and distribution of function, the diagnosis of user - problems is often very difficult. - - Problem diagnosis will be aided if host implementations include - a carefully designed facility for logging erroneous or - "strange" protocol events. It is important to include as much - diagnostic information as possible when an error is logged. In - particular, it is often useful to record the header(s) of a - packet that caused an error. However, care must be taken to - ensure that error logging does not consume prohibitive amounts - of resources or otherwise interfere with the operation of the - host. - - There is a tendency for abnormal but harmless protocol events - to overflow error logging files; this can be avoided by using a - "circular" log, or by enabling logging only while diagnosing a - known failure. It may be useful to filter and count duplicate - successive messages. One strategy that seems to work well is: - (1) always count abnormalities and make such counts accessible - through the management protocol (see Section 6.3); and (2) - allow the logging of a great variety of events to be - selectively enabled. For example, it might useful to be able - to "log everything" or to "log everything for host X". - - Note that different managements may have differing policies - about the amount of error logging that they want normally - enabled in a host. Some will say, "if it doesn't hurt me, I - don't want to know about it", while others will want to take a - more watchful and aggressive attitude about detecting and - removing protocol abnormalities. - - 1.2.4 Configuration - - It would be ideal if a host implementation of the Internet - protocol suite could be entirely self-configuring. This would - allow the whole suite to be implemented in ROM or cast into - silicon, it would simplify diskless workstations, and it would - - - -Internet Engineering Task Force [Page 8] - - - - -RFC1123 INTRODUCTION October 1989 - - - be an immense boon to harried LAN administrators as well as - system vendors. We have not reached this ideal; in fact, we - are not even close. - - At many points in this document, you will find a requirement - that a parameter be a configurable option. There are several - different reasons behind such requirements. In a few cases, - there is current uncertainty or disagreement about the best - value, and it may be necessary to update the recommended value - in the future. In other cases, the value really depends on - external factors -- e.g., the size of the host and the - distribution of its communication load, or the speeds and - topology of nearby networks -- and self-tuning algorithms are - unavailable and may be insufficient. In some cases, - configurability is needed because of administrative - requirements. - - Finally, some configuration options are required to communicate - with obsolete or incorrect implementations of the protocols, - distributed without sources, that unfortunately persist in many - parts of the Internet. To make correct systems coexist with - these faulty systems, administrators often have to "mis- - configure" the correct systems. This problem will correct - itself gradually as the faulty systems are retired, but it - cannot be ignored by vendors. - - When we say that a parameter must be configurable, we do not - intend to require that its value be explicitly read from a - configuration file at every boot time. We recommend that - implementors set up a default for each parameter, so a - configuration file is only necessary to override those defaults - that are inappropriate in a particular installation. Thus, the - configurability requirement is an assurance that it will be - POSSIBLE to override the default when necessary, even in a - binary-only or ROM-based product. - - This document requires a particular value for such defaults in - some cases. The choice of default is a sensitive issue when - the configuration item controls the accommodation to existing - faulty systems. If the Internet is to converge successfully to - complete interoperability, the default values built into - implementations must implement the official protocol, not - "mis-configurations" to accommodate faulty implementations. - Although marketing considerations have led some vendors to - choose mis-configuration defaults, we urge vendors to choose - defaults that will conform to the standard. - - Finally, we note that a vendor needs to provide adequate - - - -Internet Engineering Task Force [Page 9] - - - - -RFC1123 INTRODUCTION October 1989 - - - documentation on all configuration parameters, their limits and - effects. - - - 1.3 Reading this Document - - 1.3.1 Organization - - In general, each major section is organized into the following - subsections: - - (1) Introduction - - (2) Protocol Walk-Through -- considers the protocol - specification documents section-by-section, correcting - errors, stating requirements that may be ambiguous or - ill-defined, and providing further clarification or - explanation. - - (3) Specific Issues -- discusses protocol design and - implementation issues that were not included in the walk- - through. - - (4) Interfaces -- discusses the service interface to the next - higher layer. - - (5) Summary -- contains a summary of the requirements of the - section. - - Under many of the individual topics in this document, there is - parenthetical material labeled "DISCUSSION" or - "IMPLEMENTATION". This material is intended to give - clarification and explanation of the preceding requirements - text. It also includes some suggestions on possible future - directions or developments. The implementation material - contains suggested approaches that an implementor may want to - consider. - - The summary sections are intended to be guides and indexes to - the text, but are necessarily cryptic and incomplete. The - summaries should never be used or referenced separately from - the complete RFC. - - 1.3.2 Requirements - - In this document, the words that are used to define the - significance of each particular requirement are capitalized. - These words are: - - - -Internet Engineering Task Force [Page 10] - - - - -RFC1123 INTRODUCTION October 1989 - - - * "MUST" - - This word or the adjective "REQUIRED" means that the item - is an absolute requirement of the specification. - - * "SHOULD" - - This 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. - - * "MAY" - - This word or the adjective "OPTIONAL" means that this item - is truly optional. One vendor may choose to include the - item because a particular marketplace requires it or - because it enhances the product, for example; another - vendor may omit the same item. - - - An implementation is not compliant if it fails to satisfy one - or more of the MUST requirements for the protocols it - implements. An 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.3.3 Terminology - - This document uses the following technical terms: - - Segment - A segment is the unit of end-to-end transmission in the - TCP protocol. A segment consists of a TCP header followed - by application data. A segment is transmitted by - encapsulation in an IP datagram. - - Message - This term is used by some application layer protocols - (particularly SMTP) for an application data unit. - - Datagram - A [UDP] datagram is the unit of end-to-end transmission in - the UDP protocol. - - - - -Internet Engineering Task Force [Page 11] - - - - -RFC1123 INTRODUCTION October 1989 - - - Multihomed - A host is said to be multihomed if it has multiple IP - addresses to connected networks. - - - - 1.4 Acknowledgments - - This document incorporates contributions and comments from a large - group of Internet protocol experts, including representatives of - university and research labs, vendors, and government agencies. - It was assembled primarily by the Host Requirements Working Group - of the Internet Engineering Task Force (IETF). - - The Editor would especially like to acknowledge the tireless - dedication of the following people, who attended many long - meetings and generated 3 million bytes of electronic mail over the - past 18 months in pursuit of this document: Philip Almquist, Dave - Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve - Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), - John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), - Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge - (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). - - In addition, the following people made major contributions to the - effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia - (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), - Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), - John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill - Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul - (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue - Technology), and Mike StJohns (DCA). The following also made - significant contributions to particular areas: Eric Allman - (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic - (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn - (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann - (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun - Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen - (Toronto). - - We are grateful to all, including any contributors who may have - been inadvertently omitted from this list. - - - - - - - - - -Internet Engineering Task Force [Page 12] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - -2. GENERAL ISSUES - - This section contains general requirements that may be applicable to - all application-layer protocols. - - 2.1 Host Names and Numbers - - The syntax of a legal Internet host name was specified in RFC-952 - [DNS:4]. One aspect of host name syntax is hereby changed: the - restriction on the first character is relaxed to allow either a - letter or a digit. Host software MUST support this more liberal - syntax. - - Host software MUST handle host names of up to 63 characters and - SHOULD handle host names of up to 255 characters. - - Whenever 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. The host SHOULD check - the string syntactically for a dotted-decimal number before - looking it up in the Domain Name System. - - DISCUSSION: - This last requirement is not intended to specify the complete - syntactic form for entering a dotted-decimal host number; - that is considered to be a user-interface issue. For - example, a dotted-decimal number must be enclosed within - "[ ]" brackets for SMTP mail (see Section 5.2.17). This - notation could be made universal within a host system, - simplifying the syntactic checking for a dotted-decimal - number. - - If a dotted-decimal number can be entered without such - identifying delimiters, then a full syntactic check must be - made, because a segment of a host domain name is now allowed - to begin with a digit and could legally be entirely numeric - (see Section 6.1.2.4). However, a valid host name can never - have the dotted-decimal form #.#.#.#, since at least the - highest-level component label will be alphabetic. - - 2.2 Using Domain Name Service - - Host domain names MUST be translated to IP addresses as described - in Section 6.1. - - Applications using domain name services MUST be able to cope with - soft error conditions. Applications MUST wait a reasonable - interval between successive retries due to a soft error, and MUST - - - -Internet Engineering Task Force [Page 13] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - - allow for the possibility that network problems may deny service - for hours or even days. - - An 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. To confirm that a service is present, simply - attempt to use it. - - 2.3 Applications on Multihomed hosts - - When the remote host is multihomed, the name-to-address - translation will return a list of alternative IP addresses. As - specified in Section 6.1.3.4, this list should be in order of - decreasing preference. Application protocol implementations - SHOULD be prepared to try multiple addresses from the list until - success is obtained. More specific requirements for SMTP are - given in Section 5.3.4. - - When 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. The "specific destination address" is defined - in the "IP Addressing" section of the companion RFC [INTRO:1]. - - Similarly, a server application that opens multiple TCP - connections to the same client SHOULD use the same local IP - address for all. - - 2.4 Type-of-Service - - Applications MUST select appropriate TOS values when they invoke - transport layer services, and these values MUST be configurable. - Note 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. - - DISCUSSION: - As gateway algorithms are developed to implement Type-of- - Service, the recommended values for various application - protocols may change. In addition, it is likely that - particular combinations of users and Internet paths will want - non-standard TOS values. For these reasons, the TOS values - must be configurable. - - See the latest version of the "Assigned Numbers" RFC - [INTRO:5] for the recommended TOS values for the major - application protocols. - - - -Internet Engineering Task Force [Page 14] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - - 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -User interfaces: | | | | | | | - Allow host name to begin with digit |2.1 |x| | | | | - Host names of up to 635 characters |2.1 |x| | | | | - Host names of up to 255 characters |2.1 | |x| | | | - Support dotted-decimal host numbers |2.1 | |x| | | | - Check syntactically for dotted-dec first |2.1 | |x| | | | - | | | | | | | -Map domain names per Section 6.1 |2.2 |x| | | | | -Cope with soft DNS errors |2.2 |x| | | | | - Reasonable interval between retries |2.2 |x| | | | | - Allow for long outages |2.2 |x| | | | | -Expect WKS records to be available |2.2 | | | |x| | - | | | | | | | -Try multiple addr's for remote multihomed host |2.3 | |x| | | | -UDP reply src addr is specific dest of request |2.3 | |x| | | | -Use same IP addr for related TCP connections |2.3 | |x| | | | -Specify appropriate TOS values |2.4 |x| | | | | - TOS values configurable |2.4 |x| | | | | - Unused TOS bits zero |2.4 |x| | | | | - | | | | | | | - | | | | | | | - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 15] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - -3. REMOTE LOGIN -- TELNET PROTOCOL - - 3.1 INTRODUCTION - - Telnet is the standard Internet application protocol for remote - login. It provides the encoding rules to link a user's - keyboard/display on a client ("user") system with a command - interpreter on a remote server system. A subset of the Telnet - protocol is also incorporated within other application protocols, - e.g., FTP and SMTP. - - Telnet uses a single TCP connection, and its normal data stream - ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with - escape sequences to embed control functions. Telnet also allows - the negotiation of many optional modes and functions. - - The primary Telnet specification is to be found in RFC-854 - [TELNET:1], while the options are defined in many other RFCs; see - Section 7 for references. - - 3.2 PROTOCOL WALK-THROUGH - - 3.2.1 Option Negotiation: RFC-854, pp. 2-3 - - Every Telnet implementation MUST include option negotiation and - subnegotiation machinery [TELNET:2]. - - A host MUST carefully follow the rules of RFC-854 to avoid - option-negotiation loops. A host MUST refuse (i.e, reply - WONT/DONT to a DO/WILL) an unsupported option. Option - negotiation SHOULD continue to function (even if all requests - are refused) throughout the lifetime of a Telnet connection. - - If all option negotiations fail, a Telnet implementation MUST - default to, and support, an NVT. - - DISCUSSION: - Even though more sophisticated "terminals" and supporting - option negotiations are becoming the norm, all - implementations must be prepared to support an NVT for any - user-server communication. - - 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 - - On 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"). A User or - Server Telnet MUST always accept negotiation of the Suppress Go - - - -Internet Engineering Task Force [Page 16] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Ahead option. - - When it is driving a full-duplex terminal for which GA has no - meaning, a User Telnet implementation MAY ignore GA commands. - - DISCUSSION: - Half-duplex ("locked-keyboard") line-at-a-time terminals - for which the Go-Ahead mechanism was designed have largely - disappeared from the scene. It turned out to be difficult - to implement sending the Go-Ahead signal in many operating - systems, even some systems that support native half-duplex - terminals. The difficulty is typically that the Telnet - server code does not have access to information about - whether the user process is blocked awaiting input from - the Telnet connection, i.e., it cannot reliably determine - when to send a GA command. Therefore, most Telnet Server - hosts do not send GA commands. - - The effect of the rules in this section is to allow either - end of a Telnet connection to veto the use of GA commands. - - There is a class of half-duplex terminals that is still - commercially important: "data entry terminals," which - interact in a full-screen manner. However, supporting - data entry terminals using the Telnet protocol does not - require the Go Ahead signal; see Section 3.3.2. - - 3.2.3 Control Functions: RFC-854, pp. 7-8 - - The list of Telnet commands has been extended to include EOR - (End-of-Record), with code 239 [TELNET:9]. - - Both 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. - - A host MUST be able to receive and ignore any Telnet control - functions that it does not support. - - DISCUSSION: - Note that a Server Telnet is required to support the - Telnet IP (Interrupt Process) function, even if the server - host has an equivalent in-stream function (e.g., Control-C - in many systems). The Telnet IP function may be stronger - than an in-stream interrupt command, because of the out- - of-band effect of TCP urgent data. - - The EOR control function may be used to delimit the - - - -Internet Engineering Task Force [Page 17] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - stream. An important application is data entry terminal - support (see Section 3.3.2). There was concern that since - EOR had not been defined in RFC-854, a host that was not - prepared to correctly ignore unknown Telnet commands might - crash if it received an EOR. To protect such hosts, the - End-of-Record option [TELNET:9] was introduced; however, a - properly implemented Telnet program will not require this - protection. - - 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 - - When 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. - - When 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". The TCP urgent - pointer points to the DM octet. - - When it receives a Telnet IP command, a Server Telnet MAY send - a Telnet "Synch" sequence back to the user, to flush the output - stream. The choice ought to be consistent with the way the - server operating system behaves when a local user interrupts a - process. - - When it receives a Telnet AO command, a Server Telnet MUST send - a Telnet "Synch" sequence back to the user, to flush the output - stream. - - A User Telnet SHOULD have the capability of flushing output - when it sends a Telnet IP; see also Section 3.4.5. - - DISCUSSION: - There are three possible ways for a User Telnet to flush - the stream of server output data: - - (1) Send AO after IP. - - This will cause the server host to send a "flush- - buffered-output" signal to its operating system. - However, the AO may not take effect locally, i.e., - stop terminal output at the User Telnet end, until - the Server Telnet has received and processed the AO - and has sent back a "Synch". - - (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard - all output locally until a WILL/WONT TIMING-MARK is - - - -Internet Engineering Task Force [Page 18] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - received from the Server Telnet. - - Since the DO TIMING-MARK will be processed after the - IP at the server, the reply to it should be in the - right place in the output data stream. However, the - TIMING-MARK will not send a "flush buffered output" - signal to the server operating system. Whether or - not this is needed is dependent upon the server - system. - - (3) Do both. - - The best method is not entirely clear, since it must - accommodate a number of existing server hosts that do not - follow the Telnet standards in various ways. The safest - approach is probably to provide a user-controllable option - to select (1), (2), or (3). - - 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 - - In NVT mode, a Telnet SHOULD NOT send characters with the - high-order bit 1, and MUST NOT send it as a parity bit. - Implementations that pass the high-order bit to applications - SHOULD negotiate binary mode (see Section 3.2.6). - - - DISCUSSION: - Implementors should be aware that a strict reading of - RFC-854 allows a client or server expecting NVT ASCII to - ignore characters with the high-order bit set. In - general, binary mode is expected to be used for - transmission of an extended (beyond 7-bit) character set - with Telnet. - - However, there exist applications that really need an 8- - bit NVT mode, which is currently not defined, and these - existing applications do set the high-order bit during - part or all of the life of a Telnet connection. Note that - binary mode is not the same as 8-bit NVT mode, since - binary mode turns off end-of-line processing. For this - reason, the requirements on the high-order bit are stated - as SHOULD, not MUST. - - RFC-854 defines a minimal set of properties of a "network - virtual terminal" or NVT; this is not meant to preclude - additional features in a real terminal. A Telnet - connection is fully transparent to all 7-bit ASCII - characters, including arbitrary ASCII control characters. - - - -Internet Engineering Task Force [Page 19] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - For example, a terminal might support full-screen commands - coded as ASCII escape sequences; a Telnet implementation - would pass these sequences as uninterpreted data. Thus, - an NVT should not be conceived as a terminal type of a - highly-restricted device. - - 3.2.6 Telnet Command Structure: RFC-854, p. 13 - - Since 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. - - 3.2.7 Telnet Binary Option: RFC-856 - - When the Binary option has been successfully negotiated, - arbitrary 8-bit characters are allowed. However, 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. Other character processing (e.g., replacing - CR by CR NUL or by CR LF) MUST NOT be done. In particular, - there is no end-of-line convention (see Section 3.3.1) in - binary mode. - - DISCUSSION: - The Binary option is normally negotiated in both - directions, to change the Telnet connection from NVT mode - to "binary mode". - - The sequence IAC EOR can be used to delimit blocks of data - within a binary-mode Telnet stream. - - 3.2.8 Telnet Terminal-Type Option: RFC-1091 - - The 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. However, the - receiver of a Terminal-Type option MUST accept any name. - - DISCUSSION: - RFC-1091 [TELNET:10] updates an earlier version of the - Terminal-Type option defined in RFC-930. The earlier - version allowed a server host capable of supporting - multiple terminal types to learn the type of a particular - client's terminal, assuming that each physical terminal - had an intrinsic type. However, today a "terminal" is - often really a terminal emulator program running in a PC, - perhaps capable of emulating a range of terminal types. - Therefore, RFC-1091 extends the specification to allow a - - - -Internet Engineering Task Force [Page 20] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - more general terminal-type negotiation between User and - Server Telnets. - - 3.3 SPECIFIC ISSUES - - 3.3.1 Telnet End-of-Line Convention - - The Telnet protocol defines the sequence CR LF to mean "end- - of-line". For terminal input, this corresponds to a command- - completion or "end-of-line" key being pressed on a user - terminal; on an ASCII terminal, this is the CR key, but it may - also be labelled "Return" or "Enter". - - When 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. On server hosts that use ASCII, in particular, - receipt of the Telnet sequence CR LF must cause the same effect - as a local user pressing the CR key on a local terminal. Thus, - CR LF and CR NUL MUST have the same effect on an ASCII server - host when received as input over a Telnet connection. - - A User Telnet MUST be able to send any of the forms: CR LF, CR - NUL, and LF. A 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. - - The 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). - - DISCUSSION: - To allow interoperability between arbitrary Telnet clients - and servers, the Telnet protocol defined a standard - representation for a line terminator. Since the ASCII - character set includes no explicit end-of-line character, - systems have chosen various representations, e.g., CR, LF, - and the sequence CR LF. The Telnet protocol chose the CR - LF sequence as the standard for network transmission. - - Unfortunately, the Telnet protocol specification in RFC- - 854 [TELNET:1] has turned out to be somewhat ambiguous on - what character(s) should be sent from client to server for - the "end-of-line" key. The result has been a massive and - continuing interoperability headache, made worse by - various faulty implementations of both User and Server - - - -Internet Engineering Task Force [Page 21] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Telnets. - - Although the Telnet protocol is based on a perfectly - symmetric model, in a remote login session the role of the - user at a terminal differs from the role of the server - host. For example, RFC-854 defines the meaning of CR, LF, - and CR LF as output from the server, but does not specify - what the User Telnet should send when the user presses the - "end-of-line" key on the terminal; this turns out to be - the point at issue. - - When a user presses the "end-of-line" key, some User - Telnet implementations send CR LF, while others send CR - NUL (based on a different interpretation of the same - sentence in RFC-854). These will be equivalent for a - correctly-implemented ASCII server host, as discussed - above. For other servers, a mode in the User Telnet is - needed. - - The existence of User Telnets that send only CR NUL when - CR is pressed creates a dilemma for non-ASCII hosts: they - can either treat CR NUL as equivalent to CR LF in input, - thus precluding the possibility of entering a "bare" CR, - or else lose complete interworking. - - Suppose a user on host A uses Telnet to log into a server - host B, and then execute B's User Telnet program to log - into server host C. It is desirable for the Server/User - Telnet combination on B to be as transparent as possible, - i.e., to appear as if A were connected directly to C. In - particular, correct implementation will make B transparent - to Telnet end-of-line sequences, except that CR LF may be - translated to CR NUL or vice versa. - - IMPLEMENTATION: - To understand Telnet end-of-line issues, one must have at - least a general model of the relationship of Telnet to the - local operating system. The Server Telnet process is - typically coupled into the terminal driver software of the - operating system as a pseudo-terminal. A Telnet end-of- - line sequence received by the Server Telnet must have the - same effect as pressing the end-of-line key on a real - locally-connected terminal. - - Operating systems that support interactive character-at- - a-time applications (e.g., editors) typically have two - internal modes for their terminal I/O: a formatted mode, - in which local conventions for end-of-line and other - - - -Internet Engineering Task Force [Page 22] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - formatting rules have been applied to the data stream, and - a "raw" mode, in which the application has direct access - to every character as it was entered. A Server Telnet - must be implemented in such a way that these modes have - the same effect for remote as for local terminals. For - example, suppose a CR LF or CR NUL is received by the - Server Telnet on an ASCII host. In raw mode, a CR - character is passed to the application; in formatted mode, - the local system's end-of-line convention is used. - - 3.3.2 Data Entry Terminals - - DISCUSSION: - In addition to the line-oriented and character-oriented - ASCII terminals for which Telnet was designed, there are - several families of video display terminals that are - sometimes known as "data entry terminals" or DETs. The - IBM 3270 family is a well-known example. - - Two Internet protocols have been designed to support - generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET - option [TELNET:18, TELNET:19]. The DET option drives a - data entry terminal over a Telnet connection using (sub-) - negotiation. SUPDUP is a completely separate terminal - protocol, which can be entered from Telnet by negotiation. - Although both SUPDUP and the DET option have been used - successfully in particular environments, neither has - gained general acceptance or wide implementation. - - A different approach to DET interaction has been developed - for supporting the IBM 3270 family through Telnet, - although the same approach would be applicable to any DET. - The idea is to enter a "native DET" mode, in which the - native DET input/output stream is sent as binary data. - The Telnet EOR command is used to delimit logical records - (e.g., "screens") within this binary stream. - - IMPLEMENTATION: - The rules for entering and leaving native DET mode are as - follows: - - o The Server uses the Terminal-Type option [TELNET:10] - to learn that the client is a DET. - - o It is conventional, but not required, that both ends - negotiate the EOR option [TELNET:9]. - - o Both ends negotiate the Binary option [TELNET:3] to - - - -Internet Engineering Task Force [Page 23] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - enter native DET mode. - - o When either end negotiates out of binary mode, the - other end does too, and the mode then reverts to - normal NVT. - - - 3.3.3 Option Requirements - - Every 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. - - A User or Server Telnet SHOULD support the Window Size Option - [TELNET:12] if the local operating system provides the - corresponding capability. - - DISCUSSION: - Note that the End-of-Record option only signifies that a - Telnet can receive a Telnet EOR without crashing; - therefore, every Telnet ought to be willing to accept - negotiation of the End-of-Record option. See also the - discussion in Section 3.2.3. - - 3.3.4 Option Initiation - - When the Telnet protocol is used in a client/server situation, - the server SHOULD initiate negotiation of the terminal - interaction mode it expects. - - DISCUSSION: - The Telnet protocol was defined to be perfectly - symmetrical, but its application is generally asymmetric. - Remote login has been known to fail because NEITHER side - initiated negotiation of the required non-default terminal - modes. It is generally the server that determines the - preferred mode, so the server needs to initiate the - negotiation; since the negotiation is symmetric, the user - can also initiate it. - - A client (User Telnet) SHOULD provide a means for users to - enable and disable the initiation of option negotiation. - - DISCUSSION: - A user sometimes needs to connect to an application - service (e.g., FTP or SMTP) that uses Telnet for its - - - -Internet Engineering Task Force [Page 24] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - control stream but does not support Telnet options. User - Telnet may be used for this purpose if initiation of - option negotiation is disabled. - - 3.3.5 Telnet Linemode Option - - DISCUSSION: - An important new Telnet option, LINEMODE [TELNET:12], has - been proposed. The LINEMODE option provides a standard - way for a User Telnet and a Server Telnet to agree that - the client rather than the server will perform terminal - character processing. When the client has prepared a - complete line of text, it will send it to the server in - (usually) one TCP packet. This option will greatly - decrease the packet cost of Telnet sessions and will also - give much better user response over congested or long- - delay networks. - - The LINEMODE option allows dynamic switching between local - and remote character processing. For example, the Telnet - connection will automatically negotiate into single- - character mode while a full screen editor is running, and - then return to linemode when the editor is finished. - - We expect that when this RFC is released, hosts should - implement the client side of this option, and may - implement the server side of this option. To properly - implement the server side, the server needs to be able to - tell the local system not to do any input character - processing, but to remember its current terminal state and - notify the Server Telnet process whenever the state - changes. This will allow password echoing and full screen - editors to be handled properly, for example. - - 3.4 TELNET/USER INTERFACE - - 3.4.1 Character Set Transparency - - User Telnet implementations SHOULD be able to send or receive - any 7-bit ASCII character. Where 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. - - Some character value MUST be reserved as "escape to command - mode"; conventionally, doubling this character allows it to be - entered as data. The specific character used SHOULD be user - selectable. - - - -Internet Engineering Task Force [Page 25] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - On 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. - - IMPLEMENTATION: - The transparency issues are less pressing on servers, but - implementors should take care in dealing with issues like: - masking off parity bits (sent by an older, non-conforming - client) before they reach programs that expect only NVT - ASCII, and properly handling programs that request 8-bit - data streams. - - 3.4.2 Telnet Commands - - A 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. - - 3.4.3 TCP Connection Errors - - A 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]). - - 3.4.4 Non-Default Telnet Contact Port - - A User Telnet program SHOULD allow the user to optionally - specify a non-standard contact port number at the Server Telnet - host. - - 3.4.5 Flushing Output - - A 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. - - For 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. - - - - - - - - -Internet Engineering Task Force [Page 26] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - 3.5. TELNET REQUIREMENTS SUMMARY - - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- - | | | | | | | -Option Negotiation |3.2.1 |x| | | | | - Avoid negotiation loops |3.2.1 |x| | | | | - Refuse unsupported options |3.2.1 |x| | | | | - Negotiation OK anytime on connection |3.2.1 | |x| | | | - Default to NVT |3.2.1 |x| | | | | - Send official name in Term-Type option |3.2.8 |x| | | | | - Accept any name in Term-Type option |3.2.8 |x| | | | | - Implement Binary, Suppress-GA options |3.3.3 |x| | | | | - Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | | - Implement Window-Size option if appropriate |3.3.3 | |x| | | | - Server initiate mode negotiations |3.3.4 | |x| | | | - User can enable/disable init negotiations |3.3.4 | |x| | | | - | | | | | | | -Go-Aheads | | | | | | | - Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | | - User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | | - User Telnet ignore GA's |3.2.2 | | |x| | | - | | | | | | | -Control Functions | | | | | | | - Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | | - Support EOR EC EL Break |3.2.3 | | |x| | | - Ignore unsupported control functions |3.2.3 |x| | | | | - User, Server discard urgent data up to DM |3.2.4 |x| | | | | - User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | | - Server Telnet reply Synch to IP |3.2.4 | | |x| | | - Server Telnet reply Synch to AO |3.2.4 |x| | | | | - User Telnet can flush output when send IP |3.2.4 | |x| | | | - | | | | | | | -Encoding | | | | | | | - Send high-order bit in NVT mode |3.2.5 | | | |x| | - Send high-order bit as parity bit |3.2.5 | | | | |x| - Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | | - Always double IAC data byte |3.2.6 |x| | | | | - - - -Internet Engineering Task Force [Page 27] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Double IAC data byte in binary mode |3.2.7 |x| | | | | - Obey Telnet cmds in binary mode |3.2.7 |x| | | | | - End-of-line, CR NUL in binary mode |3.2.7 | | | | |x| - | | | | | | | -End-of-Line | | | | | | | - EOL at Server same as local end-of-line |3.3.1 |x| | | | | - ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | | - User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | | - ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | | - User Telnet default mode is CR LF |3.3.1 | |x| | | | - Non-interactive uses CR LF for EOL |3.3.1 |x| | | | | - | | | | | | | -User Telnet interface | | | | | | | - Input & output all 7-bit characters |3.4.1 | |x| | | | - Bypass local op sys interpretation |3.4.1 | |x| | | | - Escape character |3.4.1 |x| | | | | - User-settable escape character |3.4.1 | |x| | | | - Escape to enter 8-bit values |3.4.1 | | |x| | | - Can input IP, AO, AYT |3.4.2 |x| | | | | - Can input EC, EL, Break |3.4.2 | |x| | | | - Report TCP connection errors to user |3.4.3 | |x| | | | - Optional non-default contact port |3.4.4 | |x| | | | - Can spec: output flushed when IP sent |3.4.5 | |x| | | | - Can manually restore output mode |3.4.5 | |x| | | | - | | | | | | | - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 28] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - -4. FILE TRANSFER - - 4.1 FILE TRANSFER PROTOCOL -- FTP - - 4.1.1 INTRODUCTION - - The File Transfer Protocol FTP is the primary Internet standard - for file transfer. The current specification is contained in - RFC-959 [FTP:1]. - - FTP uses separate simultaneous TCP connections for control and - for data transfer. The FTP protocol includes many features, - some of which are not commonly implemented. However, for every - feature in FTP, there exists at least one implementation. The - minimum implementation defined in RFC-959 was too small, so a - somewhat larger minimum implementation is defined here. - - Internet users have been unnecessarily burdened for years by - deficient FTP implementations. Protocol implementors have - suffered from the erroneous opinion that implementing FTP ought - to be a small and trivial task. This is wrong, because FTP has - a user interface, because it has to deal (correctly) with the - whole variety of communication and operating system errors that - may occur, and because it has to handle the great diversity of - real file systems in the world. - - 4.1.2. PROTOCOL WALK-THROUGH - - 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4 - - An FTP program MUST support TYPE I ("IMAGE" or binary type) - as well as TYPE L 8 ("LOCAL" type with logical byte size 8). - A machine whose memory is organized into m-bit words, where - m is not a multiple of 8, MAY also support TYPE L m. - - DISCUSSION: - The command "TYPE L 8" is often required to transfer - binary data between a machine whose memory is organized - into (e.g.) 36-bit words and a machine with an 8-bit - byte organization. For an 8-bit byte machine, TYPE L 8 - is equivalent to IMAGE. - - "TYPE L m" is sometimes specified to the FTP programs - on two m-bit word machines to ensure the correct - transfer of a native-mode binary file from one machine - to the other. However, this command should have the - same effect on these machines as "TYPE I". - - - - -Internet Engineering Task Force [Page 29] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2 - - A host that makes no distinction between TYPE N and TYPE T - SHOULD implement TYPE T to be identical to TYPE N. - - DISCUSSION: - This provision should ease interoperation with hosts - that do make this distinction. - - Many hosts represent text files internally as strings - of ASCII characters, using the embedded ASCII format - effector characters (LF, BS, FF, ...) to control the - format when a file is printed. For such hosts, there - is no distinction between "print" files and other - files. However, systems that use record structured - files typically need a special format for printable - files (e.g., ASA carriage control). For the latter - hosts, FTP allows a choice of TYPE N or TYPE T. - - 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I - - Implementation of page structure is NOT RECOMMENDED in - general. However, 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. - - 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2 - - An FTP transformation between record-structure and file- - structure SHOULD be invertible, to the extent possible while - making the result useful on the target host. - - DISCUSSION: - RFC-959 required strict invertibility between record- - structure and file-structure, but in practice, - efficiency and convenience often preclude it. - Therefore, the requirement is being relaxed. There are - two different objectives for transferring a file: - processing it on the target host, or just storage. For - storage, strict invertibility is important. For - processing, the file created on the target host needs - to be in the format expected by application programs on - that host. - - As an example of the conflict, imagine a record- - oriented operating system that requires some data files - to have exactly 80 bytes in each record. While STORing - - - -Internet Engineering Task Force [Page 30] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - a file on such a host, an FTP Server must be able to - pad each line or record to 80 bytes; a later retrieval - of such a file cannot be strictly invertible. - - 4.1.2.5 Data Connection Management: RFC-959 Section 3.3 - - A User-FTP that uses STREAM mode SHOULD send a PORT command - to assign a non-default data port before each transfer - command is issued. - - DISCUSSION: - This is required because of the long delay after a TCP - connection is closed until its socket pair can be - reused, to allow multiple transfers during a single FTP - session. Sending a port command can avoided if a - transfer mode other than stream is used, by leaving the - data transfer connection open between transfers. - - 4.1.2.6 PASV Command: RFC-959 Section 4.1.2 - - A server-FTP MUST implement the PASV command. - - If 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. - - IMPLEMENTATION: - The format of the 227 reply to a PASV command is not - well standardized. In particular, an FTP client cannot - assume that the parentheses shown on page 40 of RFC-959 - will be present (and in fact, Figure 3 on page 43 omits - them). Therefore, a User-FTP program that interprets - the PASV reply must scan the reply for the first digit - of the host and port numbers. - - Note that the host number h1,h2,h3,h4 is the IP address - of the server host that is sending the reply, and that - p1,p2 is a non-default data transfer port that PASV has - assigned. - - 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3 - - The 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. - - The data returned by a LIST or NLST command SHOULD use an - - - -Internet Engineering Task Force [Page 31] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - implied TYPE AN, unless the current type is EBCDIC, in which - case an implied TYPE EN SHOULD be used. - - DISCUSSION: - Many FTP clients support macro-commands that will get - or put files matching a wildcard specification, using - NLST to obtain a list of pathnames. The expansion of - "multiple-put" is local to the client, but "multiple- - get" requires cooperation by the server. - - The implied type for LIST and NLST is designed to - provide compatibility with existing User-FTPs, and in - particular with multiple-get commands. - - 4.1.2.8 SITE Command: RFC-959 Section 4.1.3 - - A Server-FTP SHOULD use the SITE command for non-standard - features, rather than invent new private commands or - unstandardized extensions to existing commands. - - 4.1.2.9 STOU Command: RFC-959 Section 4.1.3 - - The STOU command stores into a uniquely named file. When 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). The - exact format of these messages is hereby defined to be as - follows: - - 125 FILE: pppp - 150 FILE: pppp - - where pppp represents the unique pathname of the file that - will be written. - - 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34 - - Implementors MUST NOT assume any correspondence between READ - boundaries on the control connection and the Telnet EOL - sequences (CR LF). - - DISCUSSION: - Thus, a server-FTP (or User-FTP) must continue reading - characters from the control connection until a complete - Telnet EOL sequence is encountered, before processing - the command (or response, respectively). Conversely, a - single READ from the control connection may include - - - -Internet Engineering Task Force [Page 32] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - more than one FTP command. - - 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35 - - A Server-FTP MUST send only correctly formatted replies on - the control connection. Note that RFC-959 (unlike earlier - versions of the FTP spec) contains no provision for a - "spontaneous" reply message. - - A Server-FTP SHOULD use the reply codes defined in RFC-959 - whenever they apply. However, a server-FTP MAY use a - different reply code when needed, as long as the general - rules of Section 4.2 are followed. When 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. - - A 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. - - A User-FTP MUST be able to handle multi-line replies. If - 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. - - A 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. - - DISCUSSION: - Server implementations that fail to strictly follow the - reply rules often cause FTP user programs to hang. - Note that RFC-959 resolved ambiguities in the reply - rules found in earlier FTP specifications and must be - followed. - - It is important to choose FTP reply codes that properly - distinguish between temporary and permanent failures, - to allow the successful use of file transfer client - daemons. These programs depend on the reply codes to - decide whether or not to retry a failed transfer; using - a permanent failure code (5xx) for a temporary error - will cause these programs to give up unnecessarily. - - - -Internet Engineering Task Force [Page 33] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - When the meaning of a reply matches exactly the text - shown in RFC-959, uniformity will be enhanced by using - the RFC-959 text verbatim. However, a Server-FTP - implementor is encouraged to choose reply text that - conveys specific system-dependent information, when - appropriate. - - 4.1.2.12 Connections: RFC-959 Section 5.2 - - The words "and the port used" in the second paragraph of - this section of RFC-959 are erroneous (historical), and they - should be ignored. - - On 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. - - A user-FTP MUST NOT send any Telnet controls other than - SYNCH and IP on an FTP control connection. In particular, it - MUST NOT attempt to negotiate Telnet options on the control - connection. However, a server-FTP MUST be capable of - accepting and refusing Telnet negotiations (i.e., sending - DONT/WONT). - - DISCUSSION: - Although the RFC says: "Server- and User- processes - should follow the conventions for the Telnet - protocol...[on the control connection]", it is not the - intent that Telnet option negotiation is to be - employed. - - 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1 - - The 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. - - Type: ASCII Non-print, IMAGE, LOCAL 8 - Mode: Stream - Structure: File, Record* - Commands: - USER, PASS, ACCT, - PORT, PASV, - TYPE, MODE, STRU, - RETR, STOR, APPE, - RNFR, RNTO, DELE, - CWD, CDUP, RMD, MKD, PWD, - - - -Internet Engineering Task Force [Page 34] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - LIST, NLST, - SYST, STAT, - HELP, NOOP, QUIT. - - *Record structure is REQUIRED only for hosts whose file - systems support record structure. - - DISCUSSION: - Vendors are encouraged to implement a larger subset of - the protocol. For example, there are important - robustness features in the protocol (e.g., Restart, - ABOR, block mode) that would be an aid to some Internet - users but are not widely implemented. - - A host that does not have record structures in its file - system may still accept files with STRU R, recording - the byte stream literally. - - 4.1.3 SPECIFIC ISSUES - - 4.1.3.1 Non-standard Command Verbs - - FTP allows "experimental" commands, whose names begin with - "X". If these commands are subsequently adopted as - standards, there may still be existing implementations using - the "X" form. At present, this is true for the directory - commands: - - RFC-959 "Experimental" - - MKD XMKD - RMD XRMD - PWD XPWD - CDUP XCUP - CWD XCWD - - All FTP implementations SHOULD recognize both forms of these - commands, by simply equating them with extra entries in the - command lookup table. - - IMPLEMENTATION: - A User-FTP can access a server that supports only the - "X" forms by implementing a mode switch, or - automatically using the following procedure: if the - RFC-959 form of one of the above commands is rejected - with a 500 or 502 response code, then try the - experimental form; any other response would be passed - to the user. - - - -Internet Engineering Task Force [Page 35] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.3.2 Idle Timeout - - A 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. The idle timeout time - SHOULD be configurable, and the default should be at least 5 - minutes. - - A client FTP process ("User-PI" in RFC-959) will need - timeouts on responses only if it is invoked from a program. - - DISCUSSION: - Without a timeout, a Server-FTP process may be left - pending indefinitely if the corresponding client - crashes without closing the control connection. - - 4.1.3.3 Concurrency of Data and Control - - DISCUSSION: - The intent of the designers of FTP was that a user - should be able to send a STAT command at any time while - data transfer was in progress and that the server-FTP - would reply immediately with status -- e.g., the number - of bytes transferred so far. Similarly, an ABOR - command should be possible at any time during a data - transfer. - - Unfortunately, some small-machine operating systems - make such concurrent programming difficult, and some - other implementers seek minimal solutions, so some FTP - implementations do not allow concurrent use of the data - and control connections. Even such a minimal server - must be prepared to accept and defer a STAT or ABOR - command that arrives during data transfer. - - 4.1.3.4 FTP Restart Mechanism - - The description of the 110 reply on pp. 40-41 of RFC-959 is - incorrect; the correct description is as follows. A restart - reply message, sent over the control connection from the - receiving FTP to the User-FTP, has the format: - - 110 MARK ssss = rrrr - - Here: - - * ssss is a text string that appeared in a Restart Marker - - - -Internet Engineering Task Force [Page 36] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - in the data stream and encodes a position in the - sender's file system; - - * rrrr encodes the corresponding position in the - receiver's file system. - - The encoding, which is specific to a particular file system - and network implementation, is always generated and - interpreted by the same system, either sender or receiver. - - When 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. An 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. - - Two new reply codes are hereby defined for errors - encountered in restarting a transfer: - - 554 Requested action not taken: invalid REST parameter. - - A 554 reply may result from a FTP service command that - follows a REST command. The reply indicates that the - existing file at the Server-FTP cannot be repositioned - as specified in the REST. - - 555 Requested action not taken: type or stru mismatch. - - A 555 reply may result from an APPE command or from any - FTP service command following a REST command. The - reply indicates that there is some mismatch between the - current transfer parameters (type and stru) and the - attributes of the existing file. - - DISCUSSION: - Note that the FTP Restart mechanism requires that Block - or Compressed mode be used for data transfer, to allow - the Restart Markers to be included within the data - stream. The frequency of Restart Markers can be low. - - Restart Markers mark a place in the data stream, but - the receiver may be performing some transformation on - the data as it is stored into stable storage. In - general, the receiver's encoding must include any state - information necessary to restart this transformation at - any point of the FTP data stream. For example, in TYPE - - - -Internet Engineering Task Force [Page 37] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - A transfers, some receiver hosts transform CR LF - sequences into a single LF character on disk. If a - Restart Marker happens to fall between CR and LF, the - receiver must encode in rrrr that the transfer must be - restarted in a "CR has been seen and discarded" state. - - Note that the Restart Marker is required to be encoded - as a string of printable ASCII characters, regardless - of the type of the data. - - RFC-959 says that restart information is to be returned - "to the user". This should not be taken literally. In - general, the User-FTP should save the restart - information (ssss,rrrr) in stable storage, e.g., append - it to a restart control file. An empty restart control - file should be created when the transfer first starts - and deleted automatically when the transfer completes - successfully. It is suggested that this file have a - name derived in an easily-identifiable manner from the - name of the file being transferred and the remote host - name; this is analogous to the means used by many text - editors for naming "backup" files. - - There are three cases for FTP restart. - - (1) User-to-Server Transfer - - The User-FTP puts Restart Markers <ssss> at - convenient places in the data stream. When the - Server-FTP receives a Marker, it writes all prior - data to disk, encodes its file system position and - transformation state as rrrr, and returns a "110 - MARK ssss = rrrr" reply over the control - connection. The User-FTP appends the pair - (ssss,rrrr) to its restart control file. - - To restart the transfer, the User-FTP fetches the - last (ssss,rrrr) pair from the restart control - file, repositions its local file system and - transformation state using ssss, and sends the - command "REST rrrr" to the Server-FTP. - - (2) Server-to-User Transfer - - The Server-FTP puts Restart Markers <ssss> at - convenient places in the data stream. When the - User-FTP receives a Marker, it writes all prior - data to disk, encodes its file system position and - - - -Internet Engineering Task Force [Page 38] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - transformation state as rrrr, and appends the pair - (rrrr,ssss) to its restart control file. - - To restart the transfer, the User-FTP fetches the - last (rrrr,ssss) pair from the restart control - file, repositions its local file system and - transformation state using rrrr, and sends the - command "REST ssss" to the Server-FTP. - - (3) Server-to-Server ("Third-Party") Transfer - - The sending Server-FTP puts Restart Markers <ssss> - at convenient places in the data stream. When it - receives a Marker, the receiving Server-FTP writes - all prior data to disk, encodes its file system - position and transformation state as rrrr, and - sends a "110 MARK ssss = rrrr" reply over the - control connection to the User. The User-FTP - appends the pair (ssss,rrrr) to its restart - control file. - - To restart the transfer, the User-FTP fetches the - last (ssss,rrrr) pair from the restart control - file, sends "REST ssss" to the sending Server-FTP, - and sends "REST rrrr" to the receiving Server-FTP. - - - 4.1.4 FTP/USER INTERFACE - - This section discusses the user interface for a User-FTP - program. - - 4.1.4.1 Pathname Specification - - Since 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. - - DISCUSSION: - In particular, remote pathnames can be of arbitrary - length, and all the printing ASCII characters as well - as space (0x20) must be allowed. RFC-959 allows a - pathname to contain any 7-bit ASCII character except CR - or LF. - - - - - -Internet Engineering Task Force [Page 39] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.4.2 "QUOTE" Command - - A 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. - - To 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. - - DISCUSSION: - The "QUOTE" command is essential to allow the user to - access servers that require system-specific commands - (e.g., SITE or ALLO), or to invoke new or optional - features that are not implemented by the User-FTP. For - example, "QUOTE" may be used to specify "TYPE A T" to - send a print file to hosts that require the - distinction, even if the User-FTP does not recognize - that TYPE. - - 4.1.4.3 Displaying Replies to User - - A User-FTP SHOULD display to the user the full text of all - error reply messages it receives. It 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. - - 4.1.4.4 Maintaining Synchronization - - The state machine in a User-FTP SHOULD be forgiving of - missing and unexpected reply messages, in order to maintain - command synchronization with the server. - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 40] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.5 FTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------|---------------|-|-|-|-|-|-- -Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | | -File/Record transform invertible if poss. |4.1.2.4 | |x| | | | -User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | | -Server-FTP implement PASV |4.1.2.6 |x| | | | | - PASV is per-transfer |4.1.2.6 |x| | | | | -NLST reply usable in RETR cmds |4.1.2.7 |x| | | | | -Implied type for LIST and NLST |4.1.2.7 | |x| | | | -SITE cmd for non-standard features |4.1.2.8 | |x| | | | -STOU cmd return pathname as specified |4.1.2.9 |x| | | | | -Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x| - | | | | | | | -Server-FTP send only correct reply format |4.1.2.11 |x| | | | | -Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | | - New reply code following Section 4.2 |4.1.2.11 | | |x| | | -User-FTP use only high digit of reply |4.1.2.11 | |x| | | | -User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | | -User-FTP handle 421 reply specially |4.1.2.11 | | | |x| | - | | | | | | | -Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | | -User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x| -User-FTP negotiate Telnet options |4.1.2.12 | | | | |x| -Server-FTP handle Telnet options |4.1.2.12 |x| | | | | -Handle "Experimental" directory cmds |4.1.3.1 | |x| | | | -Idle timeout in server-FTP |4.1.3.2 | |x| | | | - Configurable idle timeout |4.1.3.2 | |x| | | | -Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | | -Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x| - | | | | | | | -Support TYPE: | | | | | | | - ASCII - Non-Print (AN) |4.1.2.13 |x| | | | | - ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | | - ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | | - EBCDIC - (any form) |959 3.1.1.2 | | |x| | | - IMAGE |4.1.2.1 |x| | | | | - LOCAL 8 |4.1.2.1 |x| | | | | - - - -Internet Engineering Task Force [Page 41] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - LOCAL m |4.1.2.1 | | |x| | |2 - | | | | | | | -Support MODE: | | | | | | | - Stream |4.1.2.13 |x| | | | | - Block |959 3.4.2 | | |x| | | - | | | | | | | -Support STRUCTURE: | | | | | | | - File |4.1.2.13 |x| | | | | - Record |4.1.2.13 |x| | | | |3 - Page |4.1.2.3 | | | |x| | - | | | | | | | -Support commands: | | | | | | | - USER |4.1.2.13 |x| | | | | - PASS |4.1.2.13 |x| | | | | - ACCT |4.1.2.13 |x| | | | | - CWD |4.1.2.13 |x| | | | | - CDUP |4.1.2.13 |x| | | | | - SMNT |959 5.3.1 | | |x| | | - REIN |959 5.3.1 | | |x| | | - QUIT |4.1.2.13 |x| | | | | - | | | | | | | - PORT |4.1.2.13 |x| | | | | - PASV |4.1.2.6 |x| | | | | - TYPE |4.1.2.13 |x| | | | |1 - STRU |4.1.2.13 |x| | | | |1 - MODE |4.1.2.13 |x| | | | |1 - | | | | | | | - RETR |4.1.2.13 |x| | | | | - STOR |4.1.2.13 |x| | | | | - STOU |959 5.3.1 | | |x| | | - APPE |4.1.2.13 |x| | | | | - ALLO |959 5.3.1 | | |x| | | - REST |959 5.3.1 | | |x| | | - RNFR |4.1.2.13 |x| | | | | - RNTO |4.1.2.13 |x| | | | | - ABOR |959 5.3.1 | | |x| | | - DELE |4.1.2.13 |x| | | | | - RMD |4.1.2.13 |x| | | | | - MKD |4.1.2.13 |x| | | | | - PWD |4.1.2.13 |x| | | | | - LIST |4.1.2.13 |x| | | | | - NLST |4.1.2.13 |x| | | | | - SITE |4.1.2.8 | | |x| | | - STAT |4.1.2.13 |x| | | | | - SYST |4.1.2.13 |x| | | | | - HELP |4.1.2.13 |x| | | | | - NOOP |4.1.2.13 |x| | | | | - | | | | | | | - - - -Internet Engineering Task Force [Page 42] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - -User Interface: | | | | | | | - Arbitrary pathnames |4.1.4.1 |x| | | | | - Implement "QUOTE" command |4.1.4.2 |x| | | | | - Transfer control commands immediately |4.1.4.2 | |x| | | | - Display error messages to user |4.1.4.3 | |x| | | | - Verbose mode |4.1.4.3 | |x| | | | - Maintain synchronization with server |4.1.4.4 | |x| | | | - -Footnotes: - -(1) For the values shown earlier. - -(2) Here m is number of bits in a memory word. - -(3) Required for host with record-structured file system, optional - otherwise. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 43] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP - - 4.2.1 INTRODUCTION - - The Trivial File Transfer Protocol TFTP is defined in RFC-783 - [TFTP:1]. - - TFTP provides its own reliable delivery with UDP as its - transport protocol, using a simple stop-and-wait acknowledgment - system. Since TFTP has an effective window of only one 512 - octet segment, it can provide good performance only over paths - that have a small delay*bandwidth product. The TFTP file - interface is very simple, providing no access control or - security. - - TFTP's most important application is bootstrapping a host over - a local network, since it is simple and small enough to be - easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are - urged to support TFTP for booting. - - 4.2.2 PROTOCOL WALK-THROUGH - - The TFTP specification [TFTP:1] is written in an open style, - and does not fully specify many parts of the protocol. - - 4.2.2.1 Transfer Modes: RFC-783, Page 3 - - The transfer mode "mail" SHOULD NOT be supported. - - 4.2.2.2 UDP Header: RFC-783, Page 17 - - The Length field of a UDP header is incorrectly defined; it - includes the UDP header length (8). - - 4.2.3 SPECIFIC ISSUES - - 4.2.3.1 Sorcerer's Apprentice Syndrome - - There is a serious bug, known as the "Sorcerer's Apprentice - Syndrome," in the protocol specification. While it does not - cause incorrect operation of the transfer (the file will - always be transferred correctly if the transfer completes), - this bug may cause excessive retransmission, which may cause - the transfer to time out. - - Implementations 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 - - - -Internet Engineering Task Force [Page 44] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - duplicate ACK. - - DISCUSSION: - The bug is caused by the protocol rule that either - side, on receiving an old duplicate datagram, may - resend the current datagram. If a packet is delayed in - the network but later successfully delivered after - either side has timed out and retransmitted a packet, a - duplicate copy of the response may be generated. If - the other side responds to this duplicate with a - duplicate of its own, then every datagram will be sent - in duplicate for the remainder of the transfer (unless - a datagram is lost, breaking the repetition). Worse - yet, since the delay is often caused by congestion, - this duplicate transmission will usually causes more - congestion, leading to more delayed packets, etc. - - The following example may help to clarify this problem. - - TFTP A TFTP B - - (1) Receive ACK X-1 - Send DATA X - (2) Receive DATA X - Send ACK X - (ACK X is delayed in network, - and A times out): - (3) Retransmit DATA X - - (4) Receive DATA X again - Send ACK X again - (5) Receive (delayed) ACK X - Send DATA X+1 - (6) Receive DATA X+1 - Send ACK X+1 - (7) Receive ACK X again - Send DATA X+1 again - (8) Receive DATA X+1 again - Send ACK X+1 again - (9) Receive ACK X+1 - Send DATA X+2 - (10) Receive DATA X+2 - Send ACK X+3 - (11) Receive ACK X+1 again - Send DATA X+2 again - (12) Receive DATA X+2 again - Send ACK X+3 again - - - - -Internet Engineering Task Force [Page 45] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - Notice that once the delayed ACK arrives, the protocol - settles down to duplicate all further packets - (sequences 5-8 and 9-12). The problem is caused not by - either side timing out, but by both sides - retransmitting the current packet when they receive a - duplicate. - - The fix is to break the retransmission loop, as - indicated above. This is analogous to the behavior of - TCP. It is then possible to remove the retransmission - timer on the receiver, since the resent ACK will never - cause any action; this is a useful simplification where - TFTP is used in a bootstrap program. It is OK to allow - the timer to remain, and it may be helpful if the - retransmitted ACK replaces one that was genuinely lost - in the network. The sender still requires a retransmit - timer, of course. - - 4.2.3.2 Timeout Algorithms - - A TFTP implementation MUST use an adaptive timeout. - - IMPLEMENTATION: - TCP retransmission algorithms provide a useful base to - work from. At least an exponential backoff of - retransmission timeout is necessary. - - 4.2.3.3 Extensions - - A variety of non-standard extensions have been made to TFTP, - including additional transfer modes and a secure operation - mode (with passwords). None of these have been - standardized. - - 4.2.3.4 Access Control - - A server TFTP implementation SHOULD include some - configurable access control over what pathnames are allowed - in TFTP operations. - - 4.2.3.5 Broadcast Request - - A TFTP request directed to a broadcast address SHOULD be - silently ignored. - - DISCUSSION: - Due to the weak access control capability of TFTP, - directed broadcasts of TFTP requests to random networks - - - -Internet Engineering Task Force [Page 46] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - could create a significant security hole. - - 4.2.4 TFTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- -Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | | -Transfer modes: | | | | | | | - netascii |RFC-783 |x| | | | | - octet |RFC-783 |x| | | | | - mail |4.2.2.1 | | | |x| | - extensions |4.2.3.3 | | |x| | | -Use adaptive timeout |4.2.3.2 |x| | | | | -Configurable access control |4.2.3.4 | |x| | | | -Silently ignore broadcast request |4.2.3.5 | |x| | | | --------------------------------------------------|--------|-|-|-|-|-|-- --------------------------------------------------|--------|-|-|-|-|-|-- - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 47] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - -5. ELECTRONIC MAIL -- SMTP and RFC-822 - - 5.1 INTRODUCTION - - In the TCP/IP protocol suite, electronic mail in a format - specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail - Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1]. - - While SMTP has remained unchanged over the years, the Internet - community has made several changes in the way SMTP is used. In - particular, the conversion to the Domain Name System (DNS) has - caused changes in address formats and in mail routing. In this - section, we assume familiarity with the concepts and terminology - of the DNS, whose requirements are given in Section 6.1. - - RFC-822 specifies the Internet standard format for electronic mail - messages. RFC-822 supercedes an older standard, RFC-733, that may - still be in use in a few places, although it is obsolete. The two - formats are sometimes referred to simply by number ("822" and - "733"). - - RFC-822 is used in some non-Internet mail environments with - different mail transfer protocols than SMTP, and SMTP has also - been adapted for use in some non-Internet environments. Note that - this document presents the rules for the use of SMTP and RFC-822 - for the Internet environment only; other mail environments that - use these protocols may be expected to have their own rules. - - 5.2 PROTOCOL WALK-THROUGH - - This section covers both RFC-821 and RFC-822. - - The SMTP specification in RFC-821 is clear and contains numerous - examples, so implementors should not find it difficult to - understand. This section simply updates or annotates portions of - RFC-821 to conform with current usage. - - RFC-822 is a long and dense document, defining a rich syntax. - Unfortunately, incomplete or defective implementations of RFC-822 - are common. In fact, nearly all of the many formats of RFC-822 - are actually used, so an implementation generally needs to - recognize and correctly interpret all of the RFC-822 syntax. - - 5.2.1 The SMTP Model: RFC-821 Section 2 - - DISCUSSION: - Mail is sent by a series of request/response transactions - between a client, the "sender-SMTP," and a server, the - - - -Internet Engineering Task Force [Page 48] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - "receiver-SMTP". These transactions pass (1) the message - proper, which is composed of header and body, and (2) SMTP - source and destination addresses, referred to as the - "envelope". - - The SMTP programs are analogous to Message Transfer Agents - (MTAs) of X.400. There will be another level of protocol - software, closer to the end user, that is responsible for - composing and analyzing RFC-822 message headers; this - component is known as the "User Agent" in X.400, and we - use that term in this document. There is a clear logical - distinction between the User Agent and the SMTP - implementation, since they operate on different levels of - protocol. Note, however, that this distinction is may not - be exactly reflected the structure of typical - implementations of Internet mail. Often there is a - program known as the "mailer" that implements SMTP and - also some of the User Agent functions; the rest of the - User Agent functions are included in a user interface used - for entering and reading mail. - - The SMTP envelope is constructed at the originating site, - typically by the User Agent when the message is first - queued for the Sender-SMTP program. The envelope - addresses may be derived from information in the message - header, supplied by the user interface (e.g., to implement - a bcc: request), or derived from local configuration - information (e.g., expansion of a mailing list). The SMTP - envelope cannot in general be re-derived from the header - at a later stage in message delivery, so the envelope is - transmitted separately from the message itself using the - MAIL and RCPT commands of SMTP. - - The text of RFC-821 suggests that mail is to be delivered - to an individual user at a host. With the advent of the - domain system and of mail routing using mail-exchange (MX) - resource records, implementors should now think of - delivering mail to a user at a domain, which may or may - not be a particular host. This DOES NOT change the fact - that SMTP is a host-to-host mail exchange protocol. - - 5.2.2 Canonicalization: RFC-821 Section 3.1 - - The 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. A canonicalized name either - identifies a host directly or is an MX name; it cannot be a - - - -Internet Engineering Task Force [Page 49] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - CNAME. - - 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 - - A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN - (this requirement overrides RFC-821). However, 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. - - A new reply code is defined for the VRFY command: - - 252 Cannot VRFY user (e.g., info is not local), but will - take message for this user and attempt delivery. - - DISCUSSION: - SMTP users and administrators make regular use of these - commands for diagnosing mail delivery problems. With the - increasing use of multi-level mailing list expansion - (sometimes more than two levels), EXPN has been - increasingly important for diagnosing inadvertent mail - loops. On the other hand, some feel that EXPN represents - a significant privacy, and perhaps even a security, - exposure. - - 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 - - An SMTP MAY implement the commands to send a message to a - user's terminal: SEND, SOML, and SAML. - - DISCUSSION: - It has been suggested that the use of mail relaying - through an MX record is inconsistent with the intent of - SEND to deliver a message immediately and directly to a - user's terminal. However, an SMTP receiver that is unable - to write directly to the user terminal can return a "251 - User Not Local" reply to the RCPT following a SEND, to - inform the originator of possibly deferred delivery. - - 5.2.5 HELO Command: RFC-821 Section 3.5 - - The sender-SMTP MUST ensure that the <domain> parameter in a - HELO command is a valid principal host domain name for the - client host. As a result, the receiver-SMTP will not have to - perform MX resolution on this name in order to validate the - HELO parameter. - - The HELO receiver MAY verify that the HELO parameter really - - - -Internet Engineering Task Force [Page 50] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - corresponds to the IP address of the sender. However, the - receiver MUST NOT refuse to accept a message, even if the - sender's HELO command fails verification. - - DISCUSSION: - Verifying the HELO parameter requires a domain name lookup - and may therefore take considerable time. An alternative - tool for tracking bogus mail sources is suggested below - (see "DATA Command"). - - Note also that the HELO argument is still required to have - valid <domain> syntax, since it will appear in a Received: - line; otherwise, a 501 error is to be sent. - - IMPLEMENTATION: - When HELO parameter validation fails, a suggested - procedure is to insert a note about the unknown - authenticity of the sender into the message header (e.g., - in the "Received:" line). - - 5.2.6 Mail Relay: RFC-821 Section 3.6 - - We distinguish three types of mail (store-and-) forwarding: - - (1) A simple forwarder or "mail exchanger" forwards a message - using private knowledge about the recipient; see section - 3.2 of RFC-821. - - (2) An SMTP mail "relay" forwards a message within an SMTP - mail environment as the result of an explicit source route - (as defined in section 3.6 of RFC-821). The SMTP relay - function uses the "@...:" form of source route from RFC- - 822 (see Section 5.2.19 below). - - (3) A mail "gateway" passes a message between different - environments. The rules for mail gateways are discussed - below in Section 5.3.7. - - An 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. - - A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an - explicit source route using the "@...:" address form. Thus, - the relay function defined in section 3.6 of RFC-821 should - not be used. - - - -Internet Engineering Task Force [Page 51] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - The intent is to discourage all source routing and to - abolish explicit source routing for mail delivery within - the Internet environment. Source-routing is unnecessary; - the simple target address "user@domain" should always - suffice. This is the result of an explicit architectural - decision to use universal naming rather than source - routing for mail. Thus, SMTP provides end-to-end - connectivity, and the DNS provides globally-unique, - location-independent names. MX records handle the major - case where source routing might otherwise be needed. - - A 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. If 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. - - DISCUSSION: - For example, suppose a host that does not implement the - relay function receives a message with the SMTP command: - "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and - GAMMA represent domain names. Rather than immediately - refusing the message with a 550 error reply as suggested - on page 20 of RFC-821, the host should try to forward the - message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>". - Since this host does not support relaying, it is not - required to update the reverse path. - - Some have suggested that source routing may be needed - occasionally for manually routing mail around failures; - however, the reality and importance of this need is - controversial. The use of explicit SMTP mail relaying for - this purpose is discouraged, and in fact it may not be - successful, as many host systems do not support it. Some - have used the "%-hack" (see Section 5.2.16) for this - purpose. - - 5.2.7 RCPT Command: RFC-821 Section 4.1.1 - - A host that supports a receiver-SMTP MUST support the reserved - mailbox "Postmaster". - - The 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). - - Therefore, a "250 OK" response to a RCPT does not necessarily - - - -Internet Engineering Task Force [Page 52] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - imply that the delivery address(es) are valid. Errors found - after message acceptance will be reported by mailing a - notification message to an appropriate address (see Section - 5.3.3). - - DISCUSSION: - The set of conditions under which a RCPT parameter can be - validated immediately is an engineering design choice. - Reporting destination mailbox errors to the Sender-SMTP - before mail is transferred is generally desirable to save - time and network bandwidth, but this advantage is lost if - RCPT verification is lengthy. - - For example, the receiver can verify immediately any - simple local reference, such as a single locally- - registered mailbox. On the other hand, the "reasonable - time" limitation generally implies deferring verification - of a mailing list until after the message has been - transferred and accepted, since verifying a large mailing - list can take a very long time. An implementation might - or might not choose to defer validation of addresses that - are non-local and therefore require a DNS lookup. If a - DNS lookup is performed but a soft domain system error - (e.g., timeout) occurs, validity must be assumed. - - 5.2.8 DATA Command: RFC-821 Section 4.1.1 - - Every 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. In this line, - called a "time stamp line" in RFC-821: - - * 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. - - * The ID field MAY contain an "@" as suggested in RFC-822, - but this is not required. - - * The FOR field MAY contain a list of <path> entries when - multiple RCPT commands have been given. - - - An Internet mail program MUST NOT change a Received: line that - was previously added to the message header. - - - - - -Internet Engineering Task Force [Page 53] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - Including both the source host and the IP source address - in the Received: line may provide enough information for - tracking illicit mail sources and eliminate a need to - explicitly verify the HELO parameter. - - Received: lines are primarily intended for humans tracing - mail routes, primarily of diagnosis of faults. See also - the discussion under 5.3.7. - - When 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). There is an analogous - requirement when gatewaying from the Internet into a different - mail environment; see Section 5.3.7. - - DISCUSSION: - Note that the final reply to the DATA command depends only - upon the successful transfer and storage of the message. - Any problem with the destination address(es) must either - (1) have been reported in an SMTP error reply to the RCPT - command(s), or (2) be reported in a later error message - mailed to the originator. - - IMPLEMENTATION: - The MAIL FROM: information may be passed as a parameter or - in a Return-Path: line inserted at the beginning of the - message. - - 5.2.9 Command Syntax: RFC-821 Section 4.1.2 - - The syntax shown in RFC-821 for the MAIL FROM: command omits - the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page - 15). An empty reverse path MUST be supported. - - 5.2.10 SMTP Replies: RFC-821 Section 4.2 - - A receiver-SMTP SHOULD send only the reply codes listed in - section 4.2.2 of RFC-821 or in this document. A receiver-SMTP - SHOULD use the text shown in examples in RFC-821 whenever - appropriate. - - A 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. The space - (blank) following the reply code is considered part of the - text. Whenever possible, a sender-SMTP SHOULD test only the - - - -Internet Engineering Task Force [Page 54] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - first digit of the reply code, as specified in Appendix E of - RFC-821. - - DISCUSSION: - Interoperability problems have arisen with SMTP systems - using reply codes that are not listed explicitly in RFC- - 821 Section 4.3 but are legal according to the theory of - reply codes explained in Appendix E. - - 5.2.11 Transparency: RFC-821 Section 4.5.2 - - Implementors MUST be sure that their mail systems always add - and delete periods to ensure message transparency. - - 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 - - RFC-974 [SMTP:3] recommended that the domain system be queried - for WKS ("Well-Known Service") records, to verify that each - proposed mail target does support SMTP. Later experience has - shown that WKS is not widely supported, so the WKS step in MX - processing SHOULD NOT be used. - - The following are notes on RFC-822, organized by section of that - document. - - 5.2.13 RFC-822 Message Specification: RFC-822 Section 4 - - The syntax shown for the Return-path line omits the possibility - of a null return path, which is used to prevent looping of - error notifications (see Section 5.3.3). The complete syntax - is: - - return = "Return-path" ":" route-addr - / "Return-path" ":" "<" ">" - - The set of optional header fields is hereby expanded to include - the Content-Type field defined in RFC-1049 [SMTP:7]. This - field "allows mail reading systems to automatically identify - the type of a structured message body and to process it for - display accordingly". [SMTP:7] A User Agent MAY support this - field. - - 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 - - The syntax for the date is hereby changed to: - - date = 1*2DIGIT month 2*4DIGIT - - - - -Internet Engineering Task Force [Page 55] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - All mail software SHOULD use 4-digit years in dates, to ease - the transition to the next century. - - There is a strong trend towards the use of numeric timezone - indicators, and implementations SHOULD use numeric timezones - instead of timezone names. However, all implementations MUST - accept either notation. If timezone names are used, they MUST - be exactly as defined in RFC-822. - - The military time zones are specified incorrectly in RFC-822: - they count the wrong way from UT (the signs are reversed). As - a result, military time zones in RFC-822 headers carry no - information. - - Finally, note that there is a typo in the definition of "zone" - in the syntax summary of appendix D; the correct definition - occurs in Section 3 of RFC-822. - - 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 - - The syntactic definition of "mailbox" in RFC-822 is hereby - changed to: - - mailbox = addr-spec ; simple address - / [phrase] route-addr ; name & addr-spec - - That is, the phrase preceding a route address is now OPTIONAL. - This change makes the following header field legal, for - example: - - From: <craig@nnsc.nsf.net> - - 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 - - The basic mailbox address specification has the form: "local- - part@domain". Here "local-part", sometimes called the "left- - hand side" of the address, is domain-dependent. - - A 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. - - When 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. The gateway will then - interpret this local part appropriately for the foreign mail - environment. - - - -Internet Engineering Task Force [Page 56] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - Although source routes are discouraged within the Internet - (see Section 5.2.6), there are non-Internet mail - environments whose delivery mechanisms do depend upon - source routes. Source routes for extra-Internet - environments can generally be buried in the "local-part" - of the address (see Section 5.2.16) while mail traverses - the Internet. When the mail reaches the appropriate - Internet mail gateway, the gateway will interpret the - local-part and build the necessary address or route for - the target mail environment. - - For example, an Internet host might send mail to: - "a!b!c!user@gateway-domain". The complex local part - "a!b!c!user" would be uninterpreted within the Internet - domain, but could be parsed and understood by the - specified mail gateway. - - An embedded source route is sometimes encoded in the - "local-part" using "%" as a right-binding routing - operator. For example, in: - - user%domain%relay3%relay2@relay1 - - the "%" convention implies that the mail is to be routed - from "relay1" through "relay2", "relay3", and finally to - "user" at "domain". This is commonly known as the "%- - hack". It is suggested that "%" have lower precedence - than any other routing operator (e.g., "!") hidden in the - local-part; for example, "a!b%c" would be interpreted as - "(a!b)%c". - - Only the target host (in this case, "relay1") is permitted - to analyze the local-part "user%domain%relay3%relay2". - - 5.2.17 Domain Literals: RFC-822 Section 6.2.3 - - A mailer MUST be able to accept and parse an Internet domain - literal whose content ("dtext"; see RFC-822) is a dotted- - decimal host address. This satisfies the requirement of - Section 2.1 for the case of mail. - - An SMTP MUST accept and recognize a domain literal for any of - its own IP addresses. - - - - - - - -Internet Engineering Task Force [Page 57] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 - - Errors in formatting or parsing 822 addresses are unfortunately - common. This section mentions only the most common errors. A - User Agent MUST accept all valid RFC-822 address formats, and - MUST NOT generate illegal address syntax. - - o A common error is to leave out the semicolon after a group - identifier. - - o Some systems fail to fully-qualify domain names in - messages they generate. The right-hand side of an "@" - sign in a header address field MUST be a fully-qualified - domain name. - - For example, some systems fail to fully-qualify the From: - address; this prevents a "reply" command in the user - interface from automatically constructing a return - address. - - DISCUSSION: - Although RFC-822 allows the local use of abbreviated - domain names within a domain, the application of - RFC-822 in Internet mail does not allow this. The - intent is that an Internet host must not send an SMTP - message header containing an abbreviated domain name - in an address field. This allows the address fields - of the header to be passed without alteration across - the Internet, as required in Section 5.2.6. - - o Some systems mis-parse multiple-hop explicit source routes - such as: - - @relay1,@relay2,@relay3:user@domain. - - - o Some systems over-qualify domain names by adding a - trailing dot to some or all domain names in addresses or - message-ids. This violates RFC-822 syntax. - - - 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 - - Internet 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. - - DISCUSSION: - - - -Internet Engineering Task Force [Page 58] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - In an understatement, RFC-822 says "The use of explicit - source routing is discouraged". Many hosts implemented - RFC-822 source routes incorrectly, so the syntax cannot be - used unambiguously in practice. Many users feel the - syntax is ugly. Explicit source routes are not needed in - the mail envelope for delivery; see Section 5.2.6. For - all these reasons, explicit source routes using the RFC- - 822 notations are not to be used in Internet mail headers. - - As stated in Section 5.2.16, it is necessary to allow an - explicit source route to be buried in the local-part of an - address, e.g., using the "%-hack", in order to allow mail - to be gatewayed into another environment in which explicit - source routing is necessary. The vigilant will observe - that there is no way for a User Agent to detect and - prevent the use of such implicit source routing when the - destination is within the Internet. We can only - discourage source routing of any kind within the Internet, - as unnecessary and undesirable. - - 5.3 SPECIFIC ISSUES - - 5.3.1 SMTP Queueing Strategies - - The common structure of a host SMTP implementation includes - user mailboxes, one or more areas for queueing messages in - transit, and one or more daemon processes for sending and - receiving mail. The exact structure will vary depending on the - needs of the users on the host and the number and size of - mailing lists supported by the host. We describe several - optimizations that have proved helpful, particularly for - mailers supporting high traffic levels. - - Any queueing strategy MUST include: - - o Timeouts on all activities. See Section 5.3.2. - - o Never sending error messages in response to error - messages. - - - 5.3.1.1 Sending Strategy - - The general model of a sender-SMTP is one or more processes - that periodically attempt to transmit outgoing mail. In a - typical system, the program that composes a message has some - method for requesting immediate attention for a new piece of - outgoing mail, while mail that cannot be transmitted - - - -Internet Engineering Task Force [Page 59] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - immediately MUST be queued and periodically retried by the - sender. A mail queue entry will include not only the - message itself but also the envelope information. - - The sender MUST delay retrying a particular destination - after one attempt has failed. In 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. - - Retries continue until the message is transmitted or the - sender gives up; the give-up time generally needs to be at - least 4-5 days. The parameters to the retry algorithm MUST - be configurable. - - A sender SHOULD keep a list of hosts it cannot reach and - corresponding timeouts, rather than just retrying queued - mail items. - - DISCUSSION: - Experience suggests that failures are typically - transient (the target system has crashed), favoring a - policy of two connection attempts in the first hour the - message is in the queue, and then backing off to once - every two or three hours. - - The sender-SMTP can shorten the queueing delay by - cooperation with the receiver-SMTP. In particular, if - mail is received from a particular address, it is good - evidence that any mail queued for that host can now be - sent. - - The strategy may be further modified as a result of - multiple addresses per host (see Section 5.3.4), to - optimize delivery time vs. resource usage. - - A sender-SMTP may have a large queue of messages for - each unavailable destination host, and if it retried - all these messages in every retry cycle, there would be - excessive Internet overhead and the daemon would be - blocked for a long period. Note that an SMTP can - generally determine that a delivery attempt has failed - only after a timeout of a minute or more; a one minute - timeout per connection will result in a very large - delay if it is repeated for dozens or even hundreds of - queued messages. - - - - -Internet Engineering Task Force [Page 60] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - When the same message is to be delivered to several users on - the same host, only one copy of the message SHOULD be - transmitted. That is, the sender-SMTP should use the - command sequence: RCPT, RCPT,... RCPT, DATA instead of the - sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. - Implementation of this efficiency feature is strongly urged. - - Similarly, the sender-SMTP MAY support multiple concurrent - outgoing mail transactions to achieve timely delivery. - However, some limit SHOULD be imposed to protect the host - from devoting all its resources to mail. - - The use of the different addresses of a multihomed host is - discussed below. - - 5.3.1.2 Receiving strategy - - The receiver-SMTP SHOULD attempt to keep a pending listen on - the SMTP port at all times. This will require the support - of multiple incoming TCP connections for SMTP. Some limit - MAY be imposed. - - IMPLEMENTATION: - When the receiver-SMTP receives mail from a particular - host address, it could notify the sender-SMTP to retry - any mail pending for that host address. - - 5.3.2 Timeouts in SMTP - - There are two approaches to timeouts in the sender-SMTP: (a) - limit the time for each SMTP command separately, or (b) limit - the time for the entire SMTP dialogue for a single mail - message. A sender-SMTP SHOULD use option (a), per-command - timeouts. Timeouts SHOULD be easily reconfigurable, preferably - without recompiling the SMTP code. - - DISCUSSION: - Timeouts are an essential feature of an SMTP - implementation. If the timeouts are too long (or worse, - there are no timeouts), Internet communication failures or - software bugs in receiver-SMTP programs can tie up SMTP - processes indefinitely. If the timeouts are too short, - resources will be wasted with attempts that time out part - way through message delivery. - - If option (b) is used, the timeout has to be very large, - e.g., an hour, to allow time to expand very large mailing - lists. The timeout may also need to increase linearly - - - -Internet Engineering Task Force [Page 61] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - with the size of the message, to account for the time to - transmit a very large message. A large fixed timeout - leads to two problems: a failure can still tie up the - sender for a very long time, and very large messages may - still spuriously time out (which is a wasteful failure!). - - Using the recommended option (a), a timer is set for each - SMTP command and for each buffer of the data transfer. - The latter means that the overall timeout is inherently - proportional to the size of the message. - - Based on extensive experience with busy mail-relay hosts, the - minimum per-command timeout values SHOULD be as follows: - - o Initial 220 Message: 5 minutes - - A Sender-SMTP process needs to distinguish between a - failed TCP connection and a delay in receiving the initial - 220 greeting message. Many receiver-SMTPs will accept a - TCP connection but delay delivery of the 220 message until - their system load will permit more mail to be processed. - - o MAIL Command: 5 minutes - - - o RCPT Command: 5 minutes - - A longer timeout would be required if processing of - mailing lists and aliases were not deferred until after - the message was accepted. - - o DATA Initiation: 2 minutes - - This is while awaiting the "354 Start Input" reply to a - DATA command. - - o Data Block: 3 minutes - - This is while awaiting the completion of each TCP SEND - call transmitting a chunk of data. - - o DATA Termination: 10 minutes. - - This is while awaiting the "250 OK" reply. When the - receiver gets the final period terminating the message - data, it typically performs processing to deliver the - message to a user mailbox. A spurious timeout at this - point would be very wasteful, since the message has been - - - -Internet Engineering Task Force [Page 62] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - successfully sent. - - A receiver-SMTP SHOULD have a timeout of at least 5 minutes - while it is awaiting the next command from the sender. - - 5.3.3 Reliable Mail Receipt - - When the receiver-SMTP accepts a piece of mail (by sending a - "250 OK" message in response to DATA), it is accepting - responsibility for delivering or relaying the message. It 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. - - If there is a delivery failure after acceptance of a message, - the receiver-SMTP MUST formulate and mail a notification - message. This notification MUST be sent using a null ("<>") - reverse path in the envelope; see Section 3.6 of RFC-821. The - recipient of this notification SHOULD be the address from the - envelope return path (or the Return-Path: line). However, if - this address is null ("<>"), the receiver-SMTP MUST NOT send a - notification. If the address is an explicit source route, it - SHOULD be stripped down to its final hop. - - DISCUSSION: - For example, suppose that an error notification must be - sent for a message that arrived with: - "MAIL FROM:<@a,@b:user@d>". The notification message - should be sent to: "RCPT TO:<user@d>". - - Some delivery failures after the message is accepted by - SMTP will be unavoidable. For example, it may be - impossible for the receiver-SMTP to validate all the - delivery addresses in RCPT command(s) due to a "soft" - domain system error or because the target is a mailing - list (see earlier discussion of RCPT). - - To 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. See RFC-1047 [SMTP:4] for a discussion of this - problem. - - 5.3.4 Reliable Mail Transmission - - To transmit a message, a sender-SMTP determines the IP address - of the target host from the destination address in the - envelope. Specifically, it maps the string to the right of the - - - -Internet Engineering Task Force [Page 63] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - "@" sign into an IP address. This mapping or the transfer - itself may fail with a soft error, in which case the sender- - SMTP will requeue the outgoing mail for a later retry, as - required in Section 5.3.1.1. - - When it succeeds, the mapping can result in a list of - alternative delivery addresses rather than a single address, - because of (a) multiple MX records, (b) multihoming, or both. - To 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. However, there MAY - also be a configurable limit on the number of alternate - addresses that can be tried. In any case, a host SHOULD try at - least two addresses. - - The following information is to be used to rank the host - addresses: - - (1) Multiple MX Records -- these contain a preference - indication that should be used in sorting. If 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]. - - (2) Multihomed host -- The destination host (perhaps taken - from the preferred MX record) may be multihomed, in which - case the domain name resolver will return a list of - alternative IP addresses. It 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. - - DISCUSSION: - Although the capability to try multiple alternative - addresses is required, there may be circumstances where - specific installations want to limit or disable the use of - alternative addresses. The question of whether a sender - should attempt retries using the different addresses of a - multihomed host has been controversial. The main argument - for using the multiple addresses is that it maximizes the - probability of timely delivery, and indeed sometimes the - probability of any delivery; the counter argument is that - it may result in unnecessary resource use. - - Note that resource use is also strongly determined by the - - - -Internet Engineering Task Force [Page 64] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - sending strategy discussed in Section 5.3.1. - - 5.3.5 Domain Name Support - - SMTP implementations MUST use the mechanism defined in Section - 6.1 for mapping between domain names and IP addresses. This - means that every Internet SMTP MUST include support for the - Internet DNS. - - In particular, a sender-SMTP MUST support the MX record scheme - [SMTP:3]. See also Section 7.4 of [DNS:2] for information on - domain name support for SMTP. - - 5.3.6 Mailing Lists and Aliases - - An SMTP-capable host SHOULD support both the alias and the list - form of address expansion for multiple delivery. When 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. - - DISCUSSION: - An important mail facility is a mechanism for multi- - destination delivery of a single message, by transforming - or "expanding" a pseudo-mailbox address into a list of - destination mailbox addresses. When a message is sent to - such a pseudo-mailbox (sometimes called an "exploder"), - copies are forwarded or redistributed to each mailbox in - the expanded list. We classify such a pseudo-mailbox as - an "alias" or a "list", depending upon the expansion - rules: - - (a) Alias - - To expand an alias, the recipient mailer simply - replaces the pseudo-mailbox address in the envelope - with each of the expanded addresses in turn; the rest - of the envelope and the message body are left - unchanged. The message is then delivered or - forwarded to each expanded address. - - (b) List - - A mailing list may be said to operate by - "redistribution" rather than by "forwarding". To - - - -Internet Engineering Task Force [Page 65] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - expand a list, the recipient mailer replaces the - pseudo-mailbox address in the envelope with each of - the expanded addresses in turn. The return address in - the envelope is changed so that all error messages - generated by the final deliveries will be returned to - a list administrator, not to the message originator, - who generally has no control over the contents of the - list and will typically find error messages annoying. - - - 5.3.7 Mail Gatewaying - - Gatewaying mail between different mail environments, i.e., - different mail formats and protocols, is complex and does not - easily yield to standardization. See for example [SMTP:5a], - [SMTP:5b]. However, some general requirements may be given for - a gateway between the Internet and another mail environment. - - (A) Header fields MAY be rewritten when necessary as messages - are gatewayed across mail environment boundaries. - - DISCUSSION: - This may involve interpreting the local-part of the - destination address, as suggested in Section 5.2.16. - - The other mail systems gatewayed to the Internet - generally use a subset of RFC-822 headers, but some - of them do not have an equivalent to the SMTP - envelope. Therefore, when a message leaves the - Internet environment, it may be necessary to fold the - SMTP envelope information into the message header. A - possible solution would be to create new header - fields to carry the envelope information (e.g., "X- - SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would - require changes in mail programs in the foreign - environment. - - (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. - - DISCUSSION: - This requirement is a subset of the general - "Received:" line requirement of Section 5.2.8; it is - restated here for emphasis. - - Received: fields of messages originating from other - - - -Internet Engineering Task Force [Page 66] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - environments may not conform exactly to RFC822. - However, the most important use of Received: lines is - for debugging mail faults, and this debugging can be - severely hampered by well-meaning gateways that try - to "fix" a Received: line. - - The gateway is strongly encouraged to indicate the - environment and protocol in the "via" clauses of - Received field(s) that it supplies. - - (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. Although 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. - - DISCUSSION: - It is often tempting to restrict the range of - addresses accepted at the mail gateway to simplify - the translation into addresses for the remote - environment. This practice is based on the - assumption that mail users have control over the - addresses their mailers send to the mail gateway. In - practice, however, users have little control over the - addresses that are finally sent; their mailers are - free to change addresses into any legal RFC-822 - format. - - (D) The gateway MUST ensure that all header fields of a - message that it forwards into the Internet meet the - requirements for Internet mail. In particular, all - addresses in "From:", "To:", "Cc:", etc., fields must be - transformed (if necessary) to satisfy RFC-822 syntax, and - they must be effective and useful for sending replies. - - - (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. - - DISCUSSION: - Internet mail lists usually place the address of the - mail list maintainer in the envelope but leave the - - - -Internet Engineering Task Force [Page 67] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - original message header intact (with the "From:" - field containing the original sender). This yields - the behavior the average recipient expects: a reply - to the header gets sent to the original sender, not - to a mail list maintainer; however, errors get sent - to the maintainer (who can fix the problem) and not - the sender (who probably cannot). - - (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. - - - 5.3.8 Maximum Message Size - - Mailer 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. - - DISCUSSION: - Although SMTP does not define the maximum size of a - message, many systems impose implementation limits. - - The current de facto minimum limit in the Internet is 64K - bytes. However, electronic mail is used for a variety of - purposes that create much larger messages. For example, - mail is often used instead of FTP for transmitting ASCII - files, and in particular to transmit entire documents. As - a result, messages can be 1 megabyte or even larger. We - note that the present document together with its lower- - layer companion contains 0.5 megabytes. - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 68] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - 5.4 SMTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -RECEIVER-SMTP: | | | | | | | - Implement VRFY |5.2.3 |x| | | | | - Implement EXPN |5.2.3 | |x| | | | - EXPN, VRFY configurable |5.2.3 | | |x| | | - Implement SEND, SOML, SAML |5.2.4 | | |x| | | - Verify HELO parameter |5.2.5 | | |x| | | - Refuse message with bad HELO |5.2.5 | | | | |x| - Accept explicit src-route syntax in env. |5.2.6 |x| | | | | - Support "postmaster" |5.2.7 |x| | | | | - Process RCPT when received (except lists) |5.2.7 | | |x| | | - Long delay of RCPT responses |5.2.7 | | | | |x| - | | | | | | | - Add Received: line |5.2.8 |x| | | | | - Received: line include domain literal |5.2.8 | |x| | | | - Change previous Received: line |5.2.8 | | | | |x| - Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | | - Support empty reverse path |5.2.9 |x| | | | | - Send only official reply codes |5.2.10 | |x| | | | - Send text from RFC-821 when appropriate |5.2.10 | |x| | | | - Delete "." for transparency |5.2.11 |x| | | | | - Accept and recognize self domain literal(s) |5.2.17 |x| | | | | - | | | | | | | - Error message about error message |5.3.1 | | | | |x| - Keep pending listen on SMTP port |5.3.1.2 | |x| | | | - Provide limit on recv concurrency |5.3.1.2 | | |x| | | - Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | | - Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x| - Send error notification msg after accept |5.3.3 |x| | | | | - Send using null return path |5.3.3 |x| | | | | - Send to envelope return path |5.3.3 | |x| | | | - Send to null address |5.3.3 | | | | |x| - Strip off explicit src route |5.3.3 | |x| | | | - Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | | ------------------------------------------------|----------|-|-|-|-|-|-- - - - -Internet Engineering Task Force [Page 69] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - | | | | | | | -SENDER-SMTP: | | | | | | | - Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | | - Implement SEND, SOML, SAML |5.2.4 | | |x| | | - Send valid principal host name in HELO |5.2.5 |x| | | | | - Send explicit source route in RCPT TO: |5.2.6 | | | |x| | - Use only reply code to determine action |5.2.10 |x| | | | | - Use only high digit of reply code when poss. |5.2.10 | |x| | | | - Add "." for transparency |5.2.11 |x| | | | | - | | | | | | | - Retry messages after soft failure |5.3.1.1 |x| | | | | - Delay before retry |5.3.1.1 |x| | | | | - Configurable retry parameters |5.3.1.1 |x| | | | | - Retry once per each queued dest host |5.3.1.1 | |x| | | | - Multiple RCPT's for same DATA |5.3.1.1 | |x| | | | - Support multiple concurrent transactions |5.3.1.1 | | |x| | | - Provide limit on concurrency |5.3.1.1 | |x| | | | - | | | | | | | - Timeouts on all activities |5.3.1 |x| | | | | - Per-command timeouts |5.3.2 | |x| | | | - Timeouts easily reconfigurable |5.3.2 | |x| | | | - Recommended times |5.3.2 | |x| | | | - Try alternate addr's in order |5.3.4 |x| | | | | - Configurable limit on alternate tries |5.3.4 | | |x| | | - Try at least two alternates |5.3.4 | |x| | | | - Load-split across equal MX alternates |5.3.4 | |x| | | | - Use the Domain Name System |5.3.5 |x| | | | | - Support MX records |5.3.5 |x| | | | | - Use WKS records in MX processing |5.2.12 | | | |x| | ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -MAIL FORWARDING: | | | | | | | - Alter existing header field(s) |5.2.6 | | | |x| | - Implement relay function: 821/section 3.6 |5.2.6 | | |x| | | - If not, deliver to RHS domain |5.2.6 | |x| | | | - Interpret 'local-part' of addr |5.2.16 | | | | |x| - | | | | | | | -MAILING LISTS AND ALIASES | | | | | | | - Support both |5.3.6 | |x| | | | - Report mail list error to local admin. |5.3.6 |x| | | | | - | | | | | | | -MAIL GATEWAYS: | | | | | | | - Embed foreign mail route in local-part |5.2.16 | | |x| | | - Rewrite header fields when necessary |5.3.7 | | |x| | | - Prepend Received: line |5.3.7 |x| | | | | - Change existing Received: line |5.3.7 | | | | |x| - Accept full RFC-822 on Internet side |5.3.7 | |x| | | | - Act on RFC-822 explicit source route |5.3.7 | | |x| | | - - - -Internet Engineering Task Force [Page 70] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - Send only valid RFC-822 on Internet side |5.3.7 |x| | | | | - Deliver error msgs to envelope addr |5.3.7 | |x| | | | - Set env return path from err return addr |5.3.7 | |x| | | | - | | | | | | | -USER AGENT -- RFC-822 | | | | | | | - Allow user to enter <route> address |5.2.6 | | | |x| | - Support RFC-1049 Content Type field |5.2.13 | | |x| | | - Use 4-digit years |5.2.14 | |x| | | | - Generate numeric timezones |5.2.14 | |x| | | | - Accept all timezones |5.2.14 |x| | | | | - Use non-num timezones from RFC-822 |5.2.14 |x| | | | | - Omit phrase before route-addr |5.2.15 | | |x| | | - Accept and parse dot.dec. domain literals |5.2.17 |x| | | | | - Accept all RFC-822 address formats |5.2.18 |x| | | | | - Generate invalid RFC-822 address format |5.2.18 | | | | |x| - Fully-qualified domain names in header |5.2.18 |x| | | | | - Create explicit src route in header |5.2.19 | | | |x| | - Accept explicit src route in header |5.2.19 |x| | | | | - | | | | | | | -Send/recv at least 64KB messages |5.3.8 |x| | | | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 71] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - -6. SUPPORT SERVICES - - 6.1 DOMAIN NAME TRANSLATION - - 6.1.1 INTRODUCTION - - Every 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]. - - In addition to the DNS, a host MAY also implement a host name - translation mechanism that searches a local Internet host - table. See Section 6.1.3.8 for more information on this - option. - - DISCUSSION: - Internet host name translation was originally performed by - searching local copies of a table of all hosts. This - table became too large to update and distribute in a - timely manner and too large to fit into many hosts, so the - DNS was invented. - - The DNS creates a distributed database used primarily for - the translation between host names and host addresses. - Implementation of DNS software is required. The DNS - consists of two logically distinct parts: name servers and - resolvers (although implementations often combine these - two logical parts in the interest of efficiency) [DNS:2]. - - Domain name servers store authoritative data about certain - sections of the database and answer queries about the - data. Domain resolvers query domain name servers for data - on behalf of user processes. Every host therefore needs a - DNS resolver; some host machines will also need to run - domain name servers. Since no name server has complete - information, in general it is necessary to obtain - information from more than one name server to resolve a - query. - - 6.1.2 PROTOCOL WALK-THROUGH - - An implementor must study references [DNS:1] and [DNS:2] - carefully. They provide a thorough description of the theory, - protocol, and implementation of the domain name system, and - reflect several years of experience. - - - - - -Internet Engineering Task Force [Page 72] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 - - All DNS name servers and resolvers MUST properly handle RRs - with a zero TTL: return the RR to the client but do not - cache it. - - DISCUSSION: - Zero TTL values are interpreted to mean that the RR can - only be used for the transaction in progress, and - should not be cached; they are useful for extremely - volatile data. - - 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 - - A query with "QCLASS=*" SHOULD NOT be used unless the - requestor is seeking data from more than one class. In - particular, if the requestor is only interested in Internet - data types, QCLASS=IN MUST be used. - - 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 - - Unused fields in a query or response message MUST be zero. - - 6.1.2.4 Compression: RFC-1035 Section 4.1.4 - - Name servers MUST use compression in responses. - - DISCUSSION: - Compression is essential to avoid overflowing UDP - datagrams; see Section 6.1.3.2. - - 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 - - Recursive name servers and full-service resolvers generally - have some configuration information containing hints about - the location of root or local name servers. An - implementation MUST NOT include any of these hints in a - response. - - DISCUSSION: - Many implementors have found it convenient to store - these hints as if they were cached data, but some - neglected to ensure that this "cached data" was not - included in responses. This has caused serious - problems in the Internet when the hints were obsolete - or incorrect. - - - - - -Internet Engineering Task Force [Page 73] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3 SPECIFIC ISSUES - - 6.1.3.1 Resolver Implementation - - A name resolver SHOULD be able to multiplex concurrent - requests if the host supports concurrent processes. - - In implementing a DNS resolver, one of two different models - MAY optionally be chosen: a full-service resolver, or a stub - resolver. - - - (A) Full-Service Resolver - - A full-service resolver is a complete implementation of - the resolver service, and is capable of dealing with - communication failures, failure of individual name - servers, location of the proper name server for a given - name, etc. It must satisfy the following requirements: - - o The resolver MUST implement a local caching - function to avoid repeated remote access for - identical requests, and MUST time out information - in the cache. - - o The resolver SHOULD be configurable with start-up - information pointing to multiple root name servers - and multiple name servers for the local domain. - This insures that the resolver will be able to - access the whole name space in normal cases, and - will be able to access local domain information - should the local network become disconnected from - the rest of the Internet. - - - (B) Stub Resolver - - A "stub resolver" relies on the services of a recursive - name server on the connected network or a "nearby" - network. This scheme allows the host to pass on the - burden of the resolver function to a name server on - another host. This model is often essential for less - capable hosts, such as PCs, and is also recommended - when the host is one of several workstations on a local - network, because it allows all of the workstations to - share the cache of the recursive name server and hence - reduce the number of domain requests exported by the - local network. - - - -Internet Engineering Task Force [Page 74] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - At a minimum, the stub resolver MUST be capable of - directing its requests to redundant recursive name - servers. Note that recursive name servers are allowed - to restrict the sources of requests that they will - honor, so the host administrator must verify that the - service will be provided. Stub resolvers MAY implement - caching if they choose, but if so, MUST timeout cached - information. - - - 6.1.3.2 Transport Protocols - - DNS resolvers and recursive servers MUST support UDP, and - SHOULD support TCP, for sending (non-zone-transfer) queries. - Specifically, a DNS resolver or server that is sending a - non-zone-transfer query MUST send a UDP query first. If the - Answer section of the response is truncated and if the - requester supports TCP, it SHOULD try the query again using - TCP. - - DNS servers MUST be able to service UDP queries and SHOULD - be able to service TCP queries. A 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. - - Truncated responses MUST NOT be saved (cached) and later - used in such a way that the fact that they are truncated is - lost. - - DISCUSSION: - UDP is preferred over TCP for queries because UDP - queries have much lower overhead, both in packet count - and in connection state. The use of UDP is essential - for heavily-loaded servers, especially the root - servers. UDP also offers additional robustness, since - a resolver can attempt several UDP queries to different - servers for the cost of a single TCP query. - - It is possible for a DNS response to be truncated, - although this is a very rare occurrence in the present - Internet DNS. Practically speaking, truncation cannot - be predicted, since it is data-dependent. The - dependencies include the number of RRs in the answer, - the size of each RR, and the savings in space realized - by the name compression algorithm. As a rule of thumb, - truncation in NS and MX lists should not occur for - answers containing 15 or fewer RRs. - - - -Internet Engineering Task Force [Page 75] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Whether it is possible to use a truncated answer - depends on the application. A mailer must not use a - truncated MX response, since this could lead to mail - loops. - - Responsible practices can make UDP suffice in the vast - majority of cases. Name servers must use compression - in responses. Resolvers must differentiate truncation - of the Additional section of a response (which only - loses extra information) from truncation of the Answer - section (which for MX records renders the response - unusable by mailers). Database administrators should - list only a reasonable number of primary names in lists - of name servers, MX alternatives, etc. - - However, it is also clear that some new DNS record - types defined in the future will contain information - exceeding the 512 byte limit that applies to UDP, and - hence will require TCP. Thus, resolvers and name - servers should implement TCP services as a backup to - UDP today, with the knowledge that they will require - the TCP service in the future. - - By private agreement, name servers and resolvers MAY arrange - to use TCP for all traffic between themselves. TCP MUST be - used for zone transfers. - - A 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]. - - A server MAY support a UDP query that is delivered using an - IP broadcast or multicast address. However, 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. A 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. - - DISCUSSION: - Broadcast or (especially) IP multicast can provide a - way to locate nearby name servers without knowing their - IP addresses in advance. However, general broadcasting - of recursive queries can result in excessive and - unnecessary load on both network and servers. - - - - -Internet Engineering Task Force [Page 76] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3.3 Efficient Resource Usage - - The following requirements on servers and resolvers are very - important to the health of the Internet as a whole, - particularly when DNS services are invoked repeatedly by - higher level automatic servers, such as mailers. - - (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. See [DNS:2] pages 43- - 44 for specific recommendations. - - (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. - - (3) All DNS name servers and resolvers SHOULD cache - temporary failures, with a timeout period of the order - of minutes. - - DISCUSSION: - This will prevent applications that immediately - retry soft failures (in violation of Section 2.2 - of this document) from generating excessive DNS - traffic. - - (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]. - - (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. - - IMPLEMENTATION: - A measured RTT and variance (if available) should - be used to calculate an initial retransmission - interval. If this information is not available, a - default of no less than 5 seconds should be used. - Implementations may limit the retransmission - interval, but this limit must exceed twice the - Internet maximum segment lifetime plus service - delay at the name server. - - (6) When a resolver or server receives a Source Quench for - - - -Internet Engineering Task Force [Page 77] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - a query it has issued, it SHOULD take steps to reduce - the rate of querying that server in the near future. A - server MAY ignore a Source Quench that it receives as - the result of sending a response datagram. - - IMPLEMENTATION: - One recommended action to reduce the rate is to - send the next query attempt to an alternate - server, if there is one available. Another is to - backoff the retry interval for the same server. - - - 6.1.3.4 Multihomed Hosts - - When 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. - - DISCUSSION: - The different addresses of a multihomed host generally - imply different Internet paths, and some paths may be - preferable to others in performance, reliability, or - administrative restrictions. There is no general way - for the domain system to determine the best path. A - recommended approach is to base this decision on local - configuration information set by the system - administrator. - - IMPLEMENTATION: - The following scheme has been used successfully: - - (a) Incorporate into the host configuration data a - Network-Preference List, that is simply a list of - networks in preferred order. This list may be - empty if there is no preference. - - (b) When a host name is mapped into a list of IP - addresses, these addresses should be sorted by - network number, into the same order as the - corresponding networks in the Network-Preference - List. IP addresses whose networks do not appear - in the Network-Preference List should be placed at - the end of the list. - - - - - - -Internet Engineering Task Force [Page 78] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3.5 Extensibility - - DNS 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. - - DISCUSSION: - The data types and classes used by the DNS are - extensible, and thus new types will be added and old - types deleted or redefined. Introduction of new data - types ought to be dependent only upon the rules for - compression of domain names inside DNS messages, and - the translation between printable (i.e., master file) - and internal formats for Resource Records (RRs). - - Compression relies on knowledge of the format of data - inside a particular RR. Hence compression must only be - used for the contents of well-known, class-independent - RRs, and must never be used for class-specific RRs or - RR types that are not well-known. The owner name of an - RR is always eligible for compression. - - A name server may acquire, via zone transfer, RRs that - the server doesn't know how to convert to printable - format. A resolver can receive similar information as - the result of queries. For proper operation, this data - must be preserved, and hence the implication is that - DNS software cannot use textual formats for internal - storage. - - The DNS defines domain name syntax very generally -- a - string of labels each containing up to 63 8-bit octets, - separated by dots, and with a maximum total of 255 - octets. Particular applications of the DNS are - permitted to further constrain the syntax of the domain - names they use, although the DNS deployment has led to - some applications allowing more general names. In - particular, Section 2.1 of this document liberalizes - slightly the syntax of a legal Internet host name that - was defined in RFC-952 [DNS:4]. - - 6.1.3.6 Status of RR Types - - Name servers MUST be able to load all RR types except MD and - MF from configuration files. The MD and MF types are - obsolete and MUST NOT be implemented; in particular, name - servers MUST NOT load these types from configuration files. - - - -Internet Engineering Task Force [Page 79] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - DISCUSSION: - The RR types MB, MG, MR, NULL, MINFO and RP are - considered experimental, and applications that use the - DNS cannot expect these RR types to be supported by - most domains. Furthermore these types are subject to - redefinition. - - The TXT and WKS RR types have not been widely used by - Internet sites; as a result, an application cannot rely - on the the existence of a TXT or WKS RR in most - domains. - - 6.1.3.7 Robustness - - DNS software may need to operate in environments where the - root servers or other servers are unavailable due to network - connectivity or other problems. In 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. - - DISCUSSION: - Although the DNS is meant to be used primarily in the - connected Internet, it should be possible to use the - system in networks which are unconnected to the - Internet. Hence implementations must not depend on - access to root servers before providing service for - local names. - - 6.1.3.8 Local Host Table - - DISCUSSION: - A host may use a local host table as a backup or - supplement to the DNS. This raises the question of - which takes precedence, the DNS or the host table; the - most flexible approach would make this a configuration - option. - - Typically, the contents of such a supplementary host - table will be determined locally by the site. However, - a publically-available table of Internet hosts is - maintained by the DDN Network Information Center (DDN - NIC), with a format documented in [DNS:4]. This table - can be retrieved from the DDN NIC using a protocol - described in [DNS:5]. It must be noted that this table - contains only a small fraction of all Internet hosts. - Hosts using this protocol to retrieve the DDN NIC host - table should use the VERSION command to check if the - - - -Internet Engineering Task Force [Page 80] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - table has changed before requesting the entire table - with the ALL command. The VERSION identifier should be - treated as an arbitrary string and tested only for - equality; no numerical sequence may be assumed. - - The DDN NIC host table includes administrative - information that is not needed for host operation and - is therefore not currently included in the DNS - database; examples include network and gateway entries. - However, much of this additional information will be - added to the DNS in the future. Conversely, the DNS - provides essential services (in particular, MX records) - that are not available from the DDN NIC host table. - - 6.1.4 DNS USER INTERFACE - - 6.1.4.1 DNS Administration - - This document is concerned with design and implementation - issues in host software, not with administrative or - operational issues. However, administrative issues are of - particular importance in the DNS, since errors in particular - segments of this large distributed database can cause poor - or erroneous performance for many sites. These issues are - discussed in [DNS:6] and [DNS:7]. - - 6.1.4.2 DNS User Interface - - Hosts MUST provide an interface to the DNS for all - application programs running on the host. This interface - will typically direct requests to a system process to - perform the resolver function [DNS:1, 6.1:2]. - - At 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. When there is no error, the basic interface - returns the complete response information without - modification, deletion, or ordering, so that the basic - interface will not need to be changed to accommodate new - data types. - - DISCUSSION: - The soft error indication is an essential part of the - interface, since it may not always be possible to - access particular information from the DNS; see Section - 6.1.3.3. - - - -Internet Engineering Task Force [Page 81] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - A host MAY provide other DNS interfaces tailored to - particular functions, transforming the raw domain data into - formats more suited to these functions. In particular, a - host MUST provide a DNS interface to facilitate translation - between host addresses and host names. - - 6.1.4.3 Interface Abbreviation Facilities - - User interfaces MAY provide a method for users to enter - abbreviations for commonly-used names. Although the - definition of such methods is outside of the scope of the - DNS specification, certain rules are necessary to insure - that these methods allow access to the entire DNS name space - and to prevent excessive use of Internet resources. - - If an abbreviation method is provided, then: - - (a) There MUST be some convention for denoting that a name - is already complete, so that the abbreviation method(s) - are suppressed. A trailing dot is the usual method. - - (b) Abbreviation expansion MUST be done exactly once, and - MUST be done in the context in which the name was - entered. - - - DISCUSSION: - For example, if an abbreviation is used in a mail - program for a destination, the abbreviation should be - expanded into a full domain name and stored in the - queued message with an indication that it is already - complete. Otherwise, the abbreviation might be - expanded with a mail system search list, not the - user's, or a name could grow due to repeated - canonicalizations attempts interacting with wildcards. - - The two most common abbreviation methods are: - - (1) Interface-level aliases - - Interface-level aliases are conceptually implemented as - a list of alias/domain name pairs. The list can be - per-user or per-host, and separate lists can be - associated with different functions, e.g. one list for - host name-to-address translation, and a different list - for mail domains. When the user enters a name, the - interface attempts to match the name to the alias - component of a list entry, and if a matching entry can - - - -Internet Engineering Task Force [Page 82] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - be found, the name is replaced by the domain name found - in the pair. - - Note that interface-level aliases and CNAMEs are - completely separate mechanisms; interface-level aliases - are a local matter while CNAMEs are an Internet-wide - aliasing mechanism which is a required part of any DNS - implementation. - - (2) Search Lists - - A search list is conceptually implemented as an ordered - list of domain names. When the user enters a name, the - domain names in the search list are used as suffixes to - the user-supplied name, one by one, until a domain name - with the desired associated data is found, or the - search list is exhausted. Search lists often contain - the name of the local host's parent domain or other - ancestor domains. Search lists are often per-user or - per-process. - - It SHOULD be possible for an administrator to disable a - DNS search-list facility. Administrative denial may be - warranted in some cases, to prevent abuse of the DNS. - - There is danger that a search-list mechanism will - generate excessive queries to the root servers while - testing whether user input is a complete domain name, - lacking a final period to mark it as complete. A - search-list mechanism MUST have one of, and SHOULD have - both of, the following two provisions to prevent this: - - (a) The local resolver/name server can implement - caching of negative responses (see Section - 6.1.3.3). - - (b) The search list expander can require two or more - interior dots in a generated domain name before it - tries using the name in a query to non-local - domain servers, such as the root. - - DISCUSSION: - The intent of this requirement is to avoid - excessive delay for the user as the search list is - tested, and more importantly to prevent excessive - traffic to the root and other high-level servers. - For example, if the user supplied a name "X" and - the search list contained the root as a component, - - - -Internet Engineering Task Force [Page 83] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - a query would have to consult a root server before - the next search list alternative could be tried. - The resulting load seen by the root servers and - gateways near the root would be multiplied by the - number of hosts in the Internet. - - The negative caching alternative limits the effect - to the first time a name is used. The interior - dot rule is simpler to implement but can prevent - easy use of some top-level names. - - - 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|-----------|-|-|-|-|-|-- -GENERAL ISSUES | | | | | | | - | | | | | | | -Implement DNS name-to-address conversion |6.1.1 |x| | | | | -Implement DNS address-to-name conversion |6.1.1 |x| | | | | -Support conversions using host table |6.1.1 | | |x| | | -Properly handle RR with zero TTL |6.1.2.1 |x| | | | | -Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | | - Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | | -Unused fields zero |6.1.2.3 |x| | | | | -Use compression in responses |6.1.2.4 |x| | | | | - | | | | | | | -Include config info in responses |6.1.2.5 | | | | |x| -Support all well-known, class-indep. types |6.1.3.5 |x| | | | | -Easily expand type list |6.1.3.5 | |x| | | | -Load all RR types (except MD and MF) |6.1.3.6 |x| | | | | -Load MD or MF type |6.1.3.6 | | | | |x| -Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -RESOLVER ISSUES: | | | | | | | - | | | | | | | -Resolver support multiple concurrent requests |6.1.3.1 | |x| | | | -Full-service resolver: |6.1.3.1 | | |x| | | - Local caching |6.1.3.1 |x| | | | | - - - -Internet Engineering Task Force [Page 84] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Information in local cache times out |6.1.3.1 |x| | | | | - Configurable with starting info |6.1.3.1 | |x| | | | -Stub resolver: |6.1.3.1 | | |x| | | - Use redundant recursive name servers |6.1.3.1 |x| | | | | - Local caching |6.1.3.1 | | |x| | | - Information in local cache times out |6.1.3.1 |x| | | | | -Support for remote multi-homed hosts: | | | | | | | - Sort multiple addresses by preference list |6.1.3.4 | |x| | | | - | | | | | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -TRANSPORT PROTOCOLS: | | | | | | | - | | | | | | | -Support UDP queries |6.1.3.2 |x| | | | | -Support TCP queries |6.1.3.2 | |x| | | | - Send query using UDP first |6.1.3.2 |x| | | | |1 - Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | | -Name server limit TCP query resources |6.1.3.2 | | |x| | | - Punish unnecessary TCP query |6.1.3.2 | | | |x| | -Use truncated data as if it were not |6.1.3.2 | | | | |x| -Private agreement to use only TCP |6.1.3.2 | | |x| | | -Use TCP for zone transfers |6.1.3.2 |x| | | | | -TCP usage not block UDP queries |6.1.3.2 |x| | | | | -Support broadcast or multicast queries |6.1.3.2 | | |x| | | - RD bit set in query |6.1.3.2 | | | | |x| - RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | | - Send only as occasional probe for addr's |6.1.3.2 | |x| | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -RESOURCE USAGE: | | | | | | | - | | | | | | | -Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | | - Finite bounds per request |6.1.3.3 |x| | | | | -Failure after retries => soft error |6.1.3.3 |x| | | | | -Cache temporary failures |6.1.3.3 | |x| | | | -Cache negative responses |6.1.3.3 | |x| | | | -Retries use exponential backoff |6.1.3.3 | |x| | | | - Upper, lower bounds |6.1.3.3 | |x| | | | -Client handle Source Quench |6.1.3.3 | |x| | | | -Server ignore Source Quench |6.1.3.3 | | |x| | | ------------------------------------------------|-----------|-|-|-|-|-|-- -USER INTERFACE: | | | | | | | - | | | | | | | -All programs have access to DNS interface |6.1.4.2 |x| | | | | -Able to request all info for given name |6.1.4.2 |x| | | | | -Returns complete info or error |6.1.4.2 |x| | | | | -Special interfaces |6.1.4.2 | | |x| | | - Name<->Address translation |6.1.4.2 |x| | | | | - | | | | | | | -Abbreviation Facilities: |6.1.4.3 | | |x| | | - - - -Internet Engineering Task Force [Page 85] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Convention for complete names |6.1.4.3 |x| | | | | - Conversion exactly once |6.1.4.3 |x| | | | | - Conversion in proper context |6.1.4.3 |x| | | | | - Search list: |6.1.4.3 | | |x| | | - Administrator can disable |6.1.4.3 | |x| | | | - Prevention of excessive root queries |6.1.4.3 |x| | | | | - Both methods |6.1.4.3 | |x| | | | ------------------------------------------------|-----------|-|-|-|-|-|-- ------------------------------------------------|-----------|-|-|-|-|-|-- - -1. Unless there is private agreement between particular resolver and - particular server. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 86] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - 6.2 HOST INITIALIZATION - - 6.2.1 INTRODUCTION - - This section discusses the initialization of host software - across a connected network, or more generally across an - Internet path. This is necessary for a diskless host, and may - optionally be used for a host with disk drives. For a diskless - host, the initialization process is called "network booting" - and is controlled by a bootstrap program located in a boot ROM. - - To initialize a diskless host across the network, there are two - distinct phases: - - (1) Configure the IP layer. - - Diskless machines often have no permanent storage in which - to store network configuration information, so that - sufficient configuration information must be obtained - dynamically to support the loading phase that follows. - This information must include at least the IP addresses of - the host and of the boot server. To support booting - across a gateway, the address mask and a list of default - gateways are also required. - - (2) Load the host system code. - - During the loading phase, an appropriate file transfer - protocol is used to copy the system code across the - network from the boot server. - - A host with a disk may perform the first step, dynamic - configuration. This is important for microcomputers, whose - floppy disks allow network configuration information to be - mistakenly duplicated on more than one host. Also, - installation of new hosts is much simpler if they automatically - obtain their configuration information from a central server, - saving administrator time and decreasing the probability of - mistakes. - - 6.2.2 REQUIREMENTS - - 6.2.2.1 Dynamic Configuration - - A number of protocol provisions have been made for dynamic - configuration. - - o ICMP Information Request/Reply messages - - - -Internet Engineering Task Force [Page 87] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - This obsolete message pair was designed to allow a host - to find the number of the network it is on. - Unfortunately, it was useful only if the host already - knew the host number part of its IP address, - information that hosts requiring dynamic configuration - seldom had. - - o Reverse Address Resolution Protocol (RARP) [BOOT:4] - - RARP is a link-layer protocol for a broadcast medium - that allows a host to find its IP address given its - link layer address. Unfortunately, RARP does not work - across IP gateways and therefore requires a RARP server - on every network. In addition, RARP does not provide - any other configuration information. - - o ICMP Address Mask Request/Reply messages - - These ICMP messages allow a host to learn the address - mask for a particular network interface. - - o BOOTP Protocol [BOOT:2] - - This protocol allows a host to determine the IP - addresses of the local host and the boot server, the - name of an appropriate boot file, and optionally the - address mask and list of default gateways. To locate a - BOOTP server, the host broadcasts a BOOTP request using - UDP. Ad hoc gateway extensions have been used to - transmit the BOOTP broadcast through gateways, and in - the future the IP Multicasting facility will provide a - standard mechanism for this purpose. - - - The suggested approach to dynamic configuration is to use - the BOOTP protocol with the extensions defined in "BOOTP - Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 - defines some important general (not vendor-specific) - extensions. In particular, these extensions allow the - address mask to be supplied in BOOTP; we RECOMMEND that the - address mask be supplied in this manner. - - DISCUSSION: - Historically, subnetting was defined long after IP, and - so a separate mechanism (ICMP Address Mask messages) - was designed to supply the address mask to a host. - However, the IP address mask and the corresponding IP - address conceptually form a pair, and for operational - - - -Internet Engineering Task Force [Page 88] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - simplicity they ought to be defined at the same time - and by the same mechanism, whether a configuration file - or a dynamic mechanism like BOOTP. - - Note that BOOTP is not sufficiently general to specify - the configurations of all interfaces of a multihomed - host. A multihomed host must either use BOOTP - separately for each interface, or configure one - interface using BOOTP to perform the loading, and - perform the complete initialization from a file later. - - Application layer configuration information is expected - to be obtained from files after loading of the system - code. - - 6.2.2.2 Loading Phase - - A suggested approach for the loading phase is to use TFTP - [BOOT:1] between the IP addresses established by BOOTP. - - TFTP to a broadcast address SHOULD NOT be used, for reasons - explained in Section 4.2.3.4. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 89] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - 6.3 REMOTE MANAGEMENT - - 6.3.1 INTRODUCTION - - The Internet community has recently put considerable effort - into the development of network management protocols. The - result has been a two-pronged approach [MGT:1, MGT:6]: the - Simple Network Management Protocol (SNMP) [MGT:4] and the - Common Management Information Protocol over TCP (CMOT) [MGT:5]. - - In order to be managed using SNMP or CMOT, a host will need to - implement an appropriate management agent. An Internet host - SHOULD include an agent for either SNMP or CMOT. - - Both SNMP and CMOT operate on a Management Information Base - (MIB) that defines a collection of management values. By - reading and setting these values, a remote application may - query and change the state of the managed system. - - A standard MIB [MGT:3] has been defined for use by both - management protocols, using data types defined by the Structure - of Management Information (SMI) defined in [MGT:2]. Additional - MIB variables can be introduced under the "enterprises" and - "experimental" subtrees of the MIB naming space [MGT:2]. - - Every protocol module in the host SHOULD implement the relevant - MIB variables. A host SHOULD implement the MIB variables as - defined in the most recent standard MIB, and MAY implement - other MIB variables when appropriate and useful. - - 6.3.2 PROTOCOL WALK-THROUGH - - The MIB is intended to cover both hosts and gateways, although - there may be detailed differences in MIB application to the two - cases. This section contains the appropriate interpretation of - the MIB for hosts. It is likely that later versions of the MIB - will include more entries for host management. - - A managed host must implement the following groups of MIB - object definitions: System, Interfaces, Address Translation, - IP, ICMP, TCP, and UDP. - - The following specific interpretations apply to hosts: - - o ipInHdrErrors - - Note that the error "time-to-live exceeded" can occur in a - host only when it is forwarding a source-routed datagram. - - - -Internet Engineering Task Force [Page 90] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - o ipOutNoRoutes - - This object counts datagrams discarded because no route - can be found. This may happen in a host if all the - default gateways in the host's configuration are down. - - o ipFragOKs, ipFragFails, ipFragCreates - - A host that does not implement intentional fragmentation - (see "Fragmentation" section of [INTRO:1]) MUST return the - value zero for these three objects. - - o icmpOutRedirects - - For a host, this object MUST always be zero, since hosts - do not send Redirects. - - o icmpOutAddrMaskReps - - For a host, this object MUST always be zero, unless the - host is an authoritative source of address mask - information. - - o ipAddrTable - - For a host, the "IP Address Table" object is effectively a - table of logical interfaces. - - o ipRoutingTable - - For a host, the "IP Routing Table" object is effectively a - combination of the host's Routing Cache and the static - route table described in "Routing Outbound Datagrams" - section of [INTRO:1]. - - Within 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". - - If destinations on the connected network do not appear in - the Route Cache (see "Routing Outbound Datagrams section - of [INTRO:1]), there will be no entries with ipRouteType - of "direct". - - - DISCUSSION: - The current MIB does not include Type-of-Service in an - ipRouteEntry, but a future revision is expected to make - - - -Internet Engineering Task Force [Page 91] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - this addition. - - We also expect the MIB to be expanded to allow the remote - management of applications (e.g., the ability to partially - reconfigure mail systems). Network service applications - such as mail systems should therefore be written with the - "hooks" for remote management. - - 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|-----------|-|-|-|-|-|-- -Support SNMP or CMOT agent |6.3.1 | |x| | | | -Implement specified objects in standard MIB |6.3.1 | |x| | | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 92] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - -7. REFERENCES - - This section lists the primary references with which every - implementer must be thoroughly familiar. It also lists some - secondary references that are suggested additional reading. - - INTRODUCTORY REFERENCES: - - - [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," - IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, - October 1989. - - [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, - (three volumes), SRI International, December 1985. - - [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, - RFC-1011, May 1987. - - This document is republished periodically with new RFC numbers; - the latest version must be used. - - [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. - Postel, RFC-980, March 1986. - - [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, - May 1987. - - This document is republished periodically with new RFC numbers; - the latest version must be used. - - - TELNET REFERENCES: - - - [TELNET:1] "Telnet Protocol Specification," J. Postel and J. - Reynolds, RFC-854, May 1983. - - [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, - RFC-855, May 1983. - - [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, - RFC-856, May 1983. - - [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, - May 1983. - - [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. - - - -Internet Engineering Task Force [Page 93] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - Reynolds, RFC-858, May 1983. - - [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC- - 859, May 1983. - - [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, - RFC-860, May 1983. - - [TELNET:8] "Telnet Extended Options List," J. Postel and J. - Reynolds, RFC-861, May 1983. - - [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, - December 1983. - - [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, - February 1989. - - This document supercedes RFC-930. - - [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, - October 1988. - - [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August - 1989. - - [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, - December 1988. - - [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC- - 1080, November 1988. - - - SECONDARY TELNET REFERENCES: - - - [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of - Defense, May 1984. - - This document is intended to describe the same protocol as RFC- - 854. In case of conflict, RFC-854 takes precedence, and the - present document takes precedence over both. - - [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. - - [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October - 1977. - - [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. - - - -Internet Engineering Task Force [Page 94] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS - Implementation," A. Yasuda and T. Thompson, RFC-1043, February - 1988. - - - FTP REFERENCES: - - - [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- - 959, October 1985. - - [FTP:2] "Document File Format Standards," J. Postel, RFC-678, - December 1974. - - [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of - Defense, May 1984. - - This document is based on an earlier version of the FTP - specification (RFC-765) and is obsolete. - - - TFTP REFERENCES: - - - [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June - 1981. - - - MAIL REFERENCES: - - - [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August - 1982. - - [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," - D. Crocker, RFC-822, August 1982. - - This document obsoleted an earlier specification, RFC-733. - - [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- - 974, January 1986. - - This RFC describes the use of MX records, a mandatory extension - to the mail delivery process. - - [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, - February 1988. - - - - -Internet Engineering Task Force [Page 95] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, - June 1986. - - [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. - - The two preceding RFC's define a proposed standard for - gatewaying mail between the Internet and the X.400 environments. - - [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. - Department of Defense, May 1984. - - This specification is intended to describe the same protocol as - does RFC-821. However, MIL-STD-1781 is incomplete; in - particular, it does not include MX records [SMTP:3]. - - [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, - RFC-1049, March 1988. - - - DOMAIN NAME SYSTEM REFERENCES: - - - [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, - RFC-1034, November 1987. - - This document and the following one obsolete RFC-882, RFC-883, - and RFC-973. - - [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, - P. Mockapetris, November 1987. - - - [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, - January 1986. - - - [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, - RFC-952, M. Stahl, E. Feinler, October 1985. - - SECONDARY DNS REFERENCES: - - - [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, - RFC-953, October 1985. - - [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November - 1987. - - - - -Internet Engineering Task Force [Page 96] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- - 1033, November 1987. - - [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet - Protocol Handbook, NIC 50007, SRI Network Information Center, - August 1989. - - - SYSTEM INITIALIZATION REFERENCES: - - - [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June - 1984. - - [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- - 951, September 1985. - - [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- - 1084, December 1988. - - Note: this RFC revised and obsoleted RFC-1048. - - [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. - Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. - - - MANAGEMENT REFERENCES: - - - [MGT:1] "IAB Recommendations for the Development of Internet Network - Management Standards," V. Cerf, RFC-1052, April 1988. - - [MGT:2] "Structure and Identification of Management Information for - TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, - August 1988. - - [MGT:3] "Management Information Base for Network Management of - TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, - August 1988. - - [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, - M. Schoffstall, and C. Davin, RFC-1098, April 1989. - - [MGT:5] "The Common Management Information Services and Protocol - over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. - - [MGT:6] "Report of the Second Ad Hoc Network Management Review - Group," V. Cerf, RFC-1109, August 1989. - - - -Internet Engineering Task Force [Page 97] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - -Security Considerations - - There are many security issues in the application and support - programs of host software, but a full discussion is beyond the scope - of this RFC. Security-related issues are mentioned in sections - concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and - EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the - SMTP DATA command (Section 5.2.8). - -Author's Address - - Robert Braden - USC/Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, CA 90292-6695 - - Phone: (213) 822 1511 - - EMail: Braden@ISI.EDU - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 98] - |