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