7 Network Working Group Internet Engineering Task Force
8 Request for Comments: 1123 R. Braden, Editor
12 Requirements for Internet Hosts -- Application and Support
16 This RFC is an official specification for the Internet community. It
17 incorporates by reference, amends, corrects, and supplements the
18 primary protocol standards documents relating to hosts. Distribution
19 of this document is unlimited.
23 This RFC is one of a pair that defines and discusses the requirements
24 for Internet host software. This RFC covers the application and
25 support protocols; its companion RFC-1122 covers the communication
26 protocol layers: link layer, IP layer, and transport layer.
35 1. INTRODUCTION ............................................... 5
36 1.1 The Internet Architecture .............................. 6
37 1.2 General Considerations ................................. 6
38 1.2.1 Continuing Internet Evolution ..................... 6
39 1.2.2 Robustness Principle .............................. 7
40 1.2.3 Error Logging ..................................... 8
41 1.2.4 Configuration ..................................... 8
42 1.3 Reading this Document .................................. 10
43 1.3.1 Organization ...................................... 10
44 1.3.2 Requirements ...................................... 10
45 1.3.3 Terminology ....................................... 11
46 1.4 Acknowledgments ........................................ 12
48 2. GENERAL ISSUES ............................................. 13
49 2.1 Host Names and Numbers ................................. 13
50 2.2 Using Domain Name Service .............................. 13
51 2.3 Applications on Multihomed hosts ....................... 14
52 2.4 Type-of-Service ........................................ 14
53 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15
58 Internet Engineering Task Force [Page 1]
63 RFC1123 INTRODUCTION October 1989
66 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16
67 3.1 INTRODUCTION ........................................... 16
68 3.2 PROTOCOL WALK-THROUGH .................................. 16
69 3.2.1 Option Negotiation ................................ 16
70 3.2.2 Telnet Go-Ahead Function .......................... 16
71 3.2.3 Control Functions ................................. 17
72 3.2.4 Telnet "Synch" Signal ............................. 18
73 3.2.5 NVT Printer and Keyboard .......................... 19
74 3.2.6 Telnet Command Structure .......................... 20
75 3.2.7 Telnet Binary Option .............................. 20
76 3.2.8 Telnet Terminal-Type Option ....................... 20
77 3.3 SPECIFIC ISSUES ........................................ 21
78 3.3.1 Telnet End-of-Line Convention ..................... 21
79 3.3.2 Data Entry Terminals .............................. 23
80 3.3.3 Option Requirements ............................... 24
81 3.3.4 Option Initiation ................................. 24
82 3.3.5 Telnet Linemode Option ............................ 25
83 3.4 TELNET/USER INTERFACE .................................. 25
84 3.4.1 Character Set Transparency ........................ 25
85 3.4.2 Telnet Commands ................................... 26
86 3.4.3 TCP Connection Errors ............................. 26
87 3.4.4 Non-Default Telnet Contact Port ................... 26
88 3.4.5 Flushing Output ................................... 26
89 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27
91 4. FILE TRANSFER .............................................. 29
92 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29
93 4.1.1 INTRODUCTION ...................................... 29
94 4.1.2. PROTOCOL WALK-THROUGH ............................ 29
95 4.1.2.1 LOCAL Type ................................... 29
96 4.1.2.2 Telnet Format Control ........................ 30
97 4.1.2.3 Page Structure ............................... 30
98 4.1.2.4 Data Structure Transformations ............... 30
99 4.1.2.5 Data Connection Management ................... 31
100 4.1.2.6 PASV Command ................................. 31
101 4.1.2.7 LIST and NLST Commands ....................... 31
102 4.1.2.8 SITE Command ................................. 32
103 4.1.2.9 STOU Command ................................. 32
104 4.1.2.10 Telnet End-of-line Code ..................... 32
105 4.1.2.11 FTP Replies ................................. 33
106 4.1.2.12 Connections ................................. 34
107 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34
108 4.1.3 SPECIFIC ISSUES ................................... 35
109 4.1.3.1 Non-standard Command Verbs ................... 35
110 4.1.3.2 Idle Timeout ................................. 36
111 4.1.3.3 Concurrency of Data and Control .............. 36
112 4.1.3.4 FTP Restart Mechanism ........................ 36
113 4.1.4 FTP/USER INTERFACE ................................ 39
117 Internet Engineering Task Force [Page 2]
122 RFC1123 INTRODUCTION October 1989
125 4.1.4.1 Pathname Specification ....................... 39
126 4.1.4.2 "QUOTE" Command .............................. 40
127 4.1.4.3 Displaying Replies to User ................... 40
128 4.1.4.4 Maintaining Synchronization .................. 40
129 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41
130 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44
131 4.2.1 INTRODUCTION ...................................... 44
132 4.2.2 PROTOCOL WALK-THROUGH ............................. 44
133 4.2.2.1 Transfer Modes ............................... 44
134 4.2.2.2 UDP Header ................................... 44
135 4.2.3 SPECIFIC ISSUES ................................... 44
136 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44
137 4.2.3.2 Timeout Algorithms ........................... 46
138 4.2.3.3 Extensions ................................... 46
139 4.2.3.4 Access Control ............................... 46
140 4.2.3.5 Broadcast Request ............................ 46
141 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47
143 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48
144 5.1 INTRODUCTION ........................................... 48
145 5.2 PROTOCOL WALK-THROUGH .................................. 48
146 5.2.1 The SMTP Model .................................... 48
147 5.2.2 Canonicalization .................................. 49
148 5.2.3 VRFY and EXPN Commands ............................ 50
149 5.2.4 SEND, SOML, and SAML Commands ..................... 50
150 5.2.5 HELO Command ...................................... 50
151 5.2.6 Mail Relay ........................................ 51
152 5.2.7 RCPT Command ...................................... 52
153 5.2.8 DATA Command ...................................... 53
154 5.2.9 Command Syntax .................................... 54
155 5.2.10 SMTP Replies ..................................... 54
156 5.2.11 Transparency ..................................... 55
157 5.2.12 WKS Use in MX Processing ......................... 55
158 5.2.13 RFC-822 Message Specification .................... 55
159 5.2.14 RFC-822 Date and Time Specification .............. 55
160 5.2.15 RFC-822 Syntax Change ............................ 56
161 5.2.16 RFC-822 Local-part .............................. 56
162 5.2.17 Domain Literals .................................. 57
163 5.2.18 Common Address Formatting Errors ................. 58
164 5.2.19 Explicit Source Routes ........................... 58
165 5.3 SPECIFIC ISSUES ........................................ 59
166 5.3.1 SMTP Queueing Strategies .......................... 59
167 5.3.1.1 Sending Strategy .............................. 59
168 5.3.1.2 Receiving strategy ........................... 61
169 5.3.2 Timeouts in SMTP .................................. 61
170 5.3.3 Reliable Mail Receipt ............................. 63
171 5.3.4 Reliable Mail Transmission ........................ 63
172 5.3.5 Domain Name Support ............................... 65
176 Internet Engineering Task Force [Page 3]
181 RFC1123 INTRODUCTION October 1989
184 5.3.6 Mailing Lists and Aliases ......................... 65
185 5.3.7 Mail Gatewaying ................................... 66
186 5.3.8 Maximum Message Size .............................. 68
187 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69
189 6. SUPPORT SERVICES ............................................ 72
190 6.1 DOMAIN NAME TRANSLATION ................................. 72
191 6.1.1 INTRODUCTION ....................................... 72
192 6.1.2 PROTOCOL WALK-THROUGH ............................. 72
193 6.1.2.1 Resource Records with Zero TTL ............... 73
194 6.1.2.2 QCLASS Values ................................ 73
195 6.1.2.3 Unused Fields ................................ 73
196 6.1.2.4 Compression .................................. 73
197 6.1.2.5 Misusing Configuration Info .................. 73
198 6.1.3 SPECIFIC ISSUES ................................... 74
199 6.1.3.1 Resolver Implementation ...................... 74
200 6.1.3.2 Transport Protocols .......................... 75
201 6.1.3.3 Efficient Resource Usage ..................... 77
202 6.1.3.4 Multihomed Hosts ............................. 78
203 6.1.3.5 Extensibility ................................ 79
204 6.1.3.6 Status of RR Types ........................... 79
205 6.1.3.7 Robustness ................................... 80
206 6.1.3.8 Local Host Table ............................. 80
207 6.1.4 DNS USER INTERFACE ................................ 81
208 6.1.4.1 DNS Administration ........................... 81
209 6.1.4.2 DNS User Interface ........................... 81
210 6.1.4.3 Interface Abbreviation Facilities ............. 82
211 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84
212 6.2 HOST INITIALIZATION .................................... 87
213 6.2.1 INTRODUCTION ...................................... 87
214 6.2.2 REQUIREMENTS ...................................... 87
215 6.2.2.1 Dynamic Configuration ........................ 87
216 6.2.2.2 Loading Phase ................................ 89
217 6.3 REMOTE MANAGEMENT ...................................... 90
218 6.3.1 INTRODUCTION ...................................... 90
219 6.3.2 PROTOCOL WALK-THROUGH ............................. 90
220 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92
222 7. REFERENCES ................................................. 93
235 Internet Engineering Task Force [Page 4]
240 RFC1123 INTRODUCTION October 1989
245 This document is one of a pair that defines and discusses the
246 requirements for host system implementations of the Internet protocol
247 suite. This RFC covers the applications layer and support protocols.
248 Its companion RFC, "Requirements for Internet Hosts -- Communications
249 Layers" [INTRO:1] covers the lower layer protocols: transport layer,
250 IP layer, and link layer.
252 These documents are intended to provide guidance for vendors,
253 implementors, and users of Internet communication software. They
254 represent the consensus of a large body of technical experience and
255 wisdom, contributed by members of the Internet research and vendor
258 This RFC enumerates standard protocols that a host connected to the
259 Internet must use, and it incorporates by reference the RFCs and
260 other documents describing the current specifications for these
261 protocols. It corrects errors in the referenced documents and adds
262 additional discussion and guidance for an implementor.
264 For each protocol, this document also contains an explicit set of
265 requirements, recommendations, and options. The reader must
266 understand that the list of requirements in this document is
267 incomplete by itself; the complete set of requirements for an
268 Internet host is primarily defined in the standard protocol
269 specification documents, with the corrections, amendments, and
270 supplements contained in this RFC.
272 A good-faith implementation of the protocols that was produced after
273 careful reading of the RFC's and with some interaction with the
274 Internet technical community, and that followed good communications
275 software engineering practices, should differ from the requirements
276 of this document in only minor ways. Thus, in many cases, the
277 "requirements" in this RFC are already stated or implied in the
278 standard protocol documents, so that their inclusion here is, in a
279 sense, redundant. However, they were included because some past
280 implementation has made the wrong choice, causing problems of
281 interoperability, performance, and/or robustness.
283 This document includes discussion and explanation of many of the
284 requirements and recommendations. A simple list of requirements
285 would be dangerous, because:
287 o Some required features are more important than others, and some
288 features are optional.
290 o There may be valid reasons why particular vendor products that
294 Internet Engineering Task Force [Page 5]
299 RFC1123 INTRODUCTION October 1989
302 are designed for restricted contexts might choose to use
303 different specifications.
305 However, the specifications of this document must be followed to meet
306 the general goal of arbitrary host interoperation across the
307 diversity and complexity of the Internet system. Although most
308 current implementations fail to meet these requirements in various
309 ways, some minor and some major, this specification is the ideal
310 towards which we need to move.
312 These requirements are based on the current level of Internet
313 architecture. This document will be updated as required to provide
314 additional clarifications or to include additional information in
315 those areas in which specifications are still evolving.
317 This introductory section begins with general advice to host software
318 vendors, and then gives some guidance on reading the rest of the
319 document. Section 2 contains general requirements that may be
320 applicable to all application and support protocols. Sections 3, 4,
321 and 5 contain the requirements on protocols for the three major
322 applications: Telnet, file transfer, and electronic mail,
323 respectively. Section 6 covers the support applications: the domain
324 name system, system initialization, and management. Finally, all
325 references will be found in Section 7.
327 1.1 The Internet Architecture
329 For a brief introduction to the Internet architecture from a host
330 viewpoint, see Section 1.1 of [INTRO:1]. That section also
331 contains recommended references for general background on the
332 Internet architecture.
334 1.2 General Considerations
336 There are two important lessons that vendors of Internet host
337 software have learned and which a new vendor should consider
340 1.2.1 Continuing Internet Evolution
342 The enormous growth of the Internet has revealed problems of
343 management and scaling in a large datagram-based packet
344 communication system. These problems are being addressed, and
345 as a result there will be continuing evolution of the
346 specifications described in this document. These changes will
347 be carefully planned and controlled, since there is extensive
348 participation in this planning by the vendors and by the
349 organizations responsible for operations of the networks.
353 Internet Engineering Task Force [Page 6]
358 RFC1123 INTRODUCTION October 1989
361 Development, evolution, and revision are characteristic of
362 computer network protocols today, and this situation will
363 persist for some years. A vendor who develops computer
364 communication software for the Internet protocol suite (or any
365 other protocol suite!) and then fails to maintain and update
366 that software for changing specifications is going to leave a
367 trail of unhappy customers. The Internet is a large
368 communication network, and the users are in constant contact
369 through it. Experience has shown that knowledge of
370 deficiencies in vendor software propagates quickly through the
371 Internet technical community.
373 1.2.2 Robustness Principle
375 At every layer of the protocols, there is a general rule whose
376 application can lead to enormous benefits in robustness and
379 "Be liberal in what you accept, and
380 conservative in what you send"
382 Software should be written to deal with every conceivable
383 error, no matter how unlikely; sooner or later a packet will
384 come in with that particular combination of errors and
385 attributes, and unless the software is prepared, chaos can
386 ensue. In general, it is best to assume that the network is
387 filled with malevolent entities that will send in packets
388 designed to have the worst possible effect. This assumption
389 will lead to suitable protective design, although the most
390 serious problems in the Internet have been caused by
391 unenvisaged mechanisms triggered by low-probability events;
392 mere human malice would never have taken so devious a course!
394 Adaptability to change must be designed into all levels of
395 Internet host software. As a simple example, consider a
396 protocol specification that contains an enumeration of values
397 for a particular header field -- e.g., a type field, a port
398 number, or an error code; this enumeration must be assumed to
399 be incomplete. Thus, if a protocol specification defines four
400 possible error codes, the software must not break when a fifth
401 code shows up. An undefined code might be logged (see below),
402 but it must not cause a failure.
404 The second part of the principle is almost as important:
405 software on other hosts may contain deficiencies that make it
406 unwise to exploit legal but obscure protocol features. It is
407 unwise to stray far from the obvious and simple, lest untoward
408 effects result elsewhere. A corollary of this is "watch out
412 Internet Engineering Task Force [Page 7]
417 RFC1123 INTRODUCTION October 1989
420 for misbehaving hosts"; host software should be prepared, not
421 just to survive other misbehaving hosts, but also to cooperate
422 to limit the amount of disruption such hosts can cause to the
423 shared communication facility.
427 The Internet includes a great variety of host and gateway
428 systems, each implementing many protocols and protocol layers,
429 and some of these contain bugs and mis-features in their
430 Internet protocol software. As a result of complexity,
431 diversity, and distribution of function, the diagnosis of user
432 problems is often very difficult.
434 Problem diagnosis will be aided if host implementations include
435 a carefully designed facility for logging erroneous or
436 "strange" protocol events. It is important to include as much
437 diagnostic information as possible when an error is logged. In
438 particular, it is often useful to record the header(s) of a
439 packet that caused an error. However, care must be taken to
440 ensure that error logging does not consume prohibitive amounts
441 of resources or otherwise interfere with the operation of the
444 There is a tendency for abnormal but harmless protocol events
445 to overflow error logging files; this can be avoided by using a
446 "circular" log, or by enabling logging only while diagnosing a
447 known failure. It may be useful to filter and count duplicate
448 successive messages. One strategy that seems to work well is:
449 (1) always count abnormalities and make such counts accessible
450 through the management protocol (see Section 6.3); and (2)
451 allow the logging of a great variety of events to be
452 selectively enabled. For example, it might useful to be able
453 to "log everything" or to "log everything for host X".
455 Note that different managements may have differing policies
456 about the amount of error logging that they want normally
457 enabled in a host. Some will say, "if it doesn't hurt me, I
458 don't want to know about it", while others will want to take a
459 more watchful and aggressive attitude about detecting and
460 removing protocol abnormalities.
464 It would be ideal if a host implementation of the Internet
465 protocol suite could be entirely self-configuring. This would
466 allow the whole suite to be implemented in ROM or cast into
467 silicon, it would simplify diskless workstations, and it would
471 Internet Engineering Task Force [Page 8]
476 RFC1123 INTRODUCTION October 1989
479 be an immense boon to harried LAN administrators as well as
480 system vendors. We have not reached this ideal; in fact, we
483 At many points in this document, you will find a requirement
484 that a parameter be a configurable option. There are several
485 different reasons behind such requirements. In a few cases,
486 there is current uncertainty or disagreement about the best
487 value, and it may be necessary to update the recommended value
488 in the future. In other cases, the value really depends on
489 external factors -- e.g., the size of the host and the
490 distribution of its communication load, or the speeds and
491 topology of nearby networks -- and self-tuning algorithms are
492 unavailable and may be insufficient. In some cases,
493 configurability is needed because of administrative
496 Finally, some configuration options are required to communicate
497 with obsolete or incorrect implementations of the protocols,
498 distributed without sources, that unfortunately persist in many
499 parts of the Internet. To make correct systems coexist with
500 these faulty systems, administrators often have to "mis-
501 configure" the correct systems. This problem will correct
502 itself gradually as the faulty systems are retired, but it
503 cannot be ignored by vendors.
505 When we say that a parameter must be configurable, we do not
506 intend to require that its value be explicitly read from a
507 configuration file at every boot time. We recommend that
508 implementors set up a default for each parameter, so a
509 configuration file is only necessary to override those defaults
510 that are inappropriate in a particular installation. Thus, the
511 configurability requirement is an assurance that it will be
512 POSSIBLE to override the default when necessary, even in a
513 binary-only or ROM-based product.
515 This document requires a particular value for such defaults in
516 some cases. The choice of default is a sensitive issue when
517 the configuration item controls the accommodation to existing
518 faulty systems. If the Internet is to converge successfully to
519 complete interoperability, the default values built into
520 implementations must implement the official protocol, not
521 "mis-configurations" to accommodate faulty implementations.
522 Although marketing considerations have led some vendors to
523 choose mis-configuration defaults, we urge vendors to choose
524 defaults that will conform to the standard.
526 Finally, we note that a vendor needs to provide adequate
530 Internet Engineering Task Force [Page 9]
535 RFC1123 INTRODUCTION October 1989
538 documentation on all configuration parameters, their limits and
542 1.3 Reading this Document
546 In general, each major section is organized into the following
551 (2) Protocol Walk-Through -- considers the protocol
552 specification documents section-by-section, correcting
553 errors, stating requirements that may be ambiguous or
554 ill-defined, and providing further clarification or
557 (3) Specific Issues -- discusses protocol design and
558 implementation issues that were not included in the walk-
561 (4) Interfaces -- discusses the service interface to the next
564 (5) Summary -- contains a summary of the requirements of the
567 Under many of the individual topics in this document, there is
568 parenthetical material labeled "DISCUSSION" or
569 "IMPLEMENTATION". This material is intended to give
570 clarification and explanation of the preceding requirements
571 text. It also includes some suggestions on possible future
572 directions or developments. The implementation material
573 contains suggested approaches that an implementor may want to
576 The summary sections are intended to be guides and indexes to
577 the text, but are necessarily cryptic and incomplete. The
578 summaries should never be used or referenced separately from
583 In this document, the words that are used to define the
584 significance of each particular requirement are capitalized.
589 Internet Engineering Task Force [Page 10]
594 RFC1123 INTRODUCTION October 1989
599 This word or the adjective "REQUIRED" means that the item
600 is an absolute requirement of the specification.
604 This word or the adjective "RECOMMENDED" means that there
605 may exist valid reasons in particular circumstances to
606 ignore this item, but the full implications should be
607 understood and the case carefully weighed before choosing
612 This word or the adjective "OPTIONAL" means that this item
613 is truly optional. One vendor may choose to include the
614 item because a particular marketplace requires it or
615 because it enhances the product, for example; another
616 vendor may omit the same item.
619 An implementation is not compliant if it fails to satisfy one
620 or more of the MUST requirements for the protocols it
621 implements. An implementation that satisfies all the MUST and
622 all the SHOULD requirements for its protocols is said to be
623 "unconditionally compliant"; one that satisfies all the MUST
624 requirements but not all the SHOULD requirements for its
625 protocols is said to be "conditionally compliant".
629 This document uses the following technical terms:
632 A segment is the unit of end-to-end transmission in the
633 TCP protocol. A segment consists of a TCP header followed
634 by application data. A segment is transmitted by
635 encapsulation in an IP datagram.
638 This term is used by some application layer protocols
639 (particularly SMTP) for an application data unit.
642 A [UDP] datagram is the unit of end-to-end transmission in
648 Internet Engineering Task Force [Page 11]
653 RFC1123 INTRODUCTION October 1989
657 A host is said to be multihomed if it has multiple IP
658 addresses to connected networks.
664 This document incorporates contributions and comments from a large
665 group of Internet protocol experts, including representatives of
666 university and research labs, vendors, and government agencies.
667 It was assembled primarily by the Host Requirements Working Group
668 of the Internet Engineering Task Force (IETF).
670 The Editor would especially like to acknowledge the tireless
671 dedication of the following people, who attended many long
672 meetings and generated 3 million bytes of electronic mail over the
673 past 18 months in pursuit of this document: Philip Almquist, Dave
674 Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
675 Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
676 John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
677 Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
678 (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
680 In addition, the following people made major contributions to the
681 effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
682 (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
683 Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
684 John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
685 Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
686 (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
687 Technology), and Mike StJohns (DCA). The following also made
688 significant contributions to particular areas: Eric Allman
689 (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
690 (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
691 (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
692 (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
693 Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
696 We are grateful to all, including any contributors who may have
697 been inadvertently omitted from this list.
707 Internet Engineering Task Force [Page 12]
712 RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
717 This section contains general requirements that may be applicable to
718 all application-layer protocols.
720 2.1 Host Names and Numbers
722 The syntax of a legal Internet host name was specified in RFC-952
723 [DNS:4]. One aspect of host name syntax is hereby changed: the
724 restriction on the first character is relaxed to allow either a
725 letter or a digit. Host software MUST support this more liberal
728 Host software MUST handle host names of up to 63 characters and
729 SHOULD handle host names of up to 255 characters.
731 Whenever a user inputs the identity of an Internet host, it SHOULD
732 be possible to enter either (1) a host domain name or (2) an IP
733 address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
734 the string syntactically for a dotted-decimal number before
735 looking it up in the Domain Name System.
738 This last requirement is not intended to specify the complete
739 syntactic form for entering a dotted-decimal host number;
740 that is considered to be a user-interface issue. For
741 example, a dotted-decimal number must be enclosed within
742 "[ ]" brackets for SMTP mail (see Section 5.2.17). This
743 notation could be made universal within a host system,
744 simplifying the syntactic checking for a dotted-decimal
747 If a dotted-decimal number can be entered without such
748 identifying delimiters, then a full syntactic check must be
749 made, because a segment of a host domain name is now allowed
750 to begin with a digit and could legally be entirely numeric
751 (see Section 6.1.2.4). However, a valid host name can never
752 have the dotted-decimal form #.#.#.#, since at least the
753 highest-level component label will be alphabetic.
755 2.2 Using Domain Name Service
757 Host domain names MUST be translated to IP addresses as described
760 Applications using domain name services MUST be able to cope with
761 soft error conditions. Applications MUST wait a reasonable
762 interval between successive retries due to a soft error, and MUST
766 Internet Engineering Task Force [Page 13]
771 RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
774 allow for the possibility that network problems may deny service
775 for hours or even days.
777 An application SHOULD NOT rely on the ability to locate a WKS
778 record containing an accurate listing of all services at a
779 particular host address, since the WKS RR type is not often used
780 by Internet sites. To confirm that a service is present, simply
783 2.3 Applications on Multihomed hosts
785 When the remote host is multihomed, the name-to-address
786 translation will return a list of alternative IP addresses. As
787 specified in Section 6.1.3.4, this list should be in order of
788 decreasing preference. Application protocol implementations
789 SHOULD be prepared to try multiple addresses from the list until
790 success is obtained. More specific requirements for SMTP are
791 given in Section 5.3.4.
793 When the local host is multihomed, a UDP-based request/response
794 application SHOULD send the response with an IP source address
795 that is the same as the specific destination address of the UDP
796 request datagram. The "specific destination address" is defined
797 in the "IP Addressing" section of the companion RFC [INTRO:1].
799 Similarly, a server application that opens multiple TCP
800 connections to the same client SHOULD use the same local IP
805 Applications MUST select appropriate TOS values when they invoke
806 transport layer services, and these values MUST be configurable.
807 Note that a TOS value contains 5 bits, of which only the most-
808 significant 3 bits are currently defined; the other two bits MUST
812 As gateway algorithms are developed to implement Type-of-
813 Service, the recommended values for various application
814 protocols may change. In addition, it is likely that
815 particular combinations of users and Internet paths will want
816 non-standard TOS values. For these reasons, the TOS values
817 must be configurable.
819 See the latest version of the "Assigned Numbers" RFC
820 [INTRO:5] for the recommended TOS values for the major
821 application protocols.
825 Internet Engineering Task Force [Page 14]
830 RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
833 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY
844 FEATURE |SECTION | | | |T|T|e
845 -----------------------------------------------|----------|-|-|-|-|-|--
847 User interfaces: | | | | | | |
848 Allow host name to begin with digit |2.1 |x| | | | |
849 Host names of up to 635 characters |2.1 |x| | | | |
850 Host names of up to 255 characters |2.1 | |x| | | |
851 Support dotted-decimal host numbers |2.1 | |x| | | |
852 Check syntactically for dotted-dec first |2.1 | |x| | | |
854 Map domain names per Section 6.1 |2.2 |x| | | | |
855 Cope with soft DNS errors |2.2 |x| | | | |
856 Reasonable interval between retries |2.2 |x| | | | |
857 Allow for long outages |2.2 |x| | | | |
858 Expect WKS records to be available |2.2 | | | |x| |
860 Try multiple addr's for remote multihomed host |2.3 | |x| | | |
861 UDP reply src addr is specific dest of request |2.3 | |x| | | |
862 Use same IP addr for related TCP connections |2.3 | |x| | | |
863 Specify appropriate TOS values |2.4 |x| | | | |
864 TOS values configurable |2.4 |x| | | | |
865 Unused TOS bits zero |2.4 |x| | | | |
884 Internet Engineering Task Force [Page 15]
889 RFC1123 REMOTE LOGIN -- TELNET October 1989
892 3. REMOTE LOGIN -- TELNET PROTOCOL
896 Telnet is the standard Internet application protocol for remote
897 login. It provides the encoding rules to link a user's
898 keyboard/display on a client ("user") system with a command
899 interpreter on a remote server system. A subset of the Telnet
900 protocol is also incorporated within other application protocols,
903 Telnet uses a single TCP connection, and its normal data stream
904 ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
905 escape sequences to embed control functions. Telnet also allows
906 the negotiation of many optional modes and functions.
908 The primary Telnet specification is to be found in RFC-854
909 [TELNET:1], while the options are defined in many other RFCs; see
910 Section 7 for references.
912 3.2 PROTOCOL WALK-THROUGH
914 3.2.1 Option Negotiation: RFC-854, pp. 2-3
916 Every Telnet implementation MUST include option negotiation and
917 subnegotiation machinery [TELNET:2].
919 A host MUST carefully follow the rules of RFC-854 to avoid
920 option-negotiation loops. A host MUST refuse (i.e, reply
921 WONT/DONT to a DO/WILL) an unsupported option. Option
922 negotiation SHOULD continue to function (even if all requests
923 are refused) throughout the lifetime of a Telnet connection.
925 If all option negotiations fail, a Telnet implementation MUST
926 default to, and support, an NVT.
929 Even though more sophisticated "terminals" and supporting
930 option negotiations are becoming the norm, all
931 implementations must be prepared to support an NVT for any
932 user-server communication.
934 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
936 On a host that never sends the Telnet command Go Ahead (GA),
937 the Telnet Server MUST attempt to negotiate the Suppress Go
938 Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or
939 Server Telnet MUST always accept negotiation of the Suppress Go
943 Internet Engineering Task Force [Page 16]
948 RFC1123 REMOTE LOGIN -- TELNET October 1989
953 When it is driving a full-duplex terminal for which GA has no
954 meaning, a User Telnet implementation MAY ignore GA commands.
957 Half-duplex ("locked-keyboard") line-at-a-time terminals
958 for which the Go-Ahead mechanism was designed have largely
959 disappeared from the scene. It turned out to be difficult
960 to implement sending the Go-Ahead signal in many operating
961 systems, even some systems that support native half-duplex
962 terminals. The difficulty is typically that the Telnet
963 server code does not have access to information about
964 whether the user process is blocked awaiting input from
965 the Telnet connection, i.e., it cannot reliably determine
966 when to send a GA command. Therefore, most Telnet Server
967 hosts do not send GA commands.
969 The effect of the rules in this section is to allow either
970 end of a Telnet connection to veto the use of GA commands.
972 There is a class of half-duplex terminals that is still
973 commercially important: "data entry terminals," which
974 interact in a full-screen manner. However, supporting
975 data entry terminals using the Telnet protocol does not
976 require the Go Ahead signal; see Section 3.3.2.
978 3.2.3 Control Functions: RFC-854, pp. 7-8
980 The list of Telnet commands has been extended to include EOR
981 (End-of-Record), with code 239 [TELNET:9].
983 Both User and Server Telnets MAY support the control functions
984 EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
987 A host MUST be able to receive and ignore any Telnet control
988 functions that it does not support.
991 Note that a Server Telnet is required to support the
992 Telnet IP (Interrupt Process) function, even if the server
993 host has an equivalent in-stream function (e.g., Control-C
994 in many systems). The Telnet IP function may be stronger
995 than an in-stream interrupt command, because of the out-
996 of-band effect of TCP urgent data.
998 The EOR control function may be used to delimit the
1002 Internet Engineering Task Force [Page 17]
1007 RFC1123 REMOTE LOGIN -- TELNET October 1989
1010 stream. An important application is data entry terminal
1011 support (see Section 3.3.2). There was concern that since
1012 EOR had not been defined in RFC-854, a host that was not
1013 prepared to correctly ignore unknown Telnet commands might
1014 crash if it received an EOR. To protect such hosts, the
1015 End-of-Record option [TELNET:9] was introduced; however, a
1016 properly implemented Telnet program will not require this
1019 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10
1021 When it receives "urgent" TCP data, a User or Server Telnet
1022 MUST discard all data except Telnet commands until the DM (and
1023 end of urgent) is reached.
1025 When it sends Telnet IP (Interrupt Process), a User Telnet
1026 SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
1027 TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent
1028 pointer points to the DM octet.
1030 When it receives a Telnet IP command, a Server Telnet MAY send
1031 a Telnet "Synch" sequence back to the user, to flush the output
1032 stream. The choice ought to be consistent with the way the
1033 server operating system behaves when a local user interrupts a
1036 When it receives a Telnet AO command, a Server Telnet MUST send
1037 a Telnet "Synch" sequence back to the user, to flush the output
1040 A User Telnet SHOULD have the capability of flushing output
1041 when it sends a Telnet IP; see also Section 3.4.5.
1044 There are three possible ways for a User Telnet to flush
1045 the stream of server output data:
1047 (1) Send AO after IP.
1049 This will cause the server host to send a "flush-
1050 buffered-output" signal to its operating system.
1051 However, the AO may not take effect locally, i.e.,
1052 stop terminal output at the User Telnet end, until
1053 the Server Telnet has received and processed the AO
1054 and has sent back a "Synch".
1056 (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard
1057 all output locally until a WILL/WONT TIMING-MARK is
1061 Internet Engineering Task Force [Page 18]
1066 RFC1123 REMOTE LOGIN -- TELNET October 1989
1069 received from the Server Telnet.
1071 Since the DO TIMING-MARK will be processed after the
1072 IP at the server, the reply to it should be in the
1073 right place in the output data stream. However, the
1074 TIMING-MARK will not send a "flush buffered output"
1075 signal to the server operating system. Whether or
1076 not this is needed is dependent upon the server
1081 The best method is not entirely clear, since it must
1082 accommodate a number of existing server hosts that do not
1083 follow the Telnet standards in various ways. The safest
1084 approach is probably to provide a user-controllable option
1085 to select (1), (2), or (3).
1087 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11
1089 In NVT mode, a Telnet SHOULD NOT send characters with the
1090 high-order bit 1, and MUST NOT send it as a parity bit.
1091 Implementations that pass the high-order bit to applications
1092 SHOULD negotiate binary mode (see Section 3.2.6).
1096 Implementors should be aware that a strict reading of
1097 RFC-854 allows a client or server expecting NVT ASCII to
1098 ignore characters with the high-order bit set. In
1099 general, binary mode is expected to be used for
1100 transmission of an extended (beyond 7-bit) character set
1103 However, there exist applications that really need an 8-
1104 bit NVT mode, which is currently not defined, and these
1105 existing applications do set the high-order bit during
1106 part or all of the life of a Telnet connection. Note that
1107 binary mode is not the same as 8-bit NVT mode, since
1108 binary mode turns off end-of-line processing. For this
1109 reason, the requirements on the high-order bit are stated
1110 as SHOULD, not MUST.
1112 RFC-854 defines a minimal set of properties of a "network
1113 virtual terminal" or NVT; this is not meant to preclude
1114 additional features in a real terminal. A Telnet
1115 connection is fully transparent to all 7-bit ASCII
1116 characters, including arbitrary ASCII control characters.
1120 Internet Engineering Task Force [Page 19]
1125 RFC1123 REMOTE LOGIN -- TELNET October 1989
1128 For example, a terminal might support full-screen commands
1129 coded as ASCII escape sequences; a Telnet implementation
1130 would pass these sequences as uninterpreted data. Thus,
1131 an NVT should not be conceived as a terminal type of a
1132 highly-restricted device.
1134 3.2.6 Telnet Command Structure: RFC-854, p. 13
1136 Since options may appear at any point in the data stream, a
1137 Telnet escape character (known as IAC, with the value 255) to
1138 be sent as data MUST be doubled.
1140 3.2.7 Telnet Binary Option: RFC-856
1142 When the Binary option has been successfully negotiated,
1143 arbitrary 8-bit characters are allowed. However, the data
1144 stream MUST still be scanned for IAC characters, any embedded
1145 Telnet commands MUST be obeyed, and data bytes equal to IAC
1146 MUST be doubled. Other character processing (e.g., replacing
1147 CR by CR NUL or by CR LF) MUST NOT be done. In particular,
1148 there is no end-of-line convention (see Section 3.3.1) in
1152 The Binary option is normally negotiated in both
1153 directions, to change the Telnet connection from NVT mode
1156 The sequence IAC EOR can be used to delimit blocks of data
1157 within a binary-mode Telnet stream.
1159 3.2.8 Telnet Terminal-Type Option: RFC-1091
1161 The Terminal-Type option MUST use the terminal type names
1162 officially defined in the Assigned Numbers RFC [INTRO:5], when
1163 they are available for the particular terminal. However, the
1164 receiver of a Terminal-Type option MUST accept any name.
1167 RFC-1091 [TELNET:10] updates an earlier version of the
1168 Terminal-Type option defined in RFC-930. The earlier
1169 version allowed a server host capable of supporting
1170 multiple terminal types to learn the type of a particular
1171 client's terminal, assuming that each physical terminal
1172 had an intrinsic type. However, today a "terminal" is
1173 often really a terminal emulator program running in a PC,
1174 perhaps capable of emulating a range of terminal types.
1175 Therefore, RFC-1091 extends the specification to allow a
1179 Internet Engineering Task Force [Page 20]
1184 RFC1123 REMOTE LOGIN -- TELNET October 1989
1187 more general terminal-type negotiation between User and
1192 3.3.1 Telnet End-of-Line Convention
1194 The Telnet protocol defines the sequence CR LF to mean "end-
1195 of-line". For terminal input, this corresponds to a command-
1196 completion or "end-of-line" key being pressed on a user
1197 terminal; on an ASCII terminal, this is the CR key, but it may
1198 also be labelled "Return" or "Enter".
1200 When a Server Telnet receives the Telnet end-of-line sequence
1201 CR LF as input from a remote terminal, the effect MUST be the
1202 same as if the user had pressed the "end-of-line" key on a
1203 local terminal. On server hosts that use ASCII, in particular,
1204 receipt of the Telnet sequence CR LF must cause the same effect
1205 as a local user pressing the CR key on a local terminal. Thus,
1206 CR LF and CR NUL MUST have the same effect on an ASCII server
1207 host when received as input over a Telnet connection.
1209 A User Telnet MUST be able to send any of the forms: CR LF, CR
1210 NUL, and LF. A User Telnet on an ASCII host SHOULD have a
1211 user-controllable mode to send either CR LF or CR NUL when the
1212 user presses the "end-of-line" key, and CR LF SHOULD be the
1215 The Telnet end-of-line sequence CR LF MUST be used to send
1216 Telnet data that is not terminal-to-computer (e.g., for Server
1217 Telnet sending output, or the Telnet protocol incorporated
1218 another application protocol).
1221 To allow interoperability between arbitrary Telnet clients
1222 and servers, the Telnet protocol defined a standard
1223 representation for a line terminator. Since the ASCII
1224 character set includes no explicit end-of-line character,
1225 systems have chosen various representations, e.g., CR, LF,
1226 and the sequence CR LF. The Telnet protocol chose the CR
1227 LF sequence as the standard for network transmission.
1229 Unfortunately, the Telnet protocol specification in RFC-
1230 854 [TELNET:1] has turned out to be somewhat ambiguous on
1231 what character(s) should be sent from client to server for
1232 the "end-of-line" key. The result has been a massive and
1233 continuing interoperability headache, made worse by
1234 various faulty implementations of both User and Server
1238 Internet Engineering Task Force [Page 21]
1243 RFC1123 REMOTE LOGIN -- TELNET October 1989
1248 Although the Telnet protocol is based on a perfectly
1249 symmetric model, in a remote login session the role of the
1250 user at a terminal differs from the role of the server
1251 host. For example, RFC-854 defines the meaning of CR, LF,
1252 and CR LF as output from the server, but does not specify
1253 what the User Telnet should send when the user presses the
1254 "end-of-line" key on the terminal; this turns out to be
1257 When a user presses the "end-of-line" key, some User
1258 Telnet implementations send CR LF, while others send CR
1259 NUL (based on a different interpretation of the same
1260 sentence in RFC-854). These will be equivalent for a
1261 correctly-implemented ASCII server host, as discussed
1262 above. For other servers, a mode in the User Telnet is
1265 The existence of User Telnets that send only CR NUL when
1266 CR is pressed creates a dilemma for non-ASCII hosts: they
1267 can either treat CR NUL as equivalent to CR LF in input,
1268 thus precluding the possibility of entering a "bare" CR,
1269 or else lose complete interworking.
1271 Suppose a user on host A uses Telnet to log into a server
1272 host B, and then execute B's User Telnet program to log
1273 into server host C. It is desirable for the Server/User
1274 Telnet combination on B to be as transparent as possible,
1275 i.e., to appear as if A were connected directly to C. In
1276 particular, correct implementation will make B transparent
1277 to Telnet end-of-line sequences, except that CR LF may be
1278 translated to CR NUL or vice versa.
1281 To understand Telnet end-of-line issues, one must have at
1282 least a general model of the relationship of Telnet to the
1283 local operating system. The Server Telnet process is
1284 typically coupled into the terminal driver software of the
1285 operating system as a pseudo-terminal. A Telnet end-of-
1286 line sequence received by the Server Telnet must have the
1287 same effect as pressing the end-of-line key on a real
1288 locally-connected terminal.
1290 Operating systems that support interactive character-at-
1291 a-time applications (e.g., editors) typically have two
1292 internal modes for their terminal I/O: a formatted mode,
1293 in which local conventions for end-of-line and other
1297 Internet Engineering Task Force [Page 22]
1302 RFC1123 REMOTE LOGIN -- TELNET October 1989
1305 formatting rules have been applied to the data stream, and
1306 a "raw" mode, in which the application has direct access
1307 to every character as it was entered. A Server Telnet
1308 must be implemented in such a way that these modes have
1309 the same effect for remote as for local terminals. For
1310 example, suppose a CR LF or CR NUL is received by the
1311 Server Telnet on an ASCII host. In raw mode, a CR
1312 character is passed to the application; in formatted mode,
1313 the local system's end-of-line convention is used.
1315 3.3.2 Data Entry Terminals
1318 In addition to the line-oriented and character-oriented
1319 ASCII terminals for which Telnet was designed, there are
1320 several families of video display terminals that are
1321 sometimes known as "data entry terminals" or DETs. The
1322 IBM 3270 family is a well-known example.
1324 Two Internet protocols have been designed to support
1325 generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
1326 option [TELNET:18, TELNET:19]. The DET option drives a
1327 data entry terminal over a Telnet connection using (sub-)
1328 negotiation. SUPDUP is a completely separate terminal
1329 protocol, which can be entered from Telnet by negotiation.
1330 Although both SUPDUP and the DET option have been used
1331 successfully in particular environments, neither has
1332 gained general acceptance or wide implementation.
1334 A different approach to DET interaction has been developed
1335 for supporting the IBM 3270 family through Telnet,
1336 although the same approach would be applicable to any DET.
1337 The idea is to enter a "native DET" mode, in which the
1338 native DET input/output stream is sent as binary data.
1339 The Telnet EOR command is used to delimit logical records
1340 (e.g., "screens") within this binary stream.
1343 The rules for entering and leaving native DET mode are as
1346 o The Server uses the Terminal-Type option [TELNET:10]
1347 to learn that the client is a DET.
1349 o It is conventional, but not required, that both ends
1350 negotiate the EOR option [TELNET:9].
1352 o Both ends negotiate the Binary option [TELNET:3] to
1356 Internet Engineering Task Force [Page 23]
1361 RFC1123 REMOTE LOGIN -- TELNET October 1989
1364 enter native DET mode.
1366 o When either end negotiates out of binary mode, the
1367 other end does too, and the mode then reverts to
1371 3.3.3 Option Requirements
1373 Every Telnet implementation MUST support the Binary option
1374 [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
1375 SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
1376 Record [TELNET:9], and Extended Options List [TELNET:8]
1379 A User or Server Telnet SHOULD support the Window Size Option
1380 [TELNET:12] if the local operating system provides the
1381 corresponding capability.
1384 Note that the End-of-Record option only signifies that a
1385 Telnet can receive a Telnet EOR without crashing;
1386 therefore, every Telnet ought to be willing to accept
1387 negotiation of the End-of-Record option. See also the
1388 discussion in Section 3.2.3.
1390 3.3.4 Option Initiation
1392 When the Telnet protocol is used in a client/server situation,
1393 the server SHOULD initiate negotiation of the terminal
1394 interaction mode it expects.
1397 The Telnet protocol was defined to be perfectly
1398 symmetrical, but its application is generally asymmetric.
1399 Remote login has been known to fail because NEITHER side
1400 initiated negotiation of the required non-default terminal
1401 modes. It is generally the server that determines the
1402 preferred mode, so the server needs to initiate the
1403 negotiation; since the negotiation is symmetric, the user
1404 can also initiate it.
1406 A client (User Telnet) SHOULD provide a means for users to
1407 enable and disable the initiation of option negotiation.
1410 A user sometimes needs to connect to an application
1411 service (e.g., FTP or SMTP) that uses Telnet for its
1415 Internet Engineering Task Force [Page 24]
1420 RFC1123 REMOTE LOGIN -- TELNET October 1989
1423 control stream but does not support Telnet options. User
1424 Telnet may be used for this purpose if initiation of
1425 option negotiation is disabled.
1427 3.3.5 Telnet Linemode Option
1430 An important new Telnet option, LINEMODE [TELNET:12], has
1431 been proposed. The LINEMODE option provides a standard
1432 way for a User Telnet and a Server Telnet to agree that
1433 the client rather than the server will perform terminal
1434 character processing. When the client has prepared a
1435 complete line of text, it will send it to the server in
1436 (usually) one TCP packet. This option will greatly
1437 decrease the packet cost of Telnet sessions and will also
1438 give much better user response over congested or long-
1441 The LINEMODE option allows dynamic switching between local
1442 and remote character processing. For example, the Telnet
1443 connection will automatically negotiate into single-
1444 character mode while a full screen editor is running, and
1445 then return to linemode when the editor is finished.
1447 We expect that when this RFC is released, hosts should
1448 implement the client side of this option, and may
1449 implement the server side of this option. To properly
1450 implement the server side, the server needs to be able to
1451 tell the local system not to do any input character
1452 processing, but to remember its current terminal state and
1453 notify the Server Telnet process whenever the state
1454 changes. This will allow password echoing and full screen
1455 editors to be handled properly, for example.
1457 3.4 TELNET/USER INTERFACE
1459 3.4.1 Character Set Transparency
1461 User Telnet implementations SHOULD be able to send or receive
1462 any 7-bit ASCII character. Where possible, any special
1463 character interpretations by the user host's operating system
1464 SHOULD be bypassed so that these characters can conveniently be
1465 sent and received on the connection.
1467 Some character value MUST be reserved as "escape to command
1468 mode"; conventionally, doubling this character allows it to be
1469 entered as data. The specific character used SHOULD be user
1474 Internet Engineering Task Force [Page 25]
1479 RFC1123 REMOTE LOGIN -- TELNET October 1989
1482 On binary-mode connections, a User Telnet program MAY provide
1483 an escape mechanism for entering arbitrary 8-bit values, if the
1484 host operating system doesn't allow them to be entered directly
1488 The transparency issues are less pressing on servers, but
1489 implementors should take care in dealing with issues like:
1490 masking off parity bits (sent by an older, non-conforming
1491 client) before they reach programs that expect only NVT
1492 ASCII, and properly handling programs that request 8-bit
1495 3.4.2 Telnet Commands
1497 A User Telnet program MUST provide a user the capability of
1498 entering any of the Telnet control functions IP, AO, or AYT,
1499 and SHOULD provide the capability of entering EC, EL, and
1502 3.4.3 TCP Connection Errors
1504 A User Telnet program SHOULD report to the user any TCP errors
1505 that are reported by the transport layer (see "TCP/Application
1506 Layer Interface" section in [INTRO:1]).
1508 3.4.4 Non-Default Telnet Contact Port
1510 A User Telnet program SHOULD allow the user to optionally
1511 specify a non-standard contact port number at the Server Telnet
1514 3.4.5 Flushing Output
1516 A User Telnet program SHOULD provide the user the ability to
1517 specify whether or not output should be flushed when an IP is
1518 sent; see Section 3.2.4.
1520 For any output flushing scheme that causes the User Telnet to
1521 flush output locally until a Telnet signal is received from the
1522 Server, there SHOULD be a way for the user to manually restore
1523 normal output, in case the Server fails to send the expected
1533 Internet Engineering Task Force [Page 26]
1538 RFC1123 REMOTE LOGIN -- TELNET October 1989
1541 3.5. TELNET REQUIREMENTS SUMMARY
1553 FEATURE |SECTION | | | |T|T|e
1554 -------------------------------------------------|--------|-|-|-|-|-|--
1556 Option Negotiation |3.2.1 |x| | | | |
1557 Avoid negotiation loops |3.2.1 |x| | | | |
1558 Refuse unsupported options |3.2.1 |x| | | | |
1559 Negotiation OK anytime on connection |3.2.1 | |x| | | |
1560 Default to NVT |3.2.1 |x| | | | |
1561 Send official name in Term-Type option |3.2.8 |x| | | | |
1562 Accept any name in Term-Type option |3.2.8 |x| | | | |
1563 Implement Binary, Suppress-GA options |3.3.3 |x| | | | |
1564 Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | |
1565 Implement Window-Size option if appropriate |3.3.3 | |x| | | |
1566 Server initiate mode negotiations |3.3.4 | |x| | | |
1567 User can enable/disable init negotiations |3.3.4 | |x| | | |
1569 Go-Aheads | | | | | | |
1570 Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | |
1571 User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | |
1572 User Telnet ignore GA's |3.2.2 | | |x| | |
1574 Control Functions | | | | | | |
1575 Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | |
1576 Support EOR EC EL Break |3.2.3 | | |x| | |
1577 Ignore unsupported control functions |3.2.3 |x| | | | |
1578 User, Server discard urgent data up to DM |3.2.4 |x| | | | |
1579 User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | |
1580 Server Telnet reply Synch to IP |3.2.4 | | |x| | |
1581 Server Telnet reply Synch to AO |3.2.4 |x| | | | |
1582 User Telnet can flush output when send IP |3.2.4 | |x| | | |
1584 Encoding | | | | | | |
1585 Send high-order bit in NVT mode |3.2.5 | | | |x| |
1586 Send high-order bit as parity bit |3.2.5 | | | | |x|
1587 Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | |
1588 Always double IAC data byte |3.2.6 |x| | | | |
1592 Internet Engineering Task Force [Page 27]
1597 RFC1123 REMOTE LOGIN -- TELNET October 1989
1600 Double IAC data byte in binary mode |3.2.7 |x| | | | |
1601 Obey Telnet cmds in binary mode |3.2.7 |x| | | | |
1602 End-of-line, CR NUL in binary mode |3.2.7 | | | | |x|
1604 End-of-Line | | | | | | |
1605 EOL at Server same as local end-of-line |3.3.1 |x| | | | |
1606 ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | |
1607 User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | |
1608 ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | |
1609 User Telnet default mode is CR LF |3.3.1 | |x| | | |
1610 Non-interactive uses CR LF for EOL |3.3.1 |x| | | | |
1612 User Telnet interface | | | | | | |
1613 Input & output all 7-bit characters |3.4.1 | |x| | | |
1614 Bypass local op sys interpretation |3.4.1 | |x| | | |
1615 Escape character |3.4.1 |x| | | | |
1616 User-settable escape character |3.4.1 | |x| | | |
1617 Escape to enter 8-bit values |3.4.1 | | |x| | |
1618 Can input IP, AO, AYT |3.4.2 |x| | | | |
1619 Can input EC, EL, Break |3.4.2 | |x| | | |
1620 Report TCP connection errors to user |3.4.3 | |x| | | |
1621 Optional non-default contact port |3.4.4 | |x| | | |
1622 Can spec: output flushed when IP sent |3.4.5 | |x| | | |
1623 Can manually restore output mode |3.4.5 | |x| | | |
1651 Internet Engineering Task Force [Page 28]
1656 RFC1123 FILE TRANSFER -- FTP October 1989
1661 4.1 FILE TRANSFER PROTOCOL -- FTP
1665 The File Transfer Protocol FTP is the primary Internet standard
1666 for file transfer. The current specification is contained in
1669 FTP uses separate simultaneous TCP connections for control and
1670 for data transfer. The FTP protocol includes many features,
1671 some of which are not commonly implemented. However, for every
1672 feature in FTP, there exists at least one implementation. The
1673 minimum implementation defined in RFC-959 was too small, so a
1674 somewhat larger minimum implementation is defined here.
1676 Internet users have been unnecessarily burdened for years by
1677 deficient FTP implementations. Protocol implementors have
1678 suffered from the erroneous opinion that implementing FTP ought
1679 to be a small and trivial task. This is wrong, because FTP has
1680 a user interface, because it has to deal (correctly) with the
1681 whole variety of communication and operating system errors that
1682 may occur, and because it has to handle the great diversity of
1683 real file systems in the world.
1685 4.1.2. PROTOCOL WALK-THROUGH
1687 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4
1689 An FTP program MUST support TYPE I ("IMAGE" or binary type)
1690 as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
1691 A machine whose memory is organized into m-bit words, where
1692 m is not a multiple of 8, MAY also support TYPE L m.
1695 The command "TYPE L 8" is often required to transfer
1696 binary data between a machine whose memory is organized
1697 into (e.g.) 36-bit words and a machine with an 8-bit
1698 byte organization. For an 8-bit byte machine, TYPE L 8
1699 is equivalent to IMAGE.
1701 "TYPE L m" is sometimes specified to the FTP programs
1702 on two m-bit word machines to ensure the correct
1703 transfer of a native-mode binary file from one machine
1704 to the other. However, this command should have the
1705 same effect on these machines as "TYPE I".
1710 Internet Engineering Task Force [Page 29]
1715 RFC1123 FILE TRANSFER -- FTP October 1989
1718 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2
1720 A host that makes no distinction between TYPE N and TYPE T
1721 SHOULD implement TYPE T to be identical to TYPE N.
1724 This provision should ease interoperation with hosts
1725 that do make this distinction.
1727 Many hosts represent text files internally as strings
1728 of ASCII characters, using the embedded ASCII format
1729 effector characters (LF, BS, FF, ...) to control the
1730 format when a file is printed. For such hosts, there
1731 is no distinction between "print" files and other
1732 files. However, systems that use record structured
1733 files typically need a special format for printable
1734 files (e.g., ASA carriage control). For the latter
1735 hosts, FTP allows a choice of TYPE N or TYPE T.
1737 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
1739 Implementation of page structure is NOT RECOMMENDED in
1740 general. However, if a host system does need to implement
1741 FTP for "random access" or "holey" files, it MUST use the
1742 defined page structure format rather than define a new
1745 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2
1747 An FTP transformation between record-structure and file-
1748 structure SHOULD be invertible, to the extent possible while
1749 making the result useful on the target host.
1752 RFC-959 required strict invertibility between record-
1753 structure and file-structure, but in practice,
1754 efficiency and convenience often preclude it.
1755 Therefore, the requirement is being relaxed. There are
1756 two different objectives for transferring a file:
1757 processing it on the target host, or just storage. For
1758 storage, strict invertibility is important. For
1759 processing, the file created on the target host needs
1760 to be in the format expected by application programs on
1763 As an example of the conflict, imagine a record-
1764 oriented operating system that requires some data files
1765 to have exactly 80 bytes in each record. While STORing
1769 Internet Engineering Task Force [Page 30]
1774 RFC1123 FILE TRANSFER -- FTP October 1989
1777 a file on such a host, an FTP Server must be able to
1778 pad each line or record to 80 bytes; a later retrieval
1779 of such a file cannot be strictly invertible.
1781 4.1.2.5 Data Connection Management: RFC-959 Section 3.3
1783 A User-FTP that uses STREAM mode SHOULD send a PORT command
1784 to assign a non-default data port before each transfer
1788 This is required because of the long delay after a TCP
1789 connection is closed until its socket pair can be
1790 reused, to allow multiple transfers during a single FTP
1791 session. Sending a port command can avoided if a
1792 transfer mode other than stream is used, by leaving the
1793 data transfer connection open between transfers.
1795 4.1.2.6 PASV Command: RFC-959 Section 4.1.2
1797 A server-FTP MUST implement the PASV command.
1799 If multiple third-party transfers are to be executed during
1800 the same session, a new PASV command MUST be issued before
1801 each transfer command, to obtain a unique port pair.
1804 The format of the 227 reply to a PASV command is not
1805 well standardized. In particular, an FTP client cannot
1806 assume that the parentheses shown on page 40 of RFC-959
1807 will be present (and in fact, Figure 3 on page 43 omits
1808 them). Therefore, a User-FTP program that interprets
1809 the PASV reply must scan the reply for the first digit
1810 of the host and port numbers.
1812 Note that the host number h1,h2,h3,h4 is the IP address
1813 of the server host that is sending the reply, and that
1814 p1,p2 is a non-default data transfer port that PASV has
1817 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3
1819 The data returned by an NLST command MUST contain only a
1820 simple list of legal pathnames, such that the server can use
1821 them directly as the arguments of subsequent data transfer
1822 commands for the individual files.
1824 The data returned by a LIST or NLST command SHOULD use an
1828 Internet Engineering Task Force [Page 31]
1833 RFC1123 FILE TRANSFER -- FTP October 1989
1836 implied TYPE AN, unless the current type is EBCDIC, in which
1837 case an implied TYPE EN SHOULD be used.
1840 Many FTP clients support macro-commands that will get
1841 or put files matching a wildcard specification, using
1842 NLST to obtain a list of pathnames. The expansion of
1843 "multiple-put" is local to the client, but "multiple-
1844 get" requires cooperation by the server.
1846 The implied type for LIST and NLST is designed to
1847 provide compatibility with existing User-FTPs, and in
1848 particular with multiple-get commands.
1850 4.1.2.8 SITE Command: RFC-959 Section 4.1.3
1852 A Server-FTP SHOULD use the SITE command for non-standard
1853 features, rather than invent new private commands or
1854 unstandardized extensions to existing commands.
1856 4.1.2.9 STOU Command: RFC-959 Section 4.1.3
1858 The STOU command stores into a uniquely named file. When it
1859 receives an STOU command, a Server-FTP MUST return the
1860 actual file name in the "125 Transfer Starting" or the "150
1861 Opening Data Connection" message that precedes the transfer
1862 (the 250 reply code mentioned in RFC-959 is incorrect). The
1863 exact format of these messages is hereby defined to be as
1869 where pppp represents the unique pathname of the file that
1872 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34
1874 Implementors MUST NOT assume any correspondence between READ
1875 boundaries on the control connection and the Telnet EOL
1879 Thus, a server-FTP (or User-FTP) must continue reading
1880 characters from the control connection until a complete
1881 Telnet EOL sequence is encountered, before processing
1882 the command (or response, respectively). Conversely, a
1883 single READ from the control connection may include
1887 Internet Engineering Task Force [Page 32]
1892 RFC1123 FILE TRANSFER -- FTP October 1989
1895 more than one FTP command.
1897 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35
1899 A Server-FTP MUST send only correctly formatted replies on
1900 the control connection. Note that RFC-959 (unlike earlier
1901 versions of the FTP spec) contains no provision for a
1902 "spontaneous" reply message.
1904 A Server-FTP SHOULD use the reply codes defined in RFC-959
1905 whenever they apply. However, a server-FTP MAY use a
1906 different reply code when needed, as long as the general
1907 rules of Section 4.2 are followed. When the implementor has
1908 a choice between a 4xx and 5xx reply code, a Server-FTP
1909 SHOULD send a 4xx (temporary failure) code when there is any
1910 reasonable possibility that a failed FTP will succeed a few
1913 A User-FTP SHOULD generally use only the highest-order digit
1914 of a 3-digit reply code for making a procedural decision, to
1915 prevent difficulties when a Server-FTP uses non-standard
1918 A User-FTP MUST be able to handle multi-line replies. If
1919 the implementation imposes a limit on the number of lines
1920 and if this limit is exceeded, the User-FTP MUST recover,
1921 e.g., by ignoring the excess lines until the end of the
1922 multi-line reply is reached.
1924 A User-FTP SHOULD NOT interpret a 421 reply code ("Service
1925 not available, closing control connection") specially, but
1926 SHOULD detect closing of the control connection by the
1930 Server implementations that fail to strictly follow the
1931 reply rules often cause FTP user programs to hang.
1932 Note that RFC-959 resolved ambiguities in the reply
1933 rules found in earlier FTP specifications and must be
1936 It is important to choose FTP reply codes that properly
1937 distinguish between temporary and permanent failures,
1938 to allow the successful use of file transfer client
1939 daemons. These programs depend on the reply codes to
1940 decide whether or not to retry a failed transfer; using
1941 a permanent failure code (5xx) for a temporary error
1942 will cause these programs to give up unnecessarily.
1946 Internet Engineering Task Force [Page 33]
1951 RFC1123 FILE TRANSFER -- FTP October 1989
1954 When the meaning of a reply matches exactly the text
1955 shown in RFC-959, uniformity will be enhanced by using
1956 the RFC-959 text verbatim. However, a Server-FTP
1957 implementor is encouraged to choose reply text that
1958 conveys specific system-dependent information, when
1961 4.1.2.12 Connections: RFC-959 Section 5.2
1963 The words "and the port used" in the second paragraph of
1964 this section of RFC-959 are erroneous (historical), and they
1967 On a multihomed server host, the default data transfer port
1968 (L-1) MUST be associated with the same local IP address as
1969 the corresponding control connection to port L.
1971 A user-FTP MUST NOT send any Telnet controls other than
1972 SYNCH and IP on an FTP control connection. In particular, it
1973 MUST NOT attempt to negotiate Telnet options on the control
1974 connection. However, a server-FTP MUST be capable of
1975 accepting and refusing Telnet negotiations (i.e., sending
1979 Although the RFC says: "Server- and User- processes
1980 should follow the conventions for the Telnet
1981 protocol...[on the control connection]", it is not the
1982 intent that Telnet option negotiation is to be
1985 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1
1987 The following commands and options MUST be supported by
1988 every server-FTP and user-FTP, except in cases where the
1989 underlying file system or operating system does not allow or
1990 support a particular command.
1992 Type: ASCII Non-print, IMAGE, LOCAL 8
1994 Structure: File, Record*
2001 CWD, CDUP, RMD, MKD, PWD,
2005 Internet Engineering Task Force [Page 34]
2010 RFC1123 FILE TRANSFER -- FTP October 1989
2017 *Record structure is REQUIRED only for hosts whose file
2018 systems support record structure.
2021 Vendors are encouraged to implement a larger subset of
2022 the protocol. For example, there are important
2023 robustness features in the protocol (e.g., Restart,
2024 ABOR, block mode) that would be an aid to some Internet
2025 users but are not widely implemented.
2027 A host that does not have record structures in its file
2028 system may still accept files with STRU R, recording
2029 the byte stream literally.
2031 4.1.3 SPECIFIC ISSUES
2033 4.1.3.1 Non-standard Command Verbs
2035 FTP allows "experimental" commands, whose names begin with
2036 "X". If these commands are subsequently adopted as
2037 standards, there may still be existing implementations using
2038 the "X" form. At present, this is true for the directory
2041 RFC-959 "Experimental"
2049 All FTP implementations SHOULD recognize both forms of these
2050 commands, by simply equating them with extra entries in the
2051 command lookup table.
2054 A User-FTP can access a server that supports only the
2055 "X" forms by implementing a mode switch, or
2056 automatically using the following procedure: if the
2057 RFC-959 form of one of the above commands is rejected
2058 with a 500 or 502 response code, then try the
2059 experimental form; any other response would be passed
2064 Internet Engineering Task Force [Page 35]
2069 RFC1123 FILE TRANSFER -- FTP October 1989
2072 4.1.3.2 Idle Timeout
2074 A Server-FTP process SHOULD have an idle timeout, which will
2075 terminate the process and close the control connection if
2076 the server is inactive (i.e., no command or data transfer in
2077 progress) for a long period of time. The idle timeout time
2078 SHOULD be configurable, and the default should be at least 5
2081 A client FTP process ("User-PI" in RFC-959) will need
2082 timeouts on responses only if it is invoked from a program.
2085 Without a timeout, a Server-FTP process may be left
2086 pending indefinitely if the corresponding client
2087 crashes without closing the control connection.
2089 4.1.3.3 Concurrency of Data and Control
2092 The intent of the designers of FTP was that a user
2093 should be able to send a STAT command at any time while
2094 data transfer was in progress and that the server-FTP
2095 would reply immediately with status -- e.g., the number
2096 of bytes transferred so far. Similarly, an ABOR
2097 command should be possible at any time during a data
2100 Unfortunately, some small-machine operating systems
2101 make such concurrent programming difficult, and some
2102 other implementers seek minimal solutions, so some FTP
2103 implementations do not allow concurrent use of the data
2104 and control connections. Even such a minimal server
2105 must be prepared to accept and defer a STAT or ABOR
2106 command that arrives during data transfer.
2108 4.1.3.4 FTP Restart Mechanism
2110 The description of the 110 reply on pp. 40-41 of RFC-959 is
2111 incorrect; the correct description is as follows. A restart
2112 reply message, sent over the control connection from the
2113 receiving FTP to the User-FTP, has the format:
2115 110 MARK ssss = rrrr
2119 * ssss is a text string that appeared in a Restart Marker
2123 Internet Engineering Task Force [Page 36]
2128 RFC1123 FILE TRANSFER -- FTP October 1989
2131 in the data stream and encodes a position in the
2132 sender's file system;
2134 * rrrr encodes the corresponding position in the
2135 receiver's file system.
2137 The encoding, which is specific to a particular file system
2138 and network implementation, is always generated and
2139 interpreted by the same system, either sender or receiver.
2141 When an FTP that implements restart receives a Restart
2142 Marker in the data stream, it SHOULD force the data to that
2143 point to be written to stable storage before encoding the
2144 corresponding position rrrr. An FTP sending Restart Markers
2145 MUST NOT assume that 110 replies will be returned
2146 synchronously with the data, i.e., it must not await a 110
2147 reply before sending more data.
2149 Two new reply codes are hereby defined for errors
2150 encountered in restarting a transfer:
2152 554 Requested action not taken: invalid REST parameter.
2154 A 554 reply may result from a FTP service command that
2155 follows a REST command. The reply indicates that the
2156 existing file at the Server-FTP cannot be repositioned
2157 as specified in the REST.
2159 555 Requested action not taken: type or stru mismatch.
2161 A 555 reply may result from an APPE command or from any
2162 FTP service command following a REST command. The
2163 reply indicates that there is some mismatch between the
2164 current transfer parameters (type and stru) and the
2165 attributes of the existing file.
2168 Note that the FTP Restart mechanism requires that Block
2169 or Compressed mode be used for data transfer, to allow
2170 the Restart Markers to be included within the data
2171 stream. The frequency of Restart Markers can be low.
2173 Restart Markers mark a place in the data stream, but
2174 the receiver may be performing some transformation on
2175 the data as it is stored into stable storage. In
2176 general, the receiver's encoding must include any state
2177 information necessary to restart this transformation at
2178 any point of the FTP data stream. For example, in TYPE
2182 Internet Engineering Task Force [Page 37]
2187 RFC1123 FILE TRANSFER -- FTP October 1989
2190 A transfers, some receiver hosts transform CR LF
2191 sequences into a single LF character on disk. If a
2192 Restart Marker happens to fall between CR and LF, the
2193 receiver must encode in rrrr that the transfer must be
2194 restarted in a "CR has been seen and discarded" state.
2196 Note that the Restart Marker is required to be encoded
2197 as a string of printable ASCII characters, regardless
2198 of the type of the data.
2200 RFC-959 says that restart information is to be returned
2201 "to the user". This should not be taken literally. In
2202 general, the User-FTP should save the restart
2203 information (ssss,rrrr) in stable storage, e.g., append
2204 it to a restart control file. An empty restart control
2205 file should be created when the transfer first starts
2206 and deleted automatically when the transfer completes
2207 successfully. It is suggested that this file have a
2208 name derived in an easily-identifiable manner from the
2209 name of the file being transferred and the remote host
2210 name; this is analogous to the means used by many text
2211 editors for naming "backup" files.
2213 There are three cases for FTP restart.
2215 (1) User-to-Server Transfer
2217 The User-FTP puts Restart Markers <ssss> at
2218 convenient places in the data stream. When the
2219 Server-FTP receives a Marker, it writes all prior
2220 data to disk, encodes its file system position and
2221 transformation state as rrrr, and returns a "110
2222 MARK ssss = rrrr" reply over the control
2223 connection. The User-FTP appends the pair
2224 (ssss,rrrr) to its restart control file.
2226 To restart the transfer, the User-FTP fetches the
2227 last (ssss,rrrr) pair from the restart control
2228 file, repositions its local file system and
2229 transformation state using ssss, and sends the
2230 command "REST rrrr" to the Server-FTP.
2232 (2) Server-to-User Transfer
2234 The Server-FTP puts Restart Markers <ssss> at
2235 convenient places in the data stream. When the
2236 User-FTP receives a Marker, it writes all prior
2237 data to disk, encodes its file system position and
2241 Internet Engineering Task Force [Page 38]
2246 RFC1123 FILE TRANSFER -- FTP October 1989
2249 transformation state as rrrr, and appends the pair
2250 (rrrr,ssss) to its restart control file.
2252 To restart the transfer, the User-FTP fetches the
2253 last (rrrr,ssss) pair from the restart control
2254 file, repositions its local file system and
2255 transformation state using rrrr, and sends the
2256 command "REST ssss" to the Server-FTP.
2258 (3) Server-to-Server ("Third-Party") Transfer
2260 The sending Server-FTP puts Restart Markers <ssss>
2261 at convenient places in the data stream. When it
2262 receives a Marker, the receiving Server-FTP writes
2263 all prior data to disk, encodes its file system
2264 position and transformation state as rrrr, and
2265 sends a "110 MARK ssss = rrrr" reply over the
2266 control connection to the User. The User-FTP
2267 appends the pair (ssss,rrrr) to its restart
2270 To restart the transfer, the User-FTP fetches the
2271 last (ssss,rrrr) pair from the restart control
2272 file, sends "REST ssss" to the sending Server-FTP,
2273 and sends "REST rrrr" to the receiving Server-FTP.
2276 4.1.4 FTP/USER INTERFACE
2278 This section discusses the user interface for a User-FTP
2281 4.1.4.1 Pathname Specification
2283 Since FTP is intended for use in a heterogeneous
2284 environment, User-FTP implementations MUST support remote
2285 pathnames as arbitrary character strings, so that their form
2286 and content are not limited by the conventions of the local
2290 In particular, remote pathnames can be of arbitrary
2291 length, and all the printing ASCII characters as well
2292 as space (0x20) must be allowed. RFC-959 allows a
2293 pathname to contain any 7-bit ASCII character except CR
2300 Internet Engineering Task Force [Page 39]
2305 RFC1123 FILE TRANSFER -- FTP October 1989
2308 4.1.4.2 "QUOTE" Command
2310 A User-FTP program MUST implement a "QUOTE" command that
2311 will pass an arbitrary character string to the server and
2312 display all resulting response messages to the user.
2314 To make the "QUOTE" command useful, a User-FTP SHOULD send
2315 transfer control commands to the server as the user enters
2316 them, rather than saving all the commands and sending them
2317 to the server only when a data transfer is started.
2320 The "QUOTE" command is essential to allow the user to
2321 access servers that require system-specific commands
2322 (e.g., SITE or ALLO), or to invoke new or optional
2323 features that are not implemented by the User-FTP. For
2324 example, "QUOTE" may be used to specify "TYPE A T" to
2325 send a print file to hosts that require the
2326 distinction, even if the User-FTP does not recognize
2329 4.1.4.3 Displaying Replies to User
2331 A User-FTP SHOULD display to the user the full text of all
2332 error reply messages it receives. It SHOULD have a
2333 "verbose" mode in which all commands it sends and the full
2334 text and reply codes it receives are displayed, for
2335 diagnosis of problems.
2337 4.1.4.4 Maintaining Synchronization
2339 The state machine in a User-FTP SHOULD be forgiving of
2340 missing and unexpected reply messages, in order to maintain
2341 command synchronization with the server.
2359 Internet Engineering Task Force [Page 40]
2364 RFC1123 FILE TRANSFER -- FTP October 1989
2367 4.1.5 FTP REQUIREMENTS SUMMARY
2378 FEATURE |SECTION | | | |T|T|e
2379 -------------------------------------------|---------------|-|-|-|-|-|--
2380 Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | |
2381 File/Record transform invertible if poss. |4.1.2.4 | |x| | | |
2382 User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | |
2383 Server-FTP implement PASV |4.1.2.6 |x| | | | |
2384 PASV is per-transfer |4.1.2.6 |x| | | | |
2385 NLST reply usable in RETR cmds |4.1.2.7 |x| | | | |
2386 Implied type for LIST and NLST |4.1.2.7 | |x| | | |
2387 SITE cmd for non-standard features |4.1.2.8 | |x| | | |
2388 STOU cmd return pathname as specified |4.1.2.9 |x| | | | |
2389 Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x|
2391 Server-FTP send only correct reply format |4.1.2.11 |x| | | | |
2392 Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | |
2393 New reply code following Section 4.2 |4.1.2.11 | | |x| | |
2394 User-FTP use only high digit of reply |4.1.2.11 | |x| | | |
2395 User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | |
2396 User-FTP handle 421 reply specially |4.1.2.11 | | | |x| |
2398 Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | |
2399 User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x|
2400 User-FTP negotiate Telnet options |4.1.2.12 | | | | |x|
2401 Server-FTP handle Telnet options |4.1.2.12 |x| | | | |
2402 Handle "Experimental" directory cmds |4.1.3.1 | |x| | | |
2403 Idle timeout in server-FTP |4.1.3.2 | |x| | | |
2404 Configurable idle timeout |4.1.3.2 | |x| | | |
2405 Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | |
2406 Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x|
2408 Support TYPE: | | | | | | |
2409 ASCII - Non-Print (AN) |4.1.2.13 |x| | | | |
2410 ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | |
2411 ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | |
2412 EBCDIC - (any form) |959 3.1.1.2 | | |x| | |
2413 IMAGE |4.1.2.1 |x| | | | |
2414 LOCAL 8 |4.1.2.1 |x| | | | |
2418 Internet Engineering Task Force [Page 41]
2423 RFC1123 FILE TRANSFER -- FTP October 1989
2426 LOCAL m |4.1.2.1 | | |x| | |2
2428 Support MODE: | | | | | | |
2429 Stream |4.1.2.13 |x| | | | |
2430 Block |959 3.4.2 | | |x| | |
2432 Support STRUCTURE: | | | | | | |
2433 File |4.1.2.13 |x| | | | |
2434 Record |4.1.2.13 |x| | | | |3
2435 Page |4.1.2.3 | | | |x| |
2437 Support commands: | | | | | | |
2438 USER |4.1.2.13 |x| | | | |
2439 PASS |4.1.2.13 |x| | | | |
2440 ACCT |4.1.2.13 |x| | | | |
2441 CWD |4.1.2.13 |x| | | | |
2442 CDUP |4.1.2.13 |x| | | | |
2443 SMNT |959 5.3.1 | | |x| | |
2444 REIN |959 5.3.1 | | |x| | |
2445 QUIT |4.1.2.13 |x| | | | |
2447 PORT |4.1.2.13 |x| | | | |
2448 PASV |4.1.2.6 |x| | | | |
2449 TYPE |4.1.2.13 |x| | | | |1
2450 STRU |4.1.2.13 |x| | | | |1
2451 MODE |4.1.2.13 |x| | | | |1
2453 RETR |4.1.2.13 |x| | | | |
2454 STOR |4.1.2.13 |x| | | | |
2455 STOU |959 5.3.1 | | |x| | |
2456 APPE |4.1.2.13 |x| | | | |
2457 ALLO |959 5.3.1 | | |x| | |
2458 REST |959 5.3.1 | | |x| | |
2459 RNFR |4.1.2.13 |x| | | | |
2460 RNTO |4.1.2.13 |x| | | | |
2461 ABOR |959 5.3.1 | | |x| | |
2462 DELE |4.1.2.13 |x| | | | |
2463 RMD |4.1.2.13 |x| | | | |
2464 MKD |4.1.2.13 |x| | | | |
2465 PWD |4.1.2.13 |x| | | | |
2466 LIST |4.1.2.13 |x| | | | |
2467 NLST |4.1.2.13 |x| | | | |
2468 SITE |4.1.2.8 | | |x| | |
2469 STAT |4.1.2.13 |x| | | | |
2470 SYST |4.1.2.13 |x| | | | |
2471 HELP |4.1.2.13 |x| | | | |
2472 NOOP |4.1.2.13 |x| | | | |
2477 Internet Engineering Task Force [Page 42]
2482 RFC1123 FILE TRANSFER -- FTP October 1989
2485 User Interface: | | | | | | |
2486 Arbitrary pathnames |4.1.4.1 |x| | | | |
2487 Implement "QUOTE" command |4.1.4.2 |x| | | | |
2488 Transfer control commands immediately |4.1.4.2 | |x| | | |
2489 Display error messages to user |4.1.4.3 | |x| | | |
2490 Verbose mode |4.1.4.3 | |x| | | |
2491 Maintain synchronization with server |4.1.4.4 | |x| | | |
2495 (1) For the values shown earlier.
2497 (2) Here m is number of bits in a memory word.
2499 (3) Required for host with record-structured file system, optional
2536 Internet Engineering Task Force [Page 43]
2541 RFC1123 FILE TRANSFER -- TFTP October 1989
2544 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
2548 The Trivial File Transfer Protocol TFTP is defined in RFC-783
2551 TFTP provides its own reliable delivery with UDP as its
2552 transport protocol, using a simple stop-and-wait acknowledgment
2553 system. Since TFTP has an effective window of only one 512
2554 octet segment, it can provide good performance only over paths
2555 that have a small delay*bandwidth product. The TFTP file
2556 interface is very simple, providing no access control or
2559 TFTP's most important application is bootstrapping a host over
2560 a local network, since it is simple and small enough to be
2561 easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are
2562 urged to support TFTP for booting.
2564 4.2.2 PROTOCOL WALK-THROUGH
2566 The TFTP specification [TFTP:1] is written in an open style,
2567 and does not fully specify many parts of the protocol.
2569 4.2.2.1 Transfer Modes: RFC-783, Page 3
2571 The transfer mode "mail" SHOULD NOT be supported.
2573 4.2.2.2 UDP Header: RFC-783, Page 17
2575 The Length field of a UDP header is incorrectly defined; it
2576 includes the UDP header length (8).
2578 4.2.3 SPECIFIC ISSUES
2580 4.2.3.1 Sorcerer's Apprentice Syndrome
2582 There is a serious bug, known as the "Sorcerer's Apprentice
2583 Syndrome," in the protocol specification. While it does not
2584 cause incorrect operation of the transfer (the file will
2585 always be transferred correctly if the transfer completes),
2586 this bug may cause excessive retransmission, which may cause
2587 the transfer to time out.
2589 Implementations MUST contain the fix for this problem: the
2590 sender (i.e., the side originating the DATA packets) must
2591 never resend the current DATA packet on receipt of a
2595 Internet Engineering Task Force [Page 44]
2600 RFC1123 FILE TRANSFER -- TFTP October 1989
2606 The bug is caused by the protocol rule that either
2607 side, on receiving an old duplicate datagram, may
2608 resend the current datagram. If a packet is delayed in
2609 the network but later successfully delivered after
2610 either side has timed out and retransmitted a packet, a
2611 duplicate copy of the response may be generated. If
2612 the other side responds to this duplicate with a
2613 duplicate of its own, then every datagram will be sent
2614 in duplicate for the remainder of the transfer (unless
2615 a datagram is lost, breaking the repetition). Worse
2616 yet, since the delay is often caused by congestion,
2617 this duplicate transmission will usually causes more
2618 congestion, leading to more delayed packets, etc.
2620 The following example may help to clarify this problem.
2628 (ACK X is delayed in network,
2630 (3) Retransmit DATA X
2632 (4) Receive DATA X again
2634 (5) Receive (delayed) ACK X
2636 (6) Receive DATA X+1
2638 (7) Receive ACK X again
2640 (8) Receive DATA X+1 again
2644 (10) Receive DATA X+2
2646 (11) Receive ACK X+1 again
2648 (12) Receive DATA X+2 again
2654 Internet Engineering Task Force [Page 45]
2659 RFC1123 FILE TRANSFER -- TFTP October 1989
2662 Notice that once the delayed ACK arrives, the protocol
2663 settles down to duplicate all further packets
2664 (sequences 5-8 and 9-12). The problem is caused not by
2665 either side timing out, but by both sides
2666 retransmitting the current packet when they receive a
2669 The fix is to break the retransmission loop, as
2670 indicated above. This is analogous to the behavior of
2671 TCP. It is then possible to remove the retransmission
2672 timer on the receiver, since the resent ACK will never
2673 cause any action; this is a useful simplification where
2674 TFTP is used in a bootstrap program. It is OK to allow
2675 the timer to remain, and it may be helpful if the
2676 retransmitted ACK replaces one that was genuinely lost
2677 in the network. The sender still requires a retransmit
2680 4.2.3.2 Timeout Algorithms
2682 A TFTP implementation MUST use an adaptive timeout.
2685 TCP retransmission algorithms provide a useful base to
2686 work from. At least an exponential backoff of
2687 retransmission timeout is necessary.
2691 A variety of non-standard extensions have been made to TFTP,
2692 including additional transfer modes and a secure operation
2693 mode (with passwords). None of these have been
2696 4.2.3.4 Access Control
2698 A server TFTP implementation SHOULD include some
2699 configurable access control over what pathnames are allowed
2702 4.2.3.5 Broadcast Request
2704 A TFTP request directed to a broadcast address SHOULD be
2708 Due to the weak access control capability of TFTP,
2709 directed broadcasts of TFTP requests to random networks
2713 Internet Engineering Task Force [Page 46]
2718 RFC1123 FILE TRANSFER -- TFTP October 1989
2721 could create a significant security hole.
2723 4.2.4 TFTP REQUIREMENTS SUMMARY
2734 FEATURE |SECTION | | | |T|T|e
2735 -------------------------------------------------|--------|-|-|-|-|-|--
2736 Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | |
2737 Transfer modes: | | | | | | |
2738 netascii |RFC-783 |x| | | | |
2739 octet |RFC-783 |x| | | | |
2740 mail |4.2.2.1 | | | |x| |
2741 extensions |4.2.3.3 | | |x| | |
2742 Use adaptive timeout |4.2.3.2 |x| | | | |
2743 Configurable access control |4.2.3.4 | |x| | | |
2744 Silently ignore broadcast request |4.2.3.5 | |x| | | |
2745 -------------------------------------------------|--------|-|-|-|-|-|--
2746 -------------------------------------------------|--------|-|-|-|-|-|--
2772 Internet Engineering Task Force [Page 47]
2777 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2780 5. ELECTRONIC MAIL -- SMTP and RFC-822
2784 In the TCP/IP protocol suite, electronic mail in a format
2785 specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
2786 Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
2788 While SMTP has remained unchanged over the years, the Internet
2789 community has made several changes in the way SMTP is used. In
2790 particular, the conversion to the Domain Name System (DNS) has
2791 caused changes in address formats and in mail routing. In this
2792 section, we assume familiarity with the concepts and terminology
2793 of the DNS, whose requirements are given in Section 6.1.
2795 RFC-822 specifies the Internet standard format for electronic mail
2796 messages. RFC-822 supercedes an older standard, RFC-733, that may
2797 still be in use in a few places, although it is obsolete. The two
2798 formats are sometimes referred to simply by number ("822" and
2801 RFC-822 is used in some non-Internet mail environments with
2802 different mail transfer protocols than SMTP, and SMTP has also
2803 been adapted for use in some non-Internet environments. Note that
2804 this document presents the rules for the use of SMTP and RFC-822
2805 for the Internet environment only; other mail environments that
2806 use these protocols may be expected to have their own rules.
2808 5.2 PROTOCOL WALK-THROUGH
2810 This section covers both RFC-821 and RFC-822.
2812 The SMTP specification in RFC-821 is clear and contains numerous
2813 examples, so implementors should not find it difficult to
2814 understand. This section simply updates or annotates portions of
2815 RFC-821 to conform with current usage.
2817 RFC-822 is a long and dense document, defining a rich syntax.
2818 Unfortunately, incomplete or defective implementations of RFC-822
2819 are common. In fact, nearly all of the many formats of RFC-822
2820 are actually used, so an implementation generally needs to
2821 recognize and correctly interpret all of the RFC-822 syntax.
2823 5.2.1 The SMTP Model: RFC-821 Section 2
2826 Mail is sent by a series of request/response transactions
2827 between a client, the "sender-SMTP," and a server, the
2831 Internet Engineering Task Force [Page 48]
2836 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2839 "receiver-SMTP". These transactions pass (1) the message
2840 proper, which is composed of header and body, and (2) SMTP
2841 source and destination addresses, referred to as the
2844 The SMTP programs are analogous to Message Transfer Agents
2845 (MTAs) of X.400. There will be another level of protocol
2846 software, closer to the end user, that is responsible for
2847 composing and analyzing RFC-822 message headers; this
2848 component is known as the "User Agent" in X.400, and we
2849 use that term in this document. There is a clear logical
2850 distinction between the User Agent and the SMTP
2851 implementation, since they operate on different levels of
2852 protocol. Note, however, that this distinction is may not
2853 be exactly reflected the structure of typical
2854 implementations of Internet mail. Often there is a
2855 program known as the "mailer" that implements SMTP and
2856 also some of the User Agent functions; the rest of the
2857 User Agent functions are included in a user interface used
2858 for entering and reading mail.
2860 The SMTP envelope is constructed at the originating site,
2861 typically by the User Agent when the message is first
2862 queued for the Sender-SMTP program. The envelope
2863 addresses may be derived from information in the message
2864 header, supplied by the user interface (e.g., to implement
2865 a bcc: request), or derived from local configuration
2866 information (e.g., expansion of a mailing list). The SMTP
2867 envelope cannot in general be re-derived from the header
2868 at a later stage in message delivery, so the envelope is
2869 transmitted separately from the message itself using the
2870 MAIL and RCPT commands of SMTP.
2872 The text of RFC-821 suggests that mail is to be delivered
2873 to an individual user at a host. With the advent of the
2874 domain system and of mail routing using mail-exchange (MX)
2875 resource records, implementors should now think of
2876 delivering mail to a user at a domain, which may or may
2877 not be a particular host. This DOES NOT change the fact
2878 that SMTP is a host-to-host mail exchange protocol.
2880 5.2.2 Canonicalization: RFC-821 Section 3.1
2882 The domain names that a Sender-SMTP sends in MAIL and RCPT
2883 commands MUST have been "canonicalized," i.e., they must be
2884 fully-qualified principal names or domain literals, not
2885 nicknames or domain abbreviations. A canonicalized name either
2886 identifies a host directly or is an MX name; it cannot be a
2890 Internet Engineering Task Force [Page 49]
2895 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2900 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3
2902 A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
2903 (this requirement overrides RFC-821). However, there MAY be
2904 configuration information to disable VRFY and EXPN in a
2905 particular installation; this might even allow EXPN to be
2906 disabled for selected lists.
2908 A new reply code is defined for the VRFY command:
2910 252 Cannot VRFY user (e.g., info is not local), but will
2911 take message for this user and attempt delivery.
2914 SMTP users and administrators make regular use of these
2915 commands for diagnosing mail delivery problems. With the
2916 increasing use of multi-level mailing list expansion
2917 (sometimes more than two levels), EXPN has been
2918 increasingly important for diagnosing inadvertent mail
2919 loops. On the other hand, some feel that EXPN represents
2920 a significant privacy, and perhaps even a security,
2923 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4
2925 An SMTP MAY implement the commands to send a message to a
2926 user's terminal: SEND, SOML, and SAML.
2929 It has been suggested that the use of mail relaying
2930 through an MX record is inconsistent with the intent of
2931 SEND to deliver a message immediately and directly to a
2932 user's terminal. However, an SMTP receiver that is unable
2933 to write directly to the user terminal can return a "251
2934 User Not Local" reply to the RCPT following a SEND, to
2935 inform the originator of possibly deferred delivery.
2937 5.2.5 HELO Command: RFC-821 Section 3.5
2939 The sender-SMTP MUST ensure that the <domain> parameter in a
2940 HELO command is a valid principal host domain name for the
2941 client host. As a result, the receiver-SMTP will not have to
2942 perform MX resolution on this name in order to validate the
2945 The HELO receiver MAY verify that the HELO parameter really
2949 Internet Engineering Task Force [Page 50]
2954 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2957 corresponds to the IP address of the sender. However, the
2958 receiver MUST NOT refuse to accept a message, even if the
2959 sender's HELO command fails verification.
2962 Verifying the HELO parameter requires a domain name lookup
2963 and may therefore take considerable time. An alternative
2964 tool for tracking bogus mail sources is suggested below
2965 (see "DATA Command").
2967 Note also that the HELO argument is still required to have
2968 valid <domain> syntax, since it will appear in a Received:
2969 line; otherwise, a 501 error is to be sent.
2972 When HELO parameter validation fails, a suggested
2973 procedure is to insert a note about the unknown
2974 authenticity of the sender into the message header (e.g.,
2975 in the "Received:" line).
2977 5.2.6 Mail Relay: RFC-821 Section 3.6
2979 We distinguish three types of mail (store-and-) forwarding:
2981 (1) A simple forwarder or "mail exchanger" forwards a message
2982 using private knowledge about the recipient; see section
2985 (2) An SMTP mail "relay" forwards a message within an SMTP
2986 mail environment as the result of an explicit source route
2987 (as defined in section 3.6 of RFC-821). The SMTP relay
2988 function uses the "@...:" form of source route from RFC-
2989 822 (see Section 5.2.19 below).
2991 (3) A mail "gateway" passes a message between different
2992 environments. The rules for mail gateways are discussed
2993 below in Section 5.3.7.
2995 An Internet host that is forwarding a message but is not a
2996 gateway to a different mail environment (i.e., it falls under
2997 (1) or (2)) SHOULD NOT alter any existing header fields,
2998 although the host will add an appropriate Received: line as
2999 required in Section 5.2.8.
3001 A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
3002 explicit source route using the "@...:" address form. Thus,
3003 the relay function defined in section 3.6 of RFC-821 should
3008 Internet Engineering Task Force [Page 51]
3013 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3017 The intent is to discourage all source routing and to
3018 abolish explicit source routing for mail delivery within
3019 the Internet environment. Source-routing is unnecessary;
3020 the simple target address "user@domain" should always
3021 suffice. This is the result of an explicit architectural
3022 decision to use universal naming rather than source
3023 routing for mail. Thus, SMTP provides end-to-end
3024 connectivity, and the DNS provides globally-unique,
3025 location-independent names. MX records handle the major
3026 case where source routing might otherwise be needed.
3028 A receiver-SMTP MUST accept the explicit source route syntax in
3029 the envelope, but it MAY implement the relay function as
3030 defined in section 3.6 of RFC-821. If it does not implement
3031 the relay function, it SHOULD attempt to deliver the message
3032 directly to the host to the right of the right-most "@" sign.
3035 For example, suppose a host that does not implement the
3036 relay function receives a message with the SMTP command:
3037 "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
3038 GAMMA represent domain names. Rather than immediately
3039 refusing the message with a 550 error reply as suggested
3040 on page 20 of RFC-821, the host should try to forward the
3041 message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
3042 Since this host does not support relaying, it is not
3043 required to update the reverse path.
3045 Some have suggested that source routing may be needed
3046 occasionally for manually routing mail around failures;
3047 however, the reality and importance of this need is
3048 controversial. The use of explicit SMTP mail relaying for
3049 this purpose is discouraged, and in fact it may not be
3050 successful, as many host systems do not support it. Some
3051 have used the "%-hack" (see Section 5.2.16) for this
3054 5.2.7 RCPT Command: RFC-821 Section 4.1.1
3056 A host that supports a receiver-SMTP MUST support the reserved
3057 mailbox "Postmaster".
3059 The receiver-SMTP MAY verify RCPT parameters as they arrive;
3060 however, RCPT responses MUST NOT be delayed beyond a reasonable
3061 time (see Section 5.3.2).
3063 Therefore, a "250 OK" response to a RCPT does not necessarily
3067 Internet Engineering Task Force [Page 52]
3072 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3075 imply that the delivery address(es) are valid. Errors found
3076 after message acceptance will be reported by mailing a
3077 notification message to an appropriate address (see Section
3081 The set of conditions under which a RCPT parameter can be
3082 validated immediately is an engineering design choice.
3083 Reporting destination mailbox errors to the Sender-SMTP
3084 before mail is transferred is generally desirable to save
3085 time and network bandwidth, but this advantage is lost if
3086 RCPT verification is lengthy.
3088 For example, the receiver can verify immediately any
3089 simple local reference, such as a single locally-
3090 registered mailbox. On the other hand, the "reasonable
3091 time" limitation generally implies deferring verification
3092 of a mailing list until after the message has been
3093 transferred and accepted, since verifying a large mailing
3094 list can take a very long time. An implementation might
3095 or might not choose to defer validation of addresses that
3096 are non-local and therefore require a DNS lookup. If a
3097 DNS lookup is performed but a soft domain system error
3098 (e.g., timeout) occurs, validity must be assumed.
3100 5.2.8 DATA Command: RFC-821 Section 4.1.1
3102 Every receiver-SMTP (not just one that "accepts a message for
3103 relaying or for final delivery" [SMTP:1]) MUST insert a
3104 "Received:" line at the beginning of a message. In this line,
3105 called a "time stamp line" in RFC-821:
3107 * The FROM field SHOULD contain both (1) the name of the
3108 source host as presented in the HELO command and (2) a
3109 domain literal containing the IP address of the source,
3110 determined from the TCP connection.
3112 * The ID field MAY contain an "@" as suggested in RFC-822,
3113 but this is not required.
3115 * The FOR field MAY contain a list of <path> entries when
3116 multiple RCPT commands have been given.
3119 An Internet mail program MUST NOT change a Received: line that
3120 was previously added to the message header.
3126 Internet Engineering Task Force [Page 53]
3131 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3135 Including both the source host and the IP source address
3136 in the Received: line may provide enough information for
3137 tracking illicit mail sources and eliminate a need to
3138 explicitly verify the HELO parameter.
3140 Received: lines are primarily intended for humans tracing
3141 mail routes, primarily of diagnosis of faults. See also
3142 the discussion under 5.3.7.
3144 When the receiver-SMTP makes "final delivery" of a message,
3145 then it MUST pass the MAIL FROM: address from the SMTP envelope
3146 with the message, for use if an error notification message must
3147 be sent later (see Section 5.3.3). There is an analogous
3148 requirement when gatewaying from the Internet into a different
3149 mail environment; see Section 5.3.7.
3152 Note that the final reply to the DATA command depends only
3153 upon the successful transfer and storage of the message.
3154 Any problem with the destination address(es) must either
3155 (1) have been reported in an SMTP error reply to the RCPT
3156 command(s), or (2) be reported in a later error message
3157 mailed to the originator.
3160 The MAIL FROM: information may be passed as a parameter or
3161 in a Return-Path: line inserted at the beginning of the
3164 5.2.9 Command Syntax: RFC-821 Section 4.1.2
3166 The syntax shown in RFC-821 for the MAIL FROM: command omits
3167 the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page
3168 15). An empty reverse path MUST be supported.
3170 5.2.10 SMTP Replies: RFC-821 Section 4.2
3172 A receiver-SMTP SHOULD send only the reply codes listed in
3173 section 4.2.2 of RFC-821 or in this document. A receiver-SMTP
3174 SHOULD use the text shown in examples in RFC-821 whenever
3177 A sender-SMTP MUST determine its actions only by the reply
3178 code, not by the text (except for 251 and 551 replies); any
3179 text, including no text at all, must be acceptable. The space
3180 (blank) following the reply code is considered part of the
3181 text. Whenever possible, a sender-SMTP SHOULD test only the
3185 Internet Engineering Task Force [Page 54]
3190 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3193 first digit of the reply code, as specified in Appendix E of
3197 Interoperability problems have arisen with SMTP systems
3198 using reply codes that are not listed explicitly in RFC-
3199 821 Section 4.3 but are legal according to the theory of
3200 reply codes explained in Appendix E.
3202 5.2.11 Transparency: RFC-821 Section 4.5.2
3204 Implementors MUST be sure that their mail systems always add
3205 and delete periods to ensure message transparency.
3207 5.2.12 WKS Use in MX Processing: RFC-974, p. 5
3209 RFC-974 [SMTP:3] recommended that the domain system be queried
3210 for WKS ("Well-Known Service") records, to verify that each
3211 proposed mail target does support SMTP. Later experience has
3212 shown that WKS is not widely supported, so the WKS step in MX
3213 processing SHOULD NOT be used.
3215 The following are notes on RFC-822, organized by section of that
3218 5.2.13 RFC-822 Message Specification: RFC-822 Section 4
3220 The syntax shown for the Return-path line omits the possibility
3221 of a null return path, which is used to prevent looping of
3222 error notifications (see Section 5.3.3). The complete syntax
3225 return = "Return-path" ":" route-addr
3226 / "Return-path" ":" "<" ">"
3228 The set of optional header fields is hereby expanded to include
3229 the Content-Type field defined in RFC-1049 [SMTP:7]. This
3230 field "allows mail reading systems to automatically identify
3231 the type of a structured message body and to process it for
3232 display accordingly". [SMTP:7] A User Agent MAY support this
3235 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5
3237 The syntax for the date is hereby changed to:
3239 date = 1*2DIGIT month 2*4DIGIT
3244 Internet Engineering Task Force [Page 55]
3249 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3252 All mail software SHOULD use 4-digit years in dates, to ease
3253 the transition to the next century.
3255 There is a strong trend towards the use of numeric timezone
3256 indicators, and implementations SHOULD use numeric timezones
3257 instead of timezone names. However, all implementations MUST
3258 accept either notation. If timezone names are used, they MUST
3259 be exactly as defined in RFC-822.
3261 The military time zones are specified incorrectly in RFC-822:
3262 they count the wrong way from UT (the signs are reversed). As
3263 a result, military time zones in RFC-822 headers carry no
3266 Finally, note that there is a typo in the definition of "zone"
3267 in the syntax summary of appendix D; the correct definition
3268 occurs in Section 3 of RFC-822.
3270 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1
3272 The syntactic definition of "mailbox" in RFC-822 is hereby
3275 mailbox = addr-spec ; simple address
3276 / [phrase] route-addr ; name & addr-spec
3278 That is, the phrase preceding a route address is now OPTIONAL.
3279 This change makes the following header field legal, for
3282 From: <craig@nnsc.nsf.net>
3284 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2
3286 The basic mailbox address specification has the form: "local-
3287 part@domain". Here "local-part", sometimes called the "left-
3288 hand side" of the address, is domain-dependent.
3290 A host that is forwarding the message but is not the
3291 destination host implied by the right-hand side "domain" MUST
3292 NOT interpret or modify the "local-part" of the address.
3294 When mail is to be gatewayed from the Internet mail environment
3295 into a foreign mail environment (see Section 5.3.7), routing
3296 information for that foreign environment MAY be embedded within
3297 the "local-part" of the address. The gateway will then
3298 interpret this local part appropriately for the foreign mail
3303 Internet Engineering Task Force [Page 56]
3308 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3312 Although source routes are discouraged within the Internet
3313 (see Section 5.2.6), there are non-Internet mail
3314 environments whose delivery mechanisms do depend upon
3315 source routes. Source routes for extra-Internet
3316 environments can generally be buried in the "local-part"
3317 of the address (see Section 5.2.16) while mail traverses
3318 the Internet. When the mail reaches the appropriate
3319 Internet mail gateway, the gateway will interpret the
3320 local-part and build the necessary address or route for
3321 the target mail environment.
3323 For example, an Internet host might send mail to:
3324 "a!b!c!user@gateway-domain". The complex local part
3325 "a!b!c!user" would be uninterpreted within the Internet
3326 domain, but could be parsed and understood by the
3327 specified mail gateway.
3329 An embedded source route is sometimes encoded in the
3330 "local-part" using "%" as a right-binding routing
3331 operator. For example, in:
3333 user%domain%relay3%relay2@relay1
3335 the "%" convention implies that the mail is to be routed
3336 from "relay1" through "relay2", "relay3", and finally to
3337 "user" at "domain". This is commonly known as the "%-
3338 hack". It is suggested that "%" have lower precedence
3339 than any other routing operator (e.g., "!") hidden in the
3340 local-part; for example, "a!b%c" would be interpreted as
3343 Only the target host (in this case, "relay1") is permitted
3344 to analyze the local-part "user%domain%relay3%relay2".
3346 5.2.17 Domain Literals: RFC-822 Section 6.2.3
3348 A mailer MUST be able to accept and parse an Internet domain
3349 literal whose content ("dtext"; see RFC-822) is a dotted-
3350 decimal host address. This satisfies the requirement of
3351 Section 2.1 for the case of mail.
3353 An SMTP MUST accept and recognize a domain literal for any of
3354 its own IP addresses.
3362 Internet Engineering Task Force [Page 57]
3367 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3370 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1
3372 Errors in formatting or parsing 822 addresses are unfortunately
3373 common. This section mentions only the most common errors. A
3374 User Agent MUST accept all valid RFC-822 address formats, and
3375 MUST NOT generate illegal address syntax.
3377 o A common error is to leave out the semicolon after a group
3380 o Some systems fail to fully-qualify domain names in
3381 messages they generate. The right-hand side of an "@"
3382 sign in a header address field MUST be a fully-qualified
3385 For example, some systems fail to fully-qualify the From:
3386 address; this prevents a "reply" command in the user
3387 interface from automatically constructing a return
3391 Although RFC-822 allows the local use of abbreviated
3392 domain names within a domain, the application of
3393 RFC-822 in Internet mail does not allow this. The
3394 intent is that an Internet host must not send an SMTP
3395 message header containing an abbreviated domain name
3396 in an address field. This allows the address fields
3397 of the header to be passed without alteration across
3398 the Internet, as required in Section 5.2.6.
3400 o Some systems mis-parse multiple-hop explicit source routes
3403 @relay1,@relay2,@relay3:user@domain.
3406 o Some systems over-qualify domain names by adding a
3407 trailing dot to some or all domain names in addresses or
3408 message-ids. This violates RFC-822 syntax.
3411 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7
3413 Internet host software SHOULD NOT create an RFC-822 header
3414 containing an address with an explicit source route, but MUST
3415 accept such headers for compatibility with earlier systems.
3421 Internet Engineering Task Force [Page 58]
3426 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3429 In an understatement, RFC-822 says "The use of explicit
3430 source routing is discouraged". Many hosts implemented
3431 RFC-822 source routes incorrectly, so the syntax cannot be
3432 used unambiguously in practice. Many users feel the
3433 syntax is ugly. Explicit source routes are not needed in
3434 the mail envelope for delivery; see Section 5.2.6. For
3435 all these reasons, explicit source routes using the RFC-
3436 822 notations are not to be used in Internet mail headers.
3438 As stated in Section 5.2.16, it is necessary to allow an
3439 explicit source route to be buried in the local-part of an
3440 address, e.g., using the "%-hack", in order to allow mail
3441 to be gatewayed into another environment in which explicit
3442 source routing is necessary. The vigilant will observe
3443 that there is no way for a User Agent to detect and
3444 prevent the use of such implicit source routing when the
3445 destination is within the Internet. We can only
3446 discourage source routing of any kind within the Internet,
3447 as unnecessary and undesirable.
3451 5.3.1 SMTP Queueing Strategies
3453 The common structure of a host SMTP implementation includes
3454 user mailboxes, one or more areas for queueing messages in
3455 transit, and one or more daemon processes for sending and
3456 receiving mail. The exact structure will vary depending on the
3457 needs of the users on the host and the number and size of
3458 mailing lists supported by the host. We describe several
3459 optimizations that have proved helpful, particularly for
3460 mailers supporting high traffic levels.
3462 Any queueing strategy MUST include:
3464 o Timeouts on all activities. See Section 5.3.2.
3466 o Never sending error messages in response to error
3470 5.3.1.1 Sending Strategy
3472 The general model of a sender-SMTP is one or more processes
3473 that periodically attempt to transmit outgoing mail. In a
3474 typical system, the program that composes a message has some
3475 method for requesting immediate attention for a new piece of
3476 outgoing mail, while mail that cannot be transmitted
3480 Internet Engineering Task Force [Page 59]
3485 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3488 immediately MUST be queued and periodically retried by the
3489 sender. A mail queue entry will include not only the
3490 message itself but also the envelope information.
3492 The sender MUST delay retrying a particular destination
3493 after one attempt has failed. In general, the retry
3494 interval SHOULD be at least 30 minutes; however, more
3495 sophisticated and variable strategies will be beneficial
3496 when the sender-SMTP can determine the reason for non-
3499 Retries continue until the message is transmitted or the
3500 sender gives up; the give-up time generally needs to be at
3501 least 4-5 days. The parameters to the retry algorithm MUST
3504 A sender SHOULD keep a list of hosts it cannot reach and
3505 corresponding timeouts, rather than just retrying queued
3509 Experience suggests that failures are typically
3510 transient (the target system has crashed), favoring a
3511 policy of two connection attempts in the first hour the
3512 message is in the queue, and then backing off to once
3513 every two or three hours.
3515 The sender-SMTP can shorten the queueing delay by
3516 cooperation with the receiver-SMTP. In particular, if
3517 mail is received from a particular address, it is good
3518 evidence that any mail queued for that host can now be
3521 The strategy may be further modified as a result of
3522 multiple addresses per host (see Section 5.3.4), to
3523 optimize delivery time vs. resource usage.
3525 A sender-SMTP may have a large queue of messages for
3526 each unavailable destination host, and if it retried
3527 all these messages in every retry cycle, there would be
3528 excessive Internet overhead and the daemon would be
3529 blocked for a long period. Note that an SMTP can
3530 generally determine that a delivery attempt has failed
3531 only after a timeout of a minute or more; a one minute
3532 timeout per connection will result in a very large
3533 delay if it is repeated for dozens or even hundreds of
3539 Internet Engineering Task Force [Page 60]
3544 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3547 When the same message is to be delivered to several users on
3548 the same host, only one copy of the message SHOULD be
3549 transmitted. That is, the sender-SMTP should use the
3550 command sequence: RCPT, RCPT,... RCPT, DATA instead of the
3551 sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
3552 Implementation of this efficiency feature is strongly urged.
3554 Similarly, the sender-SMTP MAY support multiple concurrent
3555 outgoing mail transactions to achieve timely delivery.
3556 However, some limit SHOULD be imposed to protect the host
3557 from devoting all its resources to mail.
3559 The use of the different addresses of a multihomed host is
3562 5.3.1.2 Receiving strategy
3564 The receiver-SMTP SHOULD attempt to keep a pending listen on
3565 the SMTP port at all times. This will require the support
3566 of multiple incoming TCP connections for SMTP. Some limit
3570 When the receiver-SMTP receives mail from a particular
3571 host address, it could notify the sender-SMTP to retry
3572 any mail pending for that host address.
3574 5.3.2 Timeouts in SMTP
3576 There are two approaches to timeouts in the sender-SMTP: (a)
3577 limit the time for each SMTP command separately, or (b) limit
3578 the time for the entire SMTP dialogue for a single mail
3579 message. A sender-SMTP SHOULD use option (a), per-command
3580 timeouts. Timeouts SHOULD be easily reconfigurable, preferably
3581 without recompiling the SMTP code.
3584 Timeouts are an essential feature of an SMTP
3585 implementation. If the timeouts are too long (or worse,
3586 there are no timeouts), Internet communication failures or
3587 software bugs in receiver-SMTP programs can tie up SMTP
3588 processes indefinitely. If the timeouts are too short,
3589 resources will be wasted with attempts that time out part
3590 way through message delivery.
3592 If option (b) is used, the timeout has to be very large,
3593 e.g., an hour, to allow time to expand very large mailing
3594 lists. The timeout may also need to increase linearly
3598 Internet Engineering Task Force [Page 61]
3603 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3606 with the size of the message, to account for the time to
3607 transmit a very large message. A large fixed timeout
3608 leads to two problems: a failure can still tie up the
3609 sender for a very long time, and very large messages may
3610 still spuriously time out (which is a wasteful failure!).
3612 Using the recommended option (a), a timer is set for each
3613 SMTP command and for each buffer of the data transfer.
3614 The latter means that the overall timeout is inherently
3615 proportional to the size of the message.
3617 Based on extensive experience with busy mail-relay hosts, the
3618 minimum per-command timeout values SHOULD be as follows:
3620 o Initial 220 Message: 5 minutes
3622 A Sender-SMTP process needs to distinguish between a
3623 failed TCP connection and a delay in receiving the initial
3624 220 greeting message. Many receiver-SMTPs will accept a
3625 TCP connection but delay delivery of the 220 message until
3626 their system load will permit more mail to be processed.
3628 o MAIL Command: 5 minutes
3631 o RCPT Command: 5 minutes
3633 A longer timeout would be required if processing of
3634 mailing lists and aliases were not deferred until after
3635 the message was accepted.
3637 o DATA Initiation: 2 minutes
3639 This is while awaiting the "354 Start Input" reply to a
3642 o Data Block: 3 minutes
3644 This is while awaiting the completion of each TCP SEND
3645 call transmitting a chunk of data.
3647 o DATA Termination: 10 minutes.
3649 This is while awaiting the "250 OK" reply. When the
3650 receiver gets the final period terminating the message
3651 data, it typically performs processing to deliver the
3652 message to a user mailbox. A spurious timeout at this
3653 point would be very wasteful, since the message has been
3657 Internet Engineering Task Force [Page 62]
3662 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3667 A receiver-SMTP SHOULD have a timeout of at least 5 minutes
3668 while it is awaiting the next command from the sender.
3670 5.3.3 Reliable Mail Receipt
3672 When the receiver-SMTP accepts a piece of mail (by sending a
3673 "250 OK" message in response to DATA), it is accepting
3674 responsibility for delivering or relaying the message. It must
3675 take this responsibility seriously, i.e., it MUST NOT lose the
3676 message for frivolous reasons, e.g., because the host later
3677 crashes or because of a predictable resource shortage.
3679 If there is a delivery failure after acceptance of a message,
3680 the receiver-SMTP MUST formulate and mail a notification
3681 message. This notification MUST be sent using a null ("<>")
3682 reverse path in the envelope; see Section 3.6 of RFC-821. The
3683 recipient of this notification SHOULD be the address from the
3684 envelope return path (or the Return-Path: line). However, if
3685 this address is null ("<>"), the receiver-SMTP MUST NOT send a
3686 notification. If the address is an explicit source route, it
3687 SHOULD be stripped down to its final hop.
3690 For example, suppose that an error notification must be
3691 sent for a message that arrived with:
3692 "MAIL FROM:<@a,@b:user@d>". The notification message
3693 should be sent to: "RCPT TO:<user@d>".
3695 Some delivery failures after the message is accepted by
3696 SMTP will be unavoidable. For example, it may be
3697 impossible for the receiver-SMTP to validate all the
3698 delivery addresses in RCPT command(s) due to a "soft"
3699 domain system error or because the target is a mailing
3700 list (see earlier discussion of RCPT).
3702 To avoid receiving duplicate messages as the result of
3703 timeouts, a receiver-SMTP MUST seek to minimize the time
3704 required to respond to the final "." that ends a message
3705 transfer. See RFC-1047 [SMTP:4] for a discussion of this
3708 5.3.4 Reliable Mail Transmission
3710 To transmit a message, a sender-SMTP determines the IP address
3711 of the target host from the destination address in the
3712 envelope. Specifically, it maps the string to the right of the
3716 Internet Engineering Task Force [Page 63]
3721 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3724 "@" sign into an IP address. This mapping or the transfer
3725 itself may fail with a soft error, in which case the sender-
3726 SMTP will requeue the outgoing mail for a later retry, as
3727 required in Section 5.3.1.1.
3729 When it succeeds, the mapping can result in a list of
3730 alternative delivery addresses rather than a single address,
3731 because of (a) multiple MX records, (b) multihoming, or both.
3732 To provide reliable mail transmission, the sender-SMTP MUST be
3733 able to try (and retry) each of the addresses in this list in
3734 order, until a delivery attempt succeeds. However, there MAY
3735 also be a configurable limit on the number of alternate
3736 addresses that can be tried. In any case, a host SHOULD try at
3737 least two addresses.
3739 The following information is to be used to rank the host
3742 (1) Multiple MX Records -- these contain a preference
3743 indication that should be used in sorting. If there are
3744 multiple destinations with the same preference and there
3745 is no clear reason to favor one (e.g., by address
3746 preference), then the sender-SMTP SHOULD pick one at
3747 random to spread the load across multiple mail exchanges
3748 for a specific organization; note that this is a
3749 refinement of the procedure in [DNS:3].
3751 (2) Multihomed host -- The destination host (perhaps taken
3752 from the preferred MX record) may be multihomed, in which
3753 case the domain name resolver will return a list of
3754 alternative IP addresses. It is the responsibility of the
3755 domain name resolver interface (see Section 6.1.3.4 below)
3756 to have ordered this list by decreasing preference, and
3757 SMTP MUST try them in the order presented.
3760 Although the capability to try multiple alternative
3761 addresses is required, there may be circumstances where
3762 specific installations want to limit or disable the use of
3763 alternative addresses. The question of whether a sender
3764 should attempt retries using the different addresses of a
3765 multihomed host has been controversial. The main argument
3766 for using the multiple addresses is that it maximizes the
3767 probability of timely delivery, and indeed sometimes the
3768 probability of any delivery; the counter argument is that
3769 it may result in unnecessary resource use.
3771 Note that resource use is also strongly determined by the
3775 Internet Engineering Task Force [Page 64]
3780 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3783 sending strategy discussed in Section 5.3.1.
3785 5.3.5 Domain Name Support
3787 SMTP implementations MUST use the mechanism defined in Section
3788 6.1 for mapping between domain names and IP addresses. This
3789 means that every Internet SMTP MUST include support for the
3792 In particular, a sender-SMTP MUST support the MX record scheme
3793 [SMTP:3]. See also Section 7.4 of [DNS:2] for information on
3794 domain name support for SMTP.
3796 5.3.6 Mailing Lists and Aliases
3798 An SMTP-capable host SHOULD support both the alias and the list
3799 form of address expansion for multiple delivery. When a
3800 message is delivered or forwarded to each address of an
3801 expanded list form, the return address in the envelope
3802 ("MAIL FROM:") MUST be changed to be the address of a person
3803 who administers the list, but the message header MUST be left
3804 unchanged; in particular, the "From" field of the message is
3808 An important mail facility is a mechanism for multi-
3809 destination delivery of a single message, by transforming
3810 or "expanding" a pseudo-mailbox address into a list of
3811 destination mailbox addresses. When a message is sent to
3812 such a pseudo-mailbox (sometimes called an "exploder"),
3813 copies are forwarded or redistributed to each mailbox in
3814 the expanded list. We classify such a pseudo-mailbox as
3815 an "alias" or a "list", depending upon the expansion
3820 To expand an alias, the recipient mailer simply
3821 replaces the pseudo-mailbox address in the envelope
3822 with each of the expanded addresses in turn; the rest
3823 of the envelope and the message body are left
3824 unchanged. The message is then delivered or
3825 forwarded to each expanded address.
3829 A mailing list may be said to operate by
3830 "redistribution" rather than by "forwarding". To
3834 Internet Engineering Task Force [Page 65]
3839 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3842 expand a list, the recipient mailer replaces the
3843 pseudo-mailbox address in the envelope with each of
3844 the expanded addresses in turn. The return address in
3845 the envelope is changed so that all error messages
3846 generated by the final deliveries will be returned to
3847 a list administrator, not to the message originator,
3848 who generally has no control over the contents of the
3849 list and will typically find error messages annoying.
3852 5.3.7 Mail Gatewaying
3854 Gatewaying mail between different mail environments, i.e.,
3855 different mail formats and protocols, is complex and does not
3856 easily yield to standardization. See for example [SMTP:5a],
3857 [SMTP:5b]. However, some general requirements may be given for
3858 a gateway between the Internet and another mail environment.
3860 (A) Header fields MAY be rewritten when necessary as messages
3861 are gatewayed across mail environment boundaries.
3864 This may involve interpreting the local-part of the
3865 destination address, as suggested in Section 5.2.16.
3867 The other mail systems gatewayed to the Internet
3868 generally use a subset of RFC-822 headers, but some
3869 of them do not have an equivalent to the SMTP
3870 envelope. Therefore, when a message leaves the
3871 Internet environment, it may be necessary to fold the
3872 SMTP envelope information into the message header. A
3873 possible solution would be to create new header
3874 fields to carry the envelope information (e.g., "X-
3875 SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
3876 require changes in mail programs in the foreign
3879 (B) When forwarding a message into or out of the Internet
3880 environment, a gateway MUST prepend a Received: line, but
3881 it MUST NOT alter in any way a Received: line that is
3882 already in the header.
3885 This requirement is a subset of the general
3886 "Received:" line requirement of Section 5.2.8; it is
3887 restated here for emphasis.
3889 Received: fields of messages originating from other
3893 Internet Engineering Task Force [Page 66]
3898 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3901 environments may not conform exactly to RFC822.
3902 However, the most important use of Received: lines is
3903 for debugging mail faults, and this debugging can be
3904 severely hampered by well-meaning gateways that try
3905 to "fix" a Received: line.
3907 The gateway is strongly encouraged to indicate the
3908 environment and protocol in the "via" clauses of
3909 Received field(s) that it supplies.
3911 (C) From the Internet side, the gateway SHOULD accept all
3912 valid address formats in SMTP commands and in RFC-822
3913 headers, and all valid RFC-822 messages. Although a
3914 gateway must accept an RFC-822 explicit source route
3915 ("@...:" format) in either the RFC-822 header or in the
3916 envelope, it MAY or may not act on the source route; see
3917 Sections 5.2.6 and 5.2.19.
3920 It is often tempting to restrict the range of
3921 addresses accepted at the mail gateway to simplify
3922 the translation into addresses for the remote
3923 environment. This practice is based on the
3924 assumption that mail users have control over the
3925 addresses their mailers send to the mail gateway. In
3926 practice, however, users have little control over the
3927 addresses that are finally sent; their mailers are
3928 free to change addresses into any legal RFC-822
3931 (D) The gateway MUST ensure that all header fields of a
3932 message that it forwards into the Internet meet the
3933 requirements for Internet mail. In particular, all
3934 addresses in "From:", "To:", "Cc:", etc., fields must be
3935 transformed (if necessary) to satisfy RFC-822 syntax, and
3936 they must be effective and useful for sending replies.
3939 (E) The translation algorithm used to convert mail from the
3940 Internet protocols to another environment's protocol
3941 SHOULD try to ensure that error messages from the foreign
3942 mail environment are delivered to the return path from the
3943 SMTP envelope, not to the sender listed in the "From:"
3944 field of the RFC-822 message.
3947 Internet mail lists usually place the address of the
3948 mail list maintainer in the envelope but leave the
3952 Internet Engineering Task Force [Page 67]
3957 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3960 original message header intact (with the "From:"
3961 field containing the original sender). This yields
3962 the behavior the average recipient expects: a reply
3963 to the header gets sent to the original sender, not
3964 to a mail list maintainer; however, errors get sent
3965 to the maintainer (who can fix the problem) and not
3966 the sender (who probably cannot).
3968 (F) Similarly, when forwarding a message from another
3969 environment into the Internet, the gateway SHOULD set the
3970 envelope return path in accordance with an error message
3971 return address, if any, supplied by the foreign
3975 5.3.8 Maximum Message Size
3977 Mailer software MUST be able to send and receive messages of at
3978 least 64K bytes in length (including header), and a much larger
3979 maximum size is highly desirable.
3982 Although SMTP does not define the maximum size of a
3983 message, many systems impose implementation limits.
3985 The current de facto minimum limit in the Internet is 64K
3986 bytes. However, electronic mail is used for a variety of
3987 purposes that create much larger messages. For example,
3988 mail is often used instead of FTP for transmitting ASCII
3989 files, and in particular to transmit entire documents. As
3990 a result, messages can be 1 megabyte or even larger. We
3991 note that the present document together with its lower-
3992 layer companion contains 0.5 megabytes.
4011 Internet Engineering Task Force [Page 68]
4016 RFC1123 MAIL -- SMTP & RFC-822 October 1989
4019 5.4 SMTP REQUIREMENTS SUMMARY
4030 FEATURE |SECTION | | | |T|T|e
4031 -----------------------------------------------|----------|-|-|-|-|-|--
4033 RECEIVER-SMTP: | | | | | | |
4034 Implement VRFY |5.2.3 |x| | | | |
4035 Implement EXPN |5.2.3 | |x| | | |
4036 EXPN, VRFY configurable |5.2.3 | | |x| | |
4037 Implement SEND, SOML, SAML |5.2.4 | | |x| | |
4038 Verify HELO parameter |5.2.5 | | |x| | |
4039 Refuse message with bad HELO |5.2.5 | | | | |x|
4040 Accept explicit src-route syntax in env. |5.2.6 |x| | | | |
4041 Support "postmaster" |5.2.7 |x| | | | |
4042 Process RCPT when received (except lists) |5.2.7 | | |x| | |
4043 Long delay of RCPT responses |5.2.7 | | | | |x|
4045 Add Received: line |5.2.8 |x| | | | |
4046 Received: line include domain literal |5.2.8 | |x| | | |
4047 Change previous Received: line |5.2.8 | | | | |x|
4048 Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | |
4049 Support empty reverse path |5.2.9 |x| | | | |
4050 Send only official reply codes |5.2.10 | |x| | | |
4051 Send text from RFC-821 when appropriate |5.2.10 | |x| | | |
4052 Delete "." for transparency |5.2.11 |x| | | | |
4053 Accept and recognize self domain literal(s) |5.2.17 |x| | | | |
4055 Error message about error message |5.3.1 | | | | |x|
4056 Keep pending listen on SMTP port |5.3.1.2 | |x| | | |
4057 Provide limit on recv concurrency |5.3.1.2 | | |x| | |
4058 Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | |
4059 Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x|
4060 Send error notification msg after accept |5.3.3 |x| | | | |
4061 Send using null return path |5.3.3 |x| | | | |
4062 Send to envelope return path |5.3.3 | |x| | | |
4063 Send to null address |5.3.3 | | | | |x|
4064 Strip off explicit src route |5.3.3 | |x| | | |
4065 Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | |
4066 -----------------------------------------------|----------|-|-|-|-|-|--
4070 Internet Engineering Task Force [Page 69]
4075 RFC1123 MAIL -- SMTP & RFC-822 October 1989
4079 SENDER-SMTP: | | | | | | |
4080 Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | |
4081 Implement SEND, SOML, SAML |5.2.4 | | |x| | |
4082 Send valid principal host name in HELO |5.2.5 |x| | | | |
4083 Send explicit source route in RCPT TO: |5.2.6 | | | |x| |
4084 Use only reply code to determine action |5.2.10 |x| | | | |
4085 Use only high digit of reply code when poss. |5.2.10 | |x| | | |
4086 Add "." for transparency |5.2.11 |x| | | | |
4088 Retry messages after soft failure |5.3.1.1 |x| | | | |
4089 Delay before retry |5.3.1.1 |x| | | | |
4090 Configurable retry parameters |5.3.1.1 |x| | | | |
4091 Retry once per each queued dest host |5.3.1.1 | |x| | | |
4092 Multiple RCPT's for same DATA |5.3.1.1 | |x| | | |
4093 Support multiple concurrent transactions |5.3.1.1 | | |x| | |
4094 Provide limit on concurrency |5.3.1.1 | |x| | | |
4096 Timeouts on all activities |5.3.1 |x| | | | |
4097 Per-command timeouts |5.3.2 | |x| | | |
4098 Timeouts easily reconfigurable |5.3.2 | |x| | | |
4099 Recommended times |5.3.2 | |x| | | |
4100 Try alternate addr's in order |5.3.4 |x| | | | |
4101 Configurable limit on alternate tries |5.3.4 | | |x| | |
4102 Try at least two alternates |5.3.4 | |x| | | |
4103 Load-split across equal MX alternates |5.3.4 | |x| | | |
4104 Use the Domain Name System |5.3.5 |x| | | | |
4105 Support MX records |5.3.5 |x| | | | |
4106 Use WKS records in MX processing |5.2.12 | | | |x| |
4107 -----------------------------------------------|----------|-|-|-|-|-|--
4109 MAIL FORWARDING: | | | | | | |
4110 Alter existing header field(s) |5.2.6 | | | |x| |
4111 Implement relay function: 821/section 3.6 |5.2.6 | | |x| | |
4112 If not, deliver to RHS domain |5.2.6 | |x| | | |
4113 Interpret 'local-part' of addr |5.2.16 | | | | |x|
4115 MAILING LISTS AND ALIASES | | | | | | |
4116 Support both |5.3.6 | |x| | | |
4117 Report mail list error to local admin. |5.3.6 |x| | | | |
4119 MAIL GATEWAYS: | | | | | | |
4120 Embed foreign mail route in local-part |5.2.16 | | |x| | |
4121 Rewrite header fields when necessary |5.3.7 | | |x| | |
4122 Prepend Received: line |5.3.7 |x| | | | |
4123 Change existing Received: line |5.3.7 | | | | |x|
4124 Accept full RFC-822 on Internet side |5.3.7 | |x| | | |
4125 Act on RFC-822 explicit source route |5.3.7 | | |x| | |
4129 Internet Engineering Task Force [Page 70]
4134 RFC1123 MAIL -- SMTP & RFC-822 October 1989
4137 Send only valid RFC-822 on Internet side |5.3.7 |x| | | | |
4138 Deliver error msgs to envelope addr |5.3.7 | |x| | | |
4139 Set env return path from err return addr |5.3.7 | |x| | | |
4141 USER AGENT -- RFC-822 | | | | | | |
4142 Allow user to enter <route> address |5.2.6 | | | |x| |
4143 Support RFC-1049 Content Type field |5.2.13 | | |x| | |
4144 Use 4-digit years |5.2.14 | |x| | | |
4145 Generate numeric timezones |5.2.14 | |x| | | |
4146 Accept all timezones |5.2.14 |x| | | | |
4147 Use non-num timezones from RFC-822 |5.2.14 |x| | | | |
4148 Omit phrase before route-addr |5.2.15 | | |x| | |
4149 Accept and parse dot.dec. domain literals |5.2.17 |x| | | | |
4150 Accept all RFC-822 address formats |5.2.18 |x| | | | |
4151 Generate invalid RFC-822 address format |5.2.18 | | | | |x|
4152 Fully-qualified domain names in header |5.2.18 |x| | | | |
4153 Create explicit src route in header |5.2.19 | | | |x| |
4154 Accept explicit src route in header |5.2.19 |x| | | | |
4156 Send/recv at least 64KB messages |5.3.8 |x| | | | |
4188 Internet Engineering Task Force [Page 71]
4193 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4198 6.1 DOMAIN NAME TRANSLATION
4202 Every host MUST implement a resolver for the Domain Name System
4203 (DNS), and it MUST implement a mechanism using this DNS
4204 resolver to convert host names to IP addresses and vice-versa
4207 In addition to the DNS, a host MAY also implement a host name
4208 translation mechanism that searches a local Internet host
4209 table. See Section 6.1.3.8 for more information on this
4213 Internet host name translation was originally performed by
4214 searching local copies of a table of all hosts. This
4215 table became too large to update and distribute in a
4216 timely manner and too large to fit into many hosts, so the
4219 The DNS creates a distributed database used primarily for
4220 the translation between host names and host addresses.
4221 Implementation of DNS software is required. The DNS
4222 consists of two logically distinct parts: name servers and
4223 resolvers (although implementations often combine these
4224 two logical parts in the interest of efficiency) [DNS:2].
4226 Domain name servers store authoritative data about certain
4227 sections of the database and answer queries about the
4228 data. Domain resolvers query domain name servers for data
4229 on behalf of user processes. Every host therefore needs a
4230 DNS resolver; some host machines will also need to run
4231 domain name servers. Since no name server has complete
4232 information, in general it is necessary to obtain
4233 information from more than one name server to resolve a
4236 6.1.2 PROTOCOL WALK-THROUGH
4238 An implementor must study references [DNS:1] and [DNS:2]
4239 carefully. They provide a thorough description of the theory,
4240 protocol, and implementation of the domain name system, and
4241 reflect several years of experience.
4247 Internet Engineering Task Force [Page 72]
4252 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4255 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1
4257 All DNS name servers and resolvers MUST properly handle RRs
4258 with a zero TTL: return the RR to the client but do not
4262 Zero TTL values are interpreted to mean that the RR can
4263 only be used for the transaction in progress, and
4264 should not be cached; they are useful for extremely
4267 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5
4269 A query with "QCLASS=*" SHOULD NOT be used unless the
4270 requestor is seeking data from more than one class. In
4271 particular, if the requestor is only interested in Internet
4272 data types, QCLASS=IN MUST be used.
4274 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1
4276 Unused fields in a query or response message MUST be zero.
4278 6.1.2.4 Compression: RFC-1035 Section 4.1.4
4280 Name servers MUST use compression in responses.
4283 Compression is essential to avoid overflowing UDP
4284 datagrams; see Section 6.1.3.2.
4286 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2
4288 Recursive name servers and full-service resolvers generally
4289 have some configuration information containing hints about
4290 the location of root or local name servers. An
4291 implementation MUST NOT include any of these hints in a
4295 Many implementors have found it convenient to store
4296 these hints as if they were cached data, but some
4297 neglected to ensure that this "cached data" was not
4298 included in responses. This has caused serious
4299 problems in the Internet when the hints were obsolete
4306 Internet Engineering Task Force [Page 73]
4311 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4314 6.1.3 SPECIFIC ISSUES
4316 6.1.3.1 Resolver Implementation
4318 A name resolver SHOULD be able to multiplex concurrent
4319 requests if the host supports concurrent processes.
4321 In implementing a DNS resolver, one of two different models
4322 MAY optionally be chosen: a full-service resolver, or a stub
4326 (A) Full-Service Resolver
4328 A full-service resolver is a complete implementation of
4329 the resolver service, and is capable of dealing with
4330 communication failures, failure of individual name
4331 servers, location of the proper name server for a given
4332 name, etc. It must satisfy the following requirements:
4334 o The resolver MUST implement a local caching
4335 function to avoid repeated remote access for
4336 identical requests, and MUST time out information
4339 o The resolver SHOULD be configurable with start-up
4340 information pointing to multiple root name servers
4341 and multiple name servers for the local domain.
4342 This insures that the resolver will be able to
4343 access the whole name space in normal cases, and
4344 will be able to access local domain information
4345 should the local network become disconnected from
4346 the rest of the Internet.
4351 A "stub resolver" relies on the services of a recursive
4352 name server on the connected network or a "nearby"
4353 network. This scheme allows the host to pass on the
4354 burden of the resolver function to a name server on
4355 another host. This model is often essential for less
4356 capable hosts, such as PCs, and is also recommended
4357 when the host is one of several workstations on a local
4358 network, because it allows all of the workstations to
4359 share the cache of the recursive name server and hence
4360 reduce the number of domain requests exported by the
4365 Internet Engineering Task Force [Page 74]
4370 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4373 At a minimum, the stub resolver MUST be capable of
4374 directing its requests to redundant recursive name
4375 servers. Note that recursive name servers are allowed
4376 to restrict the sources of requests that they will
4377 honor, so the host administrator must verify that the
4378 service will be provided. Stub resolvers MAY implement
4379 caching if they choose, but if so, MUST timeout cached
4383 6.1.3.2 Transport Protocols
4385 DNS resolvers and recursive servers MUST support UDP, and
4386 SHOULD support TCP, for sending (non-zone-transfer) queries.
4387 Specifically, a DNS resolver or server that is sending a
4388 non-zone-transfer query MUST send a UDP query first. If the
4389 Answer section of the response is truncated and if the
4390 requester supports TCP, it SHOULD try the query again using
4393 DNS servers MUST be able to service UDP queries and SHOULD
4394 be able to service TCP queries. A name server MAY limit the
4395 resources it devotes to TCP queries, but it SHOULD NOT
4396 refuse to service a TCP query just because it would have
4399 Truncated responses MUST NOT be saved (cached) and later
4400 used in such a way that the fact that they are truncated is
4404 UDP is preferred over TCP for queries because UDP
4405 queries have much lower overhead, both in packet count
4406 and in connection state. The use of UDP is essential
4407 for heavily-loaded servers, especially the root
4408 servers. UDP also offers additional robustness, since
4409 a resolver can attempt several UDP queries to different
4410 servers for the cost of a single TCP query.
4412 It is possible for a DNS response to be truncated,
4413 although this is a very rare occurrence in the present
4414 Internet DNS. Practically speaking, truncation cannot
4415 be predicted, since it is data-dependent. The
4416 dependencies include the number of RRs in the answer,
4417 the size of each RR, and the savings in space realized
4418 by the name compression algorithm. As a rule of thumb,
4419 truncation in NS and MX lists should not occur for
4420 answers containing 15 or fewer RRs.
4424 Internet Engineering Task Force [Page 75]
4429 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4432 Whether it is possible to use a truncated answer
4433 depends on the application. A mailer must not use a
4434 truncated MX response, since this could lead to mail
4437 Responsible practices can make UDP suffice in the vast
4438 majority of cases. Name servers must use compression
4439 in responses. Resolvers must differentiate truncation
4440 of the Additional section of a response (which only
4441 loses extra information) from truncation of the Answer
4442 section (which for MX records renders the response
4443 unusable by mailers). Database administrators should
4444 list only a reasonable number of primary names in lists
4445 of name servers, MX alternatives, etc.
4447 However, it is also clear that some new DNS record
4448 types defined in the future will contain information
4449 exceeding the 512 byte limit that applies to UDP, and
4450 hence will require TCP. Thus, resolvers and name
4451 servers should implement TCP services as a backup to
4452 UDP today, with the knowledge that they will require
4453 the TCP service in the future.
4455 By private agreement, name servers and resolvers MAY arrange
4456 to use TCP for all traffic between themselves. TCP MUST be
4457 used for zone transfers.
4459 A DNS server MUST have sufficient internal concurrency that
4460 it can continue to process UDP queries while awaiting a
4461 response or performing a zone transfer on an open TCP
4464 A server MAY support a UDP query that is delivered using an
4465 IP broadcast or multicast address. However, the Recursion
4466 Desired bit MUST NOT be set in a query that is multicast,
4467 and MUST be ignored by name servers receiving queries via a
4468 broadcast or multicast address. A host that sends broadcast
4469 or multicast DNS queries SHOULD send them only as occasional
4470 probes, caching the IP address(es) it obtains from the
4471 response(s) so it can normally send unicast queries.
4474 Broadcast or (especially) IP multicast can provide a
4475 way to locate nearby name servers without knowing their
4476 IP addresses in advance. However, general broadcasting
4477 of recursive queries can result in excessive and
4478 unnecessary load on both network and servers.
4483 Internet Engineering Task Force [Page 76]
4488 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4491 6.1.3.3 Efficient Resource Usage
4493 The following requirements on servers and resolvers are very
4494 important to the health of the Internet as a whole,
4495 particularly when DNS services are invoked repeatedly by
4496 higher level automatic servers, such as mailers.
4498 (1) The resolver MUST implement retransmission controls to
4499 insure that it does not waste communication bandwidth,
4500 and MUST impose finite bounds on the resources consumed
4501 to respond to a single request. See [DNS:2] pages 43-
4502 44 for specific recommendations.
4504 (2) After a query has been retransmitted several times
4505 without a response, an implementation MUST give up and
4506 return a soft error to the application.
4508 (3) All DNS name servers and resolvers SHOULD cache
4509 temporary failures, with a timeout period of the order
4513 This will prevent applications that immediately
4514 retry soft failures (in violation of Section 2.2
4515 of this document) from generating excessive DNS
4518 (4) All DNS name servers and resolvers SHOULD cache
4519 negative responses that indicate the specified name, or
4520 data of the specified type, does not exist, as
4521 described in [DNS:2].
4523 (5) When a DNS server or resolver retries a UDP query, the
4524 retry interval SHOULD be constrained by an exponential
4525 backoff algorithm, and SHOULD also have upper and lower
4529 A measured RTT and variance (if available) should
4530 be used to calculate an initial retransmission
4531 interval. If this information is not available, a
4532 default of no less than 5 seconds should be used.
4533 Implementations may limit the retransmission
4534 interval, but this limit must exceed twice the
4535 Internet maximum segment lifetime plus service
4536 delay at the name server.
4538 (6) When a resolver or server receives a Source Quench for
4542 Internet Engineering Task Force [Page 77]
4547 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4550 a query it has issued, it SHOULD take steps to reduce
4551 the rate of querying that server in the near future. A
4552 server MAY ignore a Source Quench that it receives as
4553 the result of sending a response datagram.
4556 One recommended action to reduce the rate is to
4557 send the next query attempt to an alternate
4558 server, if there is one available. Another is to
4559 backoff the retry interval for the same server.
4562 6.1.3.4 Multihomed Hosts
4564 When the host name-to-address function encounters a host
4565 with multiple addresses, it SHOULD rank or sort the
4566 addresses using knowledge of the immediately connected
4567 network number(s) and any other applicable performance or
4568 history information.
4571 The different addresses of a multihomed host generally
4572 imply different Internet paths, and some paths may be
4573 preferable to others in performance, reliability, or
4574 administrative restrictions. There is no general way
4575 for the domain system to determine the best path. A
4576 recommended approach is to base this decision on local
4577 configuration information set by the system
4581 The following scheme has been used successfully:
4583 (a) Incorporate into the host configuration data a
4584 Network-Preference List, that is simply a list of
4585 networks in preferred order. This list may be
4586 empty if there is no preference.
4588 (b) When a host name is mapped into a list of IP
4589 addresses, these addresses should be sorted by
4590 network number, into the same order as the
4591 corresponding networks in the Network-Preference
4592 List. IP addresses whose networks do not appear
4593 in the Network-Preference List should be placed at
4594 the end of the list.
4601 Internet Engineering Task Force [Page 78]
4606 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4609 6.1.3.5 Extensibility
4611 DNS software MUST support all well-known, class-independent
4612 formats [DNS:2], and SHOULD be written to minimize the
4613 trauma associated with the introduction of new well-known
4614 types and local experimentation with non-standard types.
4617 The data types and classes used by the DNS are
4618 extensible, and thus new types will be added and old
4619 types deleted or redefined. Introduction of new data
4620 types ought to be dependent only upon the rules for
4621 compression of domain names inside DNS messages, and
4622 the translation between printable (i.e., master file)
4623 and internal formats for Resource Records (RRs).
4625 Compression relies on knowledge of the format of data
4626 inside a particular RR. Hence compression must only be
4627 used for the contents of well-known, class-independent
4628 RRs, and must never be used for class-specific RRs or
4629 RR types that are not well-known. The owner name of an
4630 RR is always eligible for compression.
4632 A name server may acquire, via zone transfer, RRs that
4633 the server doesn't know how to convert to printable
4634 format. A resolver can receive similar information as
4635 the result of queries. For proper operation, this data
4636 must be preserved, and hence the implication is that
4637 DNS software cannot use textual formats for internal
4640 The DNS defines domain name syntax very generally -- a
4641 string of labels each containing up to 63 8-bit octets,
4642 separated by dots, and with a maximum total of 255
4643 octets. Particular applications of the DNS are
4644 permitted to further constrain the syntax of the domain
4645 names they use, although the DNS deployment has led to
4646 some applications allowing more general names. In
4647 particular, Section 2.1 of this document liberalizes
4648 slightly the syntax of a legal Internet host name that
4649 was defined in RFC-952 [DNS:4].
4651 6.1.3.6 Status of RR Types
4653 Name servers MUST be able to load all RR types except MD and
4654 MF from configuration files. The MD and MF types are
4655 obsolete and MUST NOT be implemented; in particular, name
4656 servers MUST NOT load these types from configuration files.
4660 Internet Engineering Task Force [Page 79]
4665 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4669 The RR types MB, MG, MR, NULL, MINFO and RP are
4670 considered experimental, and applications that use the
4671 DNS cannot expect these RR types to be supported by
4672 most domains. Furthermore these types are subject to
4675 The TXT and WKS RR types have not been widely used by
4676 Internet sites; as a result, an application cannot rely
4677 on the the existence of a TXT or WKS RR in most
4682 DNS software may need to operate in environments where the
4683 root servers or other servers are unavailable due to network
4684 connectivity or other problems. In this situation, DNS name
4685 servers and resolvers MUST continue to provide service for
4686 the reachable part of the name space, while giving temporary
4687 failures for the rest.
4690 Although the DNS is meant to be used primarily in the
4691 connected Internet, it should be possible to use the
4692 system in networks which are unconnected to the
4693 Internet. Hence implementations must not depend on
4694 access to root servers before providing service for
4697 6.1.3.8 Local Host Table
4700 A host may use a local host table as a backup or
4701 supplement to the DNS. This raises the question of
4702 which takes precedence, the DNS or the host table; the
4703 most flexible approach would make this a configuration
4706 Typically, the contents of such a supplementary host
4707 table will be determined locally by the site. However,
4708 a publically-available table of Internet hosts is
4709 maintained by the DDN Network Information Center (DDN
4710 NIC), with a format documented in [DNS:4]. This table
4711 can be retrieved from the DDN NIC using a protocol
4712 described in [DNS:5]. It must be noted that this table
4713 contains only a small fraction of all Internet hosts.
4714 Hosts using this protocol to retrieve the DDN NIC host
4715 table should use the VERSION command to check if the
4719 Internet Engineering Task Force [Page 80]
4724 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4727 table has changed before requesting the entire table
4728 with the ALL command. The VERSION identifier should be
4729 treated as an arbitrary string and tested only for
4730 equality; no numerical sequence may be assumed.
4732 The DDN NIC host table includes administrative
4733 information that is not needed for host operation and
4734 is therefore not currently included in the DNS
4735 database; examples include network and gateway entries.
4736 However, much of this additional information will be
4737 added to the DNS in the future. Conversely, the DNS
4738 provides essential services (in particular, MX records)
4739 that are not available from the DDN NIC host table.
4741 6.1.4 DNS USER INTERFACE
4743 6.1.4.1 DNS Administration
4745 This document is concerned with design and implementation
4746 issues in host software, not with administrative or
4747 operational issues. However, administrative issues are of
4748 particular importance in the DNS, since errors in particular
4749 segments of this large distributed database can cause poor
4750 or erroneous performance for many sites. These issues are
4751 discussed in [DNS:6] and [DNS:7].
4753 6.1.4.2 DNS User Interface
4755 Hosts MUST provide an interface to the DNS for all
4756 application programs running on the host. This interface
4757 will typically direct requests to a system process to
4758 perform the resolver function [DNS:1, 6.1:2].
4760 At a minimum, the basic interface MUST support a request for
4761 all information of a specific type and class associated with
4762 a specific name, and it MUST return either all of the
4763 requested information, a hard error code, or a soft error
4764 indication. When there is no error, the basic interface
4765 returns the complete response information without
4766 modification, deletion, or ordering, so that the basic
4767 interface will not need to be changed to accommodate new
4771 The soft error indication is an essential part of the
4772 interface, since it may not always be possible to
4773 access particular information from the DNS; see Section
4778 Internet Engineering Task Force [Page 81]
4783 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4786 A host MAY provide other DNS interfaces tailored to
4787 particular functions, transforming the raw domain data into
4788 formats more suited to these functions. In particular, a
4789 host MUST provide a DNS interface to facilitate translation
4790 between host addresses and host names.
4792 6.1.4.3 Interface Abbreviation Facilities
4794 User interfaces MAY provide a method for users to enter
4795 abbreviations for commonly-used names. Although the
4796 definition of such methods is outside of the scope of the
4797 DNS specification, certain rules are necessary to insure
4798 that these methods allow access to the entire DNS name space
4799 and to prevent excessive use of Internet resources.
4801 If an abbreviation method is provided, then:
4803 (a) There MUST be some convention for denoting that a name
4804 is already complete, so that the abbreviation method(s)
4805 are suppressed. A trailing dot is the usual method.
4807 (b) Abbreviation expansion MUST be done exactly once, and
4808 MUST be done in the context in which the name was
4813 For example, if an abbreviation is used in a mail
4814 program for a destination, the abbreviation should be
4815 expanded into a full domain name and stored in the
4816 queued message with an indication that it is already
4817 complete. Otherwise, the abbreviation might be
4818 expanded with a mail system search list, not the
4819 user's, or a name could grow due to repeated
4820 canonicalizations attempts interacting with wildcards.
4822 The two most common abbreviation methods are:
4824 (1) Interface-level aliases
4826 Interface-level aliases are conceptually implemented as
4827 a list of alias/domain name pairs. The list can be
4828 per-user or per-host, and separate lists can be
4829 associated with different functions, e.g. one list for
4830 host name-to-address translation, and a different list
4831 for mail domains. When the user enters a name, the
4832 interface attempts to match the name to the alias
4833 component of a list entry, and if a matching entry can
4837 Internet Engineering Task Force [Page 82]
4842 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4845 be found, the name is replaced by the domain name found
4848 Note that interface-level aliases and CNAMEs are
4849 completely separate mechanisms; interface-level aliases
4850 are a local matter while CNAMEs are an Internet-wide
4851 aliasing mechanism which is a required part of any DNS
4856 A search list is conceptually implemented as an ordered
4857 list of domain names. When the user enters a name, the
4858 domain names in the search list are used as suffixes to
4859 the user-supplied name, one by one, until a domain name
4860 with the desired associated data is found, or the
4861 search list is exhausted. Search lists often contain
4862 the name of the local host's parent domain or other
4863 ancestor domains. Search lists are often per-user or
4866 It SHOULD be possible for an administrator to disable a
4867 DNS search-list facility. Administrative denial may be
4868 warranted in some cases, to prevent abuse of the DNS.
4870 There is danger that a search-list mechanism will
4871 generate excessive queries to the root servers while
4872 testing whether user input is a complete domain name,
4873 lacking a final period to mark it as complete. A
4874 search-list mechanism MUST have one of, and SHOULD have
4875 both of, the following two provisions to prevent this:
4877 (a) The local resolver/name server can implement
4878 caching of negative responses (see Section
4881 (b) The search list expander can require two or more
4882 interior dots in a generated domain name before it
4883 tries using the name in a query to non-local
4884 domain servers, such as the root.
4887 The intent of this requirement is to avoid
4888 excessive delay for the user as the search list is
4889 tested, and more importantly to prevent excessive
4890 traffic to the root and other high-level servers.
4891 For example, if the user supplied a name "X" and
4892 the search list contained the root as a component,
4896 Internet Engineering Task Force [Page 83]
4901 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4904 a query would have to consult a root server before
4905 the next search list alternative could be tried.
4906 The resulting load seen by the root servers and
4907 gateways near the root would be multiplied by the
4908 number of hosts in the Internet.
4910 The negative caching alternative limits the effect
4911 to the first time a name is used. The interior
4912 dot rule is simpler to implement but can prevent
4913 easy use of some top-level names.
4916 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
4927 FEATURE |SECTION | | | |T|T|e
4928 -----------------------------------------------|-----------|-|-|-|-|-|--
4929 GENERAL ISSUES | | | | | | |
4931 Implement DNS name-to-address conversion |6.1.1 |x| | | | |
4932 Implement DNS address-to-name conversion |6.1.1 |x| | | | |
4933 Support conversions using host table |6.1.1 | | |x| | |
4934 Properly handle RR with zero TTL |6.1.2.1 |x| | | | |
4935 Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | |
4936 Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | |
4937 Unused fields zero |6.1.2.3 |x| | | | |
4938 Use compression in responses |6.1.2.4 |x| | | | |
4940 Include config info in responses |6.1.2.5 | | | | |x|
4941 Support all well-known, class-indep. types |6.1.3.5 |x| | | | |
4942 Easily expand type list |6.1.3.5 | |x| | | |
4943 Load all RR types (except MD and MF) |6.1.3.6 |x| | | | |
4944 Load MD or MF type |6.1.3.6 | | | | |x|
4945 Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | |
4946 -----------------------------------------------|-----------|-|-|-|-|-|--
4947 RESOLVER ISSUES: | | | | | | |
4949 Resolver support multiple concurrent requests |6.1.3.1 | |x| | | |
4950 Full-service resolver: |6.1.3.1 | | |x| | |
4951 Local caching |6.1.3.1 |x| | | | |
4955 Internet Engineering Task Force [Page 84]
4960 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4963 Information in local cache times out |6.1.3.1 |x| | | | |
4964 Configurable with starting info |6.1.3.1 | |x| | | |
4965 Stub resolver: |6.1.3.1 | | |x| | |
4966 Use redundant recursive name servers |6.1.3.1 |x| | | | |
4967 Local caching |6.1.3.1 | | |x| | |
4968 Information in local cache times out |6.1.3.1 |x| | | | |
4969 Support for remote multi-homed hosts: | | | | | | |
4970 Sort multiple addresses by preference list |6.1.3.4 | |x| | | |
4972 -----------------------------------------------|-----------|-|-|-|-|-|--
4973 TRANSPORT PROTOCOLS: | | | | | | |
4975 Support UDP queries |6.1.3.2 |x| | | | |
4976 Support TCP queries |6.1.3.2 | |x| | | |
4977 Send query using UDP first |6.1.3.2 |x| | | | |1
4978 Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | |
4979 Name server limit TCP query resources |6.1.3.2 | | |x| | |
4980 Punish unnecessary TCP query |6.1.3.2 | | | |x| |
4981 Use truncated data as if it were not |6.1.3.2 | | | | |x|
4982 Private agreement to use only TCP |6.1.3.2 | | |x| | |
4983 Use TCP for zone transfers |6.1.3.2 |x| | | | |
4984 TCP usage not block UDP queries |6.1.3.2 |x| | | | |
4985 Support broadcast or multicast queries |6.1.3.2 | | |x| | |
4986 RD bit set in query |6.1.3.2 | | | | |x|
4987 RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | |
4988 Send only as occasional probe for addr's |6.1.3.2 | |x| | | |
4989 -----------------------------------------------|-----------|-|-|-|-|-|--
4990 RESOURCE USAGE: | | | | | | |
4992 Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | |
4993 Finite bounds per request |6.1.3.3 |x| | | | |
4994 Failure after retries => soft error |6.1.3.3 |x| | | | |
4995 Cache temporary failures |6.1.3.3 | |x| | | |
4996 Cache negative responses |6.1.3.3 | |x| | | |
4997 Retries use exponential backoff |6.1.3.3 | |x| | | |
4998 Upper, lower bounds |6.1.3.3 | |x| | | |
4999 Client handle Source Quench |6.1.3.3 | |x| | | |
5000 Server ignore Source Quench |6.1.3.3 | | |x| | |
5001 -----------------------------------------------|-----------|-|-|-|-|-|--
5002 USER INTERFACE: | | | | | | |
5004 All programs have access to DNS interface |6.1.4.2 |x| | | | |
5005 Able to request all info for given name |6.1.4.2 |x| | | | |
5006 Returns complete info or error |6.1.4.2 |x| | | | |
5007 Special interfaces |6.1.4.2 | | |x| | |
5008 Name<->Address translation |6.1.4.2 |x| | | | |
5010 Abbreviation Facilities: |6.1.4.3 | | |x| | |
5014 Internet Engineering Task Force [Page 85]
5019 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
5022 Convention for complete names |6.1.4.3 |x| | | | |
5023 Conversion exactly once |6.1.4.3 |x| | | | |
5024 Conversion in proper context |6.1.4.3 |x| | | | |
5025 Search list: |6.1.4.3 | | |x| | |
5026 Administrator can disable |6.1.4.3 | |x| | | |
5027 Prevention of excessive root queries |6.1.4.3 |x| | | | |
5028 Both methods |6.1.4.3 | |x| | | |
5029 -----------------------------------------------|-----------|-|-|-|-|-|--
5030 -----------------------------------------------|-----------|-|-|-|-|-|--
5032 1. Unless there is private agreement between particular resolver and
5073 Internet Engineering Task Force [Page 86]
5078 RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
5081 6.2 HOST INITIALIZATION
5085 This section discusses the initialization of host software
5086 across a connected network, or more generally across an
5087 Internet path. This is necessary for a diskless host, and may
5088 optionally be used for a host with disk drives. For a diskless
5089 host, the initialization process is called "network booting"
5090 and is controlled by a bootstrap program located in a boot ROM.
5092 To initialize a diskless host across the network, there are two
5095 (1) Configure the IP layer.
5097 Diskless machines often have no permanent storage in which
5098 to store network configuration information, so that
5099 sufficient configuration information must be obtained
5100 dynamically to support the loading phase that follows.
5101 This information must include at least the IP addresses of
5102 the host and of the boot server. To support booting
5103 across a gateway, the address mask and a list of default
5104 gateways are also required.
5106 (2) Load the host system code.
5108 During the loading phase, an appropriate file transfer
5109 protocol is used to copy the system code across the
5110 network from the boot server.
5112 A host with a disk may perform the first step, dynamic
5113 configuration. This is important for microcomputers, whose
5114 floppy disks allow network configuration information to be
5115 mistakenly duplicated on more than one host. Also,
5116 installation of new hosts is much simpler if they automatically
5117 obtain their configuration information from a central server,
5118 saving administrator time and decreasing the probability of
5123 6.2.2.1 Dynamic Configuration
5125 A number of protocol provisions have been made for dynamic
5128 o ICMP Information Request/Reply messages
5132 Internet Engineering Task Force [Page 87]
5137 RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
5140 This obsolete message pair was designed to allow a host
5141 to find the number of the network it is on.
5142 Unfortunately, it was useful only if the host already
5143 knew the host number part of its IP address,
5144 information that hosts requiring dynamic configuration
5147 o Reverse Address Resolution Protocol (RARP) [BOOT:4]
5149 RARP is a link-layer protocol for a broadcast medium
5150 that allows a host to find its IP address given its
5151 link layer address. Unfortunately, RARP does not work
5152 across IP gateways and therefore requires a RARP server
5153 on every network. In addition, RARP does not provide
5154 any other configuration information.
5156 o ICMP Address Mask Request/Reply messages
5158 These ICMP messages allow a host to learn the address
5159 mask for a particular network interface.
5161 o BOOTP Protocol [BOOT:2]
5163 This protocol allows a host to determine the IP
5164 addresses of the local host and the boot server, the
5165 name of an appropriate boot file, and optionally the
5166 address mask and list of default gateways. To locate a
5167 BOOTP server, the host broadcasts a BOOTP request using
5168 UDP. Ad hoc gateway extensions have been used to
5169 transmit the BOOTP broadcast through gateways, and in
5170 the future the IP Multicasting facility will provide a
5171 standard mechanism for this purpose.
5174 The suggested approach to dynamic configuration is to use
5175 the BOOTP protocol with the extensions defined in "BOOTP
5176 Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084
5177 defines some important general (not vendor-specific)
5178 extensions. In particular, these extensions allow the
5179 address mask to be supplied in BOOTP; we RECOMMEND that the
5180 address mask be supplied in this manner.
5183 Historically, subnetting was defined long after IP, and
5184 so a separate mechanism (ICMP Address Mask messages)
5185 was designed to supply the address mask to a host.
5186 However, the IP address mask and the corresponding IP
5187 address conceptually form a pair, and for operational
5191 Internet Engineering Task Force [Page 88]
5196 RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
5199 simplicity they ought to be defined at the same time
5200 and by the same mechanism, whether a configuration file
5201 or a dynamic mechanism like BOOTP.
5203 Note that BOOTP is not sufficiently general to specify
5204 the configurations of all interfaces of a multihomed
5205 host. A multihomed host must either use BOOTP
5206 separately for each interface, or configure one
5207 interface using BOOTP to perform the loading, and
5208 perform the complete initialization from a file later.
5210 Application layer configuration information is expected
5211 to be obtained from files after loading of the system
5214 6.2.2.2 Loading Phase
5216 A suggested approach for the loading phase is to use TFTP
5217 [BOOT:1] between the IP addresses established by BOOTP.
5219 TFTP to a broadcast address SHOULD NOT be used, for reasons
5220 explained in Section 4.2.3.4.
5250 Internet Engineering Task Force [Page 89]
5255 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5258 6.3 REMOTE MANAGEMENT
5262 The Internet community has recently put considerable effort
5263 into the development of network management protocols. The
5264 result has been a two-pronged approach [MGT:1, MGT:6]: the
5265 Simple Network Management Protocol (SNMP) [MGT:4] and the
5266 Common Management Information Protocol over TCP (CMOT) [MGT:5].
5268 In order to be managed using SNMP or CMOT, a host will need to
5269 implement an appropriate management agent. An Internet host
5270 SHOULD include an agent for either SNMP or CMOT.
5272 Both SNMP and CMOT operate on a Management Information Base
5273 (MIB) that defines a collection of management values. By
5274 reading and setting these values, a remote application may
5275 query and change the state of the managed system.
5277 A standard MIB [MGT:3] has been defined for use by both
5278 management protocols, using data types defined by the Structure
5279 of Management Information (SMI) defined in [MGT:2]. Additional
5280 MIB variables can be introduced under the "enterprises" and
5281 "experimental" subtrees of the MIB naming space [MGT:2].
5283 Every protocol module in the host SHOULD implement the relevant
5284 MIB variables. A host SHOULD implement the MIB variables as
5285 defined in the most recent standard MIB, and MAY implement
5286 other MIB variables when appropriate and useful.
5288 6.3.2 PROTOCOL WALK-THROUGH
5290 The MIB is intended to cover both hosts and gateways, although
5291 there may be detailed differences in MIB application to the two
5292 cases. This section contains the appropriate interpretation of
5293 the MIB for hosts. It is likely that later versions of the MIB
5294 will include more entries for host management.
5296 A managed host must implement the following groups of MIB
5297 object definitions: System, Interfaces, Address Translation,
5298 IP, ICMP, TCP, and UDP.
5300 The following specific interpretations apply to hosts:
5304 Note that the error "time-to-live exceeded" can occur in a
5305 host only when it is forwarding a source-routed datagram.
5309 Internet Engineering Task Force [Page 90]
5314 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5319 This object counts datagrams discarded because no route
5320 can be found. This may happen in a host if all the
5321 default gateways in the host's configuration are down.
5323 o ipFragOKs, ipFragFails, ipFragCreates
5325 A host that does not implement intentional fragmentation
5326 (see "Fragmentation" section of [INTRO:1]) MUST return the
5327 value zero for these three objects.
5331 For a host, this object MUST always be zero, since hosts
5332 do not send Redirects.
5334 o icmpOutAddrMaskReps
5336 For a host, this object MUST always be zero, unless the
5337 host is an authoritative source of address mask
5342 For a host, the "IP Address Table" object is effectively a
5343 table of logical interfaces.
5347 For a host, the "IP Routing Table" object is effectively a
5348 combination of the host's Routing Cache and the static
5349 route table described in "Routing Outbound Datagrams"
5350 section of [INTRO:1].
5352 Within each ipRouteEntry, ipRouteMetric1...4 normally will
5353 have no meaning for a host and SHOULD always be -1, while
5354 ipRouteType will normally have the value "remote".
5356 If destinations on the connected network do not appear in
5357 the Route Cache (see "Routing Outbound Datagrams section
5358 of [INTRO:1]), there will be no entries with ipRouteType
5363 The current MIB does not include Type-of-Service in an
5364 ipRouteEntry, but a future revision is expected to make
5368 Internet Engineering Task Force [Page 91]
5373 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5378 We also expect the MIB to be expanded to allow the remote
5379 management of applications (e.g., the ability to partially
5380 reconfigure mail systems). Network service applications
5381 such as mail systems should therefore be written with the
5382 "hooks" for remote management.
5384 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY
5395 FEATURE |SECTION | | | |T|T|e
5396 -----------------------------------------------|-----------|-|-|-|-|-|--
5397 Support SNMP or CMOT agent |6.3.1 | |x| | | |
5398 Implement specified objects in standard MIB |6.3.1 | |x| | | |
5427 Internet Engineering Task Force [Page 92]
5432 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5437 This section lists the primary references with which every
5438 implementer must be thoroughly familiar. It also lists some
5439 secondary references that are suggested additional reading.
5441 INTRODUCTORY REFERENCES:
5444 [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
5445 IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
5448 [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
5449 (three volumes), SRI International, December 1985.
5451 [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel,
5454 This document is republished periodically with new RFC numbers;
5455 the latest version must be used.
5457 [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J.
5458 Postel, RFC-980, March 1986.
5460 [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
5463 This document is republished periodically with new RFC numbers;
5464 the latest version must be used.
5470 [TELNET:1] "Telnet Protocol Specification," J. Postel and J.
5471 Reynolds, RFC-854, May 1983.
5473 [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds,
5476 [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds,
5479 [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
5482 [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J.
5486 Internet Engineering Task Force [Page 93]
5491 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5494 Reynolds, RFC-858, May 1983.
5496 [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC-
5499 [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds,
5502 [TELNET:8] "Telnet Extended Options List," J. Postel and J.
5503 Reynolds, RFC-861, May 1983.
5505 [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855,
5508 [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
5511 This document supercedes RFC-930.
5513 [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
5516 [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
5519 [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
5522 [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
5523 1080, November 1988.
5526 SECONDARY TELNET REFERENCES:
5529 [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
5532 This document is intended to describe the same protocol as RFC-
5533 854. In case of conflict, RFC-854 takes precedence, and the
5534 present document takes precedence over both.
5536 [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
5538 [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
5541 [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
5545 Internet Engineering Task Force [Page 94]
5550 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5553 [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
5554 Implementation," A. Yasuda and T. Thompson, RFC-1043, February
5561 [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
5564 [FTP:2] "Document File Format Standards," J. Postel, RFC-678,
5567 [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of
5570 This document is based on an earlier version of the FTP
5571 specification (RFC-765) and is obsolete.
5577 [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
5584 [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
5587 [SMTP:2] "Standard For The Format of ARPA Internet Text Messages,"
5588 D. Crocker, RFC-822, August 1982.
5590 This document obsoleted an earlier specification, RFC-733.
5592 [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC-
5595 This RFC describes the use of MX records, a mandatory extension
5596 to the mail delivery process.
5598 [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
5604 Internet Engineering Task Force [Page 95]
5609 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5612 [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
5615 [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
5617 The two preceding RFC's define a proposed standard for
5618 gatewaying mail between the Internet and the X.400 environments.
5620 [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S.
5621 Department of Defense, May 1984.
5623 This specification is intended to describe the same protocol as
5624 does RFC-821. However, MIL-STD-1781 is incomplete; in
5625 particular, it does not include MX records [SMTP:3].
5627 [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu,
5628 RFC-1049, March 1988.
5631 DOMAIN NAME SYSTEM REFERENCES:
5634 [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris,
5635 RFC-1034, November 1987.
5637 This document and the following one obsolete RFC-882, RFC-883,
5640 [DNS:2] "Domain Names - Implementation and Specification," RFC-1035,
5641 P. Mockapetris, November 1987.
5644 [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974,
5648 [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein,
5649 RFC-952, M. Stahl, E. Feinler, October 1985.
5651 SECONDARY DNS REFERENCES:
5654 [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
5655 RFC-953, October 1985.
5657 [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November
5663 Internet Engineering Task Force [Page 96]
5668 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5671 [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC-
5672 1033, November 1987.
5674 [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet
5675 Protocol Handbook, NIC 50007, SRI Network Information Center,
5679 SYSTEM INITIALIZATION REFERENCES:
5682 [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
5685 [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
5686 951, September 1985.
5688 [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
5689 1084, December 1988.
5691 Note: this RFC revised and obsoleted RFC-1048.
5693 [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
5694 Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
5697 MANAGEMENT REFERENCES:
5700 [MGT:1] "IAB Recommendations for the Development of Internet Network
5701 Management Standards," V. Cerf, RFC-1052, April 1988.
5703 [MGT:2] "Structure and Identification of Management Information for
5704 TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
5707 [MGT:3] "Management Information Base for Network Management of
5708 TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
5711 [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor,
5712 M. Schoffstall, and C. Davin, RFC-1098, April 1989.
5714 [MGT:5] "The Common Management Information Services and Protocol
5715 over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
5717 [MGT:6] "Report of the Second Ad Hoc Network Management Review
5718 Group," V. Cerf, RFC-1109, August 1989.
5722 Internet Engineering Task Force [Page 97]
5727 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5730 Security Considerations
5732 There are many security issues in the application and support
5733 programs of host software, but a full discussion is beyond the scope
5734 of this RFC. Security-related issues are mentioned in sections
5735 concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
5736 EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
5737 SMTP DATA command (Section 5.2.8).
5742 USC/Information Sciences Institute
5744 Marina del Rey, CA 90292-6695
5746 Phone: (213) 822 1511
5748 EMail: Braden@ISI.EDU
5781 Internet Engineering Task Force [Page 98]
projects / FreeBSD / releng / 7.2.git / blob