1 Network Working Group Internet Engineering Task Force
2 Request for Comments: 1123 R. Braden, Editor
3 October 1989
4
5
6 Requirements for Internet Hosts -- Application and Support
7
8 Status of This Memo
9
10 This RFC is an official specification for the Internet community. It
11 incorporates by reference, amends, corrects, and supplements the
12 primary protocol standards documents relating to hosts. Distribution
13 of this document is unlimited.
14
15 Summary
16
17 This RFC is one of a pair that defines and discusses the requirements
18 for Internet host software. This RFC covers the application and
19 support protocols; its companion RFC-1122 covers the communication
20 protocol layers: link layer, IP layer, and transport layer.
21
22
23
24 Table of Contents
25
26
27
28
29 1. INTRODUCTION ............................................... 5
30 1.1 The Internet Architecture .............................. 6
31 1.2 General Considerations ................................. 6
32 1.2.1 Continuing Internet Evolution ..................... 6
33 1.2.2 Robustness Principle .............................. 7
34 1.2.3 Error Logging ..................................... 8
35 1.2.4 Configuration ..................................... 8
36 1.3 Reading this Document .................................. 10
37 1.3.1 Organization ...................................... 10
38 1.3.2 Requirements ...................................... 10
39 1.3.3 Terminology ....................................... 11
40 1.4 Acknowledgments ........................................ 12
41
42 2. GENERAL ISSUES ............................................. 13
43 2.1 Host Names and Numbers ................................. 13
44 2.2 Using Domain Name Service .............................. 13
45 2.3 Applications on Multihomed hosts ....................... 14
46 2.4 Type-of-Service ........................................ 14
47 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15
48
49
50
51
52 Internet Engineering Task Force [Page 1]
53 RFC1123 INTRODUCTION October 1989
54
55
56 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16
57 3.1 INTRODUCTION ........................................... 16
58 3.2 PROTOCOL WALK-THROUGH .................................. 16
59 3.2.1 Option Negotiation ................................ 16
60 3.2.2 Telnet Go-Ahead Function .......................... 16
61 3.2.3 Control Functions ................................. 17
62 3.2.4 Telnet "Synch" Signal ............................. 18
63 3.2.5 NVT Printer and Keyboard .......................... 19
64 3.2.6 Telnet Command Structure .......................... 20
65 3.2.7 Telnet Binary Option .............................. 20
66 3.2.8 Telnet Terminal-Type Option ....................... 20
67 3.3 SPECIFIC ISSUES ........................................ 21
68 3.3.1 Telnet End-of-Line Convention ..................... 21
69 3.3.2 Data Entry Terminals .............................. 23
70 3.3.3 Option Requirements ............................... 24
71 3.3.4 Option Initiation ................................. 24
72 3.3.5 Telnet Linemode Option ............................ 25
73 3.4 TELNET/USER INTERFACE .................................. 25
74 3.4.1 Character Set Transparency ........................ 25
75 3.4.2 Telnet Commands ................................... 26
76 3.4.3 TCP Connection Errors ............................. 26
77 3.4.4 Non-Default Telnet Contact Port ................... 26
78 3.4.5 Flushing Output ................................... 26
79 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27
80
81 4. FILE TRANSFER .............................................. 29
82 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29
83 4.1.1 INTRODUCTION ...................................... 29
84 4.1.2. PROTOCOL WALK-THROUGH ............................ 29
85 4.1.2.1 LOCAL Type ................................... 29
86 4.1.2.2 Telnet Format Control ........................ 30
87 4.1.2.3 Page Structure ............................... 30
88 4.1.2.4 Data Structure Transformations ............... 30
89 4.1.2.5 Data Connection Management ................... 31
90 4.1.2.6 PASV Command ................................. 31
91 4.1.2.7 LIST and NLST Commands ....................... 31
92 4.1.2.8 SITE Command ................................. 32
93 4.1.2.9 STOU Command ................................. 32
94 4.1.2.10 Telnet End-of-line Code ..................... 32
95 4.1.2.11 FTP Replies ................................. 33
96 4.1.2.12 Connections ................................. 34
97 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34
98 4.1.3 SPECIFIC ISSUES ................................... 35
99 4.1.3.1 Non-standard Command Verbs ................... 35
100 4.1.3.2 Idle Timeout ................................. 36
101 4.1.3.3 Concurrency of Data and Control .............. 36
102 4.1.3.4 FTP Restart Mechanism ........................ 36
103 4.1.4 FTP/USER INTERFACE ................................ 39
104
105
106
107 Internet Engineering Task Force [Page 2]
108 RFC1123 INTRODUCTION October 1989
109
110
111 4.1.4.1 Pathname Specification ....................... 39
112 4.1.4.2 "QUOTE" Command .............................. 40
113 4.1.4.3 Displaying Replies to User ................... 40
114 4.1.4.4 Maintaining Synchronization .................. 40
115 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41
116 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44
117 4.2.1 INTRODUCTION ...................................... 44
118 4.2.2 PROTOCOL WALK-THROUGH ............................. 44
119 4.2.2.1 Transfer Modes ............................... 44
120 4.2.2.2 UDP Header ................................... 44
121 4.2.3 SPECIFIC ISSUES ................................... 44
122 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44
123 4.2.3.2 Timeout Algorithms ........................... 46
124 4.2.3.3 Extensions ................................... 46
125 4.2.3.4 Access Control ............................... 46
126 4.2.3.5 Broadcast Request ............................ 46
127 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47
128
129 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48
130 5.1 INTRODUCTION ........................................... 48
131 5.2 PROTOCOL WALK-THROUGH .................................. 48
132 5.2.1 The SMTP Model .................................... 48
133 5.2.2 Canonicalization .................................. 49
134 5.2.3 VRFY and EXPN Commands ............................ 50
135 5.2.4 SEND, SOML, and SAML Commands ..................... 50
136 5.2.5 HELO Command ...................................... 50
137 5.2.6 Mail Relay ........................................ 51
138 5.2.7 RCPT Command ...................................... 52
139 5.2.8 DATA Command ...................................... 53
140 5.2.9 Command Syntax .................................... 54
141 5.2.10 SMTP Replies ..................................... 54
142 5.2.11 Transparency ..................................... 55
143 5.2.12 WKS Use in MX Processing ......................... 55
144 5.2.13 RFC-822 Message Specification .................... 55
145 5.2.14 RFC-822 Date and Time Specification .............. 55
146 5.2.15 RFC-822 Syntax Change ............................ 56
147 5.2.16 RFC-822 Local-part .............................. 56
148 5.2.17 Domain Literals .................................. 57
149 5.2.18 Common Address Formatting Errors ................. 58
150 5.2.19 Explicit Source Routes ........................... 58
151 5.3 SPECIFIC ISSUES ........................................ 59
152 5.3.1 SMTP Queueing Strategies .......................... 59
153 5.3.1.1 Sending Strategy .............................. 59
154 5.3.1.2 Receiving strategy ........................... 61
155 5.3.2 Timeouts in SMTP .................................. 61
156 5.3.3 Reliable Mail Receipt ............................. 63
157 5.3.4 Reliable Mail Transmission ........................ 63
158 5.3.5 Domain Name Support ............................... 65
159
160
161
162 Internet Engineering Task Force [Page 3]
163 RFC1123 INTRODUCTION October 1989
164
165
166 5.3.6 Mailing Lists and Aliases ......................... 65
167 5.3.7 Mail Gatewaying ................................... 66
168 5.3.8 Maximum Message Size .............................. 68
169 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69
170
171 6. SUPPORT SERVICES ............................................ 72
172 6.1 DOMAIN NAME TRANSLATION ................................. 72
173 6.1.1 INTRODUCTION ....................................... 72
174 6.1.2 PROTOCOL WALK-THROUGH ............................. 72
175 6.1.2.1 Resource Records with Zero TTL ............... 73
176 6.1.2.2 QCLASS Values ................................ 73
177 6.1.2.3 Unused Fields ................................ 73
178 6.1.2.4 Compression .................................. 73
179 6.1.2.5 Misusing Configuration Info .................. 73
180 6.1.3 SPECIFIC ISSUES ................................... 74
181 6.1.3.1 Resolver Implementation ...................... 74
182 6.1.3.2 Transport Protocols .......................... 75
183 6.1.3.3 Efficient Resource Usage ..................... 77
184 6.1.3.4 Multihomed Hosts ............................. 78
185 6.1.3.5 Extensibility ................................ 79
186 6.1.3.6 Status of RR Types ........................... 79
187 6.1.3.7 Robustness ................................... 80
188 6.1.3.8 Local Host Table ............................. 80
189 6.1.4 DNS USER INTERFACE ................................ 81
190 6.1.4.1 DNS Administration ........................... 81
191 6.1.4.2 DNS User Interface ........................... 81
192 6.1.4.3 Interface Abbreviation Facilities ............. 82
193 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84
194 6.2 HOST INITIALIZATION .................................... 87
195 6.2.1 INTRODUCTION ...................................... 87
196 6.2.2 REQUIREMENTS ...................................... 87
197 6.2.2.1 Dynamic Configuration ........................ 87
198 6.2.2.2 Loading Phase ................................ 89
199 6.3 REMOTE MANAGEMENT ...................................... 90
200 6.3.1 INTRODUCTION ...................................... 90
201 6.3.2 PROTOCOL WALK-THROUGH ............................. 90
202 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92
203
204 7. REFERENCES ................................................. 93
205
206
207
208
209
210
211
212
213
214
215
216
217 Internet Engineering Task Force [Page 4]
218 RFC1123 INTRODUCTION October 1989
219
220
221 1. INTRODUCTION
222
223 This document is one of a pair that defines and discusses the
224 requirements for host system implementations of the Internet protocol
225 suite. This RFC covers the applications layer and support protocols.
226 Its companion RFC, "Requirements for Internet Hosts -- Communications
227 Layers" [INTRO:1] covers the lower layer protocols: transport layer,
228 IP layer, and link layer.
229
230 These documents are intended to provide guidance for vendors,
231 implementors, and users of Internet communication software. They
232 represent the consensus of a large body of technical experience and
233 wisdom, contributed by members of the Internet research and vendor
234 communities.
235
236 This RFC enumerates standard protocols that a host connected to the
237 Internet must use, and it incorporates by reference the RFCs and
238 other documents describing the current specifications for these
239 protocols. It corrects errors in the referenced documents and adds
240 additional discussion and guidance for an implementor.
241
242 For each protocol, this document also contains an explicit set of
243 requirements, recommendations, and options. The reader must
244 understand that the list of requirements in this document is
245 incomplete by itself; the complete set of requirements for an
246 Internet host is primarily defined in the standard protocol
247 specification documents, with the corrections, amendments, and
248 supplements contained in this RFC.
249
250 A good-faith implementation of the protocols that was produced after
251 careful reading of the RFC's and with some interaction with the
252 Internet technical community, and that followed good communications
253 software engineering practices, should differ from the requirements
254 of this document in only minor ways. Thus, in many cases, the
255 "requirements" in this RFC are already stated or implied in the
256 standard protocol documents, so that their inclusion here is, in a
257 sense, redundant. However, they were included because some past
258 implementation has made the wrong choice, causing problems of
259 interoperability, performance, and/or robustness.
260
261 This document includes discussion and explanation of many of the
262 requirements and recommendations. A simple list of requirements
263 would be dangerous, because:
264
265 o Some required features are more important than others, and some
266 features are optional.
267
268 o There may be valid reasons why particular vendor products that
269
270
271
272 Internet Engineering Task Force [Page 5]
273 RFC1123 INTRODUCTION October 1989
274
275
276 are designed for restricted contexts might choose to use
277 different specifications.
278
279 However, the specifications of this document must be followed to meet
280 the general goal of arbitrary host interoperation across the
281 diversity and complexity of the Internet system. Although most
282 current implementations fail to meet these requirements in various
283 ways, some minor and some major, this specification is the ideal
284 towards which we need to move.
285
286 These requirements are based on the current level of Internet
287 architecture. This document will be updated as required to provide
288 additional clarifications or to include additional information in
289 those areas in which specifications are still evolving.
290
291 This introductory section begins with general advice to host software
292 vendors, and then gives some guidance on reading the rest of the
293 document. Section 2 contains general requirements that may be
294 applicable to all application and support protocols. Sections 3, 4,
295 and 5 contain the requirements on protocols for the three major
296 applications: Telnet, file transfer, and electronic mail,
297 respectively. Section 6 covers the support applications: the domain
298 name system, system initialization, and management. Finally, all
299 references will be found in Section 7.
300
301 1.1 The Internet Architecture
302
303 For a brief introduction to the Internet architecture from a host
304 viewpoint, see Section 1.1 of [INTRO:1]. That section also
305 contains recommended references for general background on the
306 Internet architecture.
307
308 1.2 General Considerations
309
310 There are two important lessons that vendors of Internet host
311 software have learned and which a new vendor should consider
312 seriously.
313
314 1.2.1 Continuing Internet Evolution
315
316 The enormous growth of the Internet has revealed problems of
317 management and scaling in a large datagram-based packet
318 communication system. These problems are being addressed, and
319 as a result there will be continuing evolution of the
320 specifications described in this document. These changes will
321 be carefully planned and controlled, since there is extensive
322 participation in this planning by the vendors and by the
323 organizations responsible for operations of the networks.
324
325
326
327 Internet Engineering Task Force [Page 6]
328 RFC1123 INTRODUCTION October 1989
329
330
331 Development, evolution, and revision are characteristic of
332 computer network protocols today, and this situation will
333 persist for some years. A vendor who develops computer
334 communication software for the Internet protocol suite (or any
335 other protocol suite!) and then fails to maintain and update
336 that software for changing specifications is going to leave a
337 trail of unhappy customers. The Internet is a large
338 communication network, and the users are in constant contact
339 through it. Experience has shown that knowledge of
340 deficiencies in vendor software propagates quickly through the
341 Internet technical community.
342
343 1.2.2 Robustness Principle
344
345 At every layer of the protocols, there is a general rule whose
346 application can lead to enormous benefits in robustness and
347 interoperability:
348
349 "Be liberal in what you accept, and
350 conservative in what you send"
351
352 Software should be written to deal with every conceivable
353 error, no matter how unlikely; sooner or later a packet will
354 come in with that particular combination of errors and
355 attributes, and unless the software is prepared, chaos can
356 ensue. In general, it is best to assume that the network is
357 filled with malevolent entities that will send in packets
358 designed to have the worst possible effect. This assumption
359 will lead to suitable protective design, although the most
360 serious problems in the Internet have been caused by
361 unenvisaged mechanisms triggered by low-probability events;
362 mere human malice would never have taken so devious a course!
363
364 Adaptability to change must be designed into all levels of
365 Internet host software. As a simple example, consider a
366 protocol specification that contains an enumeration of values
367 for a particular header field -- e.g., a type field, a port
368 number, or an error code; this enumeration must be assumed to
369 be incomplete. Thus, if a protocol specification defines four
370 possible error codes, the software must not break when a fifth
371 code shows up. An undefined code might be logged (see below),
372 but it must not cause a failure.
373
374 The second part of the principle is almost as important:
375 software on other hosts may contain deficiencies that make it
376 unwise to exploit legal but obscure protocol features. It is
377 unwise to stray far from the obvious and simple, lest untoward
378 effects result elsewhere. A corollary of this is "watch out
379
380
381
382 Internet Engineering Task Force [Page 7]
383 RFC1123 INTRODUCTION October 1989
384
385
386 for misbehaving hosts"; host software should be prepared, not
387 just to survive other misbehaving hosts, but also to cooperate
388 to limit the amount of disruption such hosts can cause to the
389 shared communication facility.
390
391 1.2.3 Error Logging
392
393 The Internet includes a great variety of host and gateway
394 systems, each implementing many protocols and protocol layers,
395 and some of these contain bugs and mis-features in their
396 Internet protocol software. As a result of complexity,
397 diversity, and distribution of function, the diagnosis of user
398 problems is often very difficult.
399
400 Problem diagnosis will be aided if host implementations include
401 a carefully designed facility for logging erroneous or
402 "strange" protocol events. It is important to include as much
403 diagnostic information as possible when an error is logged. In
404 particular, it is often useful to record the header(s) of a
405 packet that caused an error. However, care must be taken to
406 ensure that error logging does not consume prohibitive amounts
407 of resources or otherwise interfere with the operation of the
408 host.
409
410 There is a tendency for abnormal but harmless protocol events
411 to overflow error logging files; this can be avoided by using a
412 "circular" log, or by enabling logging only while diagnosing a
413 known failure. It may be useful to filter and count duplicate
414 successive messages. One strategy that seems to work well is:
415 (1) always count abnormalities and make such counts accessible
416 through the management protocol (see Section 6.3); and (2)
417 allow the logging of a great variety of events to be
418 selectively enabled. For example, it might useful to be able
419 to "log everything" or to "log everything for host X".
420
421 Note that different managements may have differing policies
422 about the amount of error logging that they want normally
423 enabled in a host. Some will say, "if it doesn't hurt me, I
424 don't want to know about it", while others will want to take a
425 more watchful and aggressive attitude about detecting and
426 removing protocol abnormalities.
427
428 1.2.4 Configuration
429
430 It would be ideal if a host implementation of the Internet
431 protocol suite could be entirely self-configuring. This would
432 allow the whole suite to be implemented in ROM or cast into
433 silicon, it would simplify diskless workstations, and it would
434
435
436
437 Internet Engineering Task Force [Page 8]
438 RFC1123 INTRODUCTION October 1989
439
440
441 be an immense boon to harried LAN administrators as well as
442 system vendors. We have not reached this ideal; in fact, we
443 are not even close.
444
445 At many points in this document, you will find a requirement
446 that a parameter be a configurable option. There are several
447 different reasons behind such requirements. In a few cases,
448 there is current uncertainty or disagreement about the best
449 value, and it may be necessary to update the recommended value
450 in the future. In other cases, the value really depends on
451 external factors -- e.g., the size of the host and the
452 distribution of its communication load, or the speeds and
453 topology of nearby networks -- and self-tuning algorithms are
454 unavailable and may be insufficient. In some cases,
455 configurability is needed because of administrative
456 requirements.
457
458 Finally, some configuration options are required to communicate
459 with obsolete or incorrect implementations of the protocols,
460 distributed without sources, that unfortunately persist in many
461 parts of the Internet. To make correct systems coexist with
462 these faulty systems, administrators often have to "mis-
463 configure" the correct systems. This problem will correct
464 itself gradually as the faulty systems are retired, but it
465 cannot be ignored by vendors.
466
467 When we say that a parameter must be configurable, we do not
468 intend to require that its value be explicitly read from a
469 configuration file at every boot time. We recommend that
470 implementors set up a default for each parameter, so a
471 configuration file is only necessary to override those defaults
472 that are inappropriate in a particular installation. Thus, the
473 configurability requirement is an assurance that it will be
474 POSSIBLE to override the default when necessary, even in a
475 binary-only or ROM-based product.
476
477 This document requires a particular value for such defaults in
478 some cases. The choice of default is a sensitive issue when
479 the configuration item controls the accommodation to existing
480 faulty systems. If the Internet is to converge successfully to
481 complete interoperability, the default values built into
482 implementations must implement the official protocol, not
483 "mis-configurations" to accommodate faulty implementations.
484 Although marketing considerations have led some vendors to
485 choose mis-configuration defaults, we urge vendors to choose
486 defaults that will conform to the standard.
487
488 Finally, we note that a vendor needs to provide adequate
489
490
491
492 Internet Engineering Task Force [Page 9]
493 RFC1123 INTRODUCTION October 1989
494
495
496 documentation on all configuration parameters, their limits and
497 effects.
498
499
500 1.3 Reading this Document
501
502 1.3.1 Organization
503
504 In general, each major section is organized into the following
505 subsections:
506
507 (1) Introduction
508
509 (2) Protocol Walk-Through -- considers the protocol
510 specification documents section-by-section, correcting
511 errors, stating requirements that may be ambiguous or
512 ill-defined, and providing further clarification or
513 explanation.
514
515 (3) Specific Issues -- discusses protocol design and
516 implementation issues that were not included in the walk-
517 through.
518
519 (4) Interfaces -- discusses the service interface to the next
520 higher layer.
521
522 (5) Summary -- contains a summary of the requirements of the
523 section.
524
525 Under many of the individual topics in this document, there is
526 parenthetical material labeled "DISCUSSION" or
527 "IMPLEMENTATION". This material is intended to give
528 clarification and explanation of the preceding requirements
529 text. It also includes some suggestions on possible future
530 directions or developments. The implementation material
531 contains suggested approaches that an implementor may want to
532 consider.
533
534 The summary sections are intended to be guides and indexes to
535 the text, but are necessarily cryptic and incomplete. The
536 summaries should never be used or referenced separately from
537 the complete RFC.
538
539 1.3.2 Requirements
540
541 In this document, the words that are used to define the
542 significance of each particular requirement are capitalized.
543 These words are:
544
545
546
547 Internet Engineering Task Force [Page 10]
548 RFC1123 INTRODUCTION October 1989
549
550
551 * "MUST"
552
553 This word or the adjective "REQUIRED" means that the item
554 is an absolute requirement of the specification.
555
556 * "SHOULD"
557
558 This word or the adjective "RECOMMENDED" means that there
559 may exist valid reasons in particular circumstances to
560 ignore this item, but the full implications should be
561 understood and the case carefully weighed before choosing
562 a different course.
563
564 * "MAY"
565
566 This word or the adjective "OPTIONAL" means that this item
567 is truly optional. One vendor may choose to include the
568 item because a particular marketplace requires it or
569 because it enhances the product, for example; another
570 vendor may omit the same item.
571
572
573 An implementation is not compliant if it fails to satisfy one
574 or more of the MUST requirements for the protocols it
575 implements. An implementation that satisfies all the MUST and
576 all the SHOULD requirements for its protocols is said to be
577 "unconditionally compliant"; one that satisfies all the MUST
578 requirements but not all the SHOULD requirements for its
579 protocols is said to be "conditionally compliant".
580
581 1.3.3 Terminology
582
583 This document uses the following technical terms:
584
585 Segment
586 A segment is the unit of end-to-end transmission in the
587 TCP protocol. A segment consists of a TCP header followed
588 by application data. A segment is transmitted by
589 encapsulation in an IP datagram.
590
591 Message
592 This term is used by some application layer protocols
593 (particularly SMTP) for an application data unit.
594
595 Datagram
596 A [UDP] datagram is the unit of end-to-end transmission in
597 the UDP protocol.
598
599
600
601
602 Internet Engineering Task Force [Page 11]
603 RFC1123 INTRODUCTION October 1989
604
605
606 Multihomed
607 A host is said to be multihomed if it has multiple IP
608 addresses to connected networks.
609
610
611
612 1.4 Acknowledgments
613
614 This document incorporates contributions and comments from a large
615 group of Internet protocol experts, including representatives of
616 university and research labs, vendors, and government agencies.
617 It was assembled primarily by the Host Requirements Working Group
618 of the Internet Engineering Task Force (IETF).
619
620 The Editor would especially like to acknowledge the tireless
621 dedication of the following people, who attended many long
622 meetings and generated 3 million bytes of electronic mail over the
623 past 18 months in pursuit of this document: Philip Almquist, Dave
624 Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
625 Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
626 John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
627 Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
628 (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
629
630 In addition, the following people made major contributions to the
631 effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
632 (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
633 Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
634 John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
635 Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
636 (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
637 Technology), and Mike StJohns (DCA). The following also made
638 significant contributions to particular areas: Eric Allman
639 (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
640 (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
641 (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
642 (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
643 Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
644 (Toronto).
645
646 We are grateful to all, including any contributors who may have
647 been inadvertently omitted from this list.
648
649
650
651
652
653
654
655
656
657 Internet Engineering Task Force [Page 12]
658 RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
659
660
661 2. GENERAL ISSUES
662
663 This section contains general requirements that may be applicable to
664 all application-layer protocols.
665
666 2.1 Host Names and Numbers
667
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
668 The syntax of a legal Internet host name was specified in RFC-952
669 [DNS:4]. One aspect of host name syntax is hereby changed: the
670 restriction on the first character is relaxed to allow either a
671 letter or a digit. Host software MUST support this more liberal
672 syntax.
673
674 Host software MUST handle host names of up to 63 characters and
675 SHOULD handle host names of up to 255 characters.
676
677 Whenever a user inputs the identity of an Internet host, it SHOULD
678 be possible to enter either (1) a host domain name or (2) an IP
679 address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
680 the string syntactically for a dotted-decimal number before
681 looking it up in the Domain Name System.
682
683 DISCUSSION:
684 This last requirement is not intended to specify the complete
685 syntactic form for entering a dotted-decimal host number;
686 that is considered to be a user-interface issue. For
687 example, a dotted-decimal number must be enclosed within
688 "[ ]" brackets for SMTP mail (see Section 5.2.17). This
689 notation could be made universal within a host system,
690 simplifying the syntactic checking for a dotted-decimal
691 number.
692
693 If a dotted-decimal number can be entered without such
694 identifying delimiters, then a full syntactic check must be
695 made, because a segment of a host domain name is now allowed
696 to begin with a digit and could legally be entirely numeric
697 (see Section 6.1.2.4). However, a valid host name can never
698 have the dotted-decimal form #.#.#.#, since at least the
699 highest-level component label will be alphabetic.
700
701 2.2 Using Domain Name Service
702
703 Host domain names MUST be translated to IP addresses as described
704 in Section 6.1.
705
706 Applications using domain name services MUST be able to cope with
707 soft error conditions. Applications MUST wait a reasonable
708 interval between successive retries due to a soft error, and MUST
709
710
711
712 Internet Engineering Task Force [Page 13]
713 RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
714
715
716 allow for the possibility that network problems may deny service
717 for hours or even days.
718
719 An application SHOULD NOT rely on the ability to locate a WKS
720 record containing an accurate listing of all services at a
721 particular host address, since the WKS RR type is not often used
722 by Internet sites. To confirm that a service is present, simply
723 attempt to use it.
724
725 2.3 Applications on Multihomed hosts
726
727 When the remote host is multihomed, the name-to-address
728 translation will return a list of alternative IP addresses. As
729 specified in Section 6.1.3.4, this list should be in order of
730 decreasing preference. Application protocol implementations
731 SHOULD be prepared to try multiple addresses from the list until
732 success is obtained. More specific requirements for SMTP are
733 given in Section 5.3.4.
734
735 When the local host is multihomed, a UDP-based request/response
736 application SHOULD send the response with an IP source address
737 that is the same as the specific destination address of the UDP
738 request datagram. The "specific destination address" is defined
739 in the "IP Addressing" section of the companion RFC [INTRO:1].
740
741 Similarly, a server application that opens multiple TCP
742 connections to the same client SHOULD use the same local IP
743 address for all.
744
745 2.4 Type-of-Service
746
747 Applications MUST select appropriate TOS values when they invoke
748 transport layer services, and these values MUST be configurable.
749 Note that a TOS value contains 5 bits, of which only the most-
750 significant 3 bits are currently defined; the other two bits MUST
751 be zero.
752
753 DISCUSSION:
754 As gateway algorithms are developed to implement Type-of-
755 Service, the recommended values for various application
756 protocols may change. In addition, it is likely that
757 particular combinations of users and Internet paths will want
758 non-standard TOS values. For these reasons, the TOS values
759 must be configurable.
760
761 See the latest version of the "Assigned Numbers" RFC
762 [INTRO:5] for the recommended TOS values for the major
763 application protocols.
764
765
766
767 Internet Engineering Task Force [Page 14]
768 RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
769
770
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4].
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4] and reiterated in RFC-1034 Section 3.5 [DNS:1].
771 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY
772
773 | | | | |S| |
774 | | | | |H| |F
775 | | | | |O|M|o
776 | | |S| |U|U|o
777 | | |H| |L|S|t
778 | |M|O| |D|T|n
779 | |U|U|M| | |o
780 | |S|L|A|N|N|t
781 | |T|D|Y|O|O|t
782 FEATURE |SECTION | | | |T|T|e
783 -----------------------------------------------|----------|-|-|-|-|-|--
784 | | | | | | |
785 User interfaces: | | | | | | |
786 Allow host name to begin with digit |2.1 |x| | | | |
787 Host names of up to 635 characters |2.1 |x| | | | |
788 Host names of up to 255 characters |2.1 | |x| | | |
789 Support dotted-decimal host numbers |2.1 | |x| | | |
790 Check syntactically for dotted-dec first |2.1 | |x| | | |
791 | | | | | | |
792 Map domain names per Section 6.1 |2.2 |x| | | | |
793 Cope with soft DNS errors |2.2 |x| | | | |
794 Reasonable interval between retries |2.2 |x| | | | |
795 Allow for long outages |2.2 |x| | | | |
796 Expect WKS records to be available |2.2 | | | |x| |
797 | | | | | | |
798 Try multiple addr's for remote multihomed host |2.3 | |x| | | |
799 UDP reply src addr is specific dest of request |2.3 | |x| | | |
800 Use same IP addr for related TCP connections |2.3 | |x| | | |
801 Specify appropriate TOS values |2.4 |x| | | | |
802 TOS values configurable |2.4 |x| | | | |
803 Unused TOS bits zero |2.4 |x| | | | |
804 | | | | | | |
805 | | | | | | |
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822 Internet Engineering Task Force [Page 15]
823 RFC1123 REMOTE LOGIN -- TELNET October 1989
824
825
826 3. REMOTE LOGIN -- TELNET PROTOCOL
827
828 3.1 INTRODUCTION
829
830 Telnet is the standard Internet application protocol for remote
831 login. It provides the encoding rules to link a user's
832 keyboard/display on a client ("user") system with a command
833 interpreter on a remote server system. A subset of the Telnet
834 protocol is also incorporated within other application protocols,
835 e.g., FTP and SMTP.
836
837 Telnet uses a single TCP connection, and its normal data stream
838 ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
839 escape sequences to embed control functions. Telnet also allows
840 the negotiation of many optional modes and functions.
841
842 The primary Telnet specification is to be found in RFC-854
843 [TELNET:1], while the options are defined in many other RFCs; see
844 Section 7 for references.
845
846 3.2 PROTOCOL WALK-THROUGH
847
848 3.2.1 Option Negotiation: RFC-854, pp. 2-3
849
850 Every Telnet implementation MUST include option negotiation and
851 subnegotiation machinery [TELNET:2].
852
853 A host MUST carefully follow the rules of RFC-854 to avoid
Host names of up to 635 characters |2.1 |x| | | | |
Host names of up to 635characters |2.1 |x| | | | |
Section 2.1 says "Host software MUST handle host names of up to 63 characters" and doesn't mention the number 635 at all.
854 option-negotiation loops. A host MUST refuse (i.e, reply
855 WONT/DONT to a DO/WILL) an unsupported option. Option
856 negotiation SHOULD continue to function (even if all requests
857 are refused) throughout the lifetime of a Telnet connection.
858
859 If all option negotiations fail, a Telnet implementation MUST
860 default to, and support, an NVT.
861
862 DISCUSSION:
863 Even though more sophisticated "terminals" and supporting
864 option negotiations are becoming the norm, all
865 implementations must be prepared to support an NVT for any
866 user-server communication.
867
868 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
869
870 On a host that never sends the Telnet command Go Ahead (GA),
871 the Telnet Server MUST attempt to negotiate the Suppress Go
872 Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or
873 Server Telnet MUST always accept negotiation of the Suppress Go
874
875
876
877 Internet Engineering Task Force [Page 16]
878 RFC1123 REMOTE LOGIN -- TELNET October 1989
879
880
881 Ahead option.
882
883 When it is driving a full-duplex terminal for which GA has no
884 meaning, a User Telnet implementation MAY ignore GA commands.
885
886 DISCUSSION:
887 Half-duplex ("locked-keyboard") line-at-a-time terminals
888 for which the Go-Ahead mechanism was designed have largely
889 disappeared from the scene. It turned out to be difficult
890 to implement sending the Go-Ahead signal in many operating
891 systems, even some systems that support native half-duplex
892 terminals. The difficulty is typically that the Telnet
893 server code does not have access to information about
894 whether the user process is blocked awaiting input from
895 the Telnet connection, i.e., it cannot reliably determine
896 when to send a GA command. Therefore, most Telnet Server
897 hosts do not send GA commands.
898
899 The effect of the rules in this section is to allow either
900 end of a Telnet connection to veto the use of GA commands.
901
902 There is a class of half-duplex terminals that is still
903 commercially important: "data entry terminals," which
904 interact in a full-screen manner. However, supporting
905 data entry terminals using the Telnet protocol does not
906 require the Go Ahead signal; see Section 3.3.2.
907
908 3.2.3 Control Functions: RFC-854, pp. 7-8
909
910 The list of Telnet commands has been extended to include EOR
911 (End-of-Record), with code 239 [TELNET:9].
912
913 Both User and Server Telnets MAY support the control functions
914 EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
915 SB, and SE.
916
917 A host MUST be able to receive and ignore any Telnet control
918 functions that it does not support.
919
920 DISCUSSION:
921 Note that a Server Telnet is required to support the
922 Telnet IP (Interrupt Process) function, even if the server
923 host has an equivalent in-stream function (e.g., Control-C
924 in many systems). The Telnet IP function may be stronger
925 than an in-stream interrupt command, because of the out-
926 of-band effect of TCP urgent data.
927
928 The EOR control function may be used to delimit the
929
930
931
932 Internet Engineering Task Force [Page 17]
933 RFC1123 REMOTE LOGIN -- TELNET October 1989
934
935
936 stream. An important application is data entry terminal
937 support (see Section 3.3.2). There was concern that since
938 EOR had not been defined in RFC-854, a host that was not
939 prepared to correctly ignore unknown Telnet commands might
940 crash if it received an EOR. To protect such hosts, the
941 End-of-Record option [TELNET:9] was introduced; however, a
942 properly implemented Telnet program will not require this
943 protection.
944
945 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10
946
947 When it receives "urgent" TCP data, a User or Server Telnet
948 MUST discard all data except Telnet commands until the DM (and
949 end of urgent) is reached.
950
951 When it sends Telnet IP (Interrupt Process), a User Telnet
952 SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
953 TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent
954 pointer points to the DM octet.
955
956 When it receives a Telnet IP command, a Server Telnet MAY send
957 a Telnet "Synch" sequence back to the user, to flush the output
958 stream. The choice ought to be consistent with the way the
959 server operating system behaves when a local user interrupts a
960 process.
961
962 When it receives a Telnet AO command, a Server Telnet MUST send
963 a Telnet "Synch" sequence back to the user, to flush the output
964 stream.
965
966 A User Telnet SHOULD have the capability of flushing output
967 when it sends a Telnet IP; see also Section 3.4.5.
968
969 DISCUSSION:
970 There are three possible ways for a User Telnet to flush
971 the stream of server output data:
972
973 (1) Send AO after IP.
974
975 This will cause the server host to send a "flush-
976 buffered-output" signal to its operating system.
977 However, the AO may not take effect locally, i.e.,
978 stop terminal output at the User Telnet end, until
979 the Server Telnet has received and processed the AO
980 and has sent back a "Synch".
981
982 (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard
983 all output locally until a WILL/WONT TIMING-MARK is
984
985
986
987 Internet Engineering Task Force [Page 18]
988 RFC1123 REMOTE LOGIN -- TELNET October 1989
989
990
991 received from the Server Telnet.
992
993 Since the DO TIMING-MARK will be processed after the
994 IP at the server, the reply to it should be in the
995 right place in the output data stream. However, the
996 TIMING-MARK will not send a "flush buffered output"
997 signal to the server operating system. Whether or
998 not this is needed is dependent upon the server
999 system.
1000
1001 (3) Do both.
1002
1003 The best method is not entirely clear, since it must
1004 accommodate a number of existing server hosts that do not
1005 follow the Telnet standards in various ways. The safest
1006 approach is probably to provide a user-controllable option
1007 to select (1), (2), or (3).
1008
1009 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11
1010
1011 In NVT mode, a Telnet SHOULD NOT send characters with the
1012 high-order bit 1, and MUST NOT send it as a parity bit.
1013 Implementations that pass the high-order bit to applications
1014 SHOULD negotiate binary mode (see Section 3.2.6).
1015
1016
1017 DISCUSSION:
1018 Implementors should be aware that a strict reading of
1019 RFC-854 allows a client or server expecting NVT ASCII to
1020 ignore characters with the high-order bit set. In
1021 general, binary mode is expected to be used for
1022 transmission of an extended (beyond 7-bit) character set
1023 with Telnet.
1024
1025 However, there exist applications that really need an 8-
1026 bit NVT mode, which is currently not defined, and these
1027 existing applications do set the high-order bit during
1028 part or all of the life of a Telnet connection. Note that
1029 binary mode is not the same as 8-bit NVT mode, since
1030 binary mode turns off end-of-line processing. For this
1031 reason, the requirements on the high-order bit are stated
1032 as SHOULD, not MUST.
1033
1034 RFC-854 defines a minimal set of properties of a "network
1035 virtual terminal" or NVT; this is not meant to preclude
1036 additional features in a real terminal. A Telnet
1037 connection is fully transparent to all 7-bit ASCII
1038 characters, including arbitrary ASCII control characters.
1039
1040
1041
1042 Internet Engineering Task Force [Page 19]
1043 RFC1123 REMOTE LOGIN -- TELNET October 1989
1044
1045
1046 For example, a terminal might support full-screen commands
1047 coded as ASCII escape sequences; a Telnet implementation
1048 would pass these sequences as uninterpreted data. Thus,
1049 an NVT should not be conceived as a terminal type of a
1050 highly-restricted device.
1051
1052 3.2.6 Telnet Command Structure: RFC-854, p. 13
1053
1054 Since options may appear at any point in the data stream, a
1055 Telnet escape character (known as IAC, with the value 255) to
1056 be sent as data MUST be doubled.
1057
1058 3.2.7 Telnet Binary Option: RFC-856
1059
1060 When the Binary option has been successfully negotiated,
1061 arbitrary 8-bit characters are allowed. However, the data
1062 stream MUST still be scanned for IAC characters, any embedded
1063 Telnet commands MUST be obeyed, and data bytes equal to IAC
1064 MUST be doubled. Other character processing (e.g., replacing
1065 CR by CR NUL or by CR LF) MUST NOT be done. In particular,
1066 there is no end-of-line convention (see Section 3.3.1) in
1067 binary mode.
1068
1069 DISCUSSION:
1070 The Binary option is normally negotiated in both
1071 directions, to change the Telnet connection from NVT mode
1072 to "binary mode".
1073
1074 The sequence IAC EOR can be used to delimit blocks of data
1075 within a binary-mode Telnet stream.
1076
1077 3.2.8 Telnet Terminal-Type Option: RFC-1091
1078
1079 The Terminal-Type option MUST use the terminal type names
1080 officially defined in the Assigned Numbers RFC [INTRO:5], when
1081 they are available for the particular terminal. However, the
1082 receiver of a Terminal-Type option MUST accept any name.
1083
1084 DISCUSSION:
1085 RFC-1091 [TELNET:10] updates an earlier version of the
1086 Terminal-Type option defined in RFC-930. The earlier
1087 version allowed a server host capable of supporting
1088 multiple terminal types to learn the type of a particular
1089 client's terminal, assuming that each physical terminal
1090 had an intrinsic type. However, today a "terminal" is
1091 often really a terminal emulator program running in a PC,
1092 perhaps capable of emulating a range of terminal types.
1093 Therefore, RFC-1091 extends the specification to allow a
1094
1095
1096
1097 Internet Engineering Task Force [Page 20]
1098 RFC1123 REMOTE LOGIN -- TELNET October 1989
1099
1100
1101 more general terminal-type negotiation between User and
1102 Server Telnets.
1103
1104 3.3 SPECIFIC ISSUES
1105
1106 3.3.1 Telnet End-of-Line Convention
1107
1108 The Telnet protocol defines the sequence CR LF to mean "end-
1109 of-line". For terminal input, this corresponds to a command-
1110 completion or "end-of-line" key being pressed on a user
1111 terminal; on an ASCII terminal, this is the CR key, but it may
1112 also be labelled "Return" or "Enter".
1113
1114 When a Server Telnet receives the Telnet end-of-line sequence
1115 CR LF as input from a remote terminal, the effect MUST be the
1116 same as if the user had pressed the "end-of-line" key on a
1117 local terminal. On server hosts that use ASCII, in particular,
1118 receipt of the Telnet sequence CR LF must cause the same effect
1119 as a local user pressing the CR key on a local terminal. Thus,
1120 CR LF and CR NUL MUST have the same effect on an ASCII server
1121 host when received as input over a Telnet connection.
1122
1123 A User Telnet MUST be able to send any of the forms: CR LF, CR
1124 NUL, and LF. A User Telnet on an ASCII host SHOULD have a
1125 user-controllable mode to send either CR LF or CR NUL when the
1126 user presses the "end-of-line" key, and CR LF SHOULD be the
1127 default.
1128
1129 The Telnet end-of-line sequence CR LF MUST be used to send
1130 Telnet data that is not terminal-to-computer (e.g., for Server
1131 Telnet sending output, or the Telnet protocol incorporated
1132 another application protocol).
1133
1134 DISCUSSION:
1135 To allow interoperability between arbitrary Telnet clients
1136 and servers, the Telnet protocol defined a standard
1137 representation for a line terminator. Since the ASCII
1138 character set includes no explicit end-of-line character,
1139 systems have chosen various representations, e.g., CR, LF,
1140 and the sequence CR LF. The Telnet protocol chose the CR
1141 LF sequence as the standard for network transmission.
1142
1143 Unfortunately, the Telnet protocol specification in RFC-
1144 854 [TELNET:1] has turned out to be somewhat ambiguous on
1145 what character(s) should be sent from client to server for
1146 the "end-of-line" key. The result has been a massive and
1147 continuing interoperability headache, made worse by
1148 various faulty implementations of both User and Server
1149
1150
1151
1152 Internet Engineering Task Force [Page 21]
1153 RFC1123 REMOTE LOGIN -- TELNET October 1989
1154
1155
1156 Telnets.
1157
1158 Although the Telnet protocol is based on a perfectly
1159 symmetric model, in a remote login session the role of the
1160 user at a terminal differs from the role of the server
1161 host. For example, RFC-854 defines the meaning of CR, LF,
1162 and CR LF as output from the server, but does not specify
1163 what the User Telnet should send when the user presses the
1164 "end-of-line" key on the terminal; this turns out to be
1165 the point at issue.
1166
1167 When a user presses the "end-of-line" key, some User
1168 Telnet implementations send CR LF, while others send CR
1169 NUL (based on a different interpretation of the same
1170 sentence in RFC-854). These will be equivalent for a
1171 correctly-implemented ASCII server host, as discussed
1172 above. For other servers, a mode in the User Telnet is
1173 needed.
1174
1175 The existence of User Telnets that send only CR NUL when
1176 CR is pressed creates a dilemma for non-ASCII hosts: they
1177 can either treat CR NUL as equivalent to CR LF in input,
1178 thus precluding the possibility of entering a "bare" CR,
1179 or else lose complete interworking.
1180
1181 Suppose a user on host A uses Telnet to log into a server
1182 host B, and then execute B's User Telnet program to log
1183 into server host C. It is desirable for the Server/User
1184 Telnet combination on B to be as transparent as possible,
1185 i.e., to appear as if A were connected directly to C. In
1186 particular, correct implementation will make B transparent
1187 to Telnet end-of-line sequences, except that CR LF may be
1188 translated to CR NUL or vice versa.
1189
1190 IMPLEMENTATION:
1191 To understand Telnet end-of-line issues, one must have at
1192 least a general model of the relationship of Telnet to the
1193 local operating system. The Server Telnet process is
1194 typically coupled into the terminal driver software of the
1195 operating system as a pseudo-terminal. A Telnet end-of-
1196 line sequence received by the Server Telnet must have the
1197 same effect as pressing the end-of-line key on a real
1198 locally-connected terminal.
1199
1200 Operating systems that support interactive character-at-
1201 a-time applications (e.g., editors) typically have two
1202 internal modes for their terminal I/O: a formatted mode,
1203 in which local conventions for end-of-line and other
1204
1205
1206
1207 Internet Engineering Task Force [Page 22]
1208 RFC1123 REMOTE LOGIN -- TELNET October 1989
1209
1210
1211 formatting rules have been applied to the data stream, and
1212 a "raw" mode, in which the application has direct access
1213 to every character as it was entered. A Server Telnet
1214 must be implemented in such a way that these modes have
1215 the same effect for remote as for local terminals. For
1216 example, suppose a CR LF or CR NUL is received by the
1217 Server Telnet on an ASCII host. In raw mode, a CR
1218 character is passed to the application; in formatted mode,
1219 the local system's end-of-line convention is used.
1220
1221 3.3.2 Data Entry Terminals
1222
1223 DISCUSSION:
1224 In addition to the line-oriented and character-oriented
1225 ASCII terminals for which Telnet was designed, there are
1226 several families of video display terminals that are
1227 sometimes known as "data entry terminals" or DETs. The
1228 IBM 3270 family is a well-known example.
1229
1230 Two Internet protocols have been designed to support
1231 generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
1232 option [TELNET:18, TELNET:19]. The DET option drives a
1233 data entry terminal over a Telnet connection using (sub-)
1234 negotiation. SUPDUP is a completely separate terminal
1235 protocol, which can be entered from Telnet by negotiation.
1236 Although both SUPDUP and the DET option have been used
1237 successfully in particular environments, neither has
1238 gained general acceptance or wide implementation.
1239
1240 A different approach to DET interaction has been developed
1241 for supporting the IBM 3270 family through Telnet,
1242 although the same approach would be applicable to any DET.
1243 The idea is to enter a "native DET" mode, in which the
1244 native DET input/output stream is sent as binary data.
1245 The Telnet EOR command is used to delimit logical records
1246 (e.g., "screens") within this binary stream.
1247
1248 IMPLEMENTATION:
1249 The rules for entering and leaving native DET mode are as
1250 follows:
1251
1252 o The Server uses the Terminal-Type option [TELNET:10]
1253 to learn that the client is a DET.
1254
1255 o It is conventional, but not required, that both ends
1256 negotiate the EOR option [TELNET:9].
1257
1258 o Both ends negotiate the Binary option [TELNET:3] to
1259
1260
1261
1262 Internet Engineering Task Force [Page 23]
1263 RFC1123 REMOTE LOGIN -- TELNET October 1989
1264
1265
1266 enter native DET mode.
1267
1268 o When either end negotiates out of binary mode, the
1269 other end does too, and the mode then reverts to
1270 normal NVT.
1271
1272
1273 3.3.3 Option Requirements
1274
1275 Every Telnet implementation MUST support the Binary option
1276 [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
1277 SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
1278 Record [TELNET:9], and Extended Options List [TELNET:8]
1279 options.
1280
1281 A User or Server Telnet SHOULD support the Window Size Option
1282 [TELNET:12] if the local operating system provides the
1283 corresponding capability.
1284
1285 DISCUSSION:
1286 Note that the End-of-Record option only signifies that a
1287 Telnet can receive a Telnet EOR without crashing;
1288 therefore, every Telnet ought to be willing to accept
1289 negotiation of the End-of-Record option. See also the
1290 discussion in Section 3.2.3.
1291
1292 3.3.4 Option Initiation
1293
1294 When the Telnet protocol is used in a client/server situation,
1295 the server SHOULD initiate negotiation of the terminal
1296 interaction mode it expects.
1297
1298 DISCUSSION:
1299 The Telnet protocol was defined to be perfectly
1300 symmetrical, but its application is generally asymmetric.
1301 Remote login has been known to fail because NEITHER side
1302 initiated negotiation of the required non-default terminal
1303 modes. It is generally the server that determines the
1304 preferred mode, so the server needs to initiate the
1305 negotiation; since the negotiation is symmetric, the user
1306 can also initiate it.
1307
1308 A client (User Telnet) SHOULD provide a means for users to
1309 enable and disable the initiation of option negotiation.
1310
1311 DISCUSSION:
1312 A user sometimes needs to connect to an application
1313 service (e.g., FTP or SMTP) that uses Telnet for its
1314
1315
1316
1317 Internet Engineering Task Force [Page 24]
1318 RFC1123 REMOTE LOGIN -- TELNET October 1989
1319
1320
1321 control stream but does not support Telnet options. User
1322 Telnet may be used for this purpose if initiation of
1323 option negotiation is disabled.
1324
1325 3.3.5 Telnet Linemode Option
1326
1327 DISCUSSION:
1328 An important new Telnet option, LINEMODE [TELNET:12], has
1329 been proposed. The LINEMODE option provides a standard
1330 way for a User Telnet and a Server Telnet to agree that
1331 the client rather than the server will perform terminal
1332 character processing. When the client has prepared a
1333 complete line of text, it will send it to the server in
1334 (usually) one TCP packet. This option will greatly
1335 decrease the packet cost of Telnet sessions and will also
1336 give much better user response over congested or long-
1337 delay networks.
1338
1339 The LINEMODE option allows dynamic switching between local
1340 and remote character processing. For example, the Telnet
1341 connection will automatically negotiate into single-
1342 character mode while a full screen editor is running, and
1343 then return to linemode when the editor is finished.
1344
1345 We expect that when this RFC is released, hosts should
1346 implement the client side of this option, and may
1347 implement the server side of this option. To properly
1348 implement the server side, the server needs to be able to
1349 tell the local system not to do any input character
1350 processing, but to remember its current terminal state and
1351 notify the Server Telnet process whenever the state
1352 changes. This will allow password echoing and full screen
1353 editors to be handled properly, for example.
1354
1355 3.4 TELNET/USER INTERFACE
1356
1357 3.4.1 Character Set Transparency
1358
1359 User Telnet implementations SHOULD be able to send or receive
1360 any 7-bit ASCII character. Where possible, any special
1361 character interpretations by the user host's operating system
1362 SHOULD be bypassed so that these characters can conveniently be
1363 sent and received on the connection.
1364
1365 Some character value MUST be reserved as "escape to command
1366 mode"; conventionally, doubling this character allows it to be
1367 entered as data. The specific character used SHOULD be user
1368 selectable.
1369
1370
1371
1372 Internet Engineering Task Force [Page 25]
1373 RFC1123 REMOTE LOGIN -- TELNET October 1989
1374
1375
1376 On binary-mode connections, a User Telnet program MAY provide
1377 an escape mechanism for entering arbitrary 8-bit values, if the
1378 host operating system doesn't allow them to be entered directly
1379 from the keyboard.
1380
1381 IMPLEMENTATION:
1382 The transparency issues are less pressing on servers, but
1383 implementors should take care in dealing with issues like:
1384 masking off parity bits (sent by an older, non-conforming
1385 client) before they reach programs that expect only NVT
1386 ASCII, and properly handling programs that request 8-bit
1387 data streams.
1388
1389 3.4.2 Telnet Commands
1390
1391 A User Telnet program MUST provide a user the capability of
1392 entering any of the Telnet control functions IP, AO, or AYT,
1393 and SHOULD provide the capability of entering EC, EL, and
1394 Break.
1395
1396 3.4.3 TCP Connection Errors
1397
1398 A User Telnet program SHOULD report to the user any TCP errors
1399 that are reported by the transport layer (see "TCP/Application
1400 Layer Interface" section in [INTRO:1]).
1401
1402 3.4.4 Non-Default Telnet Contact Port
1403
1404 A User Telnet program SHOULD allow the user to optionally
1405 specify a non-standard contact port number at the Server Telnet
1406 host.
1407
1408 3.4.5 Flushing Output
1409
1410 A User Telnet program SHOULD provide the user the ability to
1411 specify whether or not output should be flushed when an IP is
1412 sent; see Section 3.2.4.
1413
1414 For any output flushing scheme that causes the User Telnet to
1415 flush output locally until a Telnet signal is received from the
1416 Server, there SHOULD be a way for the user to manually restore
1417 normal output, in case the Server fails to send the expected
1418 signal.
1419
1420
1421
1422
1423
1424
1425
1426
1427 Internet Engineering Task Force [Page 26]
1428 RFC1123 REMOTE LOGIN -- TELNET October 1989
1429
1430
1431 3.5. TELNET REQUIREMENTS SUMMARY
1432
1433
1434 | | | | |S| |
1435 | | | | |H| |F
1436 | | | | |O|M|o
1437 | | |S| |U|U|o
1438 | | |H| |L|S|t
1439 | |M|O| |D|T|n
1440 | |U|U|M| | |o
1441 | |S|L|A|N|N|t
1442 | |T|D|Y|O|O|t
1443 FEATURE |SECTION | | | |T|T|e
1444 -------------------------------------------------|--------|-|-|-|-|-|--
1445 | | | | | | |
1446 Option Negotiation |3.2.1 |x| | | | |
1447 Avoid negotiation loops |3.2.1 |x| | | | |
1448 Refuse unsupported options |3.2.1 |x| | | | |
1449 Negotiation OK anytime on connection |3.2.1 | |x| | | |
1450 Default to NVT |3.2.1 |x| | | | |
1451 Send official name in Term-Type option |3.2.8 |x| | | | |
1452 Accept any name in Term-Type option |3.2.8 |x| | | | |
1453 Implement Binary, Suppress-GA options |3.3.3 |x| | | | |
1454 Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | |
1455 Implement Window-Size option if appropriate |3.3.3 | |x| | | |
1456 Server initiate mode negotiations |3.3.4 | |x| | | |
1457 User can enable/disable init negotiations |3.3.4 | |x| | | |
1458 | | | | | | |
1459 Go-Aheads | | | | | | |
1460 Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | |
1461 User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | |
1462 User Telnet ignore GA's |3.2.2 | | |x| | |
1463 | | | | | | |
1464 Control Functions | | | | | | |
1465 Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | |
1466 Support EOR EC EL Break |3.2.3 | | |x| | |
1467 Ignore unsupported control functions |3.2.3 |x| | | | |
1468 User, Server discard urgent data up to DM |3.2.4 |x| | | | |
1469 User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | |
1470 Server Telnet reply Synch to IP |3.2.4 | | |x| | |
1471 Server Telnet reply Synch to AO |3.2.4 |x| | | | |
1472 User Telnet can flush output when send IP |3.2.4 | |x| | | |
1473 | | | | | | |
1474 Encoding | | | | | | |
1475 Send high-order bit in NVT mode |3.2.5 | | | |x| |
1476 Send high-order bit as parity bit |3.2.5 | | | | |x|
1477 Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | |
1478 Always double IAC data byte |3.2.6 |x| | | | |
1479
1480
1481
1482 Internet Engineering Task Force [Page 27]
1483 RFC1123 REMOTE LOGIN -- TELNET October 1989
1484
1485
1486 Double IAC data byte in binary mode |3.2.7 |x| | | | |
1487 Obey Telnet cmds in binary mode |3.2.7 |x| | | | |
1488 End-of-line, CR NUL in binary mode |3.2.7 | | | | |x|
1489 | | | | | | |
1490 End-of-Line | | | | | | |
1491 EOL at Server same as local end-of-line |3.3.1 |x| | | | |
1492 ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | |
1493 User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | |
1494 ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | |
1495 User Telnet default mode is CR LF |3.3.1 | |x| | | |
1496 Non-interactive uses CR LF for EOL |3.3.1 |x| | | | |
1497 | | | | | | |
1498 User Telnet interface | | | | | | |
1499 Input & output all 7-bit characters |3.4.1 | |x| | | |
1500 Bypass local op sys interpretation |3.4.1 | |x| | | |
1501 Escape character |3.4.1 |x| | | | |
1502 User-settable escape character |3.4.1 | |x| | | |
1503 Escape to enter 8-bit values |3.4.1 | | |x| | |
1504 Can input IP, AO, AYT |3.4.2 |x| | | | |
1505 Can input EC, EL, Break |3.4.2 | |x| | | |
1506 Report TCP connection errors to user |3.4.3 | |x| | | |
1507 Optional non-default contact port |3.4.4 | |x| | | |
1508 Can spec: output flushed when IP sent |3.4.5 | |x| | | |
1509 Can manually restore output mode |3.4.5 | |x| | | |
1510 | | | | | | |
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537 Internet Engineering Task Force [Page 28]
1538 RFC1123 FILE TRANSFER -- FTP October 1989
1539
1540
1541 4. FILE TRANSFER
1542
1543 4.1 FILE TRANSFER PROTOCOL -- FTP
1544
1545 4.1.1 INTRODUCTION
1546
1547 The File Transfer Protocol FTP is the primary Internet standard
1548 for file transfer. The current specification is contained in
1549 RFC-959 [FTP:1].
1550
1551 FTP uses separate simultaneous TCP connections for control and
1552 for data transfer. The FTP protocol includes many features,
1553 some of which are not commonly implemented. However, for every
1554 feature in FTP, there exists at least one implementation. The
1555 minimum implementation defined in RFC-959 was too small, so a
1556 somewhat larger minimum implementation is defined here.
1557
1558 Internet users have been unnecessarily burdened for years by
1559 deficient FTP implementations. Protocol implementors have
1560 suffered from the erroneous opinion that implementing FTP ought
1561 to be a small and trivial task. This is wrong, because FTP has
1562 a user interface, because it has to deal (correctly) with the
1563 whole variety of communication and operating system errors that
1564 may occur, and because it has to handle the great diversity of
1565 real file systems in the world.
1566
1567 4.1.2. PROTOCOL WALK-THROUGH
1568
1569 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4
1570
1571 An FTP program MUST support TYPE I ("IMAGE" or binary type)
1572 as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
1573 A machine whose memory is organized into m-bit words, where
1574 m is not a multiple of 8, MAY also support TYPE L m.
1575
1576 DISCUSSION:
1577 The command "TYPE L 8" is often required to transfer
1578 binary data between a machine whose memory is organized
1579 into (e.g.) 36-bit words and a machine with an 8-bit
1580 byte organization. For an 8-bit byte machine, TYPE L 8
1581 is equivalent to IMAGE.
1582
1583 "TYPE L m" is sometimes specified to the FTP programs
1584 on two m-bit word machines to ensure the correct
1585 transfer of a native-mode binary file from one machine
1586 to the other. However, this command should have the
1587 same effect on these machines as "TYPE I".
1588
1589
1590
1591
1592 Internet Engineering Task Force [Page 29]
1593 RFC1123 FILE TRANSFER -- FTP October 1989
1594
1595
1596 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2
1597
1598 A host that makes no distinction between TYPE N and TYPE T
1599 SHOULD implement TYPE T to be identical to TYPE N.
1600
1601 DISCUSSION:
1602 This provision should ease interoperation with hosts
1603 that do make this distinction.
1604
1605 Many hosts represent text files internally as strings
1606 of ASCII characters, using the embedded ASCII format
1607 effector characters (LF, BS, FF, ...) to control the
1608 format when a file is printed. For such hosts, there
1609 is no distinction between "print" files and other
1610 files. However, systems that use record structured
1611 files typically need a special format for printable
1612 files (e.g., ASA carriage control). For the latter
1613 hosts, FTP allows a choice of TYPE N or TYPE T.
1614
1615 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
1616
1617 Implementation of page structure is NOT RECOMMENDED in
1618 general. However, if a host system does need to implement
1619 FTP for "random access" or "holey" files, it MUST use the
1620 defined page structure format rather than define a new
1621 private FTP format.
1622
1623 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2
1624
1625 An FTP transformation between record-structure and file-
1626 structure SHOULD be invertible, to the extent possible while
1627 making the result useful on the target host.
1628
1629 DISCUSSION:
1630 RFC-959 required strict invertibility between record-
1631 structure and file-structure, but in practice,
1632 efficiency and convenience often preclude it.
1633 Therefore, the requirement is being relaxed. There are
1634 two different objectives for transferring a file:
1635 processing it on the target host, or just storage. For
1636 storage, strict invertibility is important. For
1637 processing, the file created on the target host needs
1638 to be in the format expected by application programs on
1639 that host.
1640
1641 As an example of the conflict, imagine a record-
1642 oriented operating system that requires some data files
1643 to have exactly 80 bytes in each record. While STORing
1644
1645
1646
1647 Internet Engineering Task Force [Page 30]
1648 RFC1123 FILE TRANSFER -- FTP October 1989
1649
1650
1651 a file on such a host, an FTP Server must be able to
1652 pad each line or record to 80 bytes; a later retrieval
1653 of such a file cannot be strictly invertible.
1654
1655 4.1.2.5 Data Connection Management: RFC-959 Section 3.3
1656
1657 A User-FTP that uses STREAM mode SHOULD send a PORT command
1658 to assign a non-default data port before each transfer
1659 command is issued.
1660
1661 DISCUSSION:
1662 This is required because of the long delay after a TCP
1663 connection is closed until its socket pair can be
1664 reused, to allow multiple transfers during a single FTP
1665 session. Sending a port command can avoided if a
1666 transfer mode other than stream is used, by leaving the
1667 data transfer connection open between transfers.
1668
1669 4.1.2.6 PASV Command: RFC-959 Section 4.1.2
1670
1671 A server-FTP MUST implement the PASV command.
1672
1673 If multiple third-party transfers are to be executed during
1674 the same session, a new PASV command MUST be issued before
1675 each transfer command, to obtain a unique port pair.
1676
1677 IMPLEMENTATION:
1678 The format of the 227 reply to a PASV command is not
1679 well standardized. In particular, an FTP client cannot
1680 assume that the parentheses shown on page 40 of RFC-959
1681 will be present (and in fact, Figure 3 on page 43 omits
1682 them). Therefore, a User-FTP program that interprets
1683 the PASV reply must scan the reply for the first digit
1684 of the host and port numbers.
1685
1686 Note that the host number h1,h2,h3,h4 is the IP address
1687 of the server host that is sending the reply, and that
1688 p1,p2 is a non-default data transfer port that PASV has
1689 assigned.
1690
1691 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3
1692
1693 The data returned by an NLST command MUST contain only a
1694 simple list of legal pathnames, such that the server can use
1695 them directly as the arguments of subsequent data transfer
1696 commands for the individual files.
1697
1698 The data returned by a LIST or NLST command SHOULD use an
1699
1700
1701
1702 Internet Engineering Task Force [Page 31]
1703 RFC1123 FILE TRANSFER -- FTP October 1989
1704
1705
1706 implied TYPE AN, unless the current type is EBCDIC, in which
1707 case an implied TYPE EN SHOULD be used.
1708
1709 DISCUSSION:
1710 Many FTP clients support macro-commands that will get
1711 or put files matching a wildcard specification, using
1712 NLST to obtain a list of pathnames. The expansion of
1713 "multiple-put" is local to the client, but "multiple-
1714 get" requires cooperation by the server.
1715
1716 The implied type for LIST and NLST is designed to
1717 provide compatibility with existing User-FTPs, and in
1718 particular with multiple-get commands.
1719
1720 4.1.2.8 SITE Command: RFC-959 Section 4.1.3
1721
1722 A Server-FTP SHOULD use the SITE command for non-standard
1723 features, rather than invent new private commands or
1724 unstandardized extensions to existing commands.
1725
1726 4.1.2.9 STOU Command: RFC-959 Section 4.1.3
1727
1728 The STOU command stores into a uniquely named file. When it
1729 receives an STOU command, a Server-FTP MUST return the
1730 actual file name in the "125 Transfer Starting" or the "150
1731 Opening Data Connection" message that precedes the transfer
1732 (the 250 reply code mentioned in RFC-959 is incorrect). The
1733 exact format of these messages is hereby defined to be as
1734 follows:
1735
1736 125 FILE: pppp
1737 150 FILE: pppp
1738
1739 where pppp represents the unique pathname of the file that
1740 will be written.
1741
1742 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34
1743
1744 Implementors MUST NOT assume any correspondence between READ
1745 boundaries on the control connection and the Telnet EOL
1746 sequences (CR LF).
1747
1748 DISCUSSION:
1749 Thus, a server-FTP (or User-FTP) must continue reading
1750 characters from the control connection until a complete
1751 Telnet EOL sequence is encountered, before processing
1752 the command (or response, respectively). Conversely, a
1753 single READ from the control connection may include
1754
1755
1756
1757 Internet Engineering Task Force [Page 32]
1758 RFC1123 FILE TRANSFER -- FTP October 1989
1759
1760
1761 more than one FTP command.
1762
1763 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35
1764
1765 A Server-FTP MUST send only correctly formatted replies on
1766 the control connection. Note that RFC-959 (unlike earlier
1767 versions of the FTP spec) contains no provision for a
1768 "spontaneous" reply message.
1769
1770 A Server-FTP SHOULD use the reply codes defined in RFC-959
1771 whenever they apply. However, a server-FTP MAY use a
1772 different reply code when needed, as long as the general
1773 rules of Section 4.2 are followed. When the implementor has
1774 a choice between a 4xx and 5xx reply code, a Server-FTP
1775 SHOULD send a 4xx (temporary failure) code when there is any
1776 reasonable possibility that a failed FTP will succeed a few
1777 hours later.
1778
1779 A User-FTP SHOULD generally use only the highest-order digit
1780 of a 3-digit reply code for making a procedural decision, to
1781 prevent difficulties when a Server-FTP uses non-standard
1782 reply codes.
1783
1784 A User-FTP MUST be able to handle multi-line replies. If
1785 the implementation imposes a limit on the number of lines
1786 and if this limit is exceeded, the User-FTP MUST recover,
1787 e.g., by ignoring the excess lines until the end of the
1788 multi-line reply is reached.
1789
1790 A User-FTP SHOULD NOT interpret a 421 reply code ("Service
1791 not available, closing control connection") specially, but
1792 SHOULD detect closing of the control connection by the
1793 server.
1794
1795 DISCUSSION:
1796 Server implementations that fail to strictly follow the
1797 reply rules often cause FTP user programs to hang.
1798 Note that RFC-959 resolved ambiguities in the reply
1799 rules found in earlier FTP specifications and must be
1800 followed.
1801
1802 It is important to choose FTP reply codes that properly
1803 distinguish between temporary and permanent failures,
1804 to allow the successful use of file transfer client
1805 daemons. These programs depend on the reply codes to
1806 decide whether or not to retry a failed transfer; using
1807 a permanent failure code (5xx) for a temporary error
1808 will cause these programs to give up unnecessarily.
1809
1810
1811
1812 Internet Engineering Task Force [Page 33]
1813 RFC1123 FILE TRANSFER -- FTP October 1989
1814
1815
1816 When the meaning of a reply matches exactly the text
1817 shown in RFC-959, uniformity will be enhanced by using
1818 the RFC-959 text verbatim. However, a Server-FTP
1819 implementor is encouraged to choose reply text that
1820 conveys specific system-dependent information, when
1821 appropriate.
1822
1823 4.1.2.12 Connections: RFC-959 Section 5.2
1824
1825 The words "and the port used" in the second paragraph of
1826 this section of RFC-959 are erroneous (historical), and they
1827 should be ignored.
1828
1829 On a multihomed server host, the default data transfer port
1830 (L-1) MUST be associated with the same local IP address as
1831 the corresponding control connection to port L.
1832
1833 A user-FTP MUST NOT send any Telnet controls other than
1834 SYNCH and IP on an FTP control connection. In particular, it
1835 MUST NOT attempt to negotiate Telnet options on the control
1836 connection. However, a server-FTP MUST be capable of
1837 accepting and refusing Telnet negotiations (i.e., sending
1838 DONT/WONT).
1839
1840 DISCUSSION:
1841 Although the RFC says: "Server- and User- processes
1842 should follow the conventions for the Telnet
1843 protocol...[on the control connection]", it is not the
1844 intent that Telnet option negotiation is to be
1845 employed.
1846
1847 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1
1848
1849 The following commands and options MUST be supported by
1850 every server-FTP and user-FTP, except in cases where the
1851 underlying file system or operating system does not allow or
1852 support a particular command.
1853
1854 Type: ASCII Non-print, IMAGE, LOCAL 8
1855 Mode: Stream
1856 Structure: File, Record*
1857 Commands:
1858 USER, PASS, ACCT,
1859 PORT, PASV,
1860 TYPE, MODE, STRU,
1861 RETR, STOR, APPE,
1862 RNFR, RNTO, DELE,
1863 CWD, CDUP, RMD, MKD, PWD,
1864
1865
1866
1867 Internet Engineering Task Force [Page 34]
1868 RFC1123 FILE TRANSFER -- FTP October 1989
1869
1870
1871 LIST, NLST,
1872 SYST, STAT,
1873 HELP, NOOP, QUIT.
1874
1875 *Record structure is REQUIRED only for hosts whose file
1876 systems support record structure.
1877
1878 DISCUSSION:
1879 Vendors are encouraged to implement a larger subset of
1880 the protocol. For example, there are important
1881 robustness features in the protocol (e.g., Restart,
1882 ABOR, block mode) that would be an aid to some Internet
1883 users but are not widely implemented.
1884
1885 A host that does not have record structures in its file
1886 system may still accept files with STRU R, recording
1887 the byte stream literally.
1888
1889 4.1.3 SPECIFIC ISSUES
1890
1891 4.1.3.1 Non-standard Command Verbs
1892
1893 FTP allows "experimental" commands, whose names begin with
1894 "X". If these commands are subsequently adopted as
1895 standards, there may still be existing implementations using
1896 the "X" form. At present, this is true for the directory
1897 commands:
1898
1899 RFC-959 "Experimental"
1900
1901 MKD XMKD
1902 RMD XRMD
1903 PWD XPWD
1904 CDUP XCUP
1905 CWD XCWD
1906
1907 All FTP implementations SHOULD recognize both forms of these
1908 commands, by simply equating them with extra entries in the
1909 command lookup table.
1910
1911 IMPLEMENTATION:
1912 A User-FTP can access a server that supports only the
1913 "X" forms by implementing a mode switch, or
1914 automatically using the following procedure: if the
1915 RFC-959 form of one of the above commands is rejected
1916 with a 500 or 502 response code, then try the
1917 experimental form; any other response would be passed
1918 to the user.
1919
1920
1921
1922 Internet Engineering Task Force [Page 35]
1923 RFC1123 FILE TRANSFER -- FTP October 1989
1924
1925
1926 4.1.3.2 Idle Timeout
1927
1928 A Server-FTP process SHOULD have an idle timeout, which will
1929 terminate the process and close the control connection if
1930 the server is inactive (i.e., no command or data transfer in
1931 progress) for a long period of time. The idle timeout time
1932 SHOULD be configurable, and the default should be at least 5
1933 minutes.
1934
1935 A client FTP process ("User-PI" in RFC-959) will need
1936 timeouts on responses only if it is invoked from a program.
1937
1938 DISCUSSION:
1939 Without a timeout, a Server-FTP process may be left
1940 pending indefinitely if the corresponding client
1941 crashes without closing the control connection.
1942
1943 4.1.3.3 Concurrency of Data and Control
1944
1945 DISCUSSION:
1946 The intent of the designers of FTP was that a user
1947 should be able to send a STAT command at any time while
1948 data transfer was in progress and that the server-FTP
1949 would reply immediately with status -- e.g., the number
1950 of bytes transferred so far. Similarly, an ABOR
1951 command should be possible at any time during a data
1952 transfer.
1953
1954 Unfortunately, some small-machine operating systems
1955 make such concurrent programming difficult, and some
1956 other implementers seek minimal solutions, so some FTP
1957 implementations do not allow concurrent use of the data
1958 and control connections. Even such a minimal server
1959 must be prepared to accept and defer a STAT or ABOR
1960 command that arrives during data transfer.
1961
1962 4.1.3.4 FTP Restart Mechanism
1963
1964 The description of the 110 reply on pp. 40-41 of RFC-959 is
1965 incorrect; the correct description is as follows. A restart
1966 reply message, sent over the control connection from the
1967 receiving FTP to the User-FTP, has the format:
1968
1969 110 MARK ssss = rrrr
1970
1971 Here:
1972
1973 * ssss is a text string that appeared in a Restart Marker
1974
1975
1976
1977 Internet Engineering Task Force [Page 36]
1978 RFC1123 FILE TRANSFER -- FTP October 1989
1979
1980
1981 in the data stream and encodes a position in the
1982 sender's file system;
1983
1984 * rrrr encodes the corresponding position in the
1985 receiver's file system.
1986
1987 The encoding, which is specific to a particular file system
1988 and network implementation, is always generated and
1989 interpreted by the same system, either sender or receiver.
1990
1991 When an FTP that implements restart receives a Restart
1992 Marker in the data stream, it SHOULD force the data to that
1993 point to be written to stable storage before encoding the
1994 corresponding position rrrr. An FTP sending Restart Markers
1995 MUST NOT assume that 110 replies will be returned
1996 synchronously with the data, i.e., it must not await a 110
1997 reply before sending more data.
1998
1999 Two new reply codes are hereby defined for errors
2000 encountered in restarting a transfer:
2001
2002 554 Requested action not taken: invalid REST parameter.
2003
2004 A 554 reply may result from a FTP service command that
2005 follows a REST command. The reply indicates that the
2006 existing file at the Server-FTP cannot be repositioned
2007 as specified in the REST.
2008
2009 555 Requested action not taken: type or stru mismatch.
2010
2011 A 555 reply may result from an APPE command or from any
2012 FTP service command following a REST command. The
2013 reply indicates that there is some mismatch between the
2014 current transfer parameters (type and stru) and the
2015 attributes of the existing file.
2016
2017 DISCUSSION:
2018 Note that the FTP Restart mechanism requires that Block
2019 or Compressed mode be used for data transfer, to allow
2020 the Restart Markers to be included within the data
2021 stream. The frequency of Restart Markers can be low.
2022
2023 Restart Markers mark a place in the data stream, but
2024 the receiver may be performing some transformation on
2025 the data as it is stored into stable storage. In
2026 general, the receiver's encoding must include any state
2027 information necessary to restart this transformation at
2028 any point of the FTP data stream. For example, in TYPE
2029
2030
2031
2032 Internet Engineering Task Force [Page 37]
2033 RFC1123 FILE TRANSFER -- FTP October 1989
2034
2035
2036 A transfers, some receiver hosts transform CR LF
2037 sequences into a single LF character on disk. If a
2038 Restart Marker happens to fall between CR and LF, the
2039 receiver must encode in rrrr that the transfer must be
2040 restarted in a "CR has been seen and discarded" state.
2041
2042 Note that the Restart Marker is required to be encoded
2043 as a string of printable ASCII characters, regardless
2044 of the type of the data.
2045
2046 RFC-959 says that restart information is to be returned
2047 "to the user". This should not be taken literally. In
2048 general, the User-FTP should save the restart
2049 information (ssss,rrrr) in stable storage, e.g., append
2050 it to a restart control file. An empty restart control
2051 file should be created when the transfer first starts
2052 and deleted automatically when the transfer completes
2053 successfully. It is suggested that this file have a
2054 name derived in an easily-identifiable manner from the
2055 name of the file being transferred and the remote host
2056 name; this is analogous to the means used by many text
2057 editors for naming "backup" files.
2058
2059 There are three cases for FTP restart.
2060
2061 (1) User-to-Server Transfer
2062
2063 The User-FTP puts Restart Markers <ssss> at
2064 convenient places in the data stream. When the
2065 Server-FTP receives a Marker, it writes all prior
2066 data to disk, encodes its file system position and
2067 transformation state as rrrr, and returns a "110
2068 MARK ssss = rrrr" reply over the control
2069 connection. The User-FTP appends the pair
2070 (ssss,rrrr) to its restart control file.
2071
2072 To restart the transfer, the User-FTP fetches the
2073 last (ssss,rrrr) pair from the restart control
2074 file, repositions its local file system and
2075 transformation state using ssss, and sends the
2076 command "REST rrrr" to the Server-FTP.
2077
2078 (2) Server-to-User Transfer
2079
2080 The Server-FTP puts Restart Markers <ssss> at
2081 convenient places in the data stream. When the
2082 User-FTP receives a Marker, it writes all prior
2083 data to disk, encodes its file system position and
2084
2085
2086
2087 Internet Engineering Task Force [Page 38]
2088 RFC1123 FILE TRANSFER -- FTP October 1989
2089
2090
2091 transformation state as rrrr, and appends the pair
2092 (rrrr,ssss) to its restart control file.
2093
2094 To restart the transfer, the User-FTP fetches the
2095 last (rrrr,ssss) pair from the restart control
2096 file, repositions its local file system and
2097 transformation state using rrrr, and sends the
2098 command "REST ssss" to the Server-FTP.
2099
2100 (3) Server-to-Server ("Third-Party") Transfer
2101
2102 The sending Server-FTP puts Restart Markers <ssss>
2103 at convenient places in the data stream. When it
2104 receives a Marker, the receiving Server-FTP writes
2105 all prior data to disk, encodes its file system
2106 position and transformation state as rrrr, and
2107 sends a "110 MARK ssss = rrrr" reply over the
2108 control connection to the User. The User-FTP
2109 appends the pair (ssss,rrrr) to its restart
2110 control file.
2111
2112 To restart the transfer, the User-FTP fetches the
2113 last (ssss,rrrr) pair from the restart control
2114 file, sends "REST ssss" to the sending Server-FTP,
2115 and sends "REST rrrr" to the receiving Server-FTP.
2116
2117
2118 4.1.4 FTP/USER INTERFACE
2119
2120 This section discusses the user interface for a User-FTP
2121 program.
2122
2123 4.1.4.1 Pathname Specification
2124
2125 Since FTP is intended for use in a heterogeneous
2126 environment, User-FTP implementations MUST support remote
2127 pathnames as arbitrary character strings, so that their form
2128 and content are not limited by the conventions of the local
2129 operating system.
2130
2131 DISCUSSION:
2132 In particular, remote pathnames can be of arbitrary
2133 length, and all the printing ASCII characters as well
2134 as space (0x20) must be allowed. RFC-959 allows a
2135 pathname to contain any 7-bit ASCII character except CR
2136 or LF.
2137
2138
2139
2140
2141
2142 Internet Engineering Task Force [Page 39]
2143 RFC1123 FILE TRANSFER -- FTP October 1989
2144
2145
2146 4.1.4.2 "QUOTE" Command
2147
2148 A User-FTP program MUST implement a "QUOTE" command that
2149 will pass an arbitrary character string to the server and
2150 display all resulting response messages to the user.
2151
2152 To make the "QUOTE" command useful, a User-FTP SHOULD send
2153 transfer control commands to the server as the user enters
2154 them, rather than saving all the commands and sending them
2155 to the server only when a data transfer is started.
2156
2157 DISCUSSION:
2158 The "QUOTE" command is essential to allow the user to
2159 access servers that require system-specific commands
2160 (e.g., SITE or ALLO), or to invoke new or optional
2161 features that are not implemented by the User-FTP. For
2162 example, "QUOTE" may be used to specify "TYPE A T" to
2163 send a print file to hosts that require the
2164 distinction, even if the User-FTP does not recognize
2165 that TYPE.
2166
2167 4.1.4.3 Displaying Replies to User
2168
2169 A User-FTP SHOULD display to the user the full text of all
2170 error reply messages it receives. It SHOULD have a
2171 "verbose" mode in which all commands it sends and the full
2172 text and reply codes it receives are displayed, for
2173 diagnosis of problems.
2174
2175 4.1.4.4 Maintaining Synchronization
2176
2177 The state machine in a User-FTP SHOULD be forgiving of
2178 missing and unexpected reply messages, in order to maintain
2179 command synchronization with the server.
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197 Internet Engineering Task Force [Page 40]
2198 RFC1123 FILE TRANSFER -- FTP October 1989
2199
2200
2201 4.1.5 FTP REQUIREMENTS SUMMARY
2202
2203 | | | | |S| |
2204 | | | | |H| |F
2205 | | | | |O|M|o
2206 | | |S| |U|U|o
2207 | | |H| |L|S|t
2208 | |M|O| |D|T|n
2209 | |U|U|M| | |o
2210 | |S|L|A|N|N|t
2211 | |T|D|Y|O|O|t
2212 FEATURE |SECTION | | | |T|T|e
2213 -------------------------------------------|---------------|-|-|-|-|-|--
2214 Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | |
2215 File/Record transform invertible if poss. |4.1.2.4 | |x| | | |
2216 User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | |
2217 Server-FTP implement PASV |4.1.2.6 |x| | | | |
2218 PASV is per-transfer |4.1.2.6 |x| | | | |
2219 NLST reply usable in RETR cmds |4.1.2.7 |x| | | | |
2220 Implied type for LIST and NLST |4.1.2.7 | |x| | | |
2221 SITE cmd for non-standard features |4.1.2.8 | |x| | | |
2222 STOU cmd return pathname as specified |4.1.2.9 |x| | | | |
2223 Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x|
2224 | | | | | | |
2225 Server-FTP send only correct reply format |4.1.2.11 |x| | | | |
2226 Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | |
2227 New reply code following Section 4.2 |4.1.2.11 | | |x| | |
2228 User-FTP use only high digit of reply |4.1.2.11 | |x| | | |
2229 User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | |
2230 User-FTP handle 421 reply specially |4.1.2.11 | | | |x| |
2231 | | | | | | |
2232 Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | |
2233 User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x|
2234 User-FTP negotiate Telnet options |4.1.2.12 | | | | |x|
2235 Server-FTP handle Telnet options |4.1.2.12 |x| | | | |
2236 Handle "Experimental" directory cmds |4.1.3.1 | |x| | | |
2237 Idle timeout in server-FTP |4.1.3.2 | |x| | | |
2238 Configurable idle timeout |4.1.3.2 | |x| | | |
2239 Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | |
2240 Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x|
2241 | | | | | | |
2242 Support TYPE: | | | | | | |
2243 ASCII - Non-Print (AN) |4.1.2.13 |x| | | | |
2244 ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | |
2245 ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | |
2246 EBCDIC - (any form) |959 3.1.1.2 | | |x| | |
2247 IMAGE |4.1.2.1 |x| | | | |
2248 LOCAL 8 |4.1.2.1 |x| | | | |
2249
2250
2251
2252 Internet Engineering Task Force [Page 41]
2253 RFC1123 FILE TRANSFER -- FTP October 1989
2254
2255
2256 LOCAL m |4.1.2.1 | | |x| | |2
2257 | | | | | | |
2258 Support MODE: | | | | | | |
2259 Stream |4.1.2.13 |x| | | | |
2260 Block |959 3.4.2 | | |x| | |
2261 | | | | | | |
2262 Support STRUCTURE: | | | | | | |
2263 File |4.1.2.13 |x| | | | |
2264 Record |4.1.2.13 |x| | | | |3
2265 Page |4.1.2.3 | | | |x| |
2266 | | | | | | |
2267 Support commands: | | | | | | |
2268 USER |4.1.2.13 |x| | | | |
2269 PASS |4.1.2.13 |x| | | | |
2270 ACCT |4.1.2.13 |x| | | | |
2271 CWD |4.1.2.13 |x| | | | |
2272 CDUP |4.1.2.13 |x| | | | |
2273 SMNT |959 5.3.1 | | |x| | |
2274 REIN |959 5.3.1 | | |x| | |
2275 QUIT |4.1.2.13 |x| | | | |
2276 | | | | | | |
2277 PORT |4.1.2.13 |x| | | | |
2278 PASV |4.1.2.6 |x| | | | |
2279 TYPE |4.1.2.13 |x| | | | |1
2280 STRU |4.1.2.13 |x| | | | |1
2281 MODE |4.1.2.13 |x| | | | |1
2282 | | | | | | |
2283 RETR |4.1.2.13 |x| | | | |
2284 STOR |4.1.2.13 |x| | | | |
2285 STOU |959 5.3.1 | | |x| | |
2286 APPE |4.1.2.13 |x| | | | |
2287 ALLO |959 5.3.1 | | |x| | |
2288 REST |959 5.3.1 | | |x| | |
2289 RNFR |4.1.2.13 |x| | | | |
2290 RNTO |4.1.2.13 |x| | | | |
2291 ABOR |959 5.3.1 | | |x| | |
2292 DELE |4.1.2.13 |x| | | | |
2293 RMD |4.1.2.13 |x| | | | |
2294 MKD |4.1.2.13 |x| | | | |
2295 PWD |4.1.2.13 |x| | | | |
2296 LIST |4.1.2.13 |x| | | | |
2297 NLST |4.1.2.13 |x| | | | |
2298 SITE |4.1.2.8 | | |x| | |
2299 STAT |4.1.2.13 |x| | | | |
2300 SYST |4.1.2.13 |x| | | | |
2301 HELP |4.1.2.13 |x| | | | |
2302 NOOP |4.1.2.13 |x| | | | |
2303 | | | | | | |
2304
2305
2306
2307 Internet Engineering Task Force [Page 42]
2308 RFC1123 FILE TRANSFER -- FTP October 1989
2309
2310
2311 User Interface: | | | | | | |
2312 Arbitrary pathnames |4.1.4.1 |x| | | | |
2313 Implement "QUOTE" command |4.1.4.2 |x| | | | |
2314 Transfer control commands immediately |4.1.4.2 | |x| | | |
2315 Display error messages to user |4.1.4.3 | |x| | | |
2316 Verbose mode |4.1.4.3 | |x| | | |
2317 Maintain synchronization with server |4.1.4.4 | |x| | | |
2318
2319 Footnotes:
2320
2321 (1) For the values shown earlier.
2322
2323 (2) Here m is number of bits in a memory word.
2324
2325 (3) Required for host with record-structured file system, optional
2326 otherwise.
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362 Internet Engineering Task Force [Page 43]
2363 RFC1123 FILE TRANSFER -- TFTP October 1989
2364
2365
2366 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
2367
2368 4.2.1 INTRODUCTION
2369
2370 The Trivial File Transfer Protocol TFTP is defined in RFC-783
2371 [TFTP:1].
2372
2373 TFTP provides its own reliable delivery with UDP as its
2374 transport protocol, using a simple stop-and-wait acknowledgment
2375 system. Since TFTP has an effective window of only one 512
2376 octet segment, it can provide good performance only over paths
2377 that have a small delay*bandwidth product. The TFTP file
2378 interface is very simple, providing no access control or
2379 security.
2380
2381 TFTP's most important application is bootstrapping a host over
2382 a local network, since it is simple and small enough to be
2383 easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are
2384 urged to support TFTP for booting.
2385
2386 4.2.2 PROTOCOL WALK-THROUGH
2387
2388 The TFTP specification [TFTP:1] is written in an open style,
2389 and does not fully specify many parts of the protocol.
2390
2391 4.2.2.1 Transfer Modes: RFC-783, Page 3
2392
2393 The transfer mode "mail" SHOULD NOT be supported.
2394
2395 4.2.2.2 UDP Header: RFC-783, Page 17
2396
2397 The Length field of a UDP header is incorrectly defined; it
2398 includes the UDP header length (8).
2399
2400 4.2.3 SPECIFIC ISSUES
2401
2402 4.2.3.1 Sorcerer's Apprentice Syndrome
2403
2404 There is a serious bug, known as the "Sorcerer's Apprentice
2405 Syndrome," in the protocol specification. While it does not
2406 cause incorrect operation of the transfer (the file will
2407 always be transferred correctly if the transfer completes),
2408 this bug may cause excessive retransmission, which may cause
2409 the transfer to time out.
2410
2411 Implementations MUST contain the fix for this problem: the
2412 sender (i.e., the side originating the DATA packets) must
2413 never resend the current DATA packet on receipt of a
2414
2415
2416
2417 Internet Engineering Task Force [Page 44]
2418 RFC1123 FILE TRANSFER -- TFTP October 1989
2419
2420
2421 duplicate ACK.
2422
2423 DISCUSSION:
2424 The bug is caused by the protocol rule that either
2425 side, on receiving an old duplicate datagram, may
2426 resend the current datagram. If a packet is delayed in
2427 the network but later successfully delivered after
2428 either side has timed out and retransmitted a packet, a
2429 duplicate copy of the response may be generated. If
2430 the other side responds to this duplicate with a
2431 duplicate of its own, then every datagram will be sent
2432 in duplicate for the remainder of the transfer (unless
2433 a datagram is lost, breaking the repetition). Worse
2434 yet, since the delay is often caused by congestion,
2435 this duplicate transmission will usually causes more
2436 congestion, leading to more delayed packets, etc.
2437
2438 The following example may help to clarify this problem.
2439
2440 TFTP A TFTP B
2441
2442 (1) Receive ACK X-1
2443 Send DATA X
2444 (2) Receive DATA X
2445 Send ACK X
2446 (ACK X is delayed in network,
2447 and A times out):
2448 (3) Retransmit DATA X
2449
2450 (4) Receive DATA X again
2451 Send ACK X again
2452 (5) Receive (delayed) ACK X
2453 Send DATA X+1
2454 (6) Receive DATA X+1
2455 Send ACK X+1
2456 (7) Receive ACK X again
2457 Send DATA X+1 again
2458 (8) Receive DATA X+1 again
2459 Send ACK X+1 again
2460 (9) Receive ACK X+1
2461 Send DATA X+2
2462 (10) Receive DATA X+2
2463 Send ACK X+3
2464 (11) Receive ACK X+1 again
2465 Send DATA X+2 again
2466 (12) Receive DATA X+2 again
2467 Send ACK X+3 again
2468
2469
2470
2471
2472 Internet Engineering Task Force [Page 45]
2473 RFC1123 FILE TRANSFER -- TFTP October 1989
2474
2475
2476 Notice that once the delayed ACK arrives, the protocol
2477 settles down to duplicate all further packets
2478 (sequences 5-8 and 9-12). The problem is caused not by
2479 either side timing out, but by both sides
2480 retransmitting the current packet when they receive a
2481 duplicate.
2482
2483 The fix is to break the retransmission loop, as
2484 indicated above. This is analogous to the behavior of
2485 TCP. It is then possible to remove the retransmission
2486 timer on the receiver, since the resent ACK will never
2487 cause any action; this is a useful simplification where
2488 TFTP is used in a bootstrap program. It is OK to allow
2489 the timer to remain, and it may be helpful if the
2490 retransmitted ACK replaces one that was genuinely lost
2491 in the network. The sender still requires a retransmit
2492 timer, of course.
2493
2494 4.2.3.2 Timeout Algorithms
2495
2496 A TFTP implementation MUST use an adaptive timeout.
2497
2498 IMPLEMENTATION:
2499 TCP retransmission algorithms provide a useful base to
2500 work from. At least an exponential backoff of
2501 retransmission timeout is necessary.
2502
2503 4.2.3.3 Extensions
2504
2505 A variety of non-standard extensions have been made to TFTP,
2506 including additional transfer modes and a secure operation
2507 mode (with passwords). None of these have been
2508 standardized.
2509
2510 4.2.3.4 Access Control
2511
2512 A server TFTP implementation SHOULD include some
2513 configurable access control over what pathnames are allowed
2514 in TFTP operations.
2515
2516 4.2.3.5 Broadcast Request
2517
2518 A TFTP request directed to a broadcast address SHOULD be
2519 silently ignored.
2520
2521 DISCUSSION:
2522 Due to the weak access control capability of TFTP,
2523 directed broadcasts of TFTP requests to random networks
2524
2525
2526
2527 Internet Engineering Task Force [Page 46]
2528 RFC1123 FILE TRANSFER -- TFTP October 1989
2529
2530
2531 could create a significant security hole.
2532
2533 4.2.4 TFTP REQUIREMENTS SUMMARY
2534
2535 | | | | |S| |
2536 | | | | |H| |F
2537 | | | | |O|M|o
2538 | | |S| |U|U|o
2539 | | |H| |L|S|t
2540 | |M|O| |D|T|n
2541 | |U|U|M| | |o
2542 | |S|L|A|N|N|t
2543 | |T|D|Y|O|O|t
2544 FEATURE |SECTION | | | |T|T|e
2545 -------------------------------------------------|--------|-|-|-|-|-|--
2546 Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | |
2547 Transfer modes: | | | | | | |
2548 netascii |RFC-783 |x| | | | |
2549 octet |RFC-783 |x| | | | |
2550 mail |4.2.2.1 | | | |x| |
2551 extensions |4.2.3.3 | | |x| | |
2552 Use adaptive timeout |4.2.3.2 |x| | | | |
2553 Configurable access control |4.2.3.4 | |x| | | |
2554 Silently ignore broadcast request |4.2.3.5 | |x| | | |
2555 -------------------------------------------------|--------|-|-|-|-|-|--
2556 -------------------------------------------------|--------|-|-|-|-|-|--
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582 Internet Engineering Task Force [Page 47]
2583 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2584
2585
2586 5. ELECTRONIC MAIL -- SMTP and RFC-822
2587
2588 5.1 INTRODUCTION
2589
2590 In the TCP/IP protocol suite, electronic mail in a format
2591 specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
2592 Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
2593
2594 While SMTP has remained unchanged over the years, the Internet
2595 community has made several changes in the way SMTP is used. In
2596 particular, the conversion to the Domain Name System (DNS) has
2597 caused changes in address formats and in mail routing. In this
2598 section, we assume familiarity with the concepts and terminology
2599 of the DNS, whose requirements are given in Section 6.1.
2600
2601 RFC-822 specifies the Internet standard format for electronic mail
2602 messages. RFC-822 supercedes an older standard, RFC-733, that may
2603 still be in use in a few places, although it is obsolete. The two
2604 formats are sometimes referred to simply by number ("822" and
2605 "733").
2606
2607 RFC-822 is used in some non-Internet mail environments with
2608 different mail transfer protocols than SMTP, and SMTP has also
2609 been adapted for use in some non-Internet environments. Note that
2610 this document presents the rules for the use of SMTP and RFC-822
2611 for the Internet environment only; other mail environments that
2612 use these protocols may be expected to have their own rules.
2613
2614 5.2 PROTOCOL WALK-THROUGH
2615
2616 This section covers both RFC-821 and RFC-822.
2617
2618 The SMTP specification in RFC-821 is clear and contains numerous
2619 examples, so implementors should not find it difficult to
2620 understand. This section simply updates or annotates portions of
2621 RFC-821 to conform with current usage.
2622
2623 RFC-822 is a long and dense document, defining a rich syntax.
2624 Unfortunately, incomplete or defective implementations of RFC-822
2625 are common. In fact, nearly all of the many formats of RFC-822
2626 are actually used, so an implementation generally needs to
2627 recognize and correctly interpret all of the RFC-822 syntax.
2628
2629 5.2.1 The SMTP Model: RFC-821 Section 2
2630
2631 DISCUSSION:
2632 Mail is sent by a series of request/response transactions
2633 between a client, the "sender-SMTP," and a server, the
2634
2635
2636
2637 Internet Engineering Task Force [Page 48]
2638 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2639
2640
2641 "receiver-SMTP". These transactions pass (1) the message
2642 proper, which is composed of header and body, and (2) SMTP
2643 source and destination addresses, referred to as the
2644 "envelope".
2645
2646 The SMTP programs are analogous to Message Transfer Agents
2647 (MTAs) of X.400. There will be another level of protocol
2648 software, closer to the end user, that is responsible for
2649 composing and analyzing RFC-822 message headers; this
2650 component is known as the "User Agent" in X.400, and we
2651 use that term in this document. There is a clear logical
2652 distinction between the User Agent and the SMTP
2653 implementation, since they operate on different levels of
2654 protocol. Note, however, that this distinction is may not
2655 be exactly reflected the structure of typical
2656 implementations of Internet mail. Often there is a
2657 program known as the "mailer" that implements SMTP and
2658 also some of the User Agent functions; the rest of the
2659 User Agent functions are included in a user interface used
2660 for entering and reading mail.
2661
2662 The SMTP envelope is constructed at the originating site,
2663 typically by the User Agent when the message is first
2664 queued for the Sender-SMTP program. The envelope
2665 addresses may be derived from information in the message
2666 header, supplied by the user interface (e.g., to implement
2667 a bcc: request), or derived from local configuration
2668 information (e.g., expansion of a mailing list). The SMTP
2669 envelope cannot in general be re-derived from the header
2670 at a later stage in message delivery, so the envelope is
2671 transmitted separately from the message itself using the
2672 MAIL and RCPT commands of SMTP.
2673
2674 The text of RFC-821 suggests that mail is to be delivered
2675 to an individual user at a host. With the advent of the
2676 domain system and of mail routing using mail-exchange (MX)
2677 resource records, implementors should now think of
2678 delivering mail to a user at a domain, which may or may
2679 not be a particular host. This DOES NOT change the fact
2680 that SMTP is a host-to-host mail exchange protocol.
2681
This is required because of the long delay after a TCP
connection is closed until its socket pair can be
reused, to allow multiple transfers during a single FTP
session. Sending a port command can avoided if a
transfer mode other than stream is used, by leaving the
data transfer connection open between transfers.
This is required because of the long delay after a TCP
connection is closed until its socket pair can be
reused, to allow multiple transfers during a single FTP
session. Sending a port command can be avoided if a
transfer mode other than stream is used, by leaving the
data transfer connection open between transfers.
2682 5.2.2 Canonicalization: RFC-821 Section 3.1
2683
2684 The domain names that a Sender-SMTP sends in MAIL and RCPT
2685 commands MUST have been "canonicalized," i.e., they must be
2686 fully-qualified principal names or domain literals, not
2687 nicknames or domain abbreviations. A canonicalized name either
2688 identifies a host directly or is an MX name; it cannot be a
2689
2690
2691
2692 Internet Engineering Task Force [Page 49]
2693 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2694
2695
2696 CNAME.
2697
2698 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3
2699
2700 A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
2701 (this requirement overrides RFC-821). However, there MAY be
2702 configuration information to disable VRFY and EXPN in a
2703 particular installation; this might even allow EXPN to be
2704 disabled for selected lists.
2705
2706 A new reply code is defined for the VRFY command:
2707
2708 252 Cannot VRFY user (e.g., info is not local), but will
2709 take message for this user and attempt delivery.
2710
2711 DISCUSSION:
2712 SMTP users and administrators make regular use of these
2713 commands for diagnosing mail delivery problems. With the
2714 increasing use of multi-level mailing list expansion
2715 (sometimes more than two levels), EXPN has been
2716 increasingly important for diagnosing inadvertent mail
2717 loops. On the other hand, some feel that EXPN represents
2718 a significant privacy, and perhaps even a security,
2719 exposure.
2720
2721 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4
2722
2723 An SMTP MAY implement the commands to send a message to a
2724 user's terminal: SEND, SOML, and SAML.
2725
2726 DISCUSSION:
2727 It has been suggested that the use of mail relaying
2728 through an MX record is inconsistent with the intent of
2729 SEND to deliver a message immediately and directly to a
2730 user's terminal. However, an SMTP receiver that is unable
2731 to write directly to the user terminal can return a "251
2732 User Not Local" reply to the RCPT following a SEND, to
2733 inform the originator of possibly deferred delivery.
2734
2735 5.2.5 HELO Command: RFC-821 Section 3.5
2736
2737 The sender-SMTP MUST ensure that the <domain> parameter in a
2738 HELO command is a valid principal host domain name for the
2739 client host. As a result, the receiver-SMTP will not have to
2740 perform MX resolution on this name in order to validate the
2741 HELO parameter.
2742
2743 The HELO receiver MAY verify that the HELO parameter really
2744
2745
2746
2747 Internet Engineering Task Force [Page 50]
2748 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2749
2750
2751 corresponds to the IP address of the sender. However, the
2752 receiver MUST NOT refuse to accept a message, even if the
2753 sender's HELO command fails verification.
2754
2755 DISCUSSION:
2756 Verifying the HELO parameter requires a domain name lookup
2757 and may therefore take considerable time. An alternative
2758 tool for tracking bogus mail sources is suggested below
2759 (see "DATA Command").
2760
2761 Note also that the HELO argument is still required to have
2762 valid <domain> syntax, since it will appear in a Received:
2763 line; otherwise, a 501 error is to be sent.
2764
2765 IMPLEMENTATION:
2766 When HELO parameter validation fails, a suggested
2767 procedure is to insert a note about the unknown
2768 authenticity of the sender into the message header (e.g.,
2769 in the "Received:" line).
2770
2771 5.2.6 Mail Relay: RFC-821 Section 3.6
2772
2773 We distinguish three types of mail (store-and-) forwarding:
2774
2775 (1) A simple forwarder or "mail exchanger" forwards a message
2776 using private knowledge about the recipient; see section
2777 3.2 of RFC-821.
2778
2779 (2) An SMTP mail "relay" forwards a message within an SMTP
2780 mail environment as the result of an explicit source route
2781 (as defined in section 3.6 of RFC-821). The SMTP relay
2782 function uses the "@...:" form of source route from RFC-
2783 822 (see Section 5.2.19 below).
2784
2785 (3) A mail "gateway" passes a message between different
2786 environments. The rules for mail gateways are discussed
2787 below in Section 5.3.7.
2788
2789 An Internet host that is forwarding a message but is not a
2790 gateway to a different mail environment (i.e., it falls under
2791 (1) or (2)) SHOULD NOT alter any existing header fields,
2792 although the host will add an appropriate Received: line as
2793 required in Section 5.2.8.
2794
2795 A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
2796 explicit source route using the "@...:" address form. Thus,
2797 the relay function defined in section 3.6 of RFC-821 should
2798 not be used.
2799
2800
2801
2802 Internet Engineering Task Force [Page 51]
2803 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2804
2805
2806 DISCUSSION:
2807 The intent is to discourage all source routing and to
2808 abolish explicit source routing for mail delivery within
2809 the Internet environment. Source-routing is unnecessary;
2810 the simple target address "user@domain" should always
2811 suffice. This is the result of an explicit architectural
2812 decision to use universal naming rather than source
2813 routing for mail. Thus, SMTP provides end-to-end
2814 connectivity, and the DNS provides globally-unique,
2815 location-independent names. MX records handle the major
2816 case where source routing might otherwise be needed.
2817
2818 A receiver-SMTP MUST accept the explicit source route syntax in
2819 the envelope, but it MAY implement the relay function as
2820 defined in section 3.6 of RFC-821. If it does not implement
2821 the relay function, it SHOULD attempt to deliver the message
2822 directly to the host to the right of the right-most "@" sign.
2823
2824 DISCUSSION:
2825 For example, suppose a host that does not implement the
2826 relay function receives a message with the SMTP command:
2827 "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
2828 GAMMA represent domain names. Rather than immediately
2829 refusing the message with a 550 error reply as suggested
2830 on page 20 of RFC-821, the host should try to forward the
2831 message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
2832 Since this host does not support relaying, it is not
2833 required to update the reverse path.
2834
2835 Some have suggested that source routing may be needed
2836 occasionally for manually routing mail around failures;
2837 however, the reality and importance of this need is
2838 controversial. The use of explicit SMTP mail relaying for
2839 this purpose is discouraged, and in fact it may not be
2840 successful, as many host systems do not support it. Some
2841 have used the "%-hack" (see Section 5.2.16) for this
2842 purpose.
2843
2844 5.2.7 RCPT Command: RFC-821 Section 4.1.1
2845
2846 A host that supports a receiver-SMTP MUST support the reserved
2847 mailbox "Postmaster".
2848
2849 The receiver-SMTP MAY verify RCPT parameters as they arrive;
2850 however, RCPT responses MUST NOT be delayed beyond a reasonable
2851 time (see Section 5.3.2).
2852
2853 Therefore, a "250 OK" response to a RCPT does not necessarily
2854
2855
2856
2857 Internet Engineering Task Force [Page 52]
2858 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2859
2860
2861 imply that the delivery address(es) are valid. Errors found
2862 after message acceptance will be reported by mailing a
2863 notification message to an appropriate address (see Section
2864 5.3.3).
2865
2866 DISCUSSION:
2867 The set of conditions under which a RCPT parameter can be
2868 validated immediately is an engineering design choice.
2869 Reporting destination mailbox errors to the Sender-SMTP
2870 before mail is transferred is generally desirable to save
2871 time and network bandwidth, but this advantage is lost if
2872 RCPT verification is lengthy.
2873
2874 For example, the receiver can verify immediately any
2875 simple local reference, such as a single locally-
2876 registered mailbox. On the other hand, the "reasonable
2877 time" limitation generally implies deferring verification
2878 of a mailing list until after the message has been
2879 transferred and accepted, since verifying a large mailing
2880 list can take a very long time. An implementation might
2881 or might not choose to defer validation of addresses that
2882 are non-local and therefore require a DNS lookup. If a
2883 DNS lookup is performed but a soft domain system error
2884 (e.g., timeout) occurs, validity must be assumed.
2885
2886 5.2.8 DATA Command: RFC-821 Section 4.1.1
2887
2888 Every receiver-SMTP (not just one that "accepts a message for
2889 relaying or for final delivery" [SMTP:1]) MUST insert a
2890 "Received:" line at the beginning of a message. In this line,
2891 called a "time stamp line" in RFC-821:
2892
2893 * The FROM field SHOULD contain both (1) the name of the
2894 source host as presented in the HELO command and (2) a
2895 domain literal containing the IP address of the source,
2896 determined from the TCP connection.
2897
2898 * The ID field MAY contain an "@" as suggested in RFC-822,
2899 but this is not required.
2900
2901 * The FOR field MAY contain a list of <path> entries when
2902 multiple RCPT commands have been given.
2903
2904
2905 An Internet mail program MUST NOT change a Received: line that
2906 was previously added to the message header.
2907
2908
2909
2910
2911
2912 Internet Engineering Task Force [Page 53]
2913 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2914
2915
2916 DISCUSSION:
2917 Including both the source host and the IP source address
2918 in the Received: line may provide enough information for
2919 tracking illicit mail sources and eliminate a need to
2920 explicitly verify the HELO parameter.
2921
2922 Received: lines are primarily intended for humans tracing
2923 mail routes, primarily of diagnosis of faults. See also
2924 the discussion under 5.3.7.
2925
2926 When the receiver-SMTP makes "final delivery" of a message,
2927 then it MUST pass the MAIL FROM: address from the SMTP envelope
2928 with the message, for use if an error notification message must
2929 be sent later (see Section 5.3.3). There is an analogous
2930 requirement when gatewaying from the Internet into a different
2931 mail environment; see Section 5.3.7.
2932
2933 DISCUSSION:
2934 Note that the final reply to the DATA command depends only
2935 upon the successful transfer and storage of the message.
2936 Any problem with the destination address(es) must either
2937 (1) have been reported in an SMTP error reply to the RCPT
2938 command(s), or (2) be reported in a later error message
2939 mailed to the originator.
2940
2941 IMPLEMENTATION:
2942 The MAIL FROM: information may be passed as a parameter or
2943 in a Return-Path: line inserted at the beginning of the
2944 message.
2945
2946 5.2.9 Command Syntax: RFC-821 Section 4.1.2
2947
2948 The syntax shown in RFC-821 for the MAIL FROM: command omits
2949 the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page
2950 15). An empty reverse path MUST be supported.
2951
2952 5.2.10 SMTP Replies: RFC-821 Section 4.2
2953
2954 A receiver-SMTP SHOULD send only the reply codes listed in
2955 section 4.2.2 of RFC-821 or in this document. A receiver-SMTP
2956 SHOULD use the text shown in examples in RFC-821 whenever
2957 appropriate.
2958
2959 A sender-SMTP MUST determine its actions only by the reply
2960 code, not by the text (except for 251 and 551 replies); any
2961 text, including no text at all, must be acceptable. The space
2962 (blank) following the reply code is considered part of the
2963 text. Whenever possible, a sender-SMTP SHOULD test only the
2964
2965
2966
2967 Internet Engineering Task Force [Page 54]
2968 RFC1123 MAIL -- SMTP & RFC-822 October 1989
2969
2970
2971 first digit of the reply code, as specified in Appendix E of
2972 RFC-821.
2973
2974 DISCUSSION:
2975 Interoperability problems have arisen with SMTP systems
2976 using reply codes that are not listed explicitly in RFC-
2977 821 Section 4.3 but are legal according to the theory of
2978 reply codes explained in Appendix E.
2979
2980 5.2.11 Transparency: RFC-821 Section 4.5.2
2981
2982 Implementors MUST be sure that their mail systems always add
2983 and delete periods to ensure message transparency.
2984
2985 5.2.12 WKS Use in MX Processing: RFC-974, p. 5
2986
2987 RFC-974 [SMTP:3] recommended that the domain system be queried
2988 for WKS ("Well-Known Service") records, to verify that each
2989 proposed mail target does support SMTP. Later experience has
2990 shown that WKS is not widely supported, so the WKS step in MX
2991 processing SHOULD NOT be used.
2992
2993 The following are notes on RFC-822, organized by section of that
2994 document.
2995
2996 5.2.13 RFC-822 Message Specification: RFC-822 Section 4
2997
2998 The syntax shown for the Return-path line omits the possibility
2999 of a null return path, which is used to prevent looping of
3000 error notifications (see Section 5.3.3). The complete syntax
3001 is:
3002
3003 return = "Return-path" ":" route-addr
3004 / "Return-path" ":" "<" ">"
3005
3006 The set of optional header fields is hereby expanded to include
3007 the Content-Type field defined in RFC-1049 [SMTP:7]. This
3008 field "allows mail reading systems to automatically identify
3009 the type of a structured message body and to process it for
3010 display accordingly". [SMTP:7] A User Agent MAY support this
3011 field.
3012
3013 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5
3014
3015 The syntax for the date is hereby changed to:
3016
3017 date = 1*2DIGIT month 2*4DIGIT
3018
3019
3020
3021
3022 Internet Engineering Task Force [Page 55]
3023 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3024
3025
3026 All mail software SHOULD use 4-digit years in dates, to ease
3027 the transition to the next century.
3028
3029 There is a strong trend towards the use of numeric timezone
3030 indicators, and implementations SHOULD use numeric timezones
3031 instead of timezone names. However, all implementations MUST
3032 accept either notation. If timezone names are used, they MUST
3033 be exactly as defined in RFC-822.
3034
3035 The military time zones are specified incorrectly in RFC-822:
3036 they count the wrong way from UT (the signs are reversed). As
3037 a result, military time zones in RFC-822 headers carry no
3038 information.
3039
3040 Finally, note that there is a typo in the definition of "zone"
3041 in the syntax summary of appendix D; the correct definition
3042 occurs in Section 3 of RFC-822.
3043
3044 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1
3045
3046 The syntactic definition of "mailbox" in RFC-822 is hereby
3047 changed to:
3048
3049 mailbox = addr-spec ; simple address
3050 / [phrase] route-addr ; name & addr-spec
3051
3052 That is, the phrase preceding a route address is now OPTIONAL.
3053 This change makes the following header field legal, for
3054 example:
3055
3056 From: <craig@nnsc.nsf.net>
3057
3058 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2
3059
3060 The basic mailbox address specification has the form: "local-
3061 part@domain". Here "local-part", sometimes called the "left-
3062 hand side" of the address, is domain-dependent.
3063
3064 A host that is forwarding the message but is not the
3065 destination host implied by the right-hand side "domain" MUST
3066 NOT interpret or modify the "local-part" of the address.
3067
3068 When mail is to be gatewayed from the Internet mail environment
3069 into a foreign mail environment (see Section 5.3.7), routing
3070 information for that foreign environment MAY be embedded within
3071 the "local-part" of the address. The gateway will then
3072 interpret this local part appropriately for the foreign mail
3073 environment.
3074
3075
3076
3077 Internet Engineering Task Force [Page 56]
3078 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3079
3080
3081 DISCUSSION:
3082 Although source routes are discouraged within the Internet
3083 (see Section 5.2.6), there are non-Internet mail
3084 environments whose delivery mechanisms do depend upon
3085 source routes. Source routes for extra-Internet
3086 environments can generally be buried in the "local-part"
3087 of the address (see Section 5.2.16) while mail traverses
3088 the Internet. When the mail reaches the appropriate
3089 Internet mail gateway, the gateway will interpret the
3090 local-part and build the necessary address or route for
3091 the target mail environment.
3092
3093 For example, an Internet host might send mail to:
3094 "a!b!c!user@gateway-domain". The complex local part
3095 "a!b!c!user" would be uninterpreted within the Internet
3096 domain, but could be parsed and understood by the
3097 specified mail gateway.
3098
3099 An embedded source route is sometimes encoded in the
3100 "local-part" using "%" as a right-binding routing
3101 operator. For example, in:
3102
3103 user%domain%relay3%relay2@relay1
3104
3105 the "%" convention implies that the mail is to be routed
3106 from "relay1" through "relay2", "relay3", and finally to
3107 "user" at "domain". This is commonly known as the "%-
3108 hack". It is suggested that "%" have lower precedence
3109 than any other routing operator (e.g., "!") hidden in the
3110 local-part; for example, "a!b%c" would be interpreted as
3111 "(a!b)%c".
3112
3113 Only the target host (in this case, "relay1") is permitted
3114 to analyze the local-part "user%domain%relay3%relay2".
3115
3116 5.2.17 Domain Literals: RFC-822 Section 6.2.3
3117
3118 A mailer MUST be able to accept and parse an Internet domain
3119 literal whose content ("dtext"; see RFC-822) is a dotted-
3120 decimal host address. This satisfies the requirement of
3121 Section 2.1 for the case of mail.
3122
3123 An SMTP MUST accept and recognize a domain literal for any of
3124 its own IP addresses.
3125
3126
3127
3128
3129
3130
3131
3132 Internet Engineering Task Force [Page 57]
3133 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3134
3135
3136 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1
3137
3138 Errors in formatting or parsing 822 addresses are unfortunately
3139 common. This section mentions only the most common errors. A
3140 User Agent MUST accept all valid RFC-822 address formats, and
3141 MUST NOT generate illegal address syntax.
3142
3143 o A common error is to leave out the semicolon after a group
3144 identifier.
3145
3146 o Some systems fail to fully-qualify domain names in
3147 messages they generate. The right-hand side of an "@"
3148 sign in a header address field MUST be a fully-qualified
3149 domain name.
3150
3151 For example, some systems fail to fully-qualify the From:
3152 address; this prevents a "reply" command in the user
3153 interface from automatically constructing a return
3154 address.
3155
3156 DISCUSSION:
3157 Although RFC-822 allows the local use of abbreviated
3158 domain names within a domain, the application of
3159 RFC-822 in Internet mail does not allow this. The
3160 intent is that an Internet host must not send an SMTP
3161 message header containing an abbreviated domain name
3162 in an address field. This allows the address fields
3163 of the header to be passed without alteration across
3164 the Internet, as required in Section 5.2.6.
3165
3166 o Some systems mis-parse multiple-hop explicit source routes
3167 such as:
3168
3169 @relay1,@relay2,@relay3:user@domain.
3170
3171
3172 o Some systems over-qualify domain names by adding a
3173 trailing dot to some or all domain names in addresses or
3174 message-ids. This violates RFC-822 syntax.
3175
3176
3177 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7
3178
3179 Internet host software SHOULD NOT create an RFC-822 header
3180 containing an address with an explicit source route, but MUST
3181 accept such headers for compatibility with earlier systems.
3182
3183 DISCUSSION:
3184
3185
3186
3187 Internet Engineering Task Force [Page 58]
3188 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3189
3190
3191 In an understatement, RFC-822 says "The use of explicit
3192 source routing is discouraged". Many hosts implemented
3193 RFC-822 source routes incorrectly, so the syntax cannot be
3194 used unambiguously in practice. Many users feel the
3195 syntax is ugly. Explicit source routes are not needed in
3196 the mail envelope for delivery; see Section 5.2.6. For
3197 all these reasons, explicit source routes using the RFC-
3198 822 notations are not to be used in Internet mail headers.
3199
3200 As stated in Section 5.2.16, it is necessary to allow an
3201 explicit source route to be buried in the local-part of an
3202 address, e.g., using the "%-hack", in order to allow mail
3203 to be gatewayed into another environment in which explicit
3204 source routing is necessary. The vigilant will observe
3205 that there is no way for a User Agent to detect and
3206 prevent the use of such implicit source routing when the
3207 destination is within the Internet. We can only
3208 discourage source routing of any kind within the Internet,
3209 as unnecessary and undesirable.
3210
3211 5.3 SPECIFIC ISSUES
3212
3213 5.3.1 SMTP Queueing Strategies
3214
3215 The common structure of a host SMTP implementation includes
3216 user mailboxes, one or more areas for queueing messages in
3217 transit, and one or more daemon processes for sending and
3218 receiving mail. The exact structure will vary depending on the
3219 needs of the users on the host and the number and size of
3220 mailing lists supported by the host. We describe several
3221 optimizations that have proved helpful, particularly for
3222 mailers supporting high traffic levels.
3223
3224 Any queueing strategy MUST include:
3225
3226 o Timeouts on all activities. See Section 5.3.2.
3227
3228 o Never sending error messages in response to error
3229 messages.
3230
3231
3232 5.3.1.1 Sending Strategy
3233
3234 The general model of a sender-SMTP is one or more processes
3235 that periodically attempt to transmit outgoing mail. In a
3236 typical system, the program that composes a message has some
3237 method for requesting immediate attention for a new piece of
3238 outgoing mail, while mail that cannot be transmitted
3239
3240
3241
3242 Internet Engineering Task Force [Page 59]
3243 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3244
3245
3246 immediately MUST be queued and periodically retried by the
3247 sender. A mail queue entry will include not only the
3248 message itself but also the envelope information.
3249
3250 The sender MUST delay retrying a particular destination
3251 after one attempt has failed. In general, the retry
3252 interval SHOULD be at least 30 minutes; however, more
3253 sophisticated and variable strategies will be beneficial
3254 when the sender-SMTP can determine the reason for non-
3255 delivery.
3256
3257 Retries continue until the message is transmitted or the
3258 sender gives up; the give-up time generally needs to be at
3259 least 4-5 days. The parameters to the retry algorithm MUST
3260 be configurable.
3261
3262 A sender SHOULD keep a list of hosts it cannot reach and
3263 corresponding timeouts, rather than just retrying queued
3264 mail items.
3265
3266 DISCUSSION:
3267 Experience suggests that failures are typically
3268 transient (the target system has crashed), favoring a
3269 policy of two connection attempts in the first hour the
3270 message is in the queue, and then backing off to once
3271 every two or three hours.
3272
3273 The sender-SMTP can shorten the queueing delay by
3274 cooperation with the receiver-SMTP. In particular, if
3275 mail is received from a particular address, it is good
3276 evidence that any mail queued for that host can now be
3277 sent.
3278
3279 The strategy may be further modified as a result of
3280 multiple addresses per host (see Section 5.3.4), to
3281 optimize delivery time vs. resource usage.
3282
3283 A sender-SMTP may have a large queue of messages for
3284 each unavailable destination host, and if it retried
3285 all these messages in every retry cycle, there would be
3286 excessive Internet overhead and the daemon would be
3287 blocked for a long period. Note that an SMTP can
3288 generally determine that a delivery attempt has failed
3289 only after a timeout of a minute or more; a one minute
3290 timeout per connection will result in a very large
3291 delay if it is repeated for dozens or even hundreds of
3292 queued messages.
3293
3294
3295
3296
3297 Internet Engineering Task Force [Page 60]
3298 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3299
3300
3301 When the same message is to be delivered to several users on
3302 the same host, only one copy of the message SHOULD be
3303 transmitted. That is, the sender-SMTP should use the
3304 command sequence: RCPT, RCPT,... RCPT, DATA instead of the
3305 sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
3306 Implementation of this efficiency feature is strongly urged.
3307
3308 Similarly, the sender-SMTP MAY support multiple concurrent
3309 outgoing mail transactions to achieve timely delivery.
3310 However, some limit SHOULD be imposed to protect the host
3311 from devoting all its resources to mail.
3312
3313 The use of the different addresses of a multihomed host is
3314 discussed below.
3315
3316 5.3.1.2 Receiving strategy
3317
3318 The receiver-SMTP SHOULD attempt to keep a pending listen on
3319 the SMTP port at all times. This will require the support
3320 of multiple incoming TCP connections for SMTP. Some limit
3321 MAY be imposed.
3322
3323 IMPLEMENTATION:
3324 When the receiver-SMTP receives mail from a particular
3325 host address, it could notify the sender-SMTP to retry
3326 any mail pending for that host address.
3327
3328 5.3.2 Timeouts in SMTP
3329
3330 There are two approaches to timeouts in the sender-SMTP: (a)
3331 limit the time for each SMTP command separately, or (b) limit
3332 the time for the entire SMTP dialogue for a single mail
3333 message. A sender-SMTP SHOULD use option (a), per-command
3334 timeouts. Timeouts SHOULD be easily reconfigurable, preferably
3335 without recompiling the SMTP code.
3336
3337 DISCUSSION:
3338 Timeouts are an essential feature of an SMTP
3339 implementation. If the timeouts are too long (or worse,
3340 there are no timeouts), Internet communication failures or
3341 software bugs in receiver-SMTP programs can tie up SMTP
3342 processes indefinitely. If the timeouts are too short,
3343 resources will be wasted with attempts that time out part
3344 way through message delivery.
3345
3346 If option (b) is used, the timeout has to be very large,
3347 e.g., an hour, to allow time to expand very large mailing
3348 lists. The timeout may also need to increase linearly
3349
3350
3351
3352 Internet Engineering Task Force [Page 61]
3353 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3354
3355
3356 with the size of the message, to account for the time to
3357 transmit a very large message. A large fixed timeout
3358 leads to two problems: a failure can still tie up the
3359 sender for a very long time, and very large messages may
3360 still spuriously time out (which is a wasteful failure!).
3361
3362 Using the recommended option (a), a timer is set for each
3363 SMTP command and for each buffer of the data transfer.
3364 The latter means that the overall timeout is inherently
3365 proportional to the size of the message.
3366
3367 Based on extensive experience with busy mail-relay hosts, the
3368 minimum per-command timeout values SHOULD be as follows:
3369
3370 o Initial 220 Message: 5 minutes
3371
3372 A Sender-SMTP process needs to distinguish between a
3373 failed TCP connection and a delay in receiving the initial
3374 220 greeting message. Many receiver-SMTPs will accept a
3375 TCP connection but delay delivery of the 220 message until
3376 their system load will permit more mail to be processed.
3377
3378 o MAIL Command: 5 minutes
3379
3380
3381 o RCPT Command: 5 minutes
3382
3383 A longer timeout would be required if processing of
3384 mailing lists and aliases were not deferred until after
3385 the message was accepted.
3386
3387 o DATA Initiation: 2 minutes
3388
3389 This is while awaiting the "354 Start Input" reply to a
3390 DATA command.
3391
3392 o Data Block: 3 minutes
3393
3394 This is while awaiting the completion of each TCP SEND
3395 call transmitting a chunk of data.
3396
3397 o DATA Termination: 10 minutes.
3398
3399 This is while awaiting the "250 OK" reply. When the
3400 receiver gets the final period terminating the message
3401 data, it typically performs processing to deliver the
3402 message to a user mailbox. A spurious timeout at this
3403 point would be very wasteful, since the message has been
3404
3405
3406
3407 Internet Engineering Task Force [Page 62]
3408 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3409
3410
3411 successfully sent.
3412
3413 A receiver-SMTP SHOULD have a timeout of at least 5 minutes
3414 while it is awaiting the next command from the sender.
3415
3416 5.3.3 Reliable Mail Receipt
3417
3418 When the receiver-SMTP accepts a piece of mail (by sending a
3419 "250 OK" message in response to DATA), it is accepting
3420 responsibility for delivering or relaying the message. It must
3421 take this responsibility seriously, i.e., it MUST NOT lose the
3422 message for frivolous reasons, e.g., because the host later
3423 crashes or because of a predictable resource shortage.
3424
3425 If there is a delivery failure after acceptance of a message,
3426 the receiver-SMTP MUST formulate and mail a notification
3427 message. This notification MUST be sent using a null ("<>")
3428 reverse path in the envelope; see Section 3.6 of RFC-821. The
3429 recipient of this notification SHOULD be the address from the
3430 envelope return path (or the Return-Path: line). However, if
3431 this address is null ("<>"), the receiver-SMTP MUST NOT send a
3432 notification. If the address is an explicit source route, it
3433 SHOULD be stripped down to its final hop.
3434
3435 DISCUSSION:
3436 For example, suppose that an error notification must be
3437 sent for a message that arrived with:
3438 "MAIL FROM:<@a,@b:user@d>". The notification message
3439 should be sent to: "RCPT TO:<user@d>".
3440
3441 Some delivery failures after the message is accepted by
3442 SMTP will be unavoidable. For example, it may be
3443 impossible for the receiver-SMTP to validate all the
3444 delivery addresses in RCPT command(s) due to a "soft"
3445 domain system error or because the target is a mailing
3446 list (see earlier discussion of RCPT).
3447
3448 To avoid receiving duplicate messages as the result of
3449 timeouts, a receiver-SMTP MUST seek to minimize the time
3450 required to respond to the final "." that ends a message
3451 transfer. See RFC-1047 [SMTP:4] for a discussion of this
3452 problem.
3453
3454 5.3.4 Reliable Mail Transmission
3455
3456 To transmit a message, a sender-SMTP determines the IP address
3457 of the target host from the destination address in the
3458 envelope. Specifically, it maps the string to the right of the
3459
3460
3461
3462 Internet Engineering Task Force [Page 63]
3463 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3464
3465
3466 "@" sign into an IP address. This mapping or the transfer
3467 itself may fail with a soft error, in which case the sender-
3468 SMTP will requeue the outgoing mail for a later retry, as
3469 required in Section 5.3.1.1.
3470
3471 When it succeeds, the mapping can result in a list of
3472 alternative delivery addresses rather than a single address,
3473 because of (a) multiple MX records, (b) multihoming, or both.
3474 To provide reliable mail transmission, the sender-SMTP MUST be
3475 able to try (and retry) each of the addresses in this list in
3476 order, until a delivery attempt succeeds. However, there MAY
3477 also be a configurable limit on the number of alternate
3478 addresses that can be tried. In any case, a host SHOULD try at
3479 least two addresses.
3480
3481 The following information is to be used to rank the host
3482 addresses:
3483
3484 (1) Multiple MX Records -- these contain a preference
3485 indication that should be used in sorting. If there are
3486 multiple destinations with the same preference and there
3487 is no clear reason to favor one (e.g., by address
3488 preference), then the sender-SMTP SHOULD pick one at
3489 random to spread the load across multiple mail exchanges
3490 for a specific organization; note that this is a
3491 refinement of the procedure in [DNS:3].
3492
3493 (2) Multihomed host -- The destination host (perhaps taken
3494 from the preferred MX record) may be multihomed, in which
3495 case the domain name resolver will return a list of
3496 alternative IP addresses. It is the responsibility of the
3497 domain name resolver interface (see Section 6.1.3.4 below)
3498 to have ordered this list by decreasing preference, and
3499 SMTP MUST try them in the order presented.
3500
3501 DISCUSSION:
3502 Although the capability to try multiple alternative
3503 addresses is required, there may be circumstances where
3504 specific installations want to limit or disable the use of
3505 alternative addresses. The question of whether a sender
3506 should attempt retries using the different addresses of a
3507 multihomed host has been controversial. The main argument
3508 for using the multiple addresses is that it maximizes the
3509 probability of timely delivery, and indeed sometimes the
3510 probability of any delivery; the counter argument is that
3511 it may result in unnecessary resource use.
3512
3513 Note that resource use is also strongly determined by the
3514
3515
3516
3517 Internet Engineering Task Force [Page 64]
3518 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3519
3520
3521 sending strategy discussed in Section 5.3.1.
3522
3523 5.3.5 Domain Name Support
3524
3525 SMTP implementations MUST use the mechanism defined in Section
3526 6.1 for mapping between domain names and IP addresses. This
3527 means that every Internet SMTP MUST include support for the
3528 Internet DNS.
3529
3530 In particular, a sender-SMTP MUST support the MX record scheme
3531 [SMTP:3]. See also Section 7.4 of [DNS:2] for information on
3532 domain name support for SMTP.
3533
3534 5.3.6 Mailing Lists and Aliases
3535
3536 An SMTP-capable host SHOULD support both the alias and the list
3537 form of address expansion for multiple delivery. When a
3538 message is delivered or forwarded to each address of an
3539 expanded list form, the return address in the envelope
3540 ("MAIL FROM:") MUST be changed to be the address of a person
3541 who administers the list, but the message header MUST be left
3542 unchanged; in particular, the "From" field of the message is
3543 unaffected.
3544
3545 DISCUSSION:
3546 An important mail facility is a mechanism for multi-
3547 destination delivery of a single message, by transforming
3548 or "expanding" a pseudo-mailbox address into a list of
3549 destination mailbox addresses. When a message is sent to
3550 such a pseudo-mailbox (sometimes called an "exploder"),
3551 copies are forwarded or redistributed to each mailbox in
3552 the expanded list. We classify such a pseudo-mailbox as
3553 an "alias" or a "list", depending upon the expansion
3554 rules:
3555
3556 (a) Alias
3557
3558 To expand an alias, the recipient mailer simply
3559 replaces the pseudo-mailbox address in the envelope
3560 with each of the expanded addresses in turn; the rest
3561 of the envelope and the message body are left
3562 unchanged. The message is then delivered or
3563 forwarded to each expanded address.
3564
3565 (b) List
3566
3567 A mailing list may be said to operate by
3568 "redistribution" rather than by "forwarding". To
3569
3570
3571
3572 Internet Engineering Task Force [Page 65]
3573 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3574
3575
3576 expand a list, the recipient mailer replaces the
3577 pseudo-mailbox address in the envelope with each of
3578 the expanded addresses in turn. The return address in
3579 the envelope is changed so that all error messages
3580 generated by the final deliveries will be returned to
3581 a list administrator, not to the message originator,
3582 who generally has no control over the contents of the
3583 list and will typically find error messages annoying.
3584
3585
3586 5.3.7 Mail Gatewaying
3587
3588 Gatewaying mail between different mail environments, i.e.,
3589 different mail formats and protocols, is complex and does not
3590 easily yield to standardization. See for example [SMTP:5a],
3591 [SMTP:5b]. However, some general requirements may be given for
3592 a gateway between the Internet and another mail environment.
3593
3594 (A) Header fields MAY be rewritten when necessary as messages
3595 are gatewayed across mail environment boundaries.
3596
3597 DISCUSSION:
3598 This may involve interpreting the local-part of the
3599 destination address, as suggested in Section 5.2.16.
3600
3601 The other mail systems gatewayed to the Internet
3602 generally use a subset of RFC-822 headers, but some
3603 of them do not have an equivalent to the SMTP
3604 envelope. Therefore, when a message leaves the
3605 Internet environment, it may be necessary to fold the
3606 SMTP envelope information into the message header. A
3607 possible solution would be to create new header
3608 fields to carry the envelope information (e.g., "X-
3609 SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
3610 require changes in mail programs in the foreign
3611 environment.
3612
3613 (B) When forwarding a message into or out of the Internet
3614 environment, a gateway MUST prepend a Received: line, but
3615 it MUST NOT alter in any way a Received: line that is
3616 already in the header.
3617
3618 DISCUSSION:
3619 This requirement is a subset of the general
3620 "Received:" line requirement of Section 5.2.8; it is
3621 restated here for emphasis.
3622
3623 Received: fields of messages originating from other
3624
3625
3626
3627 Internet Engineering Task Force [Page 66]
3628 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3629
3630
3631 environments may not conform exactly to RFC822.
3632 However, the most important use of Received: lines is
3633 for debugging mail faults, and this debugging can be
3634 severely hampered by well-meaning gateways that try
3635 to "fix" a Received: line.
3636
3637 The gateway is strongly encouraged to indicate the
3638 environment and protocol in the "via" clauses of
3639 Received field(s) that it supplies.
3640
3641 (C) From the Internet side, the gateway SHOULD accept all
3642 valid address formats in SMTP commands and in RFC-822
3643 headers, and all valid RFC-822 messages. Although a
3644 gateway must accept an RFC-822 explicit source route
3645 ("@...:" format) in either the RFC-822 header or in the
3646 envelope, it MAY or may not act on the source route; see
3647 Sections 5.2.6 and 5.2.19.
3648
3649 DISCUSSION:
3650 It is often tempting to restrict the range of
3651 addresses accepted at the mail gateway to simplify
3652 the translation into addresses for the remote
3653 environment. This practice is based on the
3654 assumption that mail users have control over the
3655 addresses their mailers send to the mail gateway. In
3656 practice, however, users have little control over the
3657 addresses that are finally sent; their mailers are
3658 free to change addresses into any legal RFC-822
3659 format.
3660
3661 (D) The gateway MUST ensure that all header fields of a
3662 message that it forwards into the Internet meet the
3663 requirements for Internet mail. In particular, all
3664 addresses in "From:", "To:", "Cc:", etc., fields must be
3665 transformed (if necessary) to satisfy RFC-822 syntax, and
3666 they must be effective and useful for sending replies.
3667
3668
3669 (E) The translation algorithm used to convert mail from the
3670 Internet protocols to another environment's protocol
3671 SHOULD try to ensure that error messages from the foreign
3672 mail environment are delivered to the return path from the
3673 SMTP envelope, not to the sender listed in the "From:"
3674 field of the RFC-822 message.
3675
3676 DISCUSSION:
3677 Internet mail lists usually place the address of the
3678 mail list maintainer in the envelope but leave the
3679
3680
3681
3682 Internet Engineering Task Force [Page 67]
3683 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3684
3685
3686 original message header intact (with the "From:"
3687 field containing the original sender). This yields
3688 the behavior the average recipient expects: a reply
3689 to the header gets sent to the original sender, not
3690 to a mail list maintainer; however, errors get sent
3691 to the maintainer (who can fix the problem) and not
3692 the sender (who probably cannot).
3693
3694 (F) Similarly, when forwarding a message from another
3695 environment into the Internet, the gateway SHOULD set the
3696 envelope return path in accordance with an error message
3697 return address, if any, supplied by the foreign
3698 environment.
3699
3700
3701 5.3.8 Maximum Message Size
3702
3703 Mailer software MUST be able to send and receive messages of at
3704 least 64K bytes in length (including header), and a much larger
3705 maximum size is highly desirable.
3706
3707 DISCUSSION:
3708 Although SMTP does not define the maximum size of a
3709 message, many systems impose implementation limits.
3710
3711 The current de facto minimum limit in the Internet is 64K
3712 bytes. However, electronic mail is used for a variety of
3713 purposes that create much larger messages. For example,
3714 mail is often used instead of FTP for transmitting ASCII
3715 files, and in particular to transmit entire documents. As
3716 a result, messages can be 1 megabyte or even larger. We
3717 note that the present document together with its lower-
3718 layer companion contains 0.5 megabytes.
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737 Internet Engineering Task Force [Page 68]
3738 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3739
3740
3741 5.4 SMTP REQUIREMENTS SUMMARY
3742
3743 | | | | |S| |
3744 | | | | |H| |F
3745 | | | | |O|M|o
3746 | | |S| |U|U|o
3747 | | |H| |L|S|t
3748 | |M|O| |D|T|n
3749 | |U|U|M| | |o
3750 | |S|L|A|N|N|t
3751 | |T|D|Y|O|O|t
3752 FEATURE |SECTION | | | |T|T|e
3753 -----------------------------------------------|----------|-|-|-|-|-|--
3754 | | | | | | |
3755 RECEIVER-SMTP: | | | | | | |
3756 Implement VRFY |5.2.3 |x| | | | |
3757 Implement EXPN |5.2.3 | |x| | | |
3758 EXPN, VRFY configurable |5.2.3 | | |x| | |
3759 Implement SEND, SOML, SAML |5.2.4 | | |x| | |
3760 Verify HELO parameter |5.2.5 | | |x| | |
3761 Refuse message with bad HELO |5.2.5 | | | | |x|
3762 Accept explicit src-route syntax in env. |5.2.6 |x| | | | |
3763 Support "postmaster" |5.2.7 |x| | | | |
3764 Process RCPT when received (except lists) |5.2.7 | | |x| | |
3765 Long delay of RCPT responses |5.2.7 | | | | |x|
3766 | | | | | | |
3767 Add Received: line |5.2.8 |x| | | | |
3768 Received: line include domain literal |5.2.8 | |x| | | |
3769 Change previous Received: line |5.2.8 | | | | |x|
3770 Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | |
3771 Support empty reverse path |5.2.9 |x| | | | |
3772 Send only official reply codes |5.2.10 | |x| | | |
3773 Send text from RFC-821 when appropriate |5.2.10 | |x| | | |
3774 Delete "." for transparency |5.2.11 |x| | | | |
3775 Accept and recognize self domain literal(s) |5.2.17 |x| | | | |
3776 | | | | | | |
3777 Error message about error message |5.3.1 | | | | |x|
3778 Keep pending listen on SMTP port |5.3.1.2 | |x| | | |
3779 Provide limit on recv concurrency |5.3.1.2 | | |x| | |
3780 Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | |
3781 Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x|
3782 Send error notification msg after accept |5.3.3 |x| | | | |
3783 Send using null return path |5.3.3 |x| | | | |
3784 Send to envelope return path |5.3.3 | |x| | | |
3785 Send to null address |5.3.3 | | | | |x|
3786 Strip off explicit src route |5.3.3 | |x| | | |
3787 Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | |
3788 -----------------------------------------------|----------|-|-|-|-|-|--
3789
3790
3791
3792 Internet Engineering Task Force [Page 69]
3793 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3794
3795
3796 | | | | | | |
3797 SENDER-SMTP: | | | | | | |
3798 Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | |
3799 Implement SEND, SOML, SAML |5.2.4 | | |x| | |
3800 Send valid principal host name in HELO |5.2.5 |x| | | | |
3801 Send explicit source route in RCPT TO: |5.2.6 | | | |x| |
3802 Use only reply code to determine action |5.2.10 |x| | | | |
3803 Use only high digit of reply code when poss. |5.2.10 | |x| | | |
3804 Add "." for transparency |5.2.11 |x| | | | |
3805 | | | | | | |
3806 Retry messages after soft failure |5.3.1.1 |x| | | | |
3807 Delay before retry |5.3.1.1 |x| | | | |
3808 Configurable retry parameters |5.3.1.1 |x| | | | |
3809 Retry once per each queued dest host |5.3.1.1 | |x| | | |
3810 Multiple RCPT's for same DATA |5.3.1.1 | |x| | | |
3811 Support multiple concurrent transactions |5.3.1.1 | | |x| | |
3812 Provide limit on concurrency |5.3.1.1 | |x| | | |
3813 | | | | | | |
3814 Timeouts on all activities |5.3.1 |x| | | | |
3815 Per-command timeouts |5.3.2 | |x| | | |
3816 Timeouts easily reconfigurable |5.3.2 | |x| | | |
3817 Recommended times |5.3.2 | |x| | | |
3818 Try alternate addr's in order |5.3.4 |x| | | | |
3819 Configurable limit on alternate tries |5.3.4 | | |x| | |
3820 Try at least two alternates |5.3.4 | |x| | | |
3821 Load-split across equal MX alternates |5.3.4 | |x| | | |
3822 Use the Domain Name System |5.3.5 |x| | | | |
3823 Support MX records |5.3.5 |x| | | | |
3824 Use WKS records in MX processing |5.2.12 | | | |x| |
3825 -----------------------------------------------|----------|-|-|-|-|-|--
3826 | | | | | | |
3827 MAIL FORWARDING: | | | | | | |
3828 Alter existing header field(s) |5.2.6 | | | |x| |
3829 Implement relay function: 821/section 3.6 |5.2.6 | | |x| | |
3830 If not, deliver to RHS domain |5.2.6 | |x| | | |
3831 Interpret 'local-part' of addr |5.2.16 | | | | |x|
3832 | | | | | | |
3833 MAILING LISTS AND ALIASES | | | | | | |
3834 Support both |5.3.6 | |x| | | |
3835 Report mail list error to local admin. |5.3.6 |x| | | | |
3836 | | | | | | |
3837 MAIL GATEWAYS: | | | | | | |
3838 Embed foreign mail route in local-part |5.2.16 | | |x| | |
3839 Rewrite header fields when necessary |5.3.7 | | |x| | |
3840 Prepend Received: line |5.3.7 |x| | | | |
3841 Change existing Received: line |5.3.7 | | | | |x|
3842 Accept full RFC-822 on Internet side |5.3.7 | |x| | | |
3843 Act on RFC-822 explicit source route |5.3.7 | | |x| | |
3844
3845
3846
3847 Internet Engineering Task Force [Page 70]
3848 RFC1123 MAIL -- SMTP & RFC-822 October 1989
3849
3850
3851 Send only valid RFC-822 on Internet side |5.3.7 |x| | | | |
3852 Deliver error msgs to envelope addr |5.3.7 | |x| | | |
3853 Set env return path from err return addr |5.3.7 | |x| | | |
3854 | | | | | | |
3855 USER AGENT -- RFC-822 | | | | | | |
3856 Allow user to enter <route> address |5.2.6 | | | |x| |
3857 Support RFC-1049 Content Type field |5.2.13 | | |x| | |
3858 Use 4-digit years |5.2.14 | |x| | | |
3859 Generate numeric timezones |5.2.14 | |x| | | |
3860 Accept all timezones |5.2.14 |x| | | | |
3861 Use non-num timezones from RFC-822 |5.2.14 |x| | | | |
3862 Omit phrase before route-addr |5.2.15 | | |x| | |
3863 Accept and parse dot.dec. domain literals |5.2.17 |x| | | | |
3864 Accept all RFC-822 address formats |5.2.18 |x| | | | |
3865 Generate invalid RFC-822 address format |5.2.18 | | | | |x|
3866 Fully-qualified domain names in header |5.2.18 |x| | | | |
3867 Create explicit src route in header |5.2.19 | | | |x| |
3868 Accept explicit src route in header |5.2.19 |x| | | | |
3869 | | | | | | |
3870 Send/recv at least 64KB messages |5.3.8 |x| | | | |
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902 Internet Engineering Task Force [Page 71]
3903 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
3904
3905
3906 6. SUPPORT SERVICES
3907
3908 6.1 DOMAIN NAME TRANSLATION
3909
3910 6.1.1 INTRODUCTION
3911
3912 Every host MUST implement a resolver for the Domain Name System
3913 (DNS), and it MUST implement a mechanism using this DNS
3914 resolver to convert host names to IP addresses and vice-versa
3915 [DNS:1, DNS:2].
3916
3917 In addition to the DNS, a host MAY also implement a host name
3918 translation mechanism that searches a local Internet host
3919 table. See Section 6.1.3.8 for more information on this
3920 option.
3921
3922 DISCUSSION:
3923 Internet host name translation was originally performed by
3924 searching local copies of a table of all hosts. This
3925 table became too large to update and distribute in a
3926 timely manner and too large to fit into many hosts, so the
3927 DNS was invented.
3928
3929 The DNS creates a distributed database used primarily for
3930 the translation between host names and host addresses.
3931 Implementation of DNS software is required. The DNS
3932 consists of two logically distinct parts: name servers and
3933 resolvers (although implementations often combine these
3934 two logical parts in the interest of efficiency) [DNS:2].
3935
3936 Domain name servers store authoritative data about certain
3937 sections of the database and answer queries about the
3938 data. Domain resolvers query domain name servers for data
3939 on behalf of user processes. Every host therefore needs a
3940 DNS resolver; some host machines will also need to run
3941 domain name servers. Since no name server has complete
3942 information, in general it is necessary to obtain
3943 information from more than one name server to resolve a
3944 query.
3945
3946 6.1.2 PROTOCOL WALK-THROUGH
3947
3948 An implementor must study references [DNS:1] and [DNS:2]
3949 carefully. They provide a thorough description of the theory,
3950 protocol, and implementation of the domain name system, and
3951 reflect several years of experience.
3952
3953
3954
3955
3956
3957 Internet Engineering Task Force [Page 72]
3958 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
3959
3960
3961 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1
3962
3963 All DNS name servers and resolvers MUST properly handle RRs
3964 with a zero TTL: return the RR to the client but do not
3965 cache it.
3966
3967 DISCUSSION:
3968 Zero TTL values are interpreted to mean that the RR can
3969 only be used for the transaction in progress, and
3970 should not be cached; they are useful for extremely
3971 volatile data.
3972
3973 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5
3974
3975 A query with "QCLASS=*" SHOULD NOT be used unless the
3976 requestor is seeking data from more than one class. In
3977 particular, if the requestor is only interested in Internet
3978 data types, QCLASS=IN MUST be used.
3979
3980 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1
3981
3982 Unused fields in a query or response message MUST be zero.
3983
3984 6.1.2.4 Compression: RFC-1035 Section 4.1.4
3985
3986 Name servers MUST use compression in responses.
3987
3988 DISCUSSION:
3989 Compression is essential to avoid overflowing UDP
3990 datagrams; see Section 6.1.3.2.
3991
3992 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2
3993
3994 Recursive name servers and full-service resolvers generally
3995 have some configuration information containing hints about
3996 the location of root or local name servers. An
3997 implementation MUST NOT include any of these hints in a
3998 response.
3999
4000 DISCUSSION:
4001 Many implementors have found it convenient to store
4002 these hints as if they were cached data, but some
4003 neglected to ensure that this "cached data" was not
4004 included in responses. This has caused serious
4005 problems in the Internet when the hints were obsolete
4006 or incorrect.
4007
4008
4009
4010
4011
4012 Internet Engineering Task Force [Page 73]
4013 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4014
4015
4016 6.1.3 SPECIFIC ISSUES
4017
4018 6.1.3.1 Resolver Implementation
4019
4020 A name resolver SHOULD be able to multiplex concurrent
4021 requests if the host supports concurrent processes.
4022
4023 In implementing a DNS resolver, one of two different models
4024 MAY optionally be chosen: a full-service resolver, or a stub
4025 resolver.
4026
4027
4028 (A) Full-Service Resolver
4029
4030 A full-service resolver is a complete implementation of
4031 the resolver service, and is capable of dealing with
4032 communication failures, failure of individual name
4033 servers, location of the proper name server for a given
4034 name, etc. It must satisfy the following requirements:
4035
4036 o The resolver MUST implement a local caching
4037 function to avoid repeated remote access for
4038 identical requests, and MUST time out information
4039 in the cache.
4040
4041 o The resolver SHOULD be configurable with start-up
4042 information pointing to multiple root name servers
4043 and multiple name servers for the local domain.
4044 This insures that the resolver will be able to
4045 access the whole name space in normal cases, and
4046 will be able to access local domain information
4047 should the local network become disconnected from
4048 the rest of the Internet.
4049
4050
4051 (B) Stub Resolver
4052
4053 A "stub resolver" relies on the services of a recursive
4054 name server on the connected network or a "nearby"
4055 network. This scheme allows the host to pass on the
4056 burden of the resolver function to a name server on
4057 another host. This model is often essential for less
4058 capable hosts, such as PCs, and is also recommended
4059 when the host is one of several workstations on a local
4060 network, because it allows all of the workstations to
4061 share the cache of the recursive name server and hence
4062 reduce the number of domain requests exported by the
4063 local network.
4064
4065
4066
4067 Internet Engineering Task Force [Page 74]
4068 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4069
4070
4071 At a minimum, the stub resolver MUST be capable of
4072 directing its requests to redundant recursive name
4073 servers. Note that recursive name servers are allowed
4074 to restrict the sources of requests that they will
4075 honor, so the host administrator must verify that the
4076 service will be provided. Stub resolvers MAY implement
4077 caching if they choose, but if so, MUST timeout cached
4078 information.
4079
4080
5.2.2 Canonicalization: RFC-821 Section 3.1
The domain names that a Sender-SMTP sends in MAIL and RCPT
commands MUST have been "canonicalized," i.e., they must be
fully-qualified principal names or domain literals, not
nicknames or domain abbreviations. A canonicalized name either
identifies a host directly or is an MX name; it cannot be a
CNAME.
RFC5321 Section 2.3.5. Domain Names Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs.
Section 2.3.5 from RFC 5321 seems to contradict the section 5.2.2 from 1123. In RFC5321 it is implied that you can have a domain CNAME pointing to another that has an MX record that is not a CNAME and it should work. However 1123 states that it's not possible. --VERIFIER NOTES-- Errata reports are for mistakes in the published document -- errata at the time of publication. Anything that might have changed since then is appropriate for a new document, but isn't errata in the old one.
4081 6.1.3.2 Transport Protocols
4082
4083 DNS resolvers and recursive servers MUST support UDP, and
4084 SHOULD support TCP, for sending (non-zone-transfer) queries.
4085 Specifically, a DNS resolver or server that is sending a
4086 non-zone-transfer query MUST send a UDP query first. If the
4087 Answer section of the response is truncated and if the
4088 requester supports TCP, it SHOULD try the query again using
4089 TCP.
4090
4091 DNS servers MUST be able to service UDP queries and SHOULD
4092 be able to service TCP queries. A name server MAY limit the
4093 resources it devotes to TCP queries, but it SHOULD NOT
4094 refuse to service a TCP query just because it would have
4095 succeeded with UDP.
4096
4097 Truncated responses MUST NOT be saved (cached) and later
4098 used in such a way that the fact that they are truncated is
4099 lost.
4100
4101 DISCUSSION:
4102 UDP is preferred over TCP for queries because UDP
4103 queries have much lower overhead, both in packet count
4104 and in connection state. The use of UDP is essential
4105 for heavily-loaded servers, especially the root
4106 servers. UDP also offers additional robustness, since
4107 a resolver can attempt several UDP queries to different
4108 servers for the cost of a single TCP query.
4109
4110 It is possible for a DNS response to be truncated,
4111 although this is a very rare occurrence in the present
4112 Internet DNS. Practically speaking, truncation cannot
4113 be predicted, since it is data-dependent. The
4114 dependencies include the number of RRs in the answer,
4115 the size of each RR, and the savings in space realized
4116 by the name compression algorithm. As a rule of thumb,
4117 truncation in NS and MX lists should not occur for
4118 answers containing 15 or fewer RRs.
4119
4120
4121
4122 Internet Engineering Task Force [Page 75]
4123 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4124
4125
4126 Whether it is possible to use a truncated answer
4127 depends on the application. A mailer must not use a
4128 truncated MX response, since this could lead to mail
4129 loops.
4130
4131 Responsible practices can make UDP suffice in the vast
4132 majority of cases. Name servers must use compression
4133 in responses. Resolvers must differentiate truncation
4134 of the Additional section of a response (which only
4135 loses extra information) from truncation of the Answer
4136 section (which for MX records renders the response
4137 unusable by mailers). Database administrators should
4138 list only a reasonable number of primary names in lists
4139 of name servers, MX alternatives, etc.
4140
4141 However, it is also clear that some new DNS record
4142 types defined in the future will contain information
4143 exceeding the 512 byte limit that applies to UDP, and
4144 hence will require TCP. Thus, resolvers and name
4145 servers should implement TCP services as a backup to
4146 UDP today, with the knowledge that they will require
4147 the TCP service in the future.
4148
4149 By private agreement, name servers and resolvers MAY arrange
4150 to use TCP for all traffic between themselves. TCP MUST be
4151 used for zone transfers.
4152
4153 A DNS server MUST have sufficient internal concurrency that
4154 it can continue to process UDP queries while awaiting a
4155 response or performing a zone transfer on an open TCP
4156 connection [DNS:2].
4157
4158 A server MAY support a UDP query that is delivered using an
4159 IP broadcast or multicast address. However, the Recursion
4160 Desired bit MUST NOT be set in a query that is multicast,
4161 and MUST be ignored by name servers receiving queries via a
4162 broadcast or multicast address. A host that sends broadcast
4163 or multicast DNS queries SHOULD send them only as occasional
4164 probes, caching the IP address(es) it obtains from the
4165 response(s) so it can normally send unicast queries.
4166
4167 DISCUSSION:
4168 Broadcast or (especially) IP multicast can provide a
4169 way to locate nearby name servers without knowing their
4170 IP addresses in advance. However, general broadcasting
4171 of recursive queries can result in excessive and
4172 unnecessary load on both network and servers.
4173
4174
4175
4176
4177 Internet Engineering Task Force [Page 76]
4178 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4179
4180
4181 6.1.3.3 Efficient Resource Usage
4182
4183 The following requirements on servers and resolvers are very
4184 important to the health of the Internet as a whole,
4185 particularly when DNS services are invoked repeatedly by
4186 higher level automatic servers, such as mailers.
4187
4188 (1) The resolver MUST implement retransmission controls to
4189 insure that it does not waste communication bandwidth,
4190 and MUST impose finite bounds on the resources consumed
4191 to respond to a single request. See [DNS:2] pages 43-
4192 44 for specific recommendations.
4193
4194 (2) After a query has been retransmitted several times
4195 without a response, an implementation MUST give up and
4196 return a soft error to the application.
4197
4198 (3) All DNS name servers and resolvers SHOULD cache
4199 temporary failures, with a timeout period of the order
4200 of minutes.
4201
4202 DISCUSSION:
4203 This will prevent applications that immediately
4204 retry soft failures (in violation of Section 2.2
4205 of this document) from generating excessive DNS
4206 traffic.
4207
4208 (4) All DNS name servers and resolvers SHOULD cache
4209 negative responses that indicate the specified name, or
4210 data of the specified type, does not exist, as
4211 described in [DNS:2].
4212
4213 (5) When a DNS server or resolver retries a UDP query, the
4214 retry interval SHOULD be constrained by an exponential
4215 backoff algorithm, and SHOULD also have upper and lower
4216 bounds.
4217
4218 IMPLEMENTATION:
4219 A measured RTT and variance (if available) should
4220 be used to calculate an initial retransmission
4221 interval. If this information is not available, a
4222 default of no less than 5 seconds should be used.
4223 Implementations may limit the retransmission
4224 interval, but this limit must exceed twice the
4225 Internet maximum segment lifetime plus service
4226 delay at the name server.
4227
4228 (6) When a resolver or server receives a Source Quench for
4229
4230
4231
4232 Internet Engineering Task Force [Page 77]
4233 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4234
4235
4236 a query it has issued, it SHOULD take steps to reduce
4237 the rate of querying that server in the near future. A
4238 server MAY ignore a Source Quench that it receives as
4239 the result of sending a response datagram.
4240
4241 IMPLEMENTATION:
4242 One recommended action to reduce the rate is to
4243 send the next query attempt to an alternate
4244 server, if there is one available. Another is to
4245 backoff the retry interval for the same server.
4246
4247
4248 6.1.3.4 Multihomed Hosts
4249
4250 When the host name-to-address function encounters a host
4251 with multiple addresses, it SHOULD rank or sort the
4252 addresses using knowledge of the immediately connected
4253 network number(s) and any other applicable performance or
4254 history information.
4255
4256 DISCUSSION:
4257 The different addresses of a multihomed host generally
4258 imply different Internet paths, and some paths may be
4259 preferable to others in performance, reliability, or
4260 administrative restrictions. There is no general way
4261 for the domain system to determine the best path. A
4262 recommended approach is to base this decision on local
4263 configuration information set by the system
4264 administrator.
4265
4266 IMPLEMENTATION:
4267 The following scheme has been used successfully:
4268
4269 (a) Incorporate into the host configuration data a
4270 Network-Preference List, that is simply a list of
4271 networks in preferred order. This list may be
4272 empty if there is no preference.
4273
4274 (b) When a host name is mapped into a list of IP
4275 addresses, these addresses should be sorted by
4276 network number, into the same order as the
4277 corresponding networks in the Network-Preference
4278 List. IP addresses whose networks do not appear
4279 in the Network-Preference List should be placed at
4280 the end of the list.
4281
4282
4283
4284
4285
4286
4287 Internet Engineering Task Force [Page 78]
4288 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4289
4290
4291 6.1.3.5 Extensibility
4292
4293 DNS software MUST support all well-known, class-independent
4294 formats [DNS:2], and SHOULD be written to minimize the
4295 trauma associated with the introduction of new well-known
4296 types and local experimentation with non-standard types.
4297
4298 DISCUSSION:
4299 The data types and classes used by the DNS are
4300 extensible, and thus new types will be added and old
4301 types deleted or redefined. Introduction of new data
4302 types ought to be dependent only upon the rules for
4303 compression of domain names inside DNS messages, and
4304 the translation between printable (i.e., master file)
4305 and internal formats for Resource Records (RRs).
4306
4307 Compression relies on knowledge of the format of data
4308 inside a particular RR. Hence compression must only be
4309 used for the contents of well-known, class-independent
4310 RRs, and must never be used for class-specific RRs or
4311 RR types that are not well-known. The owner name of an
4312 RR is always eligible for compression.
4313
4314 A name server may acquire, via zone transfer, RRs that
4315 the server doesn't know how to convert to printable
4316 format. A resolver can receive similar information as
4317 the result of queries. For proper operation, this data
4318 must be preserved, and hence the implication is that
4319 DNS software cannot use textual formats for internal
4320 storage.
4321
4322 The DNS defines domain name syntax very generally -- a
4323 string of labels each containing up to 63 8-bit octets,
4324 separated by dots, and with a maximum total of 255
4325 octets. Particular applications of the DNS are
4326 permitted to further constrain the syntax of the domain
4327 names they use, although the DNS deployment has led to
4328 some applications allowing more general names. In
4329 particular, Section 2.1 of this document liberalizes
4330 slightly the syntax of a legal Internet host name that
4331 was defined in RFC-952 [DNS:4].
4332
4333 6.1.3.6 Status of RR Types
4334
4335 Name servers MUST be able to load all RR types except MD and
4336 MF from configuration files. The MD and MF types are
4337 obsolete and MUST NOT be implemented; in particular, name
4338 servers MUST NOT load these types from configuration files.
4339
4340
4341
4342 Internet Engineering Task Force [Page 79]
4343 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4344
4345
4346 DISCUSSION:
4347 The RR types MB, MG, MR, NULL, MINFO and RP are
4348 considered experimental, and applications that use the
4349 DNS cannot expect these RR types to be supported by
4350 most domains. Furthermore these types are subject to
4351 redefinition.
4352
4353 The TXT and WKS RR types have not been widely used by
4354 Internet sites; as a result, an application cannot rely
This section indicates that TCP is optional (SHOUD-level) for DNS implementations; many later RFCs update this to make TCP required.
4355 on the the existence of a TXT or WKS RR in most
4356 domains.
4357
4358 6.1.3.7 Robustness
4359
4360 DNS software may need to operate in environments where the
4361 root servers or other servers are unavailable due to network
4362 connectivity or other problems. In this situation, DNS name
4363 servers and resolvers MUST continue to provide service for
4364 the reachable part of the name space, while giving temporary
4365 failures for the rest.
4366
4367 DISCUSSION:
4368 Although the DNS is meant to be used primarily in the
4369 connected Internet, it should be possible to use the
4370 system in networks which are unconnected to the
4371 Internet. Hence implementations must not depend on
4372 access to root servers before providing service for
4373 local names.
4374
4375 6.1.3.8 Local Host Table
4376
4377 DISCUSSION:
4378 A host may use a local host table as a backup or
4379 supplement to the DNS. This raises the question of
4380 which takes precedence, the DNS or the host table; the
4381 most flexible approach would make this a configuration
4382 option.
4383
4384 Typically, the contents of such a supplementary host
4385 table will be determined locally by the site. However,
4386 a publically-available table of Internet hosts is
4387 maintained by the DDN Network Information Center (DDN
4388 NIC), with a format documented in [DNS:4]. This table
4389 can be retrieved from the DDN NIC using a protocol
4390 described in [DNS:5]. It must be noted that this table
4391 contains only a small fraction of all Internet hosts.
4392 Hosts using this protocol to retrieve the DDN NIC host
4393 table should use the VERSION command to check if the
4394
4395
4396
4397 Internet Engineering Task Force [Page 80]
4398 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4399
4400
4401 table has changed before requesting the entire table
4402 with the ALL command. The VERSION identifier should be
4403 treated as an arbitrary string and tested only for
4404 equality; no numerical sequence may be assumed.
4405
4406 The DDN NIC host table includes administrative
4407 information that is not needed for host operation and
4408 is therefore not currently included in the DNS
4409 database; examples include network and gateway entries.
4410 However, much of this additional information will be
4411 added to the DNS in the future. Conversely, the DNS
4412 provides essential services (in particular, MX records)
4413 that are not available from the DDN NIC host table.
4414
4415 6.1.4 DNS USER INTERFACE
4416
4417 6.1.4.1 DNS Administration
4418
4419 This document is concerned with design and implementation
4420 issues in host software, not with administrative or
4421 operational issues. However, administrative issues are of
4422 particular importance in the DNS, since errors in particular
4423 segments of this large distributed database can cause poor
4424 or erroneous performance for many sites. These issues are
4425 discussed in [DNS:6] and [DNS:7].
4426
4427 6.1.4.2 DNS User Interface
4428
4429 Hosts MUST provide an interface to the DNS for all
4430 application programs running on the host. This interface
4431 will typically direct requests to a system process to
4432 perform the resolver function [DNS:1, 6.1:2].
4433
4434 At a minimum, the basic interface MUST support a request for
4435 all information of a specific type and class associated with
4436 a specific name, and it MUST return either all of the
4437 requested information, a hard error code, or a soft error
4438 indication. When there is no error, the basic interface
4439 returns the complete response information without
4440 modification, deletion, or ordering, so that the basic
4441 interface will not need to be changed to accommodate new
4442 data types.
4443
4444 DISCUSSION:
4445 The soft error indication is an essential part of the
4446 interface, since it may not always be possible to
4447 access particular information from the DNS; see Section
4448 6.1.3.3.
4449
4450
4451
4452 Internet Engineering Task Force [Page 81]
4453 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4454
4455
4456 A host MAY provide other DNS interfaces tailored to
4457 particular functions, transforming the raw domain data into
4458 formats more suited to these functions. In particular, a
4459 host MUST provide a DNS interface to facilitate translation
4460 between host addresses and host names.
4461
4462 6.1.4.3 Interface Abbreviation Facilities
4463
4464 User interfaces MAY provide a method for users to enter
4465 abbreviations for commonly-used names. Although the
4466 definition of such methods is outside of the scope of the
4467 DNS specification, certain rules are necessary to insure
4468 that these methods allow access to the entire DNS name space
4469 and to prevent excessive use of Internet resources.
4470
4471 If an abbreviation method is provided, then:
4472
4473 (a) There MUST be some convention for denoting that a name
4474 is already complete, so that the abbreviation method(s)
4475 are suppressed. A trailing dot is the usual method.
4476
4477 (b) Abbreviation expansion MUST be done exactly once, and
4478 MUST be done in the context in which the name was
4479 entered.
4480
4481
4482 DISCUSSION:
4483 For example, if an abbreviation is used in a mail
4484 program for a destination, the abbreviation should be
4485 expanded into a full domain name and stored in the
4486 queued message with an indication that it is already
4487 complete. Otherwise, the abbreviation might be
4488 expanded with a mail system search list, not the
4489 user's, or a name could grow due to repeated
4490 canonicalizations attempts interacting with wildcards.
4491
4492 The two most common abbreviation methods are:
4493
4494 (1) Interface-level aliases
4495
4496 Interface-level aliases are conceptually implemented as
4497 a list of alias/domain name pairs. The list can be
4498 per-user or per-host, and separate lists can be
4499 associated with different functions, e.g. one list for
4500 host name-to-address translation, and a different list
4501 for mail domains. When the user enters a name, the
4502 interface attempts to match the name to the alias
4503 component of a list entry, and if a matching entry can
4504
4505
4506
4507 Internet Engineering Task Force [Page 82]
4508 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4509
4510
4511 be found, the name is replaced by the domain name found
4512 in the pair.
4513
4514 Note that interface-level aliases and CNAMEs are
4515 completely separate mechanisms; interface-level aliases
4516 are a local matter while CNAMEs are an Internet-wide
4517 aliasing mechanism which is a required part of any DNS
4518 implementation.
4519
4520 (2) Search Lists
4521
4522 A search list is conceptually implemented as an ordered
4523 list of domain names. When the user enters a name, the
4524 domain names in the search list are used as suffixes to
4525 the user-supplied name, one by one, until a domain name
4526 with the desired associated data is found, or the
4527 search list is exhausted. Search lists often contain
4528 the name of the local host's parent domain or other
4529 ancestor domains. Search lists are often per-user or
4530 per-process.
4531
4532 It SHOULD be possible for an administrator to disable a
4533 DNS search-list facility. Administrative denial may be
4534 warranted in some cases, to prevent abuse of the DNS.
4535
4536 There is danger that a search-list mechanism will
4537 generate excessive queries to the root servers while
4538 testing whether user input is a complete domain name,
4539 lacking a final period to mark it as complete. A
4540 search-list mechanism MUST have one of, and SHOULD have
4541 both of, the following two provisions to prevent this:
4542
4543 (a) The local resolver/name server can implement
4544 caching of negative responses (see Section
4545 6.1.3.3).
4546
4547 (b) The search list expander can require two or more
4548 interior dots in a generated domain name before it
4549 tries using the name in a query to non-local
4550 domain servers, such as the root.
4551
4552 DISCUSSION:
4553 The intent of this requirement is to avoid
4554 excessive delay for the user as the search list is
4555 tested, and more importantly to prevent excessive
4556 traffic to the root and other high-level servers.
4557 For example, if the user supplied a name "X" and
4558 the search list contained the root as a component,
4559
4560
4561
4562 Internet Engineering Task Force [Page 83]
4563 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4564
4565
4566 a query would have to consult a root server before
4567 the next search list alternative could be tried.
4568 The resulting load seen by the root servers and
4569 gateways near the root would be multiplied by the
4570 number of hosts in the Internet.
4571
4572 The negative caching alternative limits the effect
4573 to the first time a name is used. The interior
4574 dot rule is simpler to implement but can prevent
4575 easy use of some top-level names.
4576
4577
4578 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
4579
4580 | | | | |S| |
4581 | | | | |H| |F
4582 | | | | |O|M|o
4583 | | |S| |U|U|o
4584 | | |H| |L|S|t
4585 | |M|O| |D|T|n
4586 | |U|U|M| | |o
4587 | |S|L|A|N|N|t
4588 | |T|D|Y|O|O|t
4589 FEATURE |SECTION | | | |T|T|e
4590 -----------------------------------------------|-----------|-|-|-|-|-|--
4591 GENERAL ISSUES | | | | | | |
4592 | | | | | | |
4593 Implement DNS name-to-address conversion |6.1.1 |x| | | | |
4594 Implement DNS address-to-name conversion |6.1.1 |x| | | | |
4595 Support conversions using host table |6.1.1 | | |x| | |
4596 Properly handle RR with zero TTL |6.1.2.1 |x| | | | |
4597 Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | |
4598 Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | |
4599 Unused fields zero |6.1.2.3 |x| | | | |
4600 Use compression in responses |6.1.2.4 |x| | | | |
4601 | | | | | | |
4602 Include config info in responses |6.1.2.5 | | | | |x|
4603 Support all well-known, class-indep. types |6.1.3.5 |x| | | | |
4604 Easily expand type list |6.1.3.5 | |x| | | |
4605 Load all RR types (except MD and MF) |6.1.3.6 |x| | | | |
4606 Load MD or MF type |6.1.3.6 | | | | |x|
4607 Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | |
4608 -----------------------------------------------|-----------|-|-|-|-|-|--
4609 RESOLVER ISSUES: | | | | | | |
4610 | | | | | | |
4611 Resolver support multiple concurrent requests |6.1.3.1 | |x| | | |
4612 Full-service resolver: |6.1.3.1 | | |x| | |
4613 Local caching |6.1.3.1 |x| | | | |
4614
4615
4616
4617 Internet Engineering Task Force [Page 84]
4618 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4619
4620
4621 Information in local cache times out |6.1.3.1 |x| | | | |
4622 Configurable with starting info |6.1.3.1 | |x| | | |
4623 Stub resolver: |6.1.3.1 | | |x| | |
4624 Use redundant recursive name servers |6.1.3.1 |x| | | | |
4625 Local caching |6.1.3.1 | | |x| | |
4626 Information in local cache times out |6.1.3.1 |x| | | | |
4627 Support for remote multi-homed hosts: | | | | | | |
4628 Sort multiple addresses by preference list |6.1.3.4 | |x| | | |
4629 | | | | | | |
4630 -----------------------------------------------|-----------|-|-|-|-|-|--
4631 TRANSPORT PROTOCOLS: | | | | | | |
4632 | | | | | | |
4633 Support UDP queries |6.1.3.2 |x| | | | |
4634 Support TCP queries |6.1.3.2 | |x| | | |
4635 Send query using UDP first |6.1.3.2 |x| | | | |1
4636 Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | |
4637 Name server limit TCP query resources |6.1.3.2 | | |x| | |
4638 Punish unnecessary TCP query |6.1.3.2 | | | |x| |
4639 Use truncated data as if it were not |6.1.3.2 | | | | |x|
4640 Private agreement to use only TCP |6.1.3.2 | | |x| | |
4641 Use TCP for zone transfers |6.1.3.2 |x| | | | |
4642 TCP usage not block UDP queries |6.1.3.2 |x| | | | |
4643 Support broadcast or multicast queries |6.1.3.2 | | |x| | |
4644 RD bit set in query |6.1.3.2 | | | | |x|
4645 RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | |
4646 Send only as occasional probe for addr's |6.1.3.2 | |x| | | |
4647 -----------------------------------------------|-----------|-|-|-|-|-|--
4648 RESOURCE USAGE: | | | | | | |
4649 | | | | | | |
4650 Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | |
4651 Finite bounds per request |6.1.3.3 |x| | | | |
4652 Failure after retries => soft error |6.1.3.3 |x| | | | |
4653 Cache temporary failures |6.1.3.3 | |x| | | |
4654 Cache negative responses |6.1.3.3 | |x| | | |
4655 Retries use exponential backoff |6.1.3.3 | |x| | | |
4656 Upper, lower bounds |6.1.3.3 | |x| | | |
4657 Client handle Source Quench |6.1.3.3 | |x| | | |
4658 Server ignore Source Quench |6.1.3.3 | | |x| | |
4659 -----------------------------------------------|-----------|-|-|-|-|-|--
4660 USER INTERFACE: | | | | | | |
4661 | | | | | | |
4662 All programs have access to DNS interface |6.1.4.2 |x| | | | |
4663 Able to request all info for given name |6.1.4.2 |x| | | | |
4664 Returns complete info or error |6.1.4.2 |x| | | | |
4665 Special interfaces |6.1.4.2 | | |x| | |
4666 Name<->Address translation |6.1.4.2 |x| | | | |
4667 | | | | | | |
4668 Abbreviation Facilities: |6.1.4.3 | | |x| | |
4669
4670
4671
4672 Internet Engineering Task Force [Page 85]
4673 RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
4674
4675
4676 Convention for complete names |6.1.4.3 |x| | | | |
4677 Conversion exactly once |6.1.4.3 |x| | | | |
4678 Conversion in proper context |6.1.4.3 |x| | | | |
4679 Search list: |6.1.4.3 | | |x| | |
4680 Administrator can disable |6.1.4.3 | |x| | | |
4681 Prevention of excessive root queries |6.1.4.3 |x| | | | |
4682 Both methods |6.1.4.3 | |x| | | |
4683 -----------------------------------------------|-----------|-|-|-|-|-|--
4684 -----------------------------------------------|-----------|-|-|-|-|-|--
4685
4686 1. Unless there is private agreement between particular resolver and
4687 particular server.
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727 Internet Engineering Task Force [Page 86]
4728 RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
4729
4730
4731 6.2 HOST INITIALIZATION
4732
4733 6.2.1 INTRODUCTION
4734
4735 This section discusses the initialization of host software
4736 across a connected network, or more generally across an
4737 Internet path. This is necessary for a diskless host, and may
4738 optionally be used for a host with disk drives. For a diskless
4739 host, the initialization process is called "network booting"
4740 and is controlled by a bootstrap program located in a boot ROM.
4741
4742 To initialize a diskless host across the network, there are two
4743 distinct phases:
4744
4745 (1) Configure the IP layer.
4746
4747 Diskless machines often have no permanent storage in which
4748 to store network configuration information, so that
4749 sufficient configuration information must be obtained
4750 dynamically to support the loading phase that follows.
4751 This information must include at least the IP addresses of
4752 the host and of the boot server. To support booting
4753 across a gateway, the address mask and a list of default
4754 gateways are also required.
4755
4756 (2) Load the host system code.
4757
4758 During the loading phase, an appropriate file transfer
4759 protocol is used to copy the system code across the
4760 network from the boot server.
4761
4762 A host with a disk may perform the first step, dynamic
4763 configuration. This is important for microcomputers, whose
4764 floppy disks allow network configuration information to be
4765 mistakenly duplicated on more than one host. Also,
4766 installation of new hosts is much simpler if they automatically
4767 obtain their configuration information from a central server,
4768 saving administrator time and decreasing the probability of
4769 mistakes.
4770
4771 6.2.2 REQUIREMENTS
4772
4773 6.2.2.1 Dynamic Configuration
4774
4775 A number of protocol provisions have been made for dynamic
4776 configuration.
4777
4778 o ICMP Information Request/Reply messages
4779
4780
4781
4782 Internet Engineering Task Force [Page 87]
4783 RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
4784
4785
4786 This obsolete message pair was designed to allow a host
4787 to find the number of the network it is on.
4788 Unfortunately, it was useful only if the host already
4789 knew the host number part of its IP address,
4790 information that hosts requiring dynamic configuration
4791 seldom had.
4792
4793 o Reverse Address Resolution Protocol (RARP) [BOOT:4]
4794
4795 RARP is a link-layer protocol for a broadcast medium
4796 that allows a host to find its IP address given its
4797 link layer address. Unfortunately, RARP does not work
4798 across IP gateways and therefore requires a RARP server
4799 on every network. In addition, RARP does not provide
4800 any other configuration information.
4801
4802 o ICMP Address Mask Request/Reply messages
4803
4804 These ICMP messages allow a host to learn the address
4805 mask for a particular network interface.
4806
4807 o BOOTP Protocol [BOOT:2]
4808
4809 This protocol allows a host to determine the IP
4810 addresses of the local host and the boot server, the
4811 name of an appropriate boot file, and optionally the
4812 address mask and list of default gateways. To locate a
4813 BOOTP server, the host broadcasts a BOOTP request using
4814 UDP. Ad hoc gateway extensions have been used to
4815 transmit the BOOTP broadcast through gateways, and in
4816 the future the IP Multicasting facility will provide a
4817 standard mechanism for this purpose.
4818
4819
4820 The suggested approach to dynamic configuration is to use
4821 the BOOTP protocol with the extensions defined in "BOOTP
4822 Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084
4823 defines some important general (not vendor-specific)
4824 extensions. In particular, these extensions allow the
4825 address mask to be supplied in BOOTP; we RECOMMEND that the
4826 address mask be supplied in this manner.
4827
4828 DISCUSSION:
4829 Historically, subnetting was defined long after IP, and
4830 so a separate mechanism (ICMP Address Mask messages)
4831 was designed to supply the address mask to a host.
4832 However, the IP address mask and the corresponding IP
4833 address conceptually form a pair, and for operational
4834
4835
4836
4837 Internet Engineering Task Force [Page 88]
4838 RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
4839
4840
4841 simplicity they ought to be defined at the same time
4842 and by the same mechanism, whether a configuration file
4843 or a dynamic mechanism like BOOTP.
4844
4845 Note that BOOTP is not sufficiently general to specify
4846 the configurations of all interfaces of a multihomed
4847 host. A multihomed host must either use BOOTP
4848 separately for each interface, or configure one
4849 interface using BOOTP to perform the loading, and
4850 perform the complete initialization from a file later.
4851
4852 Application layer configuration information is expected
4853 to be obtained from files after loading of the system
4854 code.
4855
4856 6.2.2.2 Loading Phase
4857
4858 A suggested approach for the loading phase is to use TFTP
4859 [BOOT:1] between the IP addresses established by BOOTP.
4860
4861 TFTP to a broadcast address SHOULD NOT be used, for reasons
4862 explained in Section 4.2.3.4.
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892 Internet Engineering Task Force [Page 89]
4893 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
4894
4895
4896 6.3 REMOTE MANAGEMENT
4897
4898 6.3.1 INTRODUCTION
4899
4900 The Internet community has recently put considerable effort
4901 into the development of network management protocols. The
4902 result has been a two-pronged approach [MGT:1, MGT:6]: the
4903 Simple Network Management Protocol (SNMP) [MGT:4] and the
4904 Common Management Information Protocol over TCP (CMOT) [MGT:5].
4905
4906 In order to be managed using SNMP or CMOT, a host will need to
4907 implement an appropriate management agent. An Internet host
4908 SHOULD include an agent for either SNMP or CMOT.
4909
4910 Both SNMP and CMOT operate on a Management Information Base
4911 (MIB) that defines a collection of management values. By
4912 reading and setting these values, a remote application may
4913 query and change the state of the managed system.
4914
4915 A standard MIB [MGT:3] has been defined for use by both
4916 management protocols, using data types defined by the Structure
4917 of Management Information (SMI) defined in [MGT:2]. Additional
4918 MIB variables can be introduced under the "enterprises" and
4919 "experimental" subtrees of the MIB naming space [MGT:2].
4920
4921 Every protocol module in the host SHOULD implement the relevant
4922 MIB variables. A host SHOULD implement the MIB variables as
4923 defined in the most recent standard MIB, and MAY implement
4924 other MIB variables when appropriate and useful.
4925
4926 6.3.2 PROTOCOL WALK-THROUGH
4927
4928 The MIB is intended to cover both hosts and gateways, although
4929 there may be detailed differences in MIB application to the two
4930 cases. This section contains the appropriate interpretation of
4931 the MIB for hosts. It is likely that later versions of the MIB
4932 will include more entries for host management.
4933
4934 A managed host must implement the following groups of MIB
4935 object definitions: System, Interfaces, Address Translation,
4936 IP, ICMP, TCP, and UDP.
4937
4938 The following specific interpretations apply to hosts:
4939
4940 o ipInHdrErrors
4941
4942 Note that the error "time-to-live exceeded" can occur in a
4943 host only when it is forwarding a source-routed datagram.
4944
4945
4946
4947 Internet Engineering Task Force [Page 90]
4948 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
4949
4950
4951 o ipOutNoRoutes
4952
4953 This object counts datagrams discarded because no route
4954 can be found. This may happen in a host if all the
4955 default gateways in the host's configuration are down.
4956
4957 o ipFragOKs, ipFragFails, ipFragCreates
4958
4959 A host that does not implement intentional fragmentation
4960 (see "Fragmentation" section of [INTRO:1]) MUST return the
4961 value zero for these three objects.
4962
4963 o icmpOutRedirects
4964
4965 For a host, this object MUST always be zero, since hosts
4966 do not send Redirects.
4967
4968 o icmpOutAddrMaskReps
4969
4970 For a host, this object MUST always be zero, unless the
4971 host is an authoritative source of address mask
4972 information.
4973
4974 o ipAddrTable
4975
4976 For a host, the "IP Address Table" object is effectively a
4977 table of logical interfaces.
4978
4979 o ipRoutingTable
4980
4981 For a host, the "IP Routing Table" object is effectively a
4982 combination of the host's Routing Cache and the static
4983 route table described in "Routing Outbound Datagrams"
4984 section of [INTRO:1].
4985
4986 Within each ipRouteEntry, ipRouteMetric1...4 normally will
4987 have no meaning for a host and SHOULD always be -1, while
4988 ipRouteType will normally have the value "remote".
4989
4990 If destinations on the connected network do not appear in
4991 the Route Cache (see "Routing Outbound Datagrams section
4992 of [INTRO:1]), there will be no entries with ipRouteType
4993 of "direct".
4994
4995
4996 DISCUSSION:
4997 The current MIB does not include Type-of-Service in an
4998 ipRouteEntry, but a future revision is expected to make
4999
5000
5001
5002 Internet Engineering Task Force [Page 91]
5003 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5004
5005
5006 this addition.
5007
5008 We also expect the MIB to be expanded to allow the remote
5009 management of applications (e.g., the ability to partially
5010 reconfigure mail systems). Network service applications
5011 such as mail systems should therefore be written with the
5012 "hooks" for remote management.
5013
5014 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY
5015
5016 | | | | |S| |
5017 | | | | |H| |F
5018 | | | | |O|M|o
5019 | | |S| |U|U|o
5020 | | |H| |L|S|t
5021 | |M|O| |D|T|n
5022 | |U|U|M| | |o
5023 | |S|L|A|N|N|t
5024 | |T|D|Y|O|O|t
5025 FEATURE |SECTION | | | |T|T|e
5026 -----------------------------------------------|-----------|-|-|-|-|-|--
5027 Support SNMP or CMOT agent |6.3.1 | |x| | | |
5028 Implement specified objects in standard MIB |6.3.1 | |x| | | |
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057 Internet Engineering Task Force [Page 92]
5058 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5059
5060
5061 7. REFERENCES
5062
5063 This section lists the primary references with which every
5064 implementer must be thoroughly familiar. It also lists some
5065 secondary references that are suggested additional reading.
5066
5067 INTRODUCTORY REFERENCES:
5068
5069
5070 [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
5071 IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
5072 October 1989.
5073
5074 [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
5075 (three volumes), SRI International, December 1985.
5076
5077 [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel,
5078 RFC-1011, May 1987.
5079
5080 This document is republished periodically with new RFC numbers;
5081 the latest version must be used.
5082
5083 [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J.
5084 Postel, RFC-980, March 1986.
5085
5086 [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
5087 May 1987.
5088
5089 This document is republished periodically with new RFC numbers;
5090 the latest version must be used.
5091
5092
5093 TELNET REFERENCES:
5094
5095
5096 [TELNET:1] "Telnet Protocol Specification," J. Postel and J.
5097 Reynolds, RFC-854, May 1983.
5098
5099 [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds,
5100 RFC-855, May 1983.
5101
5102 [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds,
5103 RFC-856, May 1983.
5104
5105 [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
5106 May 1983.
5107
5108 [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J.
5109
5110
5111
5112 Internet Engineering Task Force [Page 93]
5113 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5114
5115
5116 Reynolds, RFC-858, May 1983.
5117
5118 [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC-
5119 859, May 1983.
5120
5121 [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds,
5122 RFC-860, May 1983.
5123
5124 [TELNET:8] "Telnet Extended Options List," J. Postel and J.
5125 Reynolds, RFC-861, May 1983.
5126
5127 [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855,
5128 December 1983.
5129
5130 [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
5131 February 1989.
5132
5133 This document supercedes RFC-930.
5134
5135 [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
5136 October 1988.
5137
5138 [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
5139 1989.
5140
5141 [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
5142 December 1988.
5143
5144 [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
5145 1080, November 1988.
5146
5147
5148 SECONDARY TELNET REFERENCES:
5149
5150
5151 [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
5152 Defense, May 1984.
5153
5154 This document is intended to describe the same protocol as RFC-
5155 854. In case of conflict, RFC-854 takes precedence, and the
5156 present document takes precedence over both.
5157
5158 [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
5159
5160 [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
5161 1977.
5162
5163 [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
5164
5165
5166
5167 Internet Engineering Task Force [Page 94]
5168 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5169
5170
5171 [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
5172 Implementation," A. Yasuda and T. Thompson, RFC-1043, February
5173 1988.
5174
5175
5176 FTP REFERENCES:
5177
5178
5179 [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
5180 959, October 1985.
5181
5182 [FTP:2] "Document File Format Standards," J. Postel, RFC-678,
5183 December 1974.
5184
5185 [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of
5186 Defense, May 1984.
5187
5188 This document is based on an earlier version of the FTP
5189 specification (RFC-765) and is obsolete.
5190
5191
5192 TFTP REFERENCES:
5193
5194
5195 [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
5196 1981.
5197
5198
5199 MAIL REFERENCES:
5200
5201
5202 [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
5203 1982.
5204
5205 [SMTP:2] "Standard For The Format of ARPA Internet Text Messages,"
5206 D. Crocker, RFC-822, August 1982.
5207
5208 This document obsoleted an earlier specification, RFC-733.
5209
5210 [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC-
5211 974, January 1986.
5212
5213 This RFC describes the use of MX records, a mandatory extension
5214 to the mail delivery process.
5215
5216 [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
5217 February 1988.
5218
5219
5220
5221
5222 Internet Engineering Task Force [Page 95]
5223 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5224
5225
5226 [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
5227 June 1986.
5228
5229 [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
5230
5231 The two preceding RFC's define a proposed standard for
5232 gatewaying mail between the Internet and the X.400 environments.
5233
5234 [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S.
5235 Department of Defense, May 1984.
5236
5237 This specification is intended to describe the same protocol as
5238 does RFC-821. However, MIL-STD-1781 is incomplete; in
5239 particular, it does not include MX records [SMTP:3].
5240
5241 [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu,
5242 RFC-1049, March 1988.
5243
5244
5245 DOMAIN NAME SYSTEM REFERENCES:
5246
5247
5248 [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris,
5249 RFC-1034, November 1987.
5250
5251 This document and the following one obsolete RFC-882, RFC-883,
5252 and RFC-973.
5253
5254 [DNS:2] "Domain Names - Implementation and Specification," RFC-1035,
5255 P. Mockapetris, November 1987.
5256
5257
5258 [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974,
5259 January 1986.
5260
5261
5262 [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein,
5263 RFC-952, M. Stahl, E. Feinler, October 1985.
5264
5265 SECONDARY DNS REFERENCES:
5266
5267
5268 [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
5269 RFC-953, October 1985.
5270
5271 [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November
5272 1987.
5273
5274
5275
5276
5277 Internet Engineering Task Force [Page 96]
5278 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5279
5280
5281 [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC-
5282 1033, November 1987.
5283
5284 [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet
5285 Protocol Handbook, NIC 50007, SRI Network Information Center,
5286 August 1989.
5287
5288
5289 SYSTEM INITIALIZATION REFERENCES:
5290
5291
5292 [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
5293 1984.
5294
5295 [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
5296 951, September 1985.
5297
5298 [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
5299 1084, December 1988.
5300
5301 Note: this RFC revised and obsoleted RFC-1048.
5302
5303 [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
5304 Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
5305
5306
5307 MANAGEMENT REFERENCES:
5308
5309
5310 [MGT:1] "IAB Recommendations for the Development of Internet Network
5311 Management Standards," V. Cerf, RFC-1052, April 1988.
5312
5313 [MGT:2] "Structure and Identification of Management Information for
5314 TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
5315 August 1988.
5316
5317 [MGT:3] "Management Information Base for Network Management of
5318 TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
5319 August 1988.
5320
5321 [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor,
5322 M. Schoffstall, and C. Davin, RFC-1098, April 1989.
5323
5324 [MGT:5] "The Common Management Information Services and Protocol
5325 over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
5326
5327 [MGT:6] "Report of the Second Ad Hoc Network Management Review
5328 Group," V. Cerf, RFC-1109, August 1989.
5329
5330
5331
5332 Internet Engineering Task Force [Page 97]
5333 RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
5334
5335
5336 Security Considerations
5337
5338 There are many security issues in the application and support
5339 programs of host software, but a full discussion is beyond the scope
5340 of this RFC. Security-related issues are mentioned in sections
5341 concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
5342 EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
5343 SMTP DATA command (Section 5.2.8).
5344
5345 Author's Address
5346
5347 Robert Braden
5348 USC/Information Sciences Institute
5349 4676 Admiralty Way
5350 Marina del Rey, CA 90292-6695
5351
5352 Phone: (213) 822 1511
5353
5354 EMail: Braden@ISI.EDU
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379
5380
5381
5382
5383
5384
5385
5386
5387 Internet Engineering Task Force [Page 98]
5388
[TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, December 1983.
[TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-8585, December 1983.
IMPLEMENTATION:
The format of the 227 reply to a PASV command is not
well standardized. In particular, an FTP client cannot
assume that the parentheses shown on page 40 of RFC-959
will be present (and in fact, Figure 3 on page 43 omits
them).
IMPLEMENTATION:
The format of the 227 reply to a PASV command is not
well standardized. In particular, an FTP client cannot
assume that the parentheses shown on page 40 of RFC-959
will be present (and in fact, Figure 3 on page 45 omits
them).
In RFC 959, Figure 3 is actually on page 45, not page 43. --VERIFIER NOTES-- I see figure 3 at the top of page 45.
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be not all-numeric.
RFC 3696 section 2 states: "There is an additional rule that essentially requires that top-level domain names not be all-numeric." The eleven IDN test TLDs created in September 2007 contain hyphen-minus as specified in the IDNA RFCs. --VERIFIER NOTES-- This errata is in conflict with errata 1353. A new I-D and community consensus are probably needed.
Errata ID 1081, reported 2007-11-20, identifies a problem with the
evolution of naming of top-level domains and the text of RFC 1123.
It reads:
Section 2.1 says:
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
It should say:
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be not all-numeric.
Notes:
RFC 3696 section 2 states: "There is an additional rule that
essentially requires that top-level domain names not be
all-numeric." The eleven IDN test TLDs created in
September 2007 contain hyphen-minus as specified in the
IDNA RFCs.
However, a valid host name can never have the dotted-decimal form #.#.#.#, since this change does not permit the highest-level component label to start with a digit even if it is not all-numeric.
This is a correct identification of the problem, but the wrong fix. RFC
3696, which ID 1081 cites, is an informational document that is
deliberately relaxed about the fine details and says so. It is not
relevant to determination of the text that should have been (with
perfect knowledge of the future) in 1123.
Based on discussions when we were doing RFC 1591 and subsequently, the
expectation then (and presumably when 1123 was written) was that the
name of any new TLD would follow the rules for the existing ones, i.e.,
that they would be exactly two or three characters long and be all-
alphabetic (which is exactly what 1123 says). The slightly-odd "will
be" language in 1123 was, I believe, because that restriction was
expected to be enforced by IANA, rather than being a protocol issue.
ICANN, with a different set of assignment policies, effectively
eliminated the length rule with the TLDs allocated in 2000. IDNA (RFC
3490) uses a syntax for IDNs that requires embedded hyphens in TLDs if
there were ever to be an actual IDN TLD (hence the comment in ID 1081
about the IANA IDN testbed).
While the proposed correction in Errata ID 1081 would fix the problem by
imposing the narrowest possible restriction ("not all-numeric"), the
original host name rule and the original statement in 1123 both assume
the possibility of a minimal check to differentiate between domain names
and IP addresses, i.e., checking the first digit only. Because I
believe that there are probably implementations that depend on such
minimal parsing --some probably ancient and embedded-- it would appear
to be wise to relax the rule as little as possible and, in particular,
to restrict the "leading digit" exception to domains below the top-
level, as 1123 effectively does.
The suggested text above reflects that reasoning. Because of the
possible consequences of this issue, I would hope that it would be
discussed with the relevant DNS-related WGs, the Root Server Advisory
Committee (RSAC), and with IANA for comment and as a heads-up. This
issue is substantive enough that it should probably be dealt with by a
document that explicitly updates 1123 and that is processed on the
Standards Track, but an accurate statement in the errata is the next-
best option until that can be done. In the interim and while this
suggestion is being discussed, Errata ID 1081 should probably be taken
out of "validated" status.
--VERIFIER NOTES--
This errata is in conflict with errata 1081. A new I-D and community
consensus are probably needed.
Errata ID 1081, reported 2007-11-20, identifies a problem with the
evolution of naming of top-level domains and the text of RFC 1123.
It reads:
Section 2.1 says:
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
It should say:
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be not all-numeric.
Notes:
RFC 3696 section 2 states: "There is an additional rule that
essentially requires that top-level domain names not be
all-numeric." The eleven IDN test TLDs created in
September 2007 contain hyphen-minus as specified in the
IDNA RFCs.
However, a valid host name can never have the dotted-decimal form #.#.#.#, since this change does not permit the highest-level component label to start with a digit even if it is not all-numeric.
This is a correct identification of the problem, but the wrong fix. RFC
3696, which ID 1081 cites, is an informational document that is
deliberately relaxed about the fine details and says so. It is not
relevant to determination of the text that should have been (with
perfect knowledge of the future) in 1123.
Based on discussions when we were doing RFC 1591 and subsequently, the
expectation then (and presumably when 1123 was written) was that the
name of any new TLD would follow the rules for the existing ones, i.e.,
that they would be exactly two or three characters long and be all-
alphabetic (which is exactly what 1123 says). The slightly-odd "will
be" language in 1123 was, I believe, because that restriction was
expected to be enforced by IANA, rather than being a protocol issue.
ICANN, with a different set of assignment policies, effectively
eliminated the length rule with the TLDs allocated in 2000. IDNA (RFC
3490) uses a syntax for IDNs that requires embedded hyphens in TLDs if
there were ever to be an actual IDN TLD (hence the comment in ID 1081
about the IANA IDN testbed).
While the proposed correction in Errata ID 1081 would fix the problem by
imposing the narrowest possible restriction ("not all-numeric"), the
original host name rule and the original statement in 1123 both assume
the possibility of a minimal check to differentiate between domain names
and IP addresses, i.e., checking the first digit only. Because I
believe that there are probably implementations that depend on such
minimal parsing --some probably ancient and embedded-- it would appear
to be wise to relax the rule as little as possible and, in particular,
to restrict the "leading digit" exception to domains below the top-
level, as 1123 effectively does.
The suggested text above reflects that reasoning. Because of the
possible consequences of this issue, I would hope that it would be
discussed with the relevant DNS-related WGs, the Root Server Advisory
Committee (RSAC), and with IANA for comment and as a heads-up. This
issue is substantive enough that it should probably be dealt with by a
document that explicitly updates 1123 and that is processed on the
Standards Track, but an accurate statement in the errata is the next-
best option until that can be done. In the interim and while this
suggestion is being discussed, Errata ID 1081 should probably be taken
out of "validated" status.
--VERIFIER NOTES--
This errata is in conflict with errata 1081. A new I-D and community
consensus are probably needed.