RFC 1123
Requirements for Internet Hosts - Application and Support
RFC 1123 Part 1 is here, bestie 🌈💖
Requirements for Internet Hosts -- Application and Support 🎀
This one is from the Network Working Group of the Internet Engineering Task Force (IETF), and it's RFC 1123, edited by R. Braden, dated October 1989 📅. It's an official specification for the Internet community, so this is the real deal, not a blog post 💅.
Status of This Memo ✨
So okay, the vibe here is that this doc is an official specification for the Internet community 👑. It incorporates by reference, amends, corrects, and supplements the main protocol standards documents about hosts, which means it's basically the glue that keeps the whole host-side story together 🧚. And the best part? Distribution of this document is unlimited 🦋, so everyone can read it, no cap.
Summary 🌸
Okay so this RFC is actually one half of a power couple 💜. It defines and talks through the requirements for Internet host software, and this particular half covers the application and support protocols 💻. Its bestie, RFC-1122, handles the communication protocol layers: link layer, IP layer, and transport layer 🫶. Together they're iconic, periodt 🔥.
Table of Contents 📚
1. INTRODUCTION ............................................... 5
1.1 The Internet Architecture .............................. 6
1.2 General Considerations ................................. 6
1.2.1 Continuing Internet Evolution ..................... 6
1.2.2 Robustness Principle .............................. 7
1.2.3 Error Logging ..................................... 8
1.2.4 Configuration ..................................... 8
1.3 Reading this Document .................................. 10
1.3.1 Organization ...................................... 10
1.3.2 Requirements ...................................... 10
1.3.3 Terminology ....................................... 11
1.4 Acknowledgments ........................................ 12
2. GENERAL ISSUES ............................................. 13
2.1 Host Names and Numbers ................................. 13
2.2 Using Domain Name Service .............................. 13
2.3 Applications on Multihomed hosts ....................... 14
2.4 Type-of-Service ........................................ 14
2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15
3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16
3.1 INTRODUCTION ........................................... 16
3.2 PROTOCOL WALK-THROUGH .................................. 16
3.2.1 Option Negotiation ................................ 16
3.2.2 Telnet Go-Ahead Function .......................... 16
3.2.3 Control Functions ................................. 17
3.2.4 Telnet "Synch" Signal ............................. 18
3.2.5 NVT Printer and Keyboard .......................... 19
3.2.6 Telnet Command Structure .......................... 20
3.2.7 Telnet Binary Option .............................. 20
3.2.8 Telnet Terminal-Type Option ....................... 20
3.3 SPECIFIC ISSUES ........................................ 21
3.3.1 Telnet End-of-Line Convention ..................... 21
3.3.2 Data Entry Terminals .............................. 23
3.3.3 Option Requirements ............................... 24
3.3.4 Option Initiation ................................. 24
3.3.5 Telnet Linemode Option ............................ 25
3.4 TELNET/USER INTERFACE .................................. 25
3.4.1 Character Set Transparency ........................ 25
3.4.2 Telnet Commands ................................... 26
3.4.3 TCP Connection Errors ............................. 26
3.4.4 Non-Default Telnet Contact Port ................... 26
3.4.5 Flushing Output ................................... 26
3.5. TELNET REQUIREMENTS SUMMARY ........................... 27
4. FILE TRANSFER .............................................. 29
4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29
4.1.1 INTRODUCTION ...................................... 29
4.1.2. PROTOCOL WALK-THROUGH ............................ 29
4.1.2.1 LOCAL Type ................................... 29
4.1.2.2 Telnet Format Control ........................ 30
4.1.2.3 Page Structure ............................... 30
4.1.2.4 Data Structure Transformations ............... 30
4.1.2.5 Data Connection Management ................... 31
4.1.2.6 PASV Command ................................. 31
4.1.2.7 LIST and NLST Commands ....................... 31
4.1.2.8 SITE Command ................................. 32
4.1.2.9 STOU Command ................................. 32
4.1.2.10 Telnet End-of-line Code ..................... 32
4.1.2.11 FTP Replies ................................. 33
4.1.2.12 Connections ................................. 34
4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34
4.1.3 SPECIFIC ISSUES ................................... 35
4.1.3.1 Non-standard Command Verbs ................... 35
4.1.3.2 Idle Timeout ................................. 36
4.1.3.3 Concurrency of Data and Control .............. 36
4.1.3.4 FTP Restart Mechanism ........................ 36
4.1.4 FTP/USER INTERFACE ................................ 39
4.1.4.1 Pathname Specification ....................... 39
4.1.4.2 "QUOTE" Command .............................. 40
4.1.4.3 Displaying Replies to User ................... 40
4.1.4.4 Maintaining Synchronization .................. 40
4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41
4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44
4.2.1 INTRODUCTION ...................................... 44
4.2.2 PROTOCOL WALK-THROUGH ............................. 44
4.2.2.1 Transfer Modes ............................... 44
4.2.2.2 UDP Header ................................... 44
4.2.3 SPECIFIC ISSUES ................................... 44
4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44
4.2.3.2 Timeout Algorithms ........................... 46
4.2.3.3 Extensions ................................... 46
4.2.3.4 Access Control ............................... 46
4.2.3.5 Broadcast Request ............................ 46
4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47
5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48
5.1 INTRODUCTION ........................................... 48
5.2 PROTOCOL WALK-THROUGH .................................. 48
5.2.1 The SMTP Model .................................... 48
5.2.2 Canonicalization .................................. 49
5.2.3 VRFY and EXPN Commands ............................ 50
5.2.4 SEND, SOML, and SAML Commands ..................... 50
5.2.5 HELO Command ...................................... 50
5.2.6 Mail Relay ........................................ 51
5.2.7 RCPT Command ...................................... 52
5.2.8 DATA Command ...................................... 53
5.2.9 Command Syntax .................................... 54
5.2.10 SMTP Replies ..................................... 54
5.2.11 Transparency ..................................... 55
5.2.12 WKS Use in MX Processing ......................... 55
5.2.13 RFC-822 Message Specification .................... 55
5.2.14 RFC-822 Date and Time Specification .............. 55
5.2.15 RFC-822 Syntax Change ............................ 56
5.2.16 RFC-822 Local-part .............................. 56
5.2.17 Domain Literals .................................. 57
5.2.18 Common Address Formatting Errors ................. 58
5.2.19 Explicit Source Routes ........................... 58
5.3 SPECIFIC ISSUES ........................................ 59
5.3.1 SMTP Queueing Strategies .......................... 59
5.3.1.1 Sending Strategy .............................. 59
5.3.1.2 Receiving strategy ........................... 61
5.3.2 Timeouts in SMTP .................................. 61
5.3.3 Reliable Mail Receipt ............................. 63
5.3.4 Reliable Mail Transmission ........................ 63
5.3.5 Domain Name Support ............................... 65
5.3.6 Mailing Lists and Aliases ......................... 65
5.3.7 Mail Gatewaying ................................... 66
5.3.8 Maximum Message Size .............................. 68
5.4 SMTP REQUIREMENTS SUMMARY .............................. 69
6. SUPPORT SERVICES ............................................ 72
6.1 DOMAIN NAME TRANSLATION ................................. 72
6.1.1 INTRODUCTION ....................................... 72
6.1.2 PROTOCOL WALK-THROUGH ............................. 72
6.1.2.1 Resource Records with Zero TTL ............... 73
6.1.2.2 QCLASS Values ................................ 73
6.1.2.3 Unused Fields ................................ 73
6.1.2.4 Compression .................................. 73
6.1.2.5 Misusing Configuration Info .................. 73
6.1.3 SPECIFIC ISSUES ................................... 74
6.1.3.1 Resolver Implementation ...................... 74
6.1.3.2 Transport Protocols .......................... 75
6.1.3.3 Efficient Resource Usage ..................... 77
6.1.3.4 Multihomed Hosts ............................. 78
6.1.3.5 Extensibility ................................ 79
6.1.3.6 Status of RR Types ........................... 79
6.1.3.7 Robustness ................................... 80
6.1.3.8 Local Host Table ............................. 80
6.1.4 DNS USER INTERFACE ................................ 81
6.1.4.1 DNS Administration ........................... 81
6.1.4.2 DNS User Interface ........................... 81
6.1.4.3 Interface Abbreviation Facilities ............. 82
6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84
6.2 HOST INITIALIZATION .................................... 87
6.2.1 INTRODUCTION ...................................... 87
6.2.2 REQUIREMENTS ...................................... 87
6.2.2.1 Dynamic Configuration ........................ 87
6.2.2.2 Loading Phase ................................ 89
6.3 REMOTE MANAGEMENT ...................................... 90
6.3.1 INTRODUCTION ...................................... 90
6.3.2 PROTOCOL WALK-THROUGH ............................. 90
6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92
7. REFERENCES ................................................. 931. INTRODUCTION ✨
Part 2 picks up right here 💖🧚
Okay so this is the companion-doc setup, and it's giving "read this first or you'll get lost" 🎀 This RFC covers the applications layer and support protocols, and its bestie RFC covers the lower layers: transport, IP, and link. 💖
These docs are for vendors, implementors, and users of Internet communication software. They hold the consensus of a huge amount of real technical experience from the Internet research and vendor communities. 🌸
This RFC lists the standard protocols a host connected to the Internet MUST use. It doesn't copy them, it points at the RFCs and other docs that define them, and then it fixes their errors and adds extra guidance for implementors. ✨
Every protocol gets its own set of requirements, recommendations, and options. Here's the tea, though: the requirements in this doc are NOT the full list on their own. The complete set for an Internet host lives mainly in the standard protocol specs, plus the corrections, amendments, and supplements in this RFC. 🧚
A good-faith implementation (built after careful reading of the RFCs, with some talking to the Internet technical community, and following solid communications software engineering practices) should only differ from this doc in minor ways. So a lot of these "requirements" are already stated or implied in the standard specs, and including them here is kind of redundant. 🙈 We kept them anyway, because some past implementation made the wrong choice and caused interoperability, performance, and/or robustness problems. 💀
This doc explains a lot of the requirements and recommendations, because a plain list would be dangerous, and here's why:
- Some required features matter more than others, and some features are optional. 🍓
- There may be valid reasons why particular vendor products built for restricted contexts MAY choose different specifications. 🎀
Still, the specs in this doc MUST be followed if we want arbitrary hosts to interoperate across the diversity and complexity of the Internet. Most current implementations fail these requirements in various ways, some minor and some major, but this spec is the ideal we need to move toward. 🦋
These requirements reflect the current state of Internet architecture. This doc will get updated as needed to add clarifications, or extra info in the areas where specs are still evolving. 🌈
Here's the map of the rest of the doc. The intro starts with general advice for host software vendors, then explains how to read everything else. Section 2 has general requirements that might apply to all application and support protocols. Sections 3, 4, and 5 have the requirements for the three big applications: Telnet, file transfer, and electronic mail, in that order. Section 6 covers the support applications: the domain name system, system initialization, and management. Last but not least, all the references live in Section 7. 📚✨
1.1. The Internet Architecture ✨
For a quick intro to the Internet architecture from a host's point of view, check out Section 1.1 of [INTRO:1]. That section also has recommended references if you want general background on the Internet architecture. 🧚
1.2. General Considerations 💅
There are two big lessons that Internet host software vendors have learned, and any new vendor should take them very seriously. 🔥
1.2.1. Continuing Internet Evolution 🌸
The Internet grew so fast that it exposed management and scaling problems in a huge datagram-based packet communication system. People are working on those problems, so the specs in this doc will keep evolving. Vendors and the orgs running the networks are heavily involved in planning these changes, so they'll be carefully planned and controlled. 🫶
Development, evolution, and revision are just how computer network protocols work now, and that's gonna keep going for years. 😭 If a vendor builds communication software for the Internet protocol suite (or any other protocol suite!) and then doesn't maintain and update it as specs change, they're going to leave a trail of unhappy customers. 💀 The Internet is a massive network and users are in constant contact through it, so bugs in vendor software spread through the Internet technical community really fast. Literally no secrets. 🔥
1.2.2. Robustness Principle 👑
At every layer of the protocols there's a general rule that can give you huge benefits in robustness and interoperability:
"Be liberal in what you accept, and
conservative in what you send"Software MUST be written to deal with every conceivable error, no matter how unlikely. Sooner or later a packet will show up with that exact combo of errors and attributes, and if the software isn't ready, chaos can happen. 😱 The general move is to assume the network is full of malevolent entities sending packets built to do the most damage. That assumption leads to good protective design. The most serious Internet problems have been caused by unenvisaged mechanisms triggered by low-probability events, though. Mere human malice would never have taken so devious a route! 🙈
Adaptability to change MUST be designed into all levels of Internet host software. For example, say a protocol spec lists values for a header field (like a type field, a port number, or an error code). That enumeration MUST be assumed to be incomplete. So if a spec defines four possible error codes, the software MUST NOT break when a fifth code shows up. An undefined code might be logged (see below), but it MUST NOT cause a failure. 🦋
The second half of the principle is almost as important. Software on other hosts may have deficiencies that make it unwise to exploit legal but obscure protocol features. Don't stray far from the obvious and simple, or untoward effects might happen elsewhere. 🧚 A corollary of this is "watch out for misbehaving hosts." Host software SHOULD be prepared not just to survive other misbehaving hosts, but also to cooperate in limiting how much disruption those hosts can cause to the shared communication facility. 🫶
1.2.3. Error Logging 🍓
The Internet has a huge variety of host and gateway systems, each implementing many protocols and protocol layers. Some of them have bugs and mis-features in their Internet protocol software. Because of all that complexity, diversity, and distributed function, diagnosing user problems is often really hard. 😩
Problem diagnosis gets a lot easier if host implementations include a carefully designed facility for logging erroneous or "strange" protocol events. It's important to include as much diagnostic info as possible when logging an error. In particular, it's often useful to record the header(s) of the packet that caused the error. Be careful, though: error logging MUST be done in a way that doesn't consume prohibitive amounts of resources or otherwise interfere with the host's operation. 💅
Abnormal-but-harmless protocol events can fill up error log files pretty fast. You can avoid that with a "circular" log, or by only enabling logging while you're diagnosing a known failure. It MAY be useful to filter and count duplicate successive messages too. One strategy that works really well: (1) always count abnormalities and make those counts accessible through the management protocol (see Section 6.3); and (2) let people selectively enable logging for a great variety of events. For example, it might be useful to be able to "log everything" or to "log everything for host X." 🌈
Different managements may have different policies on how much error logging they want on by default in a host. Some will say, "if it doesn't hurt me, I don't want to know about it." Others will want a more watchful, aggressive attitude about detecting and removing protocol abnormalities. Both are valid, no judgment! 🎀
1.2.4. Configuration ⭐
Ideally, a host implementation of the Internet protocol suite would be entirely self-configuring. That would let the whole suite live in ROM or get cast into silicon, it would simplify diskless workstations, and it would be an immense boon to harried LAN administrators as well as system vendors. 🥹 We haven't reached that ideal, and honestly we're not even close. 💀
All over this doc you'll find a requirement that some parameter be a configurable option. There are a few reasons for that. Sometimes there's current uncertainty or disagreement about the best value, so the recommended value might need updating later. Other times the value really depends on external factors, like the size of the host and how its communication load is distributed, or the speeds and topology of nearby networks. Self-tuning algorithms aren't available for those, and they might not be enough anyway. And sometimes configurability is needed because of administrative requirements. 💜
Last but not least, some configuration options are needed to talk to obsolete or incorrect implementations of the protocols. Those are distributed without sources, and sadly they still persist in many parts of the Internet. To make correct systems coexist with these faulty ones, administrators often have to "mis-configure" the correct systems. This will fix itself slowly as the faulty systems get retired, but vendors can't ignore it in the meantime. 🫠🔥
When we say a parameter has to be configurable, we're not saying every single boot has to read its value from a config file 🙅♀️ 🎀 We really recommend that implementors set a default for every parameter, so a config file is only needed to override the defaults that don't fit a particular installation. The configurability requirement just guarantees that it will be possible to override the default when you need to, even in a binary-only or ROM-based product 💾✨
This document does insist on a specific value for some defaults 🧚 The default is a sensitive choice when the setting controls how a product accommodates existing faulty systems. If the Internet is going to converge on full interoperability, the default values built into implementations must implement the official protocol, not "mis-configurations" that accommodate faulty implementations. Marketing pressure has pushed some vendors toward mis-configuration defaults, which is a bummer 😭 We strongly urge vendors to pick defaults that conform to the standard 💅
Finally, a vendor needs to provide solid documentation for every configuration parameter, including its limits and effects 📚🌸
1.3. Reading this Document
1.3.1. Organization
Generally, each major section is organized into the following subsections 🗂️
- Introduction
- Protocol Walk-Through -- considers the protocol specification documents section-by-section, correcting errors, stating requirements that may be ambiguous or ill-defined, and providing further clarification or explanation.
- Specific Issues -- discusses protocol design and implementation issues that were not included in the walk-through.
- Interfaces -- discusses the service interface to the next higher layer.
- Summary -- contains a summary of the requirements of the section.
Lots of the individual topics have little parenthetical bits labeled "DISCUSSION" or "IMPLEMENTATION" 🧠 The DISCUSSION bits clarify and explain the requirements right before them, and they also toss out ideas about future directions or developments. The IMPLEMENTATION bits are suggested approaches an implementor might want to consider 🛠️
The summary sections are basically guides and indexes to the text, but they're necessarily cryptic and incomplete 🙈 Never use or cite a summary on its own. Always go back to the full RFC, bestie 🫶
1.3.2. Requirements
In this document, the words that define how significant each requirement is get capitalized 🔠 Here they are:
- "MUST": This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification.
- "SHOULD": This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
- "MAY": This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item 🦋
An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant" 👑 One that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant" ✨
1.3.3. Terminology
This document uses the following technical terms 📖
- Segment: A segment is the unit of end-to-end transmission in the TCP protocol. A segment consists of a TCP header followed by application data. A segment is transmitted by encapsulation in an IP datagram 🎀
- Message: This term is used by some application layer protocols (particularly SMTP) for an application data unit 💌
- Datagram: A [UDP] datagram is the unit of end-to-end transmission in the UDP protocol 📦
- Multihomed: A host is said to be multihomed if it has multiple IP addresses to connected networks 🌐
1.4. Acknowledgments
This document is a group project 🌈 It pulls in contributions and comments from a huge crew of Internet protocol experts, including folks from university and research labs, vendors, and government agencies. It was mostly put together by the Host Requirements Working Group of the Internet Engineering Task Force (IETF) 🙌
The Editor would especially like to shout out the tireless dedication of the following people, who sat through many long meetings and generated 3 million bytes of electronic mail over the past 18 months to make this document happen 💜 Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software) 🫶
Then there are the people who made major contributions to the effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), and Mike StJohns (DCA) 👑 Folks who made significant contributions to particular areas include Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen (Toronto) 🧚
We're so grateful to everyone, including any contributors who may have been accidentally left off this list 🥹💖
2. General Issues ✨
Okay bestie, this section is all about the general requirements that might apply to every application-layer protocol 💅
2.1. Host Names and Numbers 🌸
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One bit got a glow-up here: the restriction on the first character is relaxed so it can be either a letter or a digit ✨ Host software MUST support this more liberal syntax.
Host software MUST handle host names of up to 63 characters, and it SHOULD handle host names of up to 255 characters 🎀
Whenever a user types in the identity of an Internet host, it SHOULD be possible to enter either (1) a host domain name or (2) an IP address in dotted-decimal ("#.#.#.#") form 💖 The host SHOULD check the string syntactically for a dotted-decimal number before it looks it up in the Domain Name System.
DISCUSSION:
This last requirement isn't meant to pin down the complete syntax for typing a dotted-decimal host number. That's more of a user-interface thing 🎀 For example, a dotted-decimal number must be enclosed within "[ ]" brackets for SMTP mail (see Section 5.2.17). This notation could be made universal within a host system, which would make the syntax checking for a dotted-decimal number way simpler 🧚
If a dotted-decimal number can be entered without those identifying delimiters, then a full syntax check must be made 😭 Why? Because a segment of a host domain name is now allowed to begin with a digit, and it could legally be entirely numeric (see Section 6.1.2.4). BUT, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic 💅
2.2. Using Domain Name Service 🦋
Host domain names MUST be translated to IP addresses as described in Section 6.1 💜
Applications that use domain name services MUST be able to cope with soft error conditions 🫶 They MUST wait a reasonable interval between successive retries due to a soft error, and they MUST allow for the possibility that network problems may deny service for hours or even days. Bestie, that's a long time 💀
An application SHOULD NOT rely on being able to locate a WKS record with an accurate listing of all services at a particular host address. Why? Because the WKS RR type is not often used by Internet sites 🙈 To confirm that a service is present, simply attempt to use it. Just try it, no cap 🔥
2.3. Applications on Multihomed Hosts 🌈
When the remote host is multihomed, the name-to-address translation will return a list of alternative IP addresses. As specified in Section 6.1.3.4, this list should be in order of decreasing preference ⭐ Application protocol implementations SHOULD be prepared to try multiple addresses from the list until success is obtained. More specific requirements for SMTP are given in Section 5.3.4 🎀
When the local host is multihomed, a UDP-based request/response application SHOULD send the response with an IP source address that is the same as the specific destination address of the UDP request datagram. The "specific destination address" is defined in the "IP Addressing" section of the companion RFC [INTRO:1] 🧚
Similarly, a server application that opens multiple TCP connections to the same client SHOULD use the same local IP address for all of them 💖
2.4. Type-of-Service 🍓
Applications MUST select appropriate TOS values when they invoke transport layer services, and these values MUST be configurable ✨ Note that a TOS value contains 5 bits, but only the most-significant 3 bits are currently defined. The other two bits MUST be zero 💅
DISCUSSION:
As gateway algorithms are developed to implement Type-of-Service, the recommended values for various application protocols may change 🦋 Plus, it's likely that particular combinations of users and Internet paths will want non-standard TOS values. For these reasons, the TOS values must be configurable 👑
See the latest version of the "Assigned Numbers" RFC [INTRO:5] for the recommended TOS values for the major application protocols 📚
2.5. General Application Requirements Summary 💅
Here's the whole vibe check in one table, bestie 🌸
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-----------------------------------------------|----------|-|-|-|-|-|--
| | | | | | |
User interfaces: | | | | | | |
Allow host name to begin with digit |2.1 |x| | | | |
Host names of up to 635 characters |2.1 |x| | | | |
Host names of up to 255 characters |2.1 | |x| | | |
Support dotted-decimal host numbers |2.1 | |x| | | |
Check syntactically for dotted-dec first |2.1 | |x| | | |
| | | | | | |
Map domain names per Section 6.1 |2.2 |x| | | | |
Cope with soft DNS errors |2.2 |x| | | | |
Reasonable interval between retries |2.2 |x| | | | |
Allow for long outages |2.2 |x| | | | |
Expect WKS records to be available |2.2 | | | |x| |
| | | | | | |
Try multiple addr's for remote multihomed host |2.3 | |x| | | |
UDP reply src addr is specific dest of request |2.3 | |x| | | |
Use same IP addr for related TCP connections |2.3 | |x| | | |
Specify appropriate TOS values |2.4 |x| | | | |
TOS values configurable |2.4 |x| | | | |
Unused TOS bits zero |2.4 |x| | | | |
| | | | | | |
| | | | | | |3. Remote Login -- Telnet Protocol 🧚
3.1. INTRODUCTION 💖
Telnet is the standard Internet application protocol for remote login, and it's honestly iconic 👑 It provides the encoding rules to link a user's keyboard/display on a client ("user") system with a command interpreter on a remote server system. A subset of the Telnet protocol is also incorporated within other application protocols, e.g., FTP and SMTP 🌈
Telnet uses a single TCP connection. Its normal data stream ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with escape sequences to embed control functions 🦋 Telnet also allows the negotiation of many optional modes and functions ✨
The primary Telnet specification can be found in RFC-854 [TELNET:1], while the options are defined in many other RFCs. See Section 7 for references 📚
3.2. Protocol Walk-Through 🎀
3.2.1. Option Negotiation: RFC-854, pp. 2-3 🫶
Every Telnet implementation MUST include option negotiation and subnegotiation machinery [TELNET:2] 💅
A host MUST carefully follow the rules of RFC-854 to avoid option-negotiation loops 🙈 A host MUST refuse (i.e, reply WONT/DONT to a DO/WILL) an unsupported option. Option negotiation SHOULD continue to function (even if all requests are refused) throughout the lifetime of a Telnet connection 🔥
If all option negotiations fail, a Telnet implementation MUST default to, and support, an NVT 🍓
DISCUSSION:
Even though more sophisticated "terminals" and supporting option negotiations are becoming the norm, all implementations must be prepared to support an NVT for any user-server communication 💜
3.2.2. Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 🌸
On a host that never sends the Telnet command Go Ahead (GA), the Telnet Server MUST attempt to negotiate the Suppress Go Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or Server Telnet MUST always accept negotiation of the Suppress Go Ahead option 🎀
When it is driving a full-duplex terminal for which GA has no meaning, a User Telnet implementation MAY ignore GA commands ✨
DISCUSSION:
Half-duplex ("locked-keyboard") line-at-a-time terminals, the ones the Go-Ahead mechanism was designed for, have largely disappeared from the scene 🦋 It turned out to be difficult to implement sending the Go-Ahead signal in many operating systems, even some that support native half-duplex terminals. The difficulty is typically that the Telnet server code doesn't have access to information about whether the user process is blocked awaiting input from the Telnet connection. In other words, it cannot reliably determine when to send a GA command 😭 Therefore, most Telnet Server hosts do not send GA commands.
The effect of the rules in this section is to allow either end of a Telnet connection to veto the use of GA commands 👑
There is a class of half-duplex terminals that is still commercially important: "data entry terminals," which interact in a full-screen manner 💅 However, supporting data entry terminals using the Telnet protocol does not require the Go Ahead signal. See Section 3.3.2 🧚
3.2.3. Control Functions: RFC-854, pp. 7-8 💖
The list of Telnet commands has been extended to include EOR (End-of-Record), with code 239 [TELNET:9] 🌈
Both User and Server Telnets MAY support the control functions EOR, EC, EL, and Break, and they MUST support AO, AYT, DM, IP, NOP, SB, and SE 🦋
A host MUST be able to receive and ignore any Telnet control functions that it does not support 🫶
DISCUSSION:
Note that a Server Telnet is required to support the Telnet IP (Interrupt Process) function, even if the server host has an equivalent in-stream function (e.g., Control-C in many systems). The Telnet IP function may be stronger than an in-stream interrupt command, because of the out-of-band effect of TCP urgent data 🔥
The EOR control function may be used to delimit the stream. An important application is data entry terminal support (see Section 3.3.2). There was concern that since EOR had not been defined in RFC-854, a host that was not prepared to correctly ignore unknown Telnet commands might crash if it received an EOR 💀 To protect such hosts, the End-of-Record option [TELNET:9] was introduced. However, a properly implemented Telnet program will not require this protection 🍓
3.2.4. Telnet "Synch" Signal: RFC-854, pp. 8-10 ✨
okay bestie, the Synch thing is kind of a big deal 🧚 When a User or Server Telnet gets "urgent" TCP data, it MUST discard everything except Telnet commands until it hits the DM (and the end of urgent) 💅
When a User Telnet sends a Telnet IP (Interrupt Process), it SHOULD follow that up with the Telnet "Synch" sequence. That means sending IAC IP IAC DM as TCP urgent data, and the TCP urgent pointer points to the DM octet 🦋
When a Server Telnet gets a Telnet IP command, it MAY send a Telnet "Synch" sequence back to the user to flush the output stream. The choice ought to match how the server operating system behaves when a local user interrupts a process 🌸
When a Server Telnet gets a Telnet AO command, it MUST send a Telnet "Synch" sequence back to the user to flush the output stream 🫶
A User Telnet SHOULD be able to flush output when it sends a Telnet IP. See also Section 3.4.5 🎀
DISCUSSION:
There are three ways a User Telnet can flush the stream of server output data 👑
- Send AO after IP. This makes the server host send a "flush-buffered-output" signal to its operating system. The catch is that the AO may not take effect locally (so terminal output at the User Telnet end doesn't stop) until the Server Telnet has received and processed the AO and sent back a "Synch" 😭
- Send DO TIMING-MARK [TELNET:7] after IP, and discard all output locally until a WILL/WONT TIMING-MARK is received from the Server Telnet. Since the DO TIMING-MARK gets processed after the IP at the server, the reply lands in the right spot in the output data stream 🍓 However, the TIMING-MARK will not send a "flush buffered output" signal to the server operating system. Whether that's needed depends on the server system 🤔
- Do both.
Honestly, the best method isn't totally clear 💀 It has to work with a bunch of existing server hosts that don't follow the Telnet standards in various ways. The safest approach is probably to give the user an option to pick (1), (2), or (3) 🌈
3.2.5. NVT Printer and Keyboard: RFC-854, p. 11 🖨️
In NVT mode, a Telnet SHOULD NOT send characters with the high-order bit set to 1, and it MUST NOT send that bit as a parity bit. Implementations that pass the high-order bit up to applications SHOULD negotiate binary mode (see Section 3.2.6) 💖
DISCUSSION:
Implementors, listen up 🙈 A strict reading of RFC-854 lets a client or server that expects NVT ASCII ignore characters with the high-order bit set. In general, binary mode is expected to carry an extended (beyond 7-bit) character set over Telnet ✨
BUT some applications really do need an 8-bit NVT mode, which isn't defined yet, and these apps do set the high-order bit during part or all of a Telnet connection. Note that binary mode is NOT the same as 8-bit NVT mode, because binary mode turns off end-of-line processing. That's why the high-order bit requirements are written as SHOULD, not MUST 🙃
RFC-854 defines a minimal set of properties for a "network virtual terminal" (NVT), but that doesn't mean a real terminal can't have more features. A Telnet connection is fully transparent to all 7-bit ASCII characters, including arbitrary ASCII control characters 🦋
For example, a terminal might support full-screen commands written as ASCII escape sequences. A Telnet implementation would pass those sequences through as uninterpreted data. So an NVT should NOT be pictured as some super restricted device 💅
3.2.6. Telnet Command Structure: RFC-854, p. 13 🧩
Since options can show up at any point in the data stream, a Telnet escape character (known as IAC, with the value 255) that's meant to be sent as data MUST be doubled 🎀
3.2.7. Telnet Binary Option: RFC-856 🔥
When the Binary option has been successfully negotiated, arbitrary 8-bit characters are allowed. However 🌈 the data stream MUST still be scanned for IAC characters, any embedded Telnet commands MUST be obeyed, and data bytes equal to IAC MUST be doubled. Other character processing (for example, replacing CR with CR NUL or with CR LF) MUST NOT be done. In particular, there is no end-of-line convention (see Section 3.3.1) in binary mode 🙈
DISCUSSION:
The Binary option is usually negotiated in both directions 🫶 to switch a Telnet connection from NVT mode to "binary mode." The sequence IAC EOR can be used to mark off blocks of data inside a binary-mode Telnet stream 🍓
3.2.8. Telnet Terminal-Type Option: RFC-1091 🖥️
The Terminal-Type option MUST use the terminal type names officially defined in the Assigned Numbers RFC [INTRO:5], when those names exist for the particular terminal. However, the receiver of a Terminal-Type option MUST accept any name ✨
DISCUSSION:
RFC-1091 [TELNET:10] updates an earlier version of the Terminal-Type option from RFC-930 🧚 The old version let a server host that supported several terminal types figure out a client's terminal, assuming each physical terminal had one intrinsic type. But today a "terminal" is usually a terminal emulator program running on a PC, and it might emulate a whole range of terminal types 💻 So RFC-1091 extends the spec to allow a more general terminal-type negotiation between User and Server Telnets 👑
3.3. SPECIFIC ISSUES 🎀
3.3.1. Telnet End-of-Line Convention 🍒
The Telnet protocol defines the sequence CR LF to mean "end-of-line." For terminal input, this matches the command-completion or "end-of-line" key being pressed on a user terminal. On an ASCII terminal that's the CR key, but it may also be labelled "Return" or "Enter" 💖
When a Server Telnet receives the Telnet end-of-line sequence CR LF as input from a remote terminal, the effect MUST be the same as if the user had pressed the "end-of-line" key on a local terminal. On server hosts that use ASCII in particular, receiving CR LF has to produce the same effect as a local user pressing the CR key. So CR LF and CR NUL MUST have the same effect on an ASCII server host when they come in over a Telnet connection 🫶
A User Telnet MUST be able to send any of these forms: CR LF, CR NUL, and LF. A User Telnet on an ASCII host SHOULD have a user-controllable mode to send either CR LF or CR NUL when the user presses the "end-of-line" key, and CR LF SHOULD be the default 🌸
The Telnet end-of-line sequence CR LF MUST be used to send Telnet data that isn't terminal-to-computer. For example, that covers a Server Telnet sending output, or when Telnet has been used to carry another application protocol 🦋
DISCUSSION:
This is the drama bestie, I'm not even kidding 😭 To let arbitrary Telnet clients and servers work together, the Telnet protocol defined a standard representation for a line terminator. The ASCII character set has no explicit end-of-line character, so systems picked different representations, like CR, LF, and the sequence CR LF. Telnet chose CR LF as the standard for network transmission ✨
Unfortunately RFC-854 [TELNET:1] turned out to be somewhat ambiguous about which character(s) a client should send to a server for the "end-of-line" key. That caused a massive and ongoing interoperability headache, made worse by plenty of faulty implementations of both User and Server Telnets 💀
Even though the Telnet protocol is based on a perfectly symmetric model, in a remote login session the role of the user at a terminal is different from the role of the server host. For example, RFC-854 defines what CR, LF, and CR LF mean as output from the server, but it doesn't say what the User Telnet should send when the user presses the "end-of-line" key. That's exactly the point at issue 🧐
When a user presses "end-of-line," some User Telnet implementations send CR LF, while others send CR NUL (based on a different reading of the same sentence in RFC-854). These are equivalent for a correctly implemented ASCII server host, as discussed above. For other servers, a mode in the User Telnet is needed 🍓
Here's the dilemma 🫠 User Telnets that send only CR NUL when CR is pressed create a problem for non-ASCII hosts. They can either treat CR NUL as equivalent to CR LF on input, which rules out ever entering a "bare" CR, or else lose complete interworking 🙃
Say a user on host A uses Telnet to log into server host B, and then runs B's User Telnet program to log into server host C. It's desirable for the Server/User Telnet combination on B to be as transparent as possible, so it looks like A is connected directly to C 🧚 In particular, a correct implementation will keep B transparent to Telnet end-of-line sequences, except that CR LF may get translated to CR NUL or the other way around ✨
IMPLEMENTATION:
To get Telnet end-of-line issues, you need at least a general model of how Telnet relates to the local operating system 👑 The Server Telnet process is usually coupled into the operating system's terminal driver software as a pseudo-terminal. A Telnet end-of-line sequence received by the Server Telnet has to have the same effect as pressing the end-of-line key on a real, locally connected terminal 🌈
okay so operating systems that do interactive character-at-a-time stuff (hello, editors 💅) usually have two internal modes for their terminal I/O 🌸. There's a formatted mode, where local conventions for end-of-line and other formatting rules get applied to the data stream, and a "raw" mode, where the app gets direct access to every character exactly as it was typed 🦋. A Server Telnet must be implemented in such a way that these modes have the same effect for remote as for local terminals ✨. For example, suppose a CR LF or CR NUL gets received by the Server Telnet on an ASCII host 👀. In raw mode, a CR character is passed to the application. In formatted mode, the local system's end-of-line convention is used 💖.
3.3.2. Data Entry Terminals 🖥
DISCUSSION:
Okay so besides the line-oriented and character-oriented ASCII terminals Telnet was originally built for, there are several families of video display terminals that people call "data entry terminals" or DETs 🍓. The IBM 3270 family is the iconic example.
Two Internet protocols were designed for generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET option [TELNET:18, TELNET:19]. The DET option drives a data entry terminal over a Telnet connection using (sub-)negotiation. SUPDUP is a completely separate terminal protocol that you can enter from Telnet by negotiation 🧚. Both have been used successfully in particular environments, but neither one got general acceptance or wide implementation, sadly 🥺.
A different approach for IBM 3270 family support through Telnet has been developed, although the same approach would work for any DET 💜. The idea is to enter a "native DET" mode, where the native DET input/output stream is sent as binary data. The Telnet EOR command is used to delimit logical records (e.g., "screens") inside this binary stream 🎀.
IMPLEMENTATION:
The rules for entering and leaving native DET mode go like this 📝:
- The Server uses the Terminal-Type option [TELNET:10] to learn that the client is a DET.
- It is conventional, but not required, that both ends negotiate the EOR option [TELNET:9].
- Both ends negotiate the Binary option [TELNET:3] to enter native DET mode.
- When either end negotiates out of binary mode, the other end does too, and the mode then reverts to normal NVT.
3.3.3. Option Requirements 📋
Every Telnet implementation MUST support the Binary option [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-Record [TELNET:9], and Extended Options List [TELNET:8] options. Non-negotiable, bestie 🫶.
A User or Server Telnet SHOULD support the Window Size Option [TELNET:12] if the local operating system provides the corresponding capability ✨.
DISCUSSION:
Quick note: the End-of-Record option only signifies that a Telnet can receive a Telnet EOR without crashing 💀. So every Telnet ought to be willing to accept negotiation of the End-of-Record option. See also the discussion in Section 3.2.3 🔍.
3.3.4. Option Initiation 🚀
When the Telnet protocol is used in a client/server situation, the server SHOULD initiate negotiation of the terminal interaction mode it expects 👑.
DISCUSSION:
Telnet was defined to be perfectly symmetrical, but how people actually use it is generally asymmetric 🙈. Remote login has been known to fail because NEITHER side initiated negotiation of the required non-default terminal modes. Yikes! It's generally the server that determines the preferred mode, so the server needs to initiate the negotiation. Since the negotiation is symmetric, the user can initiate it too 🦋.
A client (User Telnet) SHOULD provide a means for users to enable and disable the initiation of option negotiation 🎛.
DISCUSSION:
Sometimes a user needs to connect to an application service (e.g., FTP or SMTP) that uses Telnet for its control stream but doesn't support Telnet options 🌈. User Telnet can be used for this purpose if initiation of option negotiation is disabled.
3.3.5. Telnet Linemode Option ⭐
DISCUSSION:
An important new Telnet option, LINEMODE [TELNET:12], has been proposed, and it's giving main character energy 😭. The LINEMODE option provides a standard way for a User Telnet and a Server Telnet to agree that the client, rather than the server, will do terminal character processing. When the client has prepared a complete line of text, it sends it to the server in (usually) one TCP packet. This option will greatly decrease the packet cost of Telnet sessions and will also give much better user response over congested or long-delay networks 🚄.
The LINEMODE option allows dynamic switching between local and remote character processing. For example, the Telnet connection will automatically negotiate into single-character mode while a full screen editor is running, and then return to linemode when the editor is finished 💅.
We expect that when this RFC is released, hosts should implement the client side of this option, and may implement the server side of this option. To properly implement the server side, the server needs to be able to tell the local system not to do any input character processing. Instead, it should remember its current terminal state and notify the Server Telnet process whenever the state changes. This will allow password echoing and full screen editors to be handled properly, for example 🔐🎀.
3.4. TELNET/USER INTERFACE 📱
3.4.1. Character Set Transparency 🔤
User Telnet implementations SHOULD be able to send or receive any 7-bit ASCII character. Where possible, any special character interpretations by the user host's operating system SHOULD be bypassed so these characters can conveniently be sent and received on the connection 🌸.
Some character value MUST be reserved as "escape to command mode." Conventionally, doubling this character allows it to be entered as data 🧚. The specific character used SHOULD be user selectable.
On binary-mode connections, a User Telnet program MAY provide an escape mechanism for entering arbitrary 8-bit values, if the host operating system doesn't allow them to be entered directly from the keyboard ⌨️.
IMPLEMENTATION:
The transparency issues are less pressing on servers, but implementors should take care in dealing with issues like masking off parity bits (sent by an older, non-conforming client) before they reach programs that expect only NVT ASCII. Also handle programs that request 8-bit data streams properly 👀.
3.4.2. Telnet Commands 🕹
A User Telnet program MUST provide a user the capability of entering any of the Telnet control functions IP, AO, or AYT, and SHOULD provide the capability of entering EC, EL, and Break 💥.
3.4.3. TCP Connection Errors 🚨
A User Telnet program SHOULD report to the user any TCP errors that are reported by the transport layer (see "TCP/Application Layer Interface" section in [INTRO:1]). Don't let errors hide, bestie 🙅♀️.
3.4.4. Non-Default Telnet Contact Port 🔌
A User Telnet program SHOULD allow the user to optionally specify a non-standard contact port number at the Server Telnet host 🦋.
3.4.5. Flushing Output 🌊
A User Telnet program SHOULD provide the user the ability to specify whether or not output should be flushed when an IP is sent; see Section 3.2.4 💜.
For any output flushing scheme that causes the User Telnet to flush output locally until a Telnet signal is received from the Server, there SHOULD be a way for the user to manually restore normal output. That covers the case where the Server fails to send the expected signal 🥹.
3.5. TELNET REQUIREMENTS SUMMARY 📊
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e-------------------------------------------------|--------|-|-|-|-|-|--
| | | | | | |
Option Negotiation |3.2.1 |x| | | | |
Avoid negotiation loops |3.2.1 |x| | | | |
Refuse unsupported options |3.2.1 |x| | | | |
Negotiation OK anytime on connection |3.2.1 | |x| | | |
Default to NVT |3.2.1 |x| | | | |
Send official name in Term-Type option |3.2.8 |x| | | | |
Accept any name in Term-Type option |3.2.8 |x| | | | |
Implement Binary, Suppress-GA options |3.3.3 |x| | | | |
Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | |
Implement Window-Size option if appropriate |3.3.3 | |x| | | |
Server initiate mode negotiations |3.3.4 | |x| | | |
User can enable/disable init negotiations |3.3.4 | |x| | | |
| | | | | | |
Go-Aheads | | | | | | |
Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | |
User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | |
User Telnet ignore GA's |3.2.2 | | |x| | |
| | | | | | |
Control Functions | | | | | | |
Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | |
Support EOR EC EL Break |3.2.3 | | |x| | |
Ignore unsupported control functions |3.2.3 |x| | | | |
User, Server discard urgent data up to DM |3.2.4 |x| | | | |
User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | |
Server Telnet reply Synch to IP |3.2.4 | | |x| | |
Server Telnet reply Synch to AO |3.2.4 |x| | | | |
User Telnet can flush output when send IP |3.2.4 | |x| | | |
| | | | | | |
Encoding | | | | | | |
Send high-order bit in NVT mode |3.2.5 | | | |x| |
Send high-order bit as parity bit |3.2.5 | | | | |x|
Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | |
Always double IAC data byte |3.2.6 |x| | | | |
Double IAC data byte in binary mode |3.2.7 |x| | | | |
Obey Telnet cmds in binary mode |3.2.7 |x| | | | |
End-of-line, CR NUL in binary mode |3.2.7 | | | | |x|
| | | | | | |
End-of-Line | | | | | | |
EOL at Server same as local end-of-line |3.3.1 |x| | | | |
ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | |
User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | |
ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | |
User Telnet default mode is CR LF |3.3.1 | |x| | | |
Non-interactive uses CR LF for EOL |3.3.1 |x| | | | |
| | | | | | |
User Telnet interface | | | | | | |
Input & output all 7-bit characters |3.4.1 | |x| | | |
Bypass local op sys interpretation |3.4.1 | |x| | | |
Escape character |3.4.1 |x| | | | |
User-settable escape character |3.4.1 | |x| | | |
Escape to enter 8-bit values |3.4.1 | | |x| | |
Can input IP, AO, AYT |3.4.2 |x| | | | |
Can input EC, EL, Break |3.4.2 | |x| | | |
Report TCP connection errors to user |3.4.3 | |x| | | |
Optional non-default contact port |3.4.4 | |x| | | |
Can spec: output flushed when IP sent |3.4.5 | |x| | | |
Can manually restore output mode |3.4.5 | |x| | | |
| | | | | | |4. FILE TRANSFER 📁✨
4.1. FILE TRANSFER PROTOCOL -- FTP 💌
4.1.1. INTRODUCTION 🌸
okay so FTP is basically the main Internet standard for moving files from one place to another, and the actual spec lives in RFC-959 [FTP:1] 📚. FTP runs on two separate TCP connections at the same time, one for control and one for the data itself 🔥. It has SO many features, and some of them barely get implemented, but here's the tea: every single feature has at least one implementation out there somewhere 🫶. The minimum implementation in RFC-959 was way too tiny, so this doc defines a somewhat bigger minimum 💅.
Internet users have been unnecessarily burdened for YEARS by sloppy FTP implementations 😭. Implementors kept thinking FTP was a small, trivial little task, and that's just wrong 🙈. It has a user interface, it has to handle (correctly!) the whole mess of communication and OS errors that can pop up, and it has to deal with the huge variety of real file systems out in the world 🌈. Not a small task at all, bestie.
4.1.2. PROTOCOL WALK-THROUGH 🦋
4.1.2.1. LOCAL Type: RFC-959 Section 3.1.1.4 🍓
An FTP program MUST support TYPE I (the "IMAGE" or binary type) as well as TYPE L 8 (the "LOCAL" type with a logical byte size of 8) 💖. A machine whose memory is organized into m-bit words, where m is not a multiple of 8, MAY also support TYPE L m ✨.
DISCUSSION: The command TYPE L 8 is super often needed to move binary data between a machine with (for example) 36-bit words and a machine with 8-bit bytes 🧚. On an 8-bit byte machine, TYPE L 8 is basically the same thing as IMAGE 💜.
TYPE L m sometimes gets specified to FTP programs on two m-bit word machines, so a native-mode binary file arrives intact from one to the other 🎀. But this command should have the same effect on those machines as TYPE I does, so no plot twist there 🙈.
4.1.2.2. Telnet Format Control: RFC-959 Section 3.1.1.5.2 🌷
A host that makes no distinction between TYPE N and TYPE T SHOULD implement TYPE T to be identical to TYPE N 💅.
DISCUSSION: This provision is all about making life easier when talking to hosts that do make that distinction 🫶.
Lots of hosts store text files internally as strings of ASCII characters, using the embedded format effector characters (LF, BS, FF, ...) to control layout when a file gets printed 📝. For those hosts there's no difference between "print" files and any other files, which is very chill 😌. But systems that use record-structured files usually need a special format for printable files (like ASA carriage control) 🖨️. For those hosts, FTP lets you pick between TYPE N and TYPE T 👑.
4.1.2.3. Page Structure: RFC-959 Section 3.1.2.3 and Appendix I 📄
Implementing page structure is NOT RECOMMENDED in general, bestie 🙅♀️. However, if a host system does need to implement FTP for "random access" or "holey" files, it MUST use the defined page structure format instead of making up a new private FTP format 🔥.
4.1.2.4. Data Structure Transformations: RFC-959 Section 3.1.2 🔄
An FTP transformation between record-structure and file-structure SHOULD be invertible, to the extent that's possible while still making the result useful on the target host 💖.
DISCUSSION: RFC-959 demanded strict invertibility between record-structure and file-structure, but in practice, efficiency and convenience often make that impossible 😭. So the requirement gets relaxed 🦋. There are two different goals when you transfer a file: processing it on the target host, or just storing it 📦. For storage, strict invertibility matters a lot ✨. For processing, the file created on the target host has to be in the format that the apps on that host expect 🧠.
Here's the conflict in action: picture a record-oriented OS that needs some data files to have exactly 80 bytes in every record 🤯. When you STOR a file onto a host like that, the FTP Server has to be able to pad each line or record out to 80 bytes, and then a later RETR of that file can't be strictly invertible 💀. Plot twist, but makes total sense 🌈.
4.1.2.5. Data Connection Management: RFC-959 Section 3.3 🔌
A User-FTP that uses STREAM mode SHOULD send a PORT command to assign a non-default data port before each transfer command is issued 🎀.
DISCUSSION: This is needed because of the long delay after a TCP connection closes before its socket pair can be reused, and FTP sessions want to allow multiple transfers 🕰️. You can skip the PORT command if you use a transfer mode other than stream, by leaving the data transfer connection open between transfers 🦋.
4.1.2.6. PASV Command: RFC-959 Section 4.1.2 🧭
A server-FTP MUST implement the PASV command 👑.
If multiple third-party transfers are going to happen in the same session, a new PASV command MUST be issued before each transfer command, so you get a unique port pair every time 💅.
IMPLEMENTATION: The format of the 227 reply to a PASV command is not well standardized, bestie 🙈. In particular, an FTP client can't assume that the parentheses shown on page 40 of RFC-959 will be there (in fact, Figure 3 on page 43 leaves them out) 😭. So a User-FTP program that interprets the PASV reply has to scan the reply for the first digit of the host and port numbers 🔍.
Note that the host number h1,h2,h3,h4 is the IP address of the server host sending the reply, and p1,p2 is the non-default data transfer port that PASV assigned 🌸.
4.1.2.7. LIST and NLST Commands: RFC-959 Section 4.1.3 📋
The data returned by an NLST command MUST contain only a simple list of legal pathnames, so the server can use them directly as the arguments of later data transfer commands for the individual files 💖.
The data returned by a LIST or NLST command SHOULD use an implied TYPE AN, unless the current type is EBCDIC, in which case an implied TYPE EN SHOULD be used 🌈.
DISCUSSION: Lots of FTP clients support macro-commands that get or put files matching a wildcard spec, using NLST to grab a list of pathnames 🧚. The "multiple-put" expansion happens locally on the client, but "multiple-get" needs the server to cooperate 🫶. Teamwork makes the dream work, fr fr ✨.
okay so the implied type for LIST and NLST exists so it plays nice with existing User-FTPs, especially the ones that send multiple-get commands 🫶✨
4.1.2.8 SITE Command: RFC-959 Section 4.1.3
bestie, a Server-FTP SHOULD use the SITE command for non-standard features 💅 instead of making up new private commands or unstandardized extensions to existing ones. no side quests 🙅♀️
4.1.2.9 STOU Command: RFC-959 Section 4.1.3
the STOU command stores into a uniquely named file 🦋 when a Server-FTP gets an STOU, it MUST send back the actual file name in either the "125 Transfer Starting" or the "150 Opening Data Connection" message that comes right before the transfer. (the 250 reply code RFC-959 mentions is wrong, so ignore it 🙈) the exact format is defined as:
125 FILE: pppp
150 FILE: ppppwhere pppp is the unique pathname of the file that will be written 🌸
4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34
implementors MUST NOT assume any correspondence between READ boundaries on the control connection and the Telnet EOL sequences (CR LF) 💀
DISCUSSION: okay so a server-FTP (or User-FTP) has to keep reading characters from the control connection until it hits a complete Telnet EOL sequence, and only then process the command (or response). and the flip side is that one single READ might grab more than one FTP command at once 🧚✨
4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35
a Server-FTP MUST send only correctly formatted replies on the control connection 🎀 also, RFC-959 (unlike the earlier FTP specs) has no provision for a "spontaneous" reply message, so don't send one 🙅♀️
a Server-FTP SHOULD use the reply codes defined in RFC-959 whenever they apply 💖 but it MAY use a different reply code when it needs to, as long as it follows the general rules of Section 4.2. when there's a choice between a 4xx and a 5xx reply code, a Server-FTP SHOULD send the 4xx (temporary failure) code whenever there's any reasonable chance the failed FTP will succeed a few hours later ⏰
a User-FTP SHOULD generally look only at the highest-order digit of a 3-digit reply code when making a procedural decision 🧠 that way it doesn't break when a Server-FTP uses non-standard reply codes 🫶
a User-FTP MUST be able to handle multi-line replies 📜 if the implementation puts a limit on the number of lines and that limit gets exceeded, the User-FTP MUST recover, e.g., by ignoring the extra lines until the end of the multi-line reply shows up 🩹
a User-FTP SHOULD NOT interpret a 421 reply code ("Service not available, closing control connection") in any special way 🙅♀️ but it SHOULD detect when the server closes the control connection 🔌
DISCUSSION: ngl server implementations that don't strictly follow the reply rules make FTP user programs hang, and that's a whole mess 😭 RFC-959 cleared up the ambiguities in the reply rules from earlier FTP specs, so it MUST be followed. (lowercase "must" in the original, but the vibe is the same 💅)
it really matters that FTP reply codes tell temporary failures apart from permanent ones, so file transfer client daemons can actually use them 🌈 those programs check the reply codes to decide whether to retry a failed transfer, and if you send a permanent failure code (5xx) for a temporary error, they'll give up way too early 💔
when a reply means exactly what the RFC-959 text says, it's nicer for everyone to use the RFC-959 text word for word ✨ still, a Server-FTP implementor is encouraged to pick reply text that includes system-dependent info when that's useful 🔥
4.1.2.12 Connections: RFC-959 Section 5.2
the words "and the port used" in the second paragraph of this section of RFC-959 are erroneous (historical) 🕰️ so just ignore them 💅
on a multihomed server host, the default data transfer port (L-1) MUST be associated with the same local IP address as the matching control connection to port L 🏠
a user-FTP MUST NOT send any Telnet controls other than SYNCH and IP on an FTP control connection 🚫 and it especially MUST NOT try to negotiate Telnet options on the control connection 🙈 a server-FTP, though, MUST be able to accept and refuse Telnet negotiations (aka sending DONT/WONT) 🫡
DISCUSSION: okay so RFC-959 says: "Server- and User- processes should follow the conventions for the Telnet protocol...[on the control connection]". but the intent was never that Telnet option negotiation gets used here 🤷♀️
4.1.2.13 Minimum Implementation; RFC-959 Section 5.1
the following commands and options MUST be supported by every server-FTP and user-FTP 👑 the only exception is when the underlying file system or operating system doesn't allow or support a particular command:
Type: ASCII Non-print, IMAGE, LOCAL 8
Mode: Stream
Structure: File, Record*
Commands:
USER, PASS, ACCT,
PORT, PASV,
TYPE, MODE, STRU,
RETR, STOR, APPE,
RNFR, RNTO, DELE,
CWD, CDUP, RMD, MKD, PWD,
LIST, NLST,
SYST, STAT,
HELP, NOOP, QUIT.*Record structure is REQUIRED only for hosts whose file systems support record structure 📂
DISCUSSION: vendors are encouraged to go bigger than this list 🚀 there are some seriously important robustness features (like Restart, ABOR, and block mode) that would help some Internet users but aren't widely implemented yet 🥺
a host whose file system has no record structures can still accept files with STRU R, storing the byte stream literally 🍓
4.1.3 SPECIFIC ISSUES
4.1.3.1 Non-standard Command Verbs
okay FTP lets you use "experimental" commands whose names start with "X" 🧚 if those commands ever get adopted as standards, there might still be existing implementations running on the "X" form. right now that's true for the directory commands 📁:
RFC-959 "Experimental"
MKD XMKD
RMD XRMD
PWD XPWD
CDUP XCUP
CWD XCWDall FTP implementations SHOULD recognize both forms of these commands 💖 the easiest way is to just treat them as extra entries in the command lookup table ✨
IMPLEMENTATION: a User-FTP can reach a server that only supports the "X" forms by adding a mode switch 🔀 or by doing it automatically with this procedure: if the RFC-959 form of one of those commands gets rejected with a 500 or 502 response code, try the experimental form instead. any other response just gets passed along to the user 🫶
4.1.3.2 Idle Timeout
a Server-FTP process SHOULD have an idle timeout ⏳ it terminates the process and closes the control connection if the server has been inactive (no command or data transfer going on) for a long time 😴 the idle timeout SHOULD be configurable, and the default should be at least 5 minutes ⏱️
a client FTP process ("User-PI" in RFC-959) only needs timeouts on responses if a program invoked it 🤖
DISCUSSION: without a timeout, a Server-FTP process could sit pending forever if its client crashes without closing the control connection 💀
4.1.3.3 Concurrency of Data and Control
DISCUSSION: the FTP designers intended that a user can send a STAT command at any time while a data transfer is running 📊 the server-FTP would reply right away with status, like how many bytes have transferred so far. an ABOR command should also be possible at any time during a data transfer 🛑
unfortunately some small-machine operating systems make that kind of concurrent programming hard 😵💫 and some implementers go for minimal solutions, so some FTP implementations don't allow the data and control connections to be used at the same time. even a minimal server must be prepared to accept and defer a STAT or ABOR command that shows up during a data transfer 🫡
4.1.3.4 FTP Restart Mechanism
the description of the 110 reply on pp. 40-41 of RFC-959 is incorrect 🙅♀️ here's the correct one. a restart reply message, sent over the control connection from the receiving FTP to the User-FTP, looks like this:
110 MARK ssss = rrrrwhere:
- ssss is a text string that showed up in a Restart Marker in the data stream and encodes a position in the sender's file system 📍
- rrrr encodes the matching position in the receiver's file system 📍
the encoding is specific to a particular file system and network implementation 🧩 it's always generated and interpreted by the same system, either the sender or the receiver.
when an FTP that implements restart receives a Restart Marker in the data stream, it SHOULD force the data up to that point to be written to stable storage before it encodes the matching position rrrr 💾 an FTP that sends Restart Markers MUST NOT assume 110 replies come back synchronously with the data. so it must not wait for a 110 reply before sending more data 🏃♀️💨
two new reply codes are defined here for errors that pop up when restarting a transfer 🆕
554 Requested action not taken: invalid REST parameter.a 554 reply may come back from an FTP service command that follows a REST command 🙃 it means the existing file at the Server-FTP can't be repositioned the way the REST asked for 🥲
The 555 reply is 555 Requested action not taken: type or stru mismatch. bestie, and it's basically the server going "hold up, your transfer settings don't match this file" 💅 It can show up after an APPE command, or after any FTP service command that comes right after a REST command. It means the current transfer parameters (type and stru) clash with what the existing file is like 🙈
DISCUSSION:
Okay, so the FTP Restart mechanism needs Block or Compressed mode for the data transfer ✨ That's how the Restart Markers get slipped into the data stream. And the markers can show up pretty rarely. Low frequency is totally fine 🦋
Restart Markers mark a spot in the data stream, but the receiver might be doing some transformation on the data as it saves it to stable storage 🤔 So the receiver's encoding has to include any state info needed to restart that transformation from any point in the FTP data stream. Here's an example: in TYPE A transfers, some receiver hosts turn CR LF pairs into a single LF character on disk. If a Restart Marker lands right between the CR and the LF, the receiver has to encode in rrrr that the transfer must restart in a "CR has been seen and discarded" state 😭
Also, the Restart Marker has to be encoded as a string of printable ASCII characters, no matter what type of data is being sent 🧚
RFC-959 says restart info goes back "to the user." Don't take that literally, bestie 🙈 In practice, the User-FTP should save the restart info (ssss,rrrr) in stable storage, like appending it to a restart control file. That file should be created empty when the transfer starts, and deleted automatically when the transfer finishes successfully. It's suggested that the file name be easy to spot, built from the name of the file being transferred and the remote host name. It's basically the same trick text editors use for naming "backup" files 💖
There are three cases for FTP restart, so let's go through them 👑
- User-to-Server Transfer
The User-FTP puts Restart Markers <ssss> at convenient places in the data stream. When the Server-FTP gets a Marker, it writes all prior data to disk, encodes its file system position and transformation state as rrrr, and sends back a 110 MARK ssss = rrrr reply over the control connection. The User-FTP then appends the pair (ssss,rrrr) to its restart control file.
To restart, the User-FTP grabs the last (ssss,rrrr) pair from the restart control file, repositions its local file system and transformation state using ssss, and sends REST rrrr to the Server-FTP. Iconic 🌸
- Server-to-User Transfer
The Server-FTP puts Restart Markers <ssss> at convenient places in the data stream. When the User-FTP gets a Marker, it writes all prior data to disk, encodes its file system position and transformation state as rrrr, and appends the pair (rrrr,ssss) to its restart control file.
To restart, the User-FTP grabs the last (rrrr,ssss) pair from the restart control file, repositions its local file system and transformation state using rrrr, and sends REST ssss to the Server-FTP. Notice the order flips here, so pay attention 👀
- Server-to-Server ("Third-Party") Transfer
The sending Server-FTP puts Restart Markers <ssss> at convenient places in the data stream. When it gets a Marker, the receiving Server-FTP writes all prior data to disk, encodes its file system position and transformation state as rrrr, and sends a 110 MARK ssss = rrrr reply over the control connection to the User. The User-FTP appends the pair (ssss,rrrr) to its restart control file.
To restart, the User-FTP grabs the last (ssss,rrrr) pair from the restart control file, sends REST ssss to the sending Server-FTP, and sends REST rrrr to the receiving Server-FTP. Two servers, two REST commands, zero drama 💅
4.1.4 FTP/USER INTERFACE ✨
This section is all about the user interface for a User-FTP program 🎀
4.1.4.1 Pathname Specification
Since FTP is meant for a heterogeneous environment, User-FTP implementations MUST support remote pathnames as arbitrary character strings, so their form and content aren't limited by the local operating system's conventions 🌈
DISCUSSION:
Remote pathnames can be any length, and all the printing ASCII characters plus space (0x20) must be allowed. RFC-959 lets a pathname contain any 7-bit ASCII character except CR or LF 🍓
4.1.4.2 "QUOTE" Command
A User-FTP program MUST implement a "QUOTE" command that passes an arbitrary character string to the server and displays all the resulting response messages to the user 🦋
To make "QUOTE" actually useful, a User-FTP SHOULD send transfer control commands to the server as the user types them, instead of saving everything up and only sending it when a data transfer starts. Main character energy 💜
DISCUSSION:
"QUOTE" is essential for reaching servers that need system-specific commands (like SITE or ALLO), or for trying new or optional features the User-FTP doesn't implement. For example, "QUOTE" can be used to send TYPE A T to hosts that need the print-file distinction, even if the User-FTP doesn't recognize that TYPE 🫶
4.1.4.3 Displaying Replies to User
A User-FTP SHOULD display the full text of every error reply message it gets. It SHOULD also have a "verbose" mode, where all the commands it sends and the full text and reply codes it gets are shown, for diagnosing problems 🔍
4.1.4.4 Maintaining Synchronization
The state machine in a User-FTP SHOULD be forgiving of missing and unexpected reply messages, so that it stays in command sync with the server 🧚♀️
4.1.5 FTP REQUIREMENTS SUMMARY 📋
Here's the start of the requirements summary table, bestie. It's a big one, so the rest is coming in the next part 🌸
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|eOkay bestie, the big matrix is here 💅🎀 Every row is a checkbox showing whether a feature is required, recommended, or optional, with the section it comes from. Ngl, the "x" columns are doing a lot of work 😭
-------------------------------------------|---------------|-|-|-|-|-|--
Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | |
File/Record transform invertible if poss. |4.1.2.4 | |x| | | |
User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | |
Server-FTP implement PASV |4.1.2.6 |x| | | | |
PASV is per-transfer |4.1.2.6 |x| | | | |
NLST reply usable in RETR cmds |4.1.2.7 |x| | | | |
Implied type for LIST and NLST |4.1.2.7 | |x| | | |
SITE cmd for non-standard features |4.1.2.8 | |x| | | |
STOU cmd return pathname as specified |4.1.2.9 |x| | | | |
Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x|
| | | | | | |
Server-FTP send only correct reply format |4.1.2.11 |x| | | | |
Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | |
New reply code following Section 4.2 |4.1.2.11 | | |x| | |
User-FTP use only high digit of reply |4.1.2.11 | |x| | | |
User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | |
User-FTP handle 421 reply specially |4.1.2.11 | | | |x| |
| | | | | | |
Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | |
User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x|
User-FTP negotiate Telnet options |4.1.2.12 | | | | |x|
Server-FTP handle Telnet options |4.1.2.12 |x| | | | |
Handle "Experimental" directory cmds |4.1.3.1 | |x| | | |
Idle timeout in server-FTP |4.1.3.2 | |x| | | |
Configurable idle timeout |4.1.3.2 | |x| | | |
Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | |
Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x|
| | | | | | |
Support TYPE: | | | | | | |
ASCII - Non-Print (AN) |4.1.2.13 |x| | | | |
ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | |
ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | |
EBCDIC - (any form) |959 3.1.1.2 | | |x| | |
IMAGE |4.1.2.1 |x| | | | |
LOCAL 8 |4.1.2.1 |x| | | | |
LOCAL m |4.1.2.1 | | |x| | |2
| | | | | | |
Support MODE: | | | | | | |
Stream |4.1.2.13 |x| | | | |
Block |959 3.4.2 | | |x| | |
| | | | | | |
Support STRUCTURE: | | | | | | |
File |4.1.2.13 |x| | | | |
Record |4.1.2.13 |x| | | | |3
Page |4.1.2.3 | | | |x| |
| | | | | | |
Support commands: | | | | | | |
USER |4.1.2.13 |x| | | | |
PASS |4.1.2.13 |x| | | | |
ACCT |4.1.2.13 |x| | | | |
CWD |4.1.2.13 |x| | | | |
CDUP |4.1.2.13 |x| | | | |
SMNT |959 5.3.1 | | |x| | |
REIN |959 5.3.1 | | |x| | |
QUIT |4.1.2.13 |x| | | | |
| | | | | | |
PORT |4.1.2.13 |x| | | | |
PASV |4.1.2.6 |x| | | | |
TYPE |4.1.2.13 |x| | | | |1
STRU |4.1.2.13 |x| | | | |1
MODE |4.1.2.13 |x| | | | |1
| | | | | | |
RETR |4.1.2.13 |x| | | | |
STOR |4.1.2.13 |x| | | | |
STOU |959 5.3.1 | | |x| | |
APPE |4.1.2.13 |x| | | | |
ALLO |959 5.3.1 | | |x| | |
REST |959 5.3.1 | | |x| | |
RNFR |4.1.2.13 |x| | | | |
RNTO |4.1.2.13 |x| | | | |
ABOR |959 5.3.1 | | |x| | |
DELE |4.1.2.13 |x| | | | |
RMD |4.1.2.13 |x| | | | |
MKD |4.1.2.13 |x| | | | |
PWD |4.1.2.13 |x| | | | |
LIST |4.1.2.13 |x| | | | |
NLST |4.1.2.13 |x| | | | |
SITE |4.1.2.8 | | |x| | |
STAT |4.1.2.13 |x| | | | |
SYST |4.1.2.13 |x| | | | |
HELP |4.1.2.13 |x| | | | |
NOOP |4.1.2.13 |x| | | | |
| | | | | | |
User Interface: | | | | | | |
Arbitrary pathnames |4.1.4.1 |x| | | | |
Implement "QUOTE" command |4.1.4.2 |x| | | | |
Transfer control commands immediately |4.1.4.2 | |x| | | |
Display error messages to user |4.1.4.3 | |x| | | |
Verbose mode |4.1.4.3 | |x| | | |
Maintain synchronization with server |4.1.4.4 | |x| | | |Footnotes, so you don't miss the good bits 🧚
(1) For the values shown earlier.
(2) Here m is number of bits in a memory word.
That's the matrix, babe 🦋 Every column is a little yes-or-no for each feature, and the footnotes explain the stuff that needs context 💜
(3) Required for host with record-structured file system, optional otherwise. 🎀
4.2. TRIVIAL FILE TRANSFER PROTOCOL -- TFTP 🦋
4.2.1. INTRODUCTION
okay so the Trivial File Transfer Protocol (TFTP) is defined in RFC-783 [TFTP:1] ✨
TFTP handles its own reliable delivery over UDP as its transport, using a simple stop-and-wait acknowledgment system 💅 It has an effective window of only one 512 octet segment, so it can only perform well over paths with a small delay*bandwidth product 🙈 The file interface is super simple, with no access control or security at all 💀
TFTP's most iconic use is bootstrapping a host over a local network, since it's simple and small enough to be easily implemented in EPROM [BOOT:1, BOOT:2] 🚀 Vendors are urged to support TFTP for booting 🫶
4.2.2. PROTOCOL WALK-THROUGH
The TFTP specification [TFTP:1] is written in an open style, and does not fully specify many parts of the protocol 🧐
4.2.2.1. Transfer Modes: RFC-783, Page 3
The transfer mode "mail" SHOULD NOT be supported. 🙅♀️
4.2.2.2. UDP Header: RFC-783, Page 17
The Length field of a UDP header is incorrectly defined; it includes the UDP header length (8). 🤓
4.2.3. SPECIFIC ISSUES
4.2.3.1. Sorcerer's Apprentice Syndrome
bestie, there's a serious bug in the protocol spec called the "Sorcerer's Apprentice Syndrome" 😭 It doesn't break the transfer (if the transfer finishes, the file always arrives correctly), but it can cause excessive retransmission, which can make the transfer time out.
Implementations MUST contain the fix for this problem: the sender (i.e., the side originating the DATA packets) must never resend the current DATA packet on receipt of a duplicate ACK. 🔥
Heads up: this one is a must-fix. The sender can't resend the current DATA packet just because a duplicate ACK showed up.
DISCUSSION:
The bug comes from the protocol rule that either side, on receiving an old duplicate datagram, may resend the current datagram 🌀 If a packet gets delayed in the network but is still delivered later, after either side has timed out and retransmitted a packet, a duplicate copy of the response can be generated. If the other side answers that duplicate with a duplicate of its own, then every datagram gets sent twice for the rest of the transfer (unless a datagram is lost, which breaks the repetition). Worse yet, since the delay is often caused by congestion, this duplicate transmission usually causes even more congestion, which leads to more delayed packets, and so on and so on 😩
Here's an example to make it click ✨
TFTP A TFTP B
(1) Receive ACK X-1
Send DATA X
(2) Receive DATA X
Send ACK X
(ACK X is delayed in network,
and A times out):
(3) Retransmit DATA X
(4) Receive DATA X again
Send ACK X again
(5) Receive (delayed) ACK X
Send DATA X+1
(6) Receive DATA X+1
Send ACK X+1
(7) Receive ACK X again
Send DATA X+1 again
(8) Receive DATA X+1 again
Send ACK X+1 again
(9) Receive ACK X+1
Send DATA X+2
(10) Receive DATA X+2
Send ACK X+3
(11) Receive ACK X+1 again
Send DATA X+2 again
(12) Receive DATA X+2 again
Send ACK X+3 againNotice that once the delayed ACK arrives, the protocol settles down to duplicate all further packets (sequences 5-8 and 9-12) 👀 The problem isn't caused by either side timing out. It's caused by both sides retransmitting the current packet when they receive a duplicate.
The fix is to break the retransmission loop, as described above 💖 This is analogous to how TCP behaves. Once that's done, the retransmission timer on the receiver can be removed, since the resent ACK will never cause any action. That's a useful simplification where TFTP is used in a bootstrap program ✨ It's OK to keep the timer, though, and it may help if the retransmitted ACK replaces one that was genuinely lost in the network. The sender still requires a retransmit timer, of course 🫶
4.2.3.2. Timeout Algorithms
A TFTP implementation MUST use an adaptive timeout. ⏱️
IMPLEMENTATION:
TCP retransmission algorithms are a useful base to work from 🌸 At least an exponential backoff of retransmission timeout is necessary.
4.2.3.3. Extensions
A bunch of non-standard extensions have been made to TFTP, including extra transfer modes and a secure operation mode (with passwords) 🧩 None of these have been standardized, so they're a bit of a wild card 🃏
4.2.3.4. Access Control
A server TFTP implementation SHOULD include some configurable access control over what pathnames are allowed in TFTP operations. 🔐
4.2.3.5. Broadcast Request
A TFTP request directed to a broadcast address SHOULD be silently ignored. 🙈
DISCUSSION:
Because TFTP's access control is so weak, directed broadcasts of TFTP requests to random networks could create a significant security hole 🚨 This one is not a vibe, it's a real risk.
4.2.4. TFTP REQUIREMENTS SUMMARY
Here's the whole TFTP checklist in one table, so you can see everything at a glance 📋
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-------------------------------------------------|--------|-|-|-|-|-|--
Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | |
Transfer modes: | | | | | | |
netascii |RFC-783 |x| | | | |
octet |RFC-783 |x| | | | |
mail |4.2.2.1 | | | |x| |
extensions |4.2.3.3 | | |x| | |
Use adaptive timeout |4.2.3.2 |x| | | | |
Configurable access control |4.2.3.4 | |x| | | |
Silently ignore broadcast request |4.2.3.5 | |x| | | |
-------------------------------------------------|--------|-|-|-|-|-|--
-------------------------------------------------|--------|-|-|-|-|-|--5. ELECTRONIC MAIL -- SMTP and RFC-822 📬
5.1. INTRODUCTION
In the TCP/IP protocol suite, electronic mail in a format specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1] 💌
SMTP has stayed unchanged over the years, but the Internet community has changed the way SMTP gets used 🔄 In particular, the move to the Domain Name System (DNS) has changed address formats and mail routing. In this section, we assume you already know the concepts and terminology of the DNS, whose requirements are given in Section 6.1 🧠
RFC-822 specifies the Internet standard format for electronic mail messages 💅 It supersedes an older standard, RFC-733, which may still be in use in a few places even though it's obsolete. People sometimes just call the two formats by number ("822" and "733") 🔢
RFC-822 is also used in some non-Internet mail environments with different mail transfer protocols than SMTP, and SMTP has been adapted for some non-Internet environments too 🌍 Just note that this document only presents the rules for using SMTP and RFC-822 in the Internet environment. Other mail environments that use these protocols are expected to have their own rules 🫶
5.2. PROTOCOL WALK-THROUGH
This section covers both RFC-821 and RFC-822 ✨
The SMTP specification in RFC-821 is clear and has tons of examples, so implementors shouldn't find it hard to understand 🙌 This section just updates or annotates parts of RFC-821 to match current usage.
RFC-822 is a long and dense document with a rich syntax 😵💫 Unfortunately, incomplete or defective implementations of RFC-822 are common. In fact, nearly all of the many RFC-822 formats are actually used, so an implementation generally needs to recognize and correctly interpret all of the RFC-822 syntax 💀
5.2.1. The SMTP Model: RFC-821 Section 2
DISCUSSION:
Mail gets sent through a series of request/response transactions between a client, the "sender-SMTP," and a server, the "receiver-SMTP" 📨 These transactions pass (1) the message proper, which is made of a header and a body, and (2) the SMTP source and destination addresses, called the "envelope" 💜
The SMTP programs are analogous to the Message Transfer Agents (MTAs) of X.400 🛰️ There's another layer of protocol software, closer to the end user, that's responsible for composing and analyzing RFC-822 message headers. In X.400 this is called the "User Agent," and we use that term in this document 🎀 There's a clear logical distinction between the User Agent and the SMTP implementation, since they operate on different levels of protocol. Note, however, that this distinction may not be exactly reflected in the structure of typical Internet mail implementations 🤷♀️ Often there's a program known as the "mailer" that implements SMTP and also some of the User Agent functions, and the rest of the User Agent functions live in a user interface for writing and reading mail 💖
The SMTP envelope gets built at the originating site 💌, usually by the User Agent right when the message is first queued for the Sender-SMTP program. The envelope addresses can come from the message header, from whatever the user interface supplies (like a bcc: request 👀), or from local configuration (like expanding a mailing list 📬). Here's the tea: the envelope can't generally be re-derived from the header later in delivery, so it gets sent separately from the message itself, using the MAIL and RCPT commands of SMTP 🫶.
The text of RFC-821 kinda suggests mail goes to an individual user at a host. But with the domain system and mail routing through mail-exchange (MX) resource records, implementors should now think of delivering mail to a user at a domain, which may or may not be a particular host 🌐. This does not change the fact that SMTP is a host-to-host mail exchange protocol 💅.
5.2.2. Canonicalization: RFC-821 Section 3.1 ✨
The domain names a Sender-SMTP sends in MAIL and RCPT commands MUST have been "canonicalized," which means they must be fully-qualified principal names or domain literals, not nicknames or domain abbreviations 🧾. A canonicalized name either identifies a host directly or is an MX name, and it cannot be a CNAME 🚫.
5.2.3. VRFY and EXPN Commands: RFC-821 Section 3.3 🔍
A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN (this requirement overrides RFC-821). However, there MAY be configuration information to disable VRFY and EXPN in a particular installation, and this might even let EXPN be disabled for selected lists 🙅.
A new reply code is defined for the VRFY command:
252 Cannot VRFY user (e.g., info is not local), but will
take message for this user and attempt delivery.DISCUSSION:
SMTP users and administrators use these commands all the time to diagnose mail delivery problems 🛠️. With multi-level mailing list expansion getting more common (sometimes more than two levels deep), EXPN has become really important for spotting accidental mail loops 🔁. On the other hand, some people feel that EXPN is a significant privacy, and maybe even a security, exposure 👀.
5.2.4. SEND, SOML, and SAML Commands: RFC-821 Section 3.4 📟
An SMTP MAY implement the commands for sending a message to a user's terminal: SEND, SOML, and SAML 💬.
DISCUSSION:
It's been suggested that relaying mail through an MX record clashes with the purpose of SEND, which is to deliver a message immediately and directly to a user's terminal 🤔. However, an SMTP receiver that can't write directly to the user's terminal can answer the RCPT following a SEND with 251 User Not Local, which tells the sender that delivery might be deferred 📥.
5.2.5. HELO Command: RFC-821 Section 3.5 👋
The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. That way, the receiver-SMTP won't have to do MX resolution on this name to validate the HELO parameter 🙌.
The HELO receiver MAY verify that the HELO parameter really matches the IP address of the sender. However, the receiver MUST NOT refuse to accept a message just because the sender's HELO command fails verification 💖.
DISCUSSION:
Checking the HELO parameter needs a domain name lookup, so it can take a while ⏳. A different tool for tracking bogus mail sources is suggested below (see "DATA Command").
Also, the HELO argument still has to have valid <domain> syntax, because it ends up in a Received: line. Otherwise, a 501 error is sent 🚨.
IMPLEMENTATION:
When HELO parameter validation fails, a suggested move is to add a note about the sender's unknown authenticity into the message header (for example, in the Received: line) 📝.
5.2.6. Mail Relay: RFC-821 Section 3.6 🔁
We distinguish three types of mail (store-and-) forwarding 🧚:
- A simple forwarder or "mail exchanger" forwards a message using private knowledge about the recipient; see section 3.2 of RFC-821.
- An SMTP mail "relay" forwards a message within an SMTP mail environment as the result of an explicit source route (as defined in section 3.6 of RFC-821). The SMTP relay function uses the
"@...:"form of source route from RFC-822 (see Section 5.2.19 below). - A mail "gateway" passes a message between different environments. The rules for mail gateways are discussed below in Section 5.3.7.
An Internet host that forwards a message but is not a gateway to a different mail environment (so it falls under (1) or (2)) SHOULD NOT alter any existing header fields. It will still add an appropriate Received: line, as required in Section 5.2.8 🎀.
A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an explicit source route using the "@...:" address form. So the relay function defined in section 3.6 of RFC-821 shouldn't be used 🙅♀️.
DISCUSSION:
The goal is to discourage all source routing and to abolish explicit source routing for mail delivery within the Internet environment 🌸. Source routing isn't necessary, because the simple target address user@domain should always be enough. This comes from a deliberate architectural decision to use universal naming instead of source routing for mail. So SMTP gives end-to-end connectivity, and the DNS gives globally-unique, location-independent names 🌍. MX records handle the main case where source routing might otherwise be needed.
A receiver-SMTP MUST accept the explicit source route syntax in the envelope, but it MAY implement the relay function as defined in section 3.6 of RFC-821. If it doesn't implement the relay function, it SHOULD attempt to deliver the message directly to the host to the right of the right-most "@" sign 🎯.
DISCUSSION:
Say a host that doesn't implement the relay function gets a message with the SMTP command RCPT TO:<@ALPHA,@BETA:joe@GAMMA>, where ALPHA, BETA, and GAMMA are domain names. Instead of immediately refusing it with a 550 error reply, as suggested on page 20 of RFC-821, the host should try to forward the message to GAMMA directly, using RCPT TO:<joe@GAMMA> 🚀. Since this host doesn't support relaying, it is not required to update the reverse path.
Some people have suggested that source routing might sometimes be needed to route mail manually around failures, but how real and important that need is remains controversial 🤷. Using explicit SMTP mail relaying for this is discouraged, and it may not even work, since many host systems don't support it 🙃. Some have used the "%-hack" (see Section 5.2.16) for this purpose.
5.2.7. RCPT Command: RFC-821 Section 4.1.1 📬
A host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster" 📮.
The receiver-SMTP MAY verify RCPT parameters as they arrive. However, RCPT responses MUST NOT be delayed beyond a reasonable time (see Section 5.3.2) ⏰.
So a 250 OK response to a RCPT doesn't necessarily mean the delivery address(es) are valid. Errors found after the message is accepted will be reported by mailing a notification message to an appropriate address (see Section 5.3.3) 💌.
DISCUSSION:
When a RCPT parameter can be validated right away is an engineering design choice 🧠. Reporting destination mailbox errors to the Sender-SMTP before mail is transferred is usually worth it, since it saves time and network bandwidth, but that advantage disappears if RCPT verification takes forever 🐢.
For example, the receiver can verify any simple local reference right away, like a single locally-registered mailbox 🏠. The "reasonable time" limit usually means verifying a mailing list gets deferred until after the message has been transferred and accepted, because checking a big list can take ages 📋. An implementation might or might not defer validation of non-local addresses that need a DNS lookup. If a DNS lookup is performed but a soft domain system error (e.g., timeout) occurs, validity must be assumed 🫠.
5.2.8. DATA Command: RFC-821 Section 4.1.1 📦
Every receiver-SMTP (not just one that "accepts a message for relaying or for final delivery" [SMTP:1]) MUST insert a "Received:" line at the beginning of a message. This line is called a "time stamp line" in RFC-821 ⏱️:
- The FROM field SHOULD contain both (1) the name of the source host as presented in the HELO command and (2) a domain literal containing the IP address of the source, determined from the TCP connection.
- The ID field MAY contain an "@" as suggested in RFC-822, but this is not required.
- The FOR field MAY contain a list of
<path>entries when multiple RCPT commands have been given.
An Internet mail program MUST NOT change a Received: line that was previously added to the message header 🔒.
DISCUSSION:
Including both the source host and the IP source address in the Received: line may give enough info to track illicit mail sources, and it removes the need to explicitly verify the HELO parameter 🕵️.
Received: lines are mainly for humans tracing mail routes, mostly to diagnose faults 🧑💻. See also the discussion under 5.3.7.
When the receiver-SMTP makes "final delivery" of a message, it MUST pass the MAIL FROM: address from the SMTP envelope along with the message, so it can be used if an error notification message has to be sent later (see Section 5.3.3). There's an analogous requirement when gatewaying from the Internet into a different mail environment; see Section 5.3.7 🌈✨ okay that's the whole vibe ✨🌈
DISCUSSION: Okay so the final reply to the DATA command only depends on the message being successfully transferred and stored 💌✨ Any problem with the destination address(es) has to either (1) show up in an SMTP error reply to the RCPT command(s), or (2) get reported in a later error message mailed back to the originator 🫶
IMPLEMENTATION: The MAIL FROM: info can be passed as a parameter, or tucked into a Return-Path: line at the very top of the message 🎀
5.2.9 Command Syntax: RFC-821 Section 4.1.2 💅
The RFC-821 syntax for the MAIL FROM: command skips the empty path case, which is MAIL FROM: <> (see RFC-821 Page 15) 🙈 An empty reverse path MUST be supported, no excuses 💖
5.2.10 SMTP Replies: RFC-821 Section 4.2 🦋
A receiver-SMTP SHOULD send only the reply codes listed in section 4.2.2 of RFC-821 or in this document. It also SHOULD use the text shown in the RFC-821 examples whenever that makes sense ✨
A sender-SMTP MUST decide what to do only by the reply code, not the text (except for 251 and 551 replies). Any text, including no text at all, must be acceptable 🌈 The space (blank) after the reply code counts as part of the text, fyi. Whenever possible, a sender-SMTP SHOULD test only the first digit of the reply code, as specified in Appendix E of RFC-821 🔥
DISCUSSION: Interoperability problems have shown up with SMTP systems using reply codes that aren't explicitly listed in RFC-821 Section 4.3, but are still legal according to the theory of reply codes in Appendix E 😭
5.2.11 Transparency: RFC-821 Section 4.5.2 🧚
Implementors MUST be sure that their mail systems always add and delete periods, so message transparency stays intact 💜
5.2.12 WKS Use in MX Processing: RFC-974, p. 5 🍓
RFC-974 [SMTP:3] recommended querying the domain system for WKS ("Well-Known Service") records, to verify that each proposed mail target supports SMTP. Later experience showed that WKS isn't widely supported, so the WKS step in MX processing SHOULD NOT be used 🥲
The following are notes on RFC-822, organized by section of that document 📝
5.2.13 RFC-822 Message Specification: RFC-822 Section 4 💌
The Return-path line syntax leaves out the possibility of a null return path, which is used to stop error notifications from looping (see Section 5.3.3). The complete syntax is:
return = "Return-path" ":" route-addr
/ "Return-path" ":" "<" ">"The set of optional header fields is also expanded to include the Content-Type field defined in RFC-1049 [SMTP:7]. This field "allows mail reading systems to automatically identify the type of a structured message body and to process it for display accordingly". [SMTP:7] A User Agent MAY support this field 🎀
5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 🕰️
The date syntax is now:
date = 1*2DIGIT month 2*4DIGITAll mail software SHOULD use 4-digit years in dates, so the transition to the next century goes smoothly 🎉
There's a strong trend toward numeric timezone indicators, so implementations SHOULD use numeric timezones instead of timezone names 💅 However, all implementations MUST accept either notation. If timezone names are used, they MUST be exactly as defined in RFC-822 🫶
The military time zones are specified incorrectly in RFC-822: they count the wrong way from UT (the signs are reversed). As a result, military time zones in RFC-822 headers carry no information 💀
Finally, there's a typo in the definition of "zone" in the syntax summary of appendix D. The correct definition is in Section 3 of RFC-822 ✨
5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 🦋
The syntactic definition of "mailbox" in RFC-822 is now:
mailbox = addr-spec ; simple address
/ [phrase] route-addr ; name & addr-specSo the phrase before a route address is now OPTIONAL 👑 This change makes the following header field legal, for example:
From: <craig@nnsc.nsf.net>5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 🌸
The basic mailbox address format is local-part@domain. The "local-part", sometimes called the "left-hand side" of the address, is domain-dependent 🧠
A host that forwards a message without being the destination host implied by the right-hand side "domain" MUST NOT interpret or modify the "local-part" of the address 🙅♀️
When mail is gatewayed from the Internet mail environment into a foreign mail environment (see Section 5.3.7), routing information for that foreign environment MAY be embedded within the "local-part" of the address. The gateway then interprets this local part for the foreign mail environment 🚪
DISCUSSION: Source routes are discouraged within the Internet (see Section 5.2.6), but some non-Internet mail environments depend on them for delivery. Those source routes can usually be buried in the "local-part" of the address (see Section 5.2.16) while the mail travels across the Internet. When it reaches the right Internet mail gateway, the gateway interprets the local-part and builds the necessary address or route for the target mail environment 🛣️
For example, an Internet host might send mail to:
a!b!c!user@gateway-domainThe complex local part a!b!c!user would be left alone within the Internet domain, but the specified mail gateway could parse and understand it 🤓
An embedded source route is sometimes encoded in the "local-part" using "%" as a right-binding routing operator. For example:
user%domain%relay3%relay2@relay1The "%" convention means the mail is routed from "relay1" through "relay2", "relay3", and finally to "user" at "domain". This is commonly known as the "%-hack" 🫠 It's suggested that "%" have lower precedence than any other routing operator (e.g., "!") hidden in the local-part. For example, "a!b%c" would be interpreted as "(a!b)%c" 🧩
Only the target host (in this case, "relay1") is permitted to analyze the local-part user%domain%relay3%relay2 🔒
5.2.17 Domain Literals: RFC-822 Section 6.2.3 🧱
A mailer MUST be able to accept and parse an Internet domain literal whose content ("dtext"; see RFC-822) is a dotted-decimal host address. This satisfies the requirement of Section 2.1 for the case of mail 💌
An SMTP MUST accept and recognize a domain literal for any of its own IP addresses 🙌
5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 🙈
Errors in formatting or parsing 822 addresses are unfortunately common. This section only mentions the most common ones. A User Agent MUST accept all valid RFC-822 address formats, and MUST NOT generate illegal address syntax 😤
- A common error is to leave out the semicolon after a group identifier.
- Some systems fail to fully-qualify domain names in messages they generate. The right-hand side of an "@" sign in a header address field MUST be a fully-qualified domain name. For example, some systems fail to fully-qualify the
From:address, which stops a "reply" command in the user interface from automatically building a return address 😭
DISCUSSION: Although RFC-822 allows local use of abbreviated domain names within a domain, applying RFC-822 to Internet mail doesn't allow this. The intent is that an Internet host must not send an SMTP message header containing an abbreviated domain name in an address field. This lets the address fields of the header pass across the Internet without alteration, as required in Section 5.2.6 🌍
- Some systems mis-parse multiple-hop explicit source routes such as:
@relay1,@relay2,@relay3:user@domain.- Some systems over-qualify domain names by adding a trailing dot to some or all domain names in addresses or message-ids. This violates RFC-822 syntax 🙃
5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 🚫
Internet host software SHOULD NOT create an RFC-822 header containing an address with an explicit source route, but MUST accept such headers for compatibility with earlier systems 🕰️
DISCUSSION: RFC-822 says "The use of explicit source routing is discouraged", which is a big understatement 😂 Many hosts implemented RFC-822 source routes incorrectly, so the syntax can't be used unambiguously in practice. Lots of users think the syntax is ugly too. Explicit source routes aren't needed in the mail envelope for delivery (see Section 5.2.6). For all these reasons, explicit source routes using the RFC-822 notations are not to be used in Internet mail headers 🛑
As stated in Section 5.2.16, an explicit source route has to be allowed to be buried in the local-part of an address (e.g., using the "%-hack"), so mail can be gatewayed into another environment where explicit source routing is necessary. The vigilant will notice there's no way for a User Agent to detect and prevent this kind of implicit source routing when the destination is within the Internet. We can only discourage source routing of any kind within the Internet, since it's unnecessary and undesirable 🫶
5.3 SPECIFIC ISSUES 🌸
5.3.1 SMTP Queueing Strategies 📬
The common structure of a host SMTP implementation includes user mailboxes, one or more areas for queueing messages in transit, and one or more daemon processes for sending and receiving mail. The exact structure depends on the users on the host and the number and size of mailing lists the host supports. We describe several optimizations that have proved helpful, especially for mailers handling high traffic levels 🚀
Any queueing strategy MUST include:
- Timeouts on all activities. See Section 5.3.2.
- Never sending error messages in response to error messages. 🙅♀️
5.3.1.1. Sending Strategy ✨
okay so a sender-SMTP is basically one or more processes that keep checking for outgoing mail 💌 In a typical system, the program that writes the message has some way to say "hey, this one needs attention NOW," but any mail that can't go out right away MUST be queued and periodically retried by the sender. Each queue entry holds the message itself AND the envelope information, so nothing gets left behind 🎀
The sender MUST delay retrying a particular destination after one attempt has failed. The retry interval SHOULD be at least 30 minutes 🕰️ Smarter, more variable strategies are honestly iconic, though, when the sender-SMTP can figure out WHY delivery failed 🧠
Retries keep going until the message gets sent or the sender gives up. The give-up time generally needs to be at least 4-5 days 📅 The parameters to the retry algorithm MUST be configurable ⚙️
A sender SHOULD keep a list of hosts it cannot reach, along with corresponding timeouts, instead of just retrying every queued item over and over 🙅♀️
DISCUSSION:
Experience suggests that failures are usually transient (like the target system just crashed 💀), so the vibe is two connection attempts in the first hour the message is in the queue, then backing off to once every two or three hours 🦋
The sender-SMTP can shorten the queueing delay by cooperating with the receiver-SMTP. For example, if mail is received from a particular address, that's good evidence that any mail queued for that host can now be sent 💜
The strategy may be further modified because of multiple addresses per host (see Section 5.3.4), so delivery time and resource usage stay balanced ⚖️
A sender-SMTP may have a huge queue of messages for each unavailable destination host. If it retried all of them in every retry cycle, there would be excessive Internet overhead and the daemon would be blocked for a long period 😭 An SMTP can usually only figure out that a delivery attempt failed after a timeout of a minute or more, so a one minute timeout per connection adds up to a very large delay if it's repeated for dozens or even hundreds of queued messages 🙈
When the same message is going to several users on the same host, only one copy of the message SHOULD be transmitted. So the sender-SMTP should use the command sequence RCPT, RCPT,... RCPT, DATA instead of the sequence RCPT, DATA, RCPT, DATA,... RCPT, DATA. Implementing this efficiency feature is strongly urged 🫶
Similarly, the sender-SMTP MAY support multiple concurrent outgoing mail transactions for timely delivery. However, some limit SHOULD be imposed so the host doesn't devote ALL its resources to mail 🍓
The use of the different addresses of a multihomed host is discussed below 🌈
5.3.1.2. Receiving strategy 📥
The receiver-SMTP SHOULD attempt to keep a pending listen on the SMTP port at all times. This means supporting multiple incoming TCP connections for SMTP. Some limit MAY be imposed 🔒
IMPLEMENTATION:
When the receiver-SMTP receives mail from a particular host address, it could notify the sender-SMTP to retry any mail pending for that host address 🔔
5.3.2. Timeouts in SMTP ⏱️
There are two approaches to timeouts in the sender-SMTP: (a) limit the time for each SMTP command separately, or (b) limit the time for the entire SMTP dialogue for a single mail message. A sender-SMTP SHOULD use option (a), per-command timeouts. Timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code 💅
DISCUSSION:
Timeouts are an essential feature of an SMTP implementation 🔥 If they're too long (or worse, there are none), Internet communication failures or software bugs in receiver-SMTP programs can tie up SMTP processes forever. If they're too short, resources get wasted on attempts that time out partway through delivery 😤
If option (b) is used, the timeout has to be very large, e.g., an hour, so there's time to expand very large mailing lists 📬 The timeout may also need to increase linearly with the size of the message, to account for the time needed to transmit a very large message. A large fixed timeout causes two problems: a failure can still tie up the sender for a very long time, and very large messages may still time out spuriously (which is a wasteful failure!) 💀
With the recommended option (a), a timer is set for each SMTP command and for each buffer of the data transfer. The latter means the overall timeout is inherently proportional to the size of the message ✨
Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
- Initial 220 Message: 5 minutes
- A Sender-SMTP process needs to tell apart a failed TCP connection from a delay in receiving the initial 220 greeting message. Many receiver-SMTPs will accept a TCP connection but delay delivering the 220 message until their system load permits more mail to be processed 🐢
- MAIL Command: 5 minutes
- RCPT Command: 5 minutes
- A longer timeout would be required if processing of mailing lists and aliases were not deferred until after the message was accepted 📃
- DATA Initiation: 2 minutes
- This is while awaiting the "354 Start Input" reply to a DATA command 👀
- Data Block: 3 minutes
- This is while awaiting the completion of each TCP SEND call transmitting a chunk of data 📦
- DATA Termination: 10 minutes.
- This is while awaiting the "250 OK" reply. When the receiver gets the final period terminating the message data, it typically does processing to deliver the message to a user mailbox. A spurious timeout at this point would be very wasteful, since the message has already been successfully sent 🥲
A receiver-SMTP SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender ⏳
5.3.3. Reliable Mail Receipt 🛡️
When the receiver-SMTP accepts a piece of mail (by sending a 250 OK message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously, i.e., it MUST NOT lose the message for frivolous reasons, e.g., because the host later crashes or because of a predictable resource shortage 👑
If there is a delivery failure after the message is accepted, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null (<>) reverse path in the envelope; see Section 3.6 of RFC-821. The recipient of this notification SHOULD be the address from the envelope return path (or the Return-Path: line). However, if this address is null (<>), the receiver-SMTP MUST NOT send a notification. If the address is an explicit source route, it SHOULD be stripped down to its final hop 🗺️
DISCUSSION:
For example, suppose an error notification must be sent for a message that arrived with MAIL FROM:<@a,@b:user@d>. The notification message should be sent to RCPT TO:<user@d> 🧚
Some delivery failures after the message is accepted by SMTP will be unavoidable. For example, the receiver-SMTP might be unable to validate all the delivery addresses in RCPT command(s) because of a "soft" domain system error, or because the target is a mailing list (see earlier discussion of RCPT) 🙃
To avoid receiving duplicate messages as the result of timeouts, a receiver-SMTP MUST seek to minimize the time required to respond to the final "." that ends a message transfer. See RFC-1047 [SMTP:4] for a discussion of this problem 🔁
5.3.4. Reliable Mail Transmission 🚚
To transmit a message, a sender-SMTP determines the IP address of the target host from the destination address in the envelope. Specifically, it maps the string to the right of the "@" sign into an IP address. This mapping, or the transfer itself, may fail with a soft error, in which case the sender-SMTP will requeue the outgoing mail for a later retry, as required in Section 5.3.1.1 🔄
When it succeeds, the mapping can result in a list of alternative delivery addresses instead of a single address, because of (a) multiple MX records, (b) multihoming, or both. To provide reliable mail transmission, the sender-SMTP MUST be able to try (and retry) each of the addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, a host SHOULD try at least two addresses 🎯
The following information is used to rank the host addresses:
- Multiple MX Records -- these contain a preference indication that should be used in sorting. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by address preference), then the sender-SMTP SHOULD pick one at random to spread the load across multiple mail exchanges for a specific organization. Note that this is a refinement of the procedure in [DNS:3] 🎲
- Multihomed host -- The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface (see Section 6.1.3.4 below) to have ordered this list by decreasing preference, and SMTP MUST try them in the order presented 🌸
DISCUSSION: okay so even though trying multiple alternative addresses is required 💅, some installations might want to limit or turn off alternative addresses 🙈. Whether a sender should retry using the different addresses of a multihomed host has been a total drama 🍿. The main argument for using them is that it maximizes the chance of timely delivery, and sometimes even any delivery at all ✨. The counterargument is that it can lead to unnecessary resource use 💀.
Note that resource use is also heavily shaped by the sending strategy in Section 5.3.1 🎀.
5.3.5. Domain Name Support
SMTP implementations MUST use the mechanism defined in Section 6.1 for mapping between domain names and IP addresses. Translation: every Internet SMTP MUST include support for the Internet DNS 🌐🫶.
Specifically, a sender-SMTP MUST support the MX record scheme [SMTP:3] 💖. See also Section 7.4 of [DNS:2] for more info on domain name support for SMTP 🧚.
5.3.6. Mailing Lists and Aliases
An SMTP-capable host SHOULD support both the alias and the list form of address expansion for multiple delivery 🦋. When a message gets delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to the address of a person who administers the list 👑, but the message header MUST be left unchanged. So the "From" field of the message is unaffected 🙌.
DISCUSSION: the big mail feature here is multi-destination delivery, where one message gets sent to lots of people by "expanding" a pseudo-mailbox address into a list of real mailbox addresses 📬✨. When a message goes to one of these pseudo-mailboxes (sometimes called an "exploder" 💅), copies get forwarded or redistributed to each mailbox on the expanded list. We sort these into two types, depending on how the expansion works 🌸:
(a) Alias
To expand an alias, the recipient mailer just swaps the pseudo-mailbox address in the envelope for each expanded address, one at a time 🔁. The rest of the envelope and the message body stay unchanged. The message then gets delivered or forwarded to each expanded address 🎀.
(b) List
A mailing list can be said to work by "redistribution" instead of "forwarding" 🌈. To expand a list, the recipient mailer swaps the pseudo-mailbox address in the envelope for each expanded address, one at a time. The return address in the envelope gets changed so that every error message from the final deliveries goes to a list administrator, not the message originator 😭. The originator generally has no control over the list contents and would find those error messages super annoying 🙈.
5.3.7. Mail Gatewaying
Gatewaying mail between different mail environments (different mail formats and protocols) is complex and doesn't easily standardize 😵💫. See, for example, [SMTP:5a] and [SMTP:5b] 📚. Still, there are some general requirements for a gateway between the Internet and another mail environment 💜.
(A) Header fields MAY be rewritten when necessary as messages are gatewayed across mail environment boundaries 🦋.
DISCUSSION: this can involve interpreting the local-part of the destination address, as suggested in Section 5.2.16 🧐.
Other mail systems gatewayed to the Internet usually use a subset of RFC-822 headers, but some of them don't have an equivalent to the SMTP envelope 🥺. So when a message leaves the Internet environment, it may be necessary to fold the SMTP envelope information into the message header 📦. One idea is to make new header fields to carry the envelope info (like "X-SMTP-MAIL:" and "X-SMTP-RCPT:") 💌. The catch is that this would require changes in mail programs in the foreign environment 😩.
(B) When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header 🚫✋.
DISCUSSION: this is basically a subset of the general "Received:" line requirement in Section 5.2.8, restated here for emphasis 📢.
Received: fields from messages originating in other environments may not conform exactly to RFC822 🌀. But the most important use of Received: lines is debugging mail faults, and that debugging gets seriously hampered by well-meaning gateways that try to "fix" a Received: line 🙈🔧. The gateway is strongly encouraged to name the environment and protocol in the "via" clauses of the Received field(s) it supplies 🫶.
(C) From the Internet side, the gateway SHOULD accept all valid address formats in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages ✅. Although a gateway must accept an RFC-822 explicit source route ("@...:" format) in either the header or the envelope, it MAY or may not act on the source route. See Sections 5.2.6 and 5.2.19 🗺️.
DISCUSSION: it's super tempting to restrict the range of addresses accepted at the mail gateway to make translation easier 🙃. That's based on the assumption that mail users control the addresses their mailers send to the gateway. In reality, users have very little control over the addresses that finally get sent 🫠. Their mailers are free to change addresses into any legal RFC-822 format 💅.
(D) The gateway MUST ensure that all header fields of a message it forwards into the Internet meet the requirements for Internet mail 📮. In particular, all addresses in "From:", "To:", "Cc:", etc. fields must be transformed (if necessary) to satisfy RFC-822 syntax, and they must be effective and useful for sending replies 💌.
(E) The translation algorithm used to convert mail from Internet protocols to another environment's protocol SHOULD try to make sure error messages from the foreign mail environment go to the return path from the SMTP envelope, not to the sender listed in the "From:" field of the RFC-822 message 🚨.
DISCUSSION: Internet mail lists usually put the list maintainer's address in the envelope but leave the original header intact (with "From:" showing the original sender) 💖. That gives the behavior the average recipient expects: a reply to the header goes to the original sender, not the list maintainer 🙌. Errors, though, go to the maintainer, who can fix the problem, and not to the sender, who probably can't 🛠️✨.
(F) Similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path to match an error message return address, if any, supplied by the foreign environment 🦋.
5.3.8. Maximum Message Size
Mailer software MUST be able to send and receive messages of at least 64K bytes in length (including header), and a much larger maximum size is highly desirable 📏💜.
DISCUSSION: SMTP doesn't define a maximum message size, but lots of systems impose implementation limits 🙃.
The current de facto minimum limit on the Internet is 64K bytes 📐. But email gets used for all kinds of purposes that create way bigger messages 🤯. For example, mail is often used instead of FTP to transmit ASCII files, especially entire documents 📄. So messages can be 1 megabyte or even larger 💅. We also note that this document, together with its lower-layer companion, is 0.5 megabytes 🥹.
5.4. SMTP REQUIREMENTS SUMMARY ✨
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|eokay the SMTP checklist is literally a whole vibe 💅 here's the full table, unchanged:
-----------------------------------------------|----------|-|-|-|-|-|--
| | | | | | |
RECEIVER-SMTP: | | | | | | |
Implement VRFY |5.2.3 |x| | | | |
Implement EXPN |5.2.3 | |x| | | |
EXPN, VRFY configurable |5.2.3 | | |x| | |
Implement SEND, SOML, SAML |5.2.4 | | |x| | |
Verify HELO parameter |5.2.5 | | |x| | |
Refuse message with bad HELO |5.2.5 | | | | |x|
Accept explicit src-route syntax in env. |5.2.6 |x| | | | |
Support "postmaster" |5.2.7 |x| | | | |
Process RCPT when received (except lists) |5.2.7 | | |x| | |
Long delay of RCPT responses |5.2.7 | | | | |x|
| | | | | | |
Add Received: line |5.2.8 |x| | | | |
Received: line include domain literal |5.2.8 | |x| | | |
Change previous Received: line |5.2.8 | | | | |x|
Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | |
Support empty reverse path |5.2.9 |x| | | | |
Send only official reply codes |5.2.10 | |x| | | |
Send text from RFC-821 when appropriate |5.2.10 | |x| | | |
Delete "." for transparency |5.2.11 |x| | | | |
Accept and recognize self domain literal(s) |5.2.17 |x| | | | |
| | | | | | |
Error message about error message |5.3.1 | | | | |x|
Keep pending listen on SMTP port |5.3.1.2 | |x| | | |
Provide limit on recv concurrency |5.3.1.2 | | |x| | |
Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | |
Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x|
Send error notification msg after accept |5.3.3 |x| | | | |
Send using null return path |5.3.3 |x| | | | |
Send to envelope return path |5.3.3 | |x| | | |
Send to null address |5.3.3 | | | | |x|
Strip off explicit src route |5.3.3 | |x| | | |
Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | |
-----------------------------------------------|----------|-|-|-|-|-|--
| | | | | | |
SENDER-SMTP: | | | | | | |
Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | |
Implement SEND, SOML, SAML |5.2.4 | | |x| | |
Send valid principal host name in HELO |5.2.5 |x| | | | |
Send explicit source route in RCPT TO: |5.2.6 | | | |x| |
Use only reply code to determine action |5.2.10 |x| | | | |
Use only high digit of reply code when poss. |5.2.10 | |x| | | |
Add "." for transparency |5.2.11 |x| | | | |
| | | | | | |
Retry messages after soft failure |5.3.1.1 |x| | | | |
Delay before retry |5.3.1.1 |x| | | | |
Configurable retry parameters |5.3.1.1 |x| | | | |
Retry once per each queued dest host |5.3.1.1 | |x| | | |
Multiple RCPT's for same DATA |5.3.1.1 | |x| | | |
Support multiple concurrent transactions |5.3.1.1 | | |x| | |
Provide limit on concurrency |5.3.1.1 | |x| | | |
| | | | | | |
Timeouts on all activities |5.3.1 |x| | | | |
Per-command timeouts |5.3.2 | |x| | | |
Timeouts easily reconfigurable |5.3.2 | |x| | | |
Recommended times |5.3.2 | |x| | | |
Try alternate addr's in order |5.3.4 |x| | | | |
Configurable limit on alternate tries |5.3.4 | | |x| | |
Try at least two alternates |5.3.4 | |x| | | |
Load-split across equal MX alternates |5.3.4 | |x| | | |
Use the Domain Name System |5.3.5 |x| | | | |
Support MX records |5.3.5 |x| | | | |
Use WKS records in MX processing |5.2.12 | | | |x| |
-----------------------------------------------|----------|-|-|-|-|-|--
| | | | | | |
MAIL FORWARDING: | | | | | | |
Alter existing header field(s) |5.2.6 | | | |x| |
Implement relay function: 821/section 3.6 |5.2.6 | | |x| | |
If not, deliver to RHS domain |5.2.6 | |x| | | |
Interpret 'local-part' of addr |5.2.16 | | | | |x|
| | | | | | |
MAILING LISTS AND ALIASES | | | | | | |
Support both |5.3.6 | |x| | | |
Report mail list error to local admin. |5.3.6 |x| | | | |
| | | | | | |
MAIL GATEWAYS: | | | | | | |
Embed foreign mail route in local-part |5.2.16 | | |x| | |
Rewrite header fields when necessary |5.3.7 | | |x| | |
Prepend Received: line |5.3.7 |x| | | | |
Change existing Received: line |5.3.7 | | | | |x|
Accept full RFC-822 on Internet side |5.3.7 | |x| | | |
Act on RFC-822 explicit source route |5.3.7 | | |x| | |
Send only valid RFC-822 on Internet side |5.3.7 |x| | | | |
Deliver error msgs to envelope addr |5.3.7 | |x| | | |
Set env return path from err return addr |5.3.7 | |x| | | |
| | | | | | |
USER AGENT -- RFC-822 | | | | | | |
Allow user to enter <route> address |5.2.6 | | | |x| |
Support RFC-1049 Content Type field |5.2.13 | | |x| | |
Use 4-digit years |5.2.14 | |x| | | |
Generate numeric timezones |5.2.14 | |x| | | |
Accept all timezones |5.2.14 |x| | | | |
Use non-num timezones from RFC-822 |5.2.14 |x| | | | |
Omit phrase before route-addr |5.2.15 | | |x| | |
Accept and parse dot.dec. domain literals |5.2.17 |x| | | | |
Accept all RFC-822 address formats |5.2.18 |x| | | | |
Generate invalid RFC-822 address format |5.2.18 | | | | |x|
Fully-qualified domain names in header |5.2.18 |x| | | | |
Create explicit src route in header |5.2.19 | | | |x| |
Accept explicit src route in header |5.2.19 |x| | | | |
| | | | | | |
Send/recv at least 64KB messages |5.3.8 |x| | | | |6. SUPPORT SERVICES 🧚
6.1 DOMAIN NAME TRANSLATION 🌸
6.1.1 INTRODUCTION
okay so every host MUST implement a resolver for the Domain Name System (DNS), and it MUST have a mechanism that uses that DNS resolver to turn host names into IP addresses and vice-versa [DNS:1, DNS:2]. no skipping this one bestie 🫶
in addition to the DNS, a host MAY also implement a host name translation mechanism that searches a local Internet host table. see Section 6.1.3.8 for the deets on this option ✨
DISCUSSION: Internet host name translation used to happen by searching local copies of one big table of all hosts. 😭 that table got way too big to update and pass around in a timely way, and way too big to fit on lots of hosts, so the DNS was invented 💖 The DNS is a distributed database mostly used for translating between host names and host addresses. You need to implement DNS software, no debate 💅 It has two logically distinct parts: name servers and resolvers (though implementations often mash these together for efficiency) [DNS:2]. Domain name servers hold authoritative data for certain sections of the database and answer questions about that data. Domain resolvers ask name servers for data on behalf of user processes. Every host needs a DNS resolver, and some hosts will also run domain name servers 🧚 Since no single name server has the complete picture, you usually have to gather info from more than one name server to resolve a query 🍓
6.1.2 PROTOCOL WALK-THROUGH
an implementor really needs to study references [DNS:1] and [DNS:2] carefully 🙈 they give a thorough description of the theory, protocol, and implementation of the domain name system, and they reflect years of experience 👑
6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1
all DNS name servers and resolvers MUST properly handle RRs with a zero TTL: return the RR to the client but do not cache it 🦋
DISCUSSION: zero TTL values mean the RR can only be used for the transaction in progress, and it shouldn't get cached. they're super useful for extremely volatile data 🌈
6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5
a query with "QCLASS=*" SHOULD NOT be used unless the requestor is seeking data from more than one class. 💅 if the requestor only cares about Internet data types, then QCLASS=IN MUST be used 💜
6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1
unused fields in a query or response message MUST be zero ✨
6.1.2.4 Compression: RFC-1035 Section 4.1.4
name servers MUST use compression in responses 🎀
DISCUSSION: compression is essential so UDP datagrams don't overflow, see Section 6.1.3.2 🙈
6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2
recursive name servers and full-service resolvers usually have some config info with hints about where the root or local name servers live. an implementation MUST NOT include any of these hints in a response 🚫💀
DISCUSSION: lots of implementors found it convenient to store these hints like they were cached data, but some forgot to make sure that "cached data" stayed out of responses 😭 that has caused serious problems on the Internet when the hints were obsolete or wrong. main character energy for all the wrong reasons 🥀
6.1.3 SPECIFIC ISSUES 🌟
6.1.3.1 Resolver Implementation
a name resolver SHOULD be able to multiplex concurrent requests if the host supports concurrent processes ⚡
when implementing a DNS resolver, you MAY optionally pick one of two models: a full-service resolver, or a stub resolver 🧁
(A) Full-Service Resolver
The resolver section is where it gets spicy 🌶️ A full-service resolver is a complete implementation of the resolver service, and it's giving total main character energy 💅 It can deal with communication failures, with individual name servers failing, with finding the proper name server for a given name, etc. 🫶 It has to meet these requirements:
- The resolver MUST implement a local caching function to avoid repeated remote access for identical requests, and MUST time out information in the cache 🗂️
- The resolver SHOULD be configurable with start-up information pointing to multiple root name servers and multiple name servers for the local domain. This insures that the resolver will be able to access the whole name space in normal cases, and will be able to access local domain information should the local network become disconnected from the rest of the Internet 🌐✨
(B) Stub Resolver 🎀
A "stub resolver" relies on the services of a recursive name server on the connected network or a "nearby" network. It lets the host hand off the resolver work to a name server on another host, which is so iconic 🧚 This model is often essential for less capable hosts, such as PCs, and is also recommended when the host is one of several workstations on a local network, because it lets all of the workstations share the cache of the recursive name server. That means fewer domain requests get exported by the local network 🦋
At a minimum, the stub resolver MUST be capable of directing its requests to redundant recursive name servers. Note that recursive name servers are allowed to restrict the sources of requests that they will honor, so the host administrator must verify that the service will be provided 👑 Stub resolvers MAY implement caching if they choose, but if so, MUST timeout cached information 💜
6.1.3.2 Transport Protocols 🚀
DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries. Specifically, a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first. If the Answer section of the response is truncated and if the requester supports TCP, it SHOULD try the query again using TCP 🌸
DNS servers MUST be able to service UDP queries and SHOULD be able to service TCP queries. A name server MAY limit the resources it devotes to TCP queries, but it SHOULD NOT refuse to service a TCP query just because it would have succeeded with UDP 🫶
Truncated responses MUST NOT be saved (cached) and later used in such a way that the fact that they are truncated is lost. Bestie, don't be sneaky with truncated answers 🙈
DISCUSSION:
UDP is preferred over TCP for queries because UDP queries have much lower overhead, both in packet count and in connection state. The use of UDP is essential for heavily-loaded servers, especially the root servers. UDP also offers additional robustness, since a resolver can attempt several UDP queries to different servers for the cost of a single TCP query 💅
It is possible for a DNS response to be truncated, although this is a very rare occurrence in the present Internet DNS. Practically speaking, truncation cannot be predicted, since it is data-dependent. The dependencies include the number of RRs in the answer, the size of each RR, and the savings in space realized by the name compression algorithm. As a rule of thumb, truncation in NS and MX lists should not occur for answers containing 15 or fewer RRs 🍓
Whether it is possible to use a truncated answer depends on the application. A mailer must not use a truncated MX response, since this could lead to mail loops 💀
Responsible practices can make UDP suffice in the vast majority of cases. Name servers must use compression in responses. Resolvers must differentiate truncation of the Additional section of a response (which only loses extra information) from truncation of the Answer section (which for MX records renders the response unusable by mailers). Database administrators should list only a reasonable number of primary names in lists of name servers, MX alternatives, etc. ✨
However, it is also clear that some new DNS record types defined in the future will contain information exceeding the 512 byte limit that applies to UDP, and hence will require TCP. Thus, resolvers and name servers should implement TCP services as a backup to UDP today, with the knowledge that they will require the TCP service in the future 🔮
By private agreement, name servers and resolvers MAY arrange to use TCP for all traffic between themselves. TCP MUST be used for zone transfers 🫶
A DNS server MUST have sufficient internal concurrency that it can continue to process UDP queries while awaiting a response or performing a zone transfer on an open TCP connection [DNS:2] 🔥
A server MAY support a UDP query that is delivered using an IP broadcast or multicast address. However, the Recursion Desired bit MUST NOT be set in a query that is multicast, and MUST be ignored by name servers receiving queries via a broadcast or multicast address. A host that sends broadcast or multicast DNS queries SHOULD send them only as occasional probes, caching the IP address(es) it obtains from the response(s) so it can normally send unicast queries 📡
DISCUSSION:
Broadcast or (especially) IP multicast can provide a way to locate nearby name servers without knowing their IP addresses in advance. However, general broadcasting of recursive queries can result in excessive and unnecessary load on both network and servers 😭
6.1.3.3 Efficient Resource Usage 🌈
The following requirements on servers and resolvers are very important to the health of the Internet as a whole, particularly when DNS services are invoked repeatedly by higher level automatic servers, such as mailers. Iykyk 🫶
(1) The resolver MUST implement retransmission controls to insure that it does not waste communication bandwidth, and MUST impose finite bounds on the resources consumed to respond to a single request. See [DNS:2] pages 43-44 for specific recommendations 📚
(2) After a query has been retransmitted several times without a response, an implementation MUST give up and return a soft error to the application 🛑
(3) All DNS name servers and resolvers SHOULD cache temporary failures, with a timeout period of the order of minutes.
DISCUSSION:
This will prevent applications that immediately retry soft failures (in violation of Section 2.2 of this document) from generating excessive DNS traffic 🙅♀️
(4) All DNS name servers and resolvers SHOULD cache negative responses that indicate the specified name, or data of the specified type, does not exist, as described in [DNS:2] 🙈
(5) When a DNS server or resolver retries a UDP query, the retry interval SHOULD be constrained by an exponential backoff algorithm, and SHOULD also have upper and lower bounds 📈
IMPLEMENTATION:
A measured RTT and variance (if available) should be used to calculate an initial retransmission interval. If this information is not available, a default of no less than 5 seconds should be used. Implementations may limit the retransmission interval, but this limit must exceed twice the Internet maximum segment lifetime plus service delay at the name server ⏱️
(6) When a resolver or server receives a Source Quench for a query it has issued, it SHOULD take steps to reduce the rate of querying that server in the near future. A server MAY ignore a Source Quench that it receives as the result of sending a response datagram 🧃
IMPLEMENTATION:
One recommended action to reduce the rate is to send the next query attempt to an alternate server, if there is one available. Another is to backoff the retry interval for the same server 💖
6.1.3.4 Multihomed Hosts 🦋
When the host name-to-address function encounters a host with multiple addresses, it SHOULD rank or sort the addresses using knowledge of the immediately connected network number(s) and any other applicable performance or history information 🗺️
DISCUSSION:
The different addresses of a multihomed host generally imply different Internet paths, and some paths may be preferable to others in performance, reliability, or administrative restrictions. There is no general way for the domain system to determine the best path. A recommended approach is to base this decision on local configuration information set by the system administrator 🎀
IMPLEMENTATION:
The following scheme has been used successfully:
(a) Incorporate into the host configuration data a Network-Preference List, that is simply a list of networks in preferred order. This list may be empty if there is no preference.
(b) When a host name is mapped into a list of IP addresses, these addresses should be sorted by network number, into the same order as the corresponding networks in the Network-Preference List. IP addresses whose networks do not appear in the Network-Preference List should be placed at the end of the list 🌟
6.1.3.5 Extensibility 🧚
The DNS software MUST support all well-known, class-independent formats [DNS:2] 💅, and it SHOULD be written so that new well-known types and local experiments with non-standard types don't cause total chaos 🫶
DISCUSSION 🧚 The DNS data types and classes are extensible, so new types will show up and old ones will get deleted or redefined ✨ Bringing in a new data type should only depend on the rules for compressing domain names inside DNS messages, plus the translation between printable (master file) and internal formats for Resource Records (RRs) 🎀
Compression relies on knowing the format of the data inside a particular RR 🧠 So compression must only be used for the contents of well-known, class-independent RRs, and must never be used for class-specific RRs or for RR types that aren't well-known 🙅♀️ The owner name of an RR is always eligible for compression 💖
A name server may pick up RRs via zone transfer that it doesn't know how to convert to printable format 😭 A resolver can get similar info as the result of queries too. For things to work properly, that data has to be preserved, which means DNS software can't use textual formats for internal storage 💅
The DNS defines domain name syntax very generally 🌈 It's a string of labels, each holding up to 63 8-bit octets, separated by dots, with a max total of 255 octets. Particular applications can further constrain the syntax of the domain names they use, although DNS deployment has led some applications to allow more general names 👑 In particular, Section 2.1 of this document liberalizes the syntax of a legal Internet host name that was defined in RFC-952 [DNS:4] slightly 🦋
6.1.3.6. Status of RR Types 🍓
Name servers MUST be able to load all RR types except MD and MF from configuration files 📂 The MD and MF types are obsolete and MUST NOT be implemented. In particular, name servers MUST NOT load these types from configuration files 🙅♀️
DISCUSSION 🌸 The RR types MB, MG, MR, NULL, MINFO and RP are considered experimental, so applications that use the DNS can't expect most domains to support them. They're also subject to redefinition, so no promises 🫠
The TXT and WKS RR types haven't been widely used by Internet sites 💀 So an application can't count on a TXT or WKS RR existing in most domains 🙈
6.1.3.7. Robustness 🛡️
DNS software may need to operate in environments where the root servers or other servers are unavailable because of network connectivity or other problems 😤 In that situation, DNS name servers and resolvers MUST continue to provide service for the reachable part of the name space, while giving temporary failures for the rest 🔥
DISCUSSION 🌍 The DNS is mainly meant for the connected Internet, but it should be possible to use the system on networks that aren't connected to the Internet 🏝️ So implementations must not depend on access to root servers before providing service for local names 💜
6.1.3.8. Local Host Table 📒
DISCUSSION 🎀 A host may use a local host table as a backup or supplement to the DNS. That raises the question of which one takes precedence, the DNS or the host table 🤔 The most flexible approach would make this a configuration option ⭐
Usually, the contents of a supplementary host table are decided locally by the site 🏡 However, there's a publicly available table of Internet hosts maintained by the DDN Network Information Center (DDN NIC), with a format documented in [DNS:4] 📖 You can retrieve this table from the DDN NIC using a protocol described in [DNS:5] ✨
⚠️ This table contains only a small fraction of all Internet hosts, so don't assume it's the whole picture 🙈
Hosts using this protocol to grab the DDN NIC host table should use the VERSION command to check whether the table has changed before requesting the entire table with the ALL command 🧚 Treat the VERSION identifier as an arbitrary string and only test it for equality. No numerical sequence may be assumed 🔢
The DDN NIC host table includes administrative info that hosts don't need to operate, so it isn't currently included in the DNS database. Examples include network and gateway entries 🌐 Much of this extra info will be added to the DNS in the future though 🔮 Meanwhile, the DNS provides essential services (in particular, MX records) that aren't available from the DDN NIC host table 💌
6.1.4. DNS USER INTERFACE 🦋
6.1.4.1. DNS Administration 🗂️
This document is about design and implementation issues in host software, not administrative or operational issues 💅 Administrative issues are still super important in the DNS though, since errors in particular segments of this huge distributed database can cause poor or wrong performance for many sites 😱 These issues are discussed in [DNS:6] and [DNS:7] 📚
6.1.4.2. DNS User Interface 💻
Hosts MUST provide an interface to the DNS for all application programs running on the host 🫶 This interface will typically send requests to a system process that performs the resolver function [DNS:1, 6.1:2] ✨
At a minimum, the basic interface MUST support a request for all information of a specific type and class associated with a specific name 🎯 It MUST return either all of the requested information, a hard error code, or a soft error indication 👀 When there is no error, the basic interface returns the complete response information without modification, deletion, or ordering. That way the basic interface won't need to change to handle new data types 🥹
DISCUSSION 💜 The soft error indication is an essential part of the interface, since it may not always be possible to access particular information from the DNS. See Section 6.1.3.3 🙌
A host MAY provide other DNS interfaces tailored to particular functions, transforming the raw domain data into formats that suit those functions better 🌸 In particular, a host MUST provide a DNS interface to facilitate translation between host addresses and host names 🔥
6.1.4.3. Interface Abbreviation Facilities ✂️
User interfaces MAY provide a way for users to enter abbreviations for commonly used names 💅 Although defining these methods is outside the scope of the DNS specification, certain rules are needed to make sure they still allow access to the entire DNS name space and don't cause excessive use of Internet resources 🛑
If an abbreviation method is provided, then:
- (a) There MUST be some convention for denoting that a name is already complete, so that the abbreviation method(s) are suppressed. A trailing dot is the usual method 🦶
- (b) Abbreviation expansion MUST be done exactly once, and MUST be done in the context in which the name was entered ⭐
DISCUSSION 🧠 Say an abbreviation is used in a mail program for a destination. The abbreviation should be expanded into a full domain name and stored in the queued message with an indication that it's already complete 📬 Otherwise, the abbreviation might get expanded with a mail system search list instead of the user's, or a name could grow because of repeated canonicalization attempts interacting with wildcards 😵💫
The two most common abbreviation methods are:
- Interface-level aliases 🪞
Interface-level aliases are conceptually implemented as a list of alias/domain name pairs 📋 The list can be per-user or per-host, and separate lists can be associated with different functions. For example, one list could be for host name-to-address translation and a different one for mail domains 💌 When the user enters a name, the interface tries to match it to the alias component of a list entry. If a matching entry is found, the name is replaced by the domain name in the pair 🫧
Note that interface-level aliases and CNAMEs are completely separate mechanisms. Interface-level aliases are a local matter, while CNAMEs are an Internet-wide aliasing mechanism that's a required part of any DNS implementation 🌍
- Search Lists 🔍
A search list is conceptually implemented as an ordered list of domain names 📜 When the user enters a name, the domain names in the search list are used as suffixes to the user-supplied name, one by one, until a domain name with the desired associated data is found or the search list runs out 🏃♀️ Search lists often contain the name of the local host's parent domain or other ancestor domains 🌳 They're often per-user or per-process 👩💻
It SHOULD be possible for an administrator to disable a DNS search-list facility. Administrative denial may be warranted in some cases, to prevent abuse of the DNS 🚫
🚨 There's a danger that a search-list mechanism will generate excessive queries to the root servers while testing whether user input is a complete domain name that's missing a final period to mark it as complete. A search-list mechanism MUST have one of, and SHOULD have both of, the following two provisions to prevent this:
- (a) The local resolver/name server can implement caching of negative responses (see Section 6.1.3.3) 🧊
(b) The search list expander can require two or more interior dots in a generated domain name before it tries using the name in a query to non-local domain servers, such as the root.
DISCUSSION: okay so the whole point here is to stop the user from waiting forever while the search list gets tested 😩, and more importantly to stop a flood of traffic from hitting the root and other high-level servers 💀. Say the user types "X" and the search list includes the root as a component. The query has to consult a root server before the next search list alternative can even be tried. Now multiply that by every host on the Internet and the root servers and gateways near the root are getting absolutely wrecked 😭🔥.
The negative caching alternative limits the effect to the first time a name is used 🌸. The interior dot rule is simpler to implement, but it can block easy use of some top-level names 🙈.
6.1.5. DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ✨
Here's the big checklist, bestie 💖. Every row is a feature, and the columns tell you where it lives and how strict it is 💅.
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-----------------------------------------------|-----------|-|-|-|-|-|--
GENERAL ISSUES | | | | | | |
| | | | | | |
Implement DNS name-to-address conversion |6.1.1 |x| | | | |
Implement DNS address-to-name conversion |6.1.1 |x| | | | |
Support conversions using host table |6.1.1 | | |x| | |
Properly handle RR with zero TTL |6.1.2.1 |x| | | | |
Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | |
Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | |
Unused fields zero |6.1.2.3 |x| | | | |
Use compression in responses |6.1.2.4 |x| | | | |
| | | | | | |
Include config info in responses |6.1.2.5 | | | | |x|
Support all well-known, class-indep. types |6.1.3.5 |x| | | | |
Easily expand type list |6.1.3.5 | |x| | | |
Load all RR types (except MD and MF) |6.1.3.6 |x| | | | |
Load MD or MF type |6.1.3.6 | | | | |x|
Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
RESOLVER ISSUES: | | | | | | |
| | | | | | |
Resolver support multiple concurrent requests |6.1.3.1 | |x| | | |
Full-service resolver: |6.1.3.1 | | |x| | |
Local caching |6.1.3.1 |x| | | | |
Information in local cache times out |6.1.3.1 |x| | | | |
Configurable with starting info |6.1.3.1 | |x| | | |
Stub resolver: |6.1.3.1 | | |x| | |
Use redundant recursive name servers |6.1.3.1 |x| | | | |
Local caching |6.1.3.1 | | |x| | |
Information in local cache times out |6.1.3.1 |x| | | | |
Support for remote multi-homed hosts: | | | | | | |
Sort multiple addresses by preference list |6.1.3.4 | |x| | | |
| | | | | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
TRANSPORT PROTOCOLS: | | | | | | |
| | | | | | |
Support UDP queries |6.1.3.2 |x| | | | |
Support TCP queries |6.1.3.2 | |x| | | |
Send query using UDP first |6.1.3.2 |x| | | | |1
Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | |
Name server limit TCP query resources |6.1.3.2 | | |x| | |
Punish unnecessary TCP query |6.1.3.2 | | | |x| |
Use truncated data as if it were not |6.1.3.2 | | | | |x|
Private agreement to use only TCP |6.1.3.2 | | |x| | |
Use TCP for zone transfers |6.1.3.2 |x| | | | |
TCP usage not block UDP queries |6.1.3.2 |x| | | | |
Support broadcast or multicast queries |6.1.3.2 | | |x| | |
RD bit set in query |6.1.3.2 | | | | |x|
RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | |
Send only as occasional probe for addr's |6.1.3.2 | |x| | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
RESOURCE USAGE: | | | | | | |
| | | | | | |
Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | |
Finite bounds per request |6.1.3.3 |x| | | | |
Failure after retries => soft error |6.1.3.3 |x| | | | |
Cache temporary failures |6.1.3.3 | |x| | | |
Cache negative responses |6.1.3.3 | |x| | | |
Retries use exponential backoff |6.1.3.3 | |x| | | |
Upper, lower bounds |6.1.3.3 | |x| | | |
Client handle Source Quench |6.1.3.3 | |x| | | |
Server ignore Source Quench |6.1.3.3 | | |x| | |
-----------------------------------------------|-----------|-|-|-|-|-|--
USER INTERFACE: | | | | | | |
| | | | | | |
All programs have access to DNS interface |6.1.4.2 |x| | | | |
Able to request all info for given name |6.1.4.2 |x| | | | |
Returns complete info or error |6.1.4.2 |x| | | | |
Special interfaces |6.1.4.2 | | |x| | |
Name<->Address translation |6.1.4.2 |x| | | | |
| | | | | | |
Abbreviation Facilities: |6.1.4.3 | | |x| | |
Convention for complete names |6.1.4.3 |x| | | | |
Conversion exactly once |6.1.4.3 |x| | | | |
Conversion in proper context |6.1.4.3 |x| | | | |
Search list: |6.1.4.3 | | |x| | |
Administrator can disable |6.1.4.3 | |x| | | |
Prevention of excessive root queries |6.1.4.3 |x| | | | |
Both methods |6.1.4.3 | |x| | | |
-----------------------------------------------|-----------|-|-|-|-|-|--- Unless there is private agreement between particular resolver and particular server.
6.2. HOST INITIALIZATION 💾✨
6.2.1. INTRODUCTION 🌸
okay so this section is about starting up host software across a connected network, or more generally across an Internet path 🌐 this is necessary for a diskless host, and it may optionally be used for a host with disk drives too. for a diskless host, the startup process is called "network booting" and it's run by a bootstrap program that lives in a boot ROM 🔌
to initialize a diskless host across the network, there are two distinct phases, and bestie, they're both iconic:
- Configure the IP layer.
diskless machines usually have no permanent storage to keep network configuration info, so the host has to grab enough configuration info dynamically to support the loading phase that comes next. this info MUST include at least the IP addresses of the host and of the boot server. to support booting across a gateway, the address mask and a list of default gateways are also required 🧭
- Load the host system code.
during the loading phase, an appropriate file transfer protocol copies the system code across the network from the boot server 📦
a host with a disk may do the first step (dynamic configuration) too. this is important for microcomputers, because their floppy disks make it super easy to accidentally copy the same network configuration onto more than one host 💀 also, installing new hosts is way simpler when they automatically get their config from a central server, which saves admin time and lowers the chances of mistakes 🫶
6.2.2. REQUIREMENTS 📋
6.2.2.1. Dynamic Configuration 🔍
A number of protocol provisions have been made for dynamic configuration, and there are a few main contenders:
- ICMP Information Request/Reply messages
this obsolete message pair was designed to let a host find the number of the network it's on. unfortunately, it only worked if the host already knew the host number part of its IP address, and hosts that needed dynamic configuration rarely had that info 😭
- Reverse Address Resolution Protocol (RARP) [BOOT:4]
RARP is a link-layer protocol for a broadcast medium that lets a host find its IP address when it only knows its link layer address. unfortunately, RARP does not work across IP gateways, so you need a RARP server on every network 🙃 and it doesn't give any other configuration info either
- ICMP Address Mask Request/Reply messages
these ICMP messages let a host learn the address mask for a particular network interface 🎭
- BOOTP Protocol [BOOT:2]
this protocol lets a host determine the IP addresses of the local host and the boot server, the name of an appropriate boot file, and optionally the address mask and list of default gateways 🎀 to find a BOOTP server, the host broadcasts a BOOTP request using UDP. ad hoc gateway extensions have been used to pass the BOOTP broadcast through gateways, and in the future the IP Multicasting facility will provide a standard mechanism for this purpose 🦋
the suggested approach to dynamic configuration is to use the BOOTP protocol with the extensions defined in "BOOTP Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 defines some important general (not vendor-specific) extensions 💅 in particular, these extensions let the address mask be supplied in BOOTP, and we RECOMMEND that the address mask be supplied in this manner 🔥
DISCUSSION: historically, subnetting was defined long after IP, so a separate mechanism (ICMP Address Mask messages) was designed to supply the address mask to a host 🙈 but the IP address mask and the IP address conceptually form a pair. for operational simplicity they ought to be defined at the same time and by the same mechanism, whether that's a configuration file or a dynamic mechanism like BOOTP 🧚 also, BOOTP is not sufficiently general to specify the configurations of all interfaces of a multihomed host. a multihomed host must either use BOOTP separately for each interface, or configure one interface using BOOTP to do the loading and then do the complete initialization from a file later 🌈 application layer configuration info is expected to be obtained from files after the system code has been loaded 📁
6.2.2.2. Loading Phase 🚚
a suggested approach for the loading phase is to use TFTP [BOOT:1] between the IP addresses established by BOOTP 💜
TFTP to a broadcast address SHOULD NOT be used, for reasons explained in Section 4.2.3.4. 🙅♀️
6.3. REMOTE MANAGEMENT 🛰️
6.3.1. INTRODUCTION 👑
the Internet community has recently put a LOT of effort into developing network management protocols 🔥 the result is a two-pronged approach [MGT:1, MGT:6]: the Simple Network Management Protocol (SNMP) [MGT:4] and the Common Management Information Protocol over TCP (CMOT) [MGT:5] 🍓
to be managed using SNMP or CMOT, a host will need to implement an appropriate management agent. an Internet host SHOULD include an agent for either SNMP or CMOT 🫶
both SNMP and CMOT operate on a Management Information Base (MIB) that defines a collection of management values. by reading and setting these values, a remote application can query and change the state of the managed system 🧠
a standard MIB [MGT:3] has been defined for use by both management protocols, using data types from the Structure of Management Information (SMI) defined in [MGT:2]. additional MIB variables can be introduced under the "enterprises" and "experimental" subtrees of the MIB naming space [MGT:2] 🌸
every protocol module in the host SHOULD implement the relevant MIB variables. a host SHOULD implement the MIB variables as defined in the most recent standard MIB, and MAY implement other MIB variables when appropriate and useful ✨
6.3.2. PROTOCOL WALK-THROUGH 🚶♀️
the MIB is meant to cover both hosts and gateways, although there may be detailed differences in how it applies to the two cases. this section has the right interpretation of the MIB for hosts. later versions of the MIB will probably include more entries for host management 🦋
a managed host must implement the following groups of MIB object definitions: System, Interfaces, Address Translation, IP, ICMP, TCP, and UDP 💖
the following specific interpretations apply to hosts:
ipInHdrErrors
note that the error "time-to-live exceeded" can only occur in a host when it's forwarding a source-routed datagram 🤓
ipOutNoRoutes
this object counts datagrams discarded because no route can be found. this can happen in a host if all the default gateways in the host's configuration are down 📉
ipFragOKs,ipFragFails,ipFragCreates
a host that does not implement intentional fragmentation (see "Fragmentation" section of [INTRO:1]) MUST return the value zero for these three objects. no drama 🙌
icmpOutRedirects
for a host, this object MUST always be zero, since hosts do not send Redirects 🚫
icmpOutAddrMaskReps
for a host, this object MUST always be zero, unless the host is an authoritative source of address mask information 🎭
ipAddrTable
for a host, the "IP Address Table" object is effectively a table of logical interfaces 🗂️
ipRoutingTable
for a host, the "IP Routing Table" object is effectively a combination of the host's Routing Cache and the static route table described in the "Routing Outbound Datagrams" section of [INTRO:1] 🗺️
within each ipRouteEntry, ipRouteMetric1...4 normally will have no meaning for a host and SHOULD always be -1, while ipRouteType will normally have the value "remote" 🎀
if destinations on the connected network don't show up in the Route Cache (see "Routing Outbound Datagrams" section of [INTRO:1]), there won't be any entries with ipRouteType of "direct" 👀
DISCUSSION: the current MIB doesn't include Type-of-Service in an ipRouteEntry, but a future revision is expected to add it 💅 we also expect the MIB to be expanded to allow remote management of applications (e.g., the ability to partially reconfigure mail systems). network service applications like mail systems should therefore be written with "hooks" for remote management 🪝✨
6.3.3. MANAGEMENT REQUIREMENTS SUMMARY 📝
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-----------------------------------------------|-----------|-|-|-|-|-|--
Support SNMP or CMOT agent |6.3.1 | |x| | | |
Implement specified objects in standard MIB |6.3.1 | |x| | | |7. REFERENCES ✨
okay bestie, this section is the reading list every implementer needs to know cold 📚💅 It also has some secondary reads that are suggested extra credit 🦋
Introductory References 🌸
- [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, October 1989.
- [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985.
- [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, RFC-1011, May 1987.
- This document is republished periodically with new RFC numbers; the latest version must be used. 🔥
- [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. Postel, RFC-980, March 1986.
- [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May 1987.
- This document is republished periodically with new RFC numbers; the latest version must be used. 🔥
Telnet References 💖
- [TELNET:1] "Telnet Protocol Specification," J. Postel and J. Reynolds, RFC-854, May 1983.
- [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, RFC-855, May 1983.
- [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, RFC-856, May 1983.
- [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, May 1983.
- [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. Reynolds, RFC-858, May 1983.
- [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC-859, May 1983.
- [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, RFC-860, May 1983.
- [TELNET:8] "Telnet Extended Options List," J. Postel and J. Reynolds, RFC-861, May 1983.
- [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, December 1983.
- [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, February 1989.
- This document supercedes RFC-930. 🙈
- [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, October 1988.
- [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August 1989.
- [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, December 1988.
- [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-1080, November 1988.
Secondary Telnet References 🧚
- [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of Defense, May 1984.
- This document is intended to describe the same protocol as RFC-854. In case of conflict, RFC-854 takes precedence, and the present document takes precedence over both. ✨
- [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
- [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October 1977.
- [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
- [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS Implementation," A. Yasuda and T. Thompson, RFC-1043, February 1988.
FTP References 🍓
- [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC-959, October 1985.
- [FTP:2] "Document File Format Standards," J. Postel, RFC-678, December 1974.
- [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of Defense, May 1984.
- This document is based on an earlier version of the FTP specification (RFC-765) and is obsolete. 💀
TFTP References 🌈
- [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June 1981.
Mail References 💜
- [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August 1982.
- [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," D. Crocker, RFC-822, August 1982.
- This document obsoleted an earlier specification, RFC-733. 🫶
- [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, January 1986.
- This RFC describes the use of MX records, a mandatory extension to the mail delivery process. 👑
- [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, February 1988.
- [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, June 1986.
- [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
- The two preceding RFC's define a proposed standard for gatewaying mail between the Internet and the X.400 environments. 🦋
- [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. Department of Defense, May 1984.
- This specification is intended to describe the same protocol as does RFC-821. However, MIL-STD-1781 is incomplete; in particular, it does not include MX records [SMTP:3]. 😭
- [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, RFC-1049, March 1988.
Domain Name System References 🌐
- [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, RFC-1034, November 1987.
- This document and the following one obsolete RFC-882, RFC-883, and RFC-973. 💅
- [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, P. Mockapetris, November 1987.
- [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, January 1986.
- [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, RFC-952, M. Stahl, E. Feinler, October 1985.
Secondary DNS References ✨
- [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, RFC-953, October 1985.
- [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November 1987.
- [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC-1033, November 1987.
- [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet Protocol Handbook, NIC 50007, SRI Network Information Center, August 1989.
System Initialization References 🎀
- [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June 1984.
- [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-951, September 1985.
- [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-1084, December 1988.
- Note: this RFC revised and obsoleted RFC-1048. 👀
- [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
Management References 🔥
- [MGT:1] "IAB Recommendations for the Development of Internet Network Management Standards," V. Cerf, RFC-1052, April 1988.
- [MGT:2] "Structure and Identification of Management Information for TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, August 1988.
- [MGT:3] "Management Information Base for Network Management of TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, August 1988.
- [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, M. Schoffstall, and C. Davin, RFC-1098, April 1989.
- [MGT:5] "The Common Management Information Services and Protocol over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
- [MGT:6] "Report of the Second Ad Hoc Network Management Review Group," V. Cerf, RFC-1109, August 1989.
Security Considerations 🔒
okay this part is SERIOUS, bestie 😭🔒 There are many security issues in the application and support programs of host software, but a full discussion is beyond the scope of this RFC. Security-related issues are mentioned in sections concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the SMTP DATA command (Section 5.2.8). Go read those sections before you ship anything, periodt 💅
Author's Address 🧚
Robert Braden
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: (213) 822 1511
EMail: Braden@ISI.EDU📦 where this page comes from
- ietf: rfc1123 1989-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms