summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--Documentation/en/rfc/rfc1123.txt5782
-rw-r--r--Documentation/en/rfc/rfc1413.txt451
-rw-r--r--Documentation/en/rfc/rfc1428.txt339
-rw-r--r--Documentation/en/rfc/rfc1521.txt4539
-rw-r--r--Documentation/en/rfc/rfc1651.txt619
-rw-r--r--Documentation/en/rfc/rfc1652.txt339
-rw-r--r--Documentation/en/rfc/rfc1869.txt619
-rw-r--r--Documentation/en/rfc/rfc1891.txt1739
-rw-r--r--Documentation/en/rfc/rfc1893.txt843
-rw-r--r--Documentation/en/rfc/rfc1985.txt395
-rw-r--r--Documentation/en/rfc/rfc2034.txt339
-rw-r--r--Documentation/en/rfc/rfc2045.txt1739
-rw-r--r--Documentation/en/rfc/rfc2046.txt2467
-rw-r--r--Documentation/en/rfc/rfc2254.txt451
-rw-r--r--Documentation/en/rfc/rfc2476.txt843
-rw-r--r--Documentation/en/rfc/rfc2487.txt451
-rw-r--r--Documentation/en/rfc/rfc2554.txt619
-rw-r--r--Documentation/en/rfc/rfc2821.txt4427
-rw-r--r--Documentation/en/rfc/rfc2822.txt2859
-rw-r--r--Documentation/en/rfc/rfc2852.txt731
-rw-r--r--Documentation/en/rfc/rfc2870.txt563
-rw-r--r--Documentation/en/rfc/rfc2919.txt507
-rw-r--r--Documentation/en/rfc/rfc821.txt4050
-rw-r--r--Documentation/en/rfc/rfc822.txt2901
-rw-r--r--Documentation/en/rfc/rfc974.txt399
25 files changed, 39011 insertions, 0 deletions
diff --git a/Documentation/en/rfc/rfc1123.txt b/Documentation/en/rfc/rfc1123.txt
new file mode 100644
index 00000000..51cdf83c
--- /dev/null
+++ b/Documentation/en/rfc/rfc1123.txt
@@ -0,0 +1,5782 @@
+
+
+
+
+
+
+Network Working Group Internet Engineering Task Force
+Request for Comments: 1123 R. Braden, Editor
+ October 1989
+
+
+ Requirements for Internet Hosts -- Application and Support
+
+Status of This Memo
+
+ This RFC is an official specification for the Internet community. It
+ incorporates by reference, amends, corrects, and supplements the
+ primary protocol standards documents relating to hosts. Distribution
+ of this document is unlimited.
+
+Summary
+
+ This RFC is one of a pair that defines and discusses the requirements
+ for Internet host software. This RFC covers the application and
+ support protocols; its companion RFC-1122 covers the communication
+ protocol layers: link layer, IP layer, and transport layer.
+
+
+
+ Table of Contents
+
+
+
+
+ 1. INTRODUCTION ............................................... 5
+ 1.1 The Internet Architecture .............................. 6
+ 1.2 General Considerations ................................. 6
+ 1.2.1 Continuing Internet Evolution ..................... 6
+ 1.2.2 Robustness Principle .............................. 7
+ 1.2.3 Error Logging ..................................... 8
+ 1.2.4 Configuration ..................................... 8
+ 1.3 Reading this Document .................................. 10
+ 1.3.1 Organization ...................................... 10
+ 1.3.2 Requirements ...................................... 10
+ 1.3.3 Terminology ....................................... 11
+ 1.4 Acknowledgments ........................................ 12
+
+ 2. GENERAL ISSUES ............................................. 13
+ 2.1 Host Names and Numbers ................................. 13
+ 2.2 Using Domain Name Service .............................. 13
+ 2.3 Applications on Multihomed hosts ....................... 14
+ 2.4 Type-of-Service ........................................ 14
+ 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15
+
+
+
+
+Internet Engineering Task Force [Page 1]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16
+ 3.1 INTRODUCTION ........................................... 16
+ 3.2 PROTOCOL WALK-THROUGH .................................. 16
+ 3.2.1 Option Negotiation ................................ 16
+ 3.2.2 Telnet Go-Ahead Function .......................... 16
+ 3.2.3 Control Functions ................................. 17
+ 3.2.4 Telnet "Synch" Signal ............................. 18
+ 3.2.5 NVT Printer and Keyboard .......................... 19
+ 3.2.6 Telnet Command Structure .......................... 20
+ 3.2.7 Telnet Binary Option .............................. 20
+ 3.2.8 Telnet Terminal-Type Option ....................... 20
+ 3.3 SPECIFIC ISSUES ........................................ 21
+ 3.3.1 Telnet End-of-Line Convention ..................... 21
+ 3.3.2 Data Entry Terminals .............................. 23
+ 3.3.3 Option Requirements ............................... 24
+ 3.3.4 Option Initiation ................................. 24
+ 3.3.5 Telnet Linemode Option ............................ 25
+ 3.4 TELNET/USER INTERFACE .................................. 25
+ 3.4.1 Character Set Transparency ........................ 25
+ 3.4.2 Telnet Commands ................................... 26
+ 3.4.3 TCP Connection Errors ............................. 26
+ 3.4.4 Non-Default Telnet Contact Port ................... 26
+ 3.4.5 Flushing Output ................................... 26
+ 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27
+
+ 4. FILE TRANSFER .............................................. 29
+ 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29
+ 4.1.1 INTRODUCTION ...................................... 29
+ 4.1.2. PROTOCOL WALK-THROUGH ............................ 29
+ 4.1.2.1 LOCAL Type ................................... 29
+ 4.1.2.2 Telnet Format Control ........................ 30
+ 4.1.2.3 Page Structure ............................... 30
+ 4.1.2.4 Data Structure Transformations ............... 30
+ 4.1.2.5 Data Connection Management ................... 31
+ 4.1.2.6 PASV Command ................................. 31
+ 4.1.2.7 LIST and NLST Commands ....................... 31
+ 4.1.2.8 SITE Command ................................. 32
+ 4.1.2.9 STOU Command ................................. 32
+ 4.1.2.10 Telnet End-of-line Code ..................... 32
+ 4.1.2.11 FTP Replies ................................. 33
+ 4.1.2.12 Connections ................................. 34
+ 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34
+ 4.1.3 SPECIFIC ISSUES ................................... 35
+ 4.1.3.1 Non-standard Command Verbs ................... 35
+ 4.1.3.2 Idle Timeout ................................. 36
+ 4.1.3.3 Concurrency of Data and Control .............. 36
+ 4.1.3.4 FTP Restart Mechanism ........................ 36
+ 4.1.4 FTP/USER INTERFACE ................................ 39
+
+
+
+Internet Engineering Task Force [Page 2]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ 4.1.4.1 Pathname Specification ....................... 39
+ 4.1.4.2 "QUOTE" Command .............................. 40
+ 4.1.4.3 Displaying Replies to User ................... 40
+ 4.1.4.4 Maintaining Synchronization .................. 40
+ 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41
+ 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44
+ 4.2.1 INTRODUCTION ...................................... 44
+ 4.2.2 PROTOCOL WALK-THROUGH ............................. 44
+ 4.2.2.1 Transfer Modes ............................... 44
+ 4.2.2.2 UDP Header ................................... 44
+ 4.2.3 SPECIFIC ISSUES ................................... 44
+ 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44
+ 4.2.3.2 Timeout Algorithms ........................... 46
+ 4.2.3.3 Extensions ................................... 46
+ 4.2.3.4 Access Control ............................... 46
+ 4.2.3.5 Broadcast Request ............................ 46
+ 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47
+
+ 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48
+ 5.1 INTRODUCTION ........................................... 48
+ 5.2 PROTOCOL WALK-THROUGH .................................. 48
+ 5.2.1 The SMTP Model .................................... 48
+ 5.2.2 Canonicalization .................................. 49
+ 5.2.3 VRFY and EXPN Commands ............................ 50
+ 5.2.4 SEND, SOML, and SAML Commands ..................... 50
+ 5.2.5 HELO Command ...................................... 50
+ 5.2.6 Mail Relay ........................................ 51
+ 5.2.7 RCPT Command ...................................... 52
+ 5.2.8 DATA Command ...................................... 53
+ 5.2.9 Command Syntax .................................... 54
+ 5.2.10 SMTP Replies ..................................... 54
+ 5.2.11 Transparency ..................................... 55
+ 5.2.12 WKS Use in MX Processing ......................... 55
+ 5.2.13 RFC-822 Message Specification .................... 55
+ 5.2.14 RFC-822 Date and Time Specification .............. 55
+ 5.2.15 RFC-822 Syntax Change ............................ 56
+ 5.2.16 RFC-822 Local-part .............................. 56
+ 5.2.17 Domain Literals .................................. 57
+ 5.2.18 Common Address Formatting Errors ................. 58
+ 5.2.19 Explicit Source Routes ........................... 58
+ 5.3 SPECIFIC ISSUES ........................................ 59
+ 5.3.1 SMTP Queueing Strategies .......................... 59
+ 5.3.1.1 Sending Strategy .............................. 59
+ 5.3.1.2 Receiving strategy ........................... 61
+ 5.3.2 Timeouts in SMTP .................................. 61
+ 5.3.3 Reliable Mail Receipt ............................. 63
+ 5.3.4 Reliable Mail Transmission ........................ 63
+ 5.3.5 Domain Name Support ............................... 65
+
+
+
+Internet Engineering Task Force [Page 3]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ 5.3.6 Mailing Lists and Aliases ......................... 65
+ 5.3.7 Mail Gatewaying ................................... 66
+ 5.3.8 Maximum Message Size .............................. 68
+ 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69
+
+ 6. SUPPORT SERVICES ............................................ 72
+ 6.1 DOMAIN NAME TRANSLATION ................................. 72
+ 6.1.1 INTRODUCTION ....................................... 72
+ 6.1.2 PROTOCOL WALK-THROUGH ............................. 72
+ 6.1.2.1 Resource Records with Zero TTL ............... 73
+ 6.1.2.2 QCLASS Values ................................ 73
+ 6.1.2.3 Unused Fields ................................ 73
+ 6.1.2.4 Compression .................................. 73
+ 6.1.2.5 Misusing Configuration Info .................. 73
+ 6.1.3 SPECIFIC ISSUES ................................... 74
+ 6.1.3.1 Resolver Implementation ...................... 74
+ 6.1.3.2 Transport Protocols .......................... 75
+ 6.1.3.3 Efficient Resource Usage ..................... 77
+ 6.1.3.4 Multihomed Hosts ............................. 78
+ 6.1.3.5 Extensibility ................................ 79
+ 6.1.3.6 Status of RR Types ........................... 79
+ 6.1.3.7 Robustness ................................... 80
+ 6.1.3.8 Local Host Table ............................. 80
+ 6.1.4 DNS USER INTERFACE ................................ 81
+ 6.1.4.1 DNS Administration ........................... 81
+ 6.1.4.2 DNS User Interface ........................... 81
+ 6.1.4.3 Interface Abbreviation Facilities ............. 82
+ 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84
+ 6.2 HOST INITIALIZATION .................................... 87
+ 6.2.1 INTRODUCTION ...................................... 87
+ 6.2.2 REQUIREMENTS ...................................... 87
+ 6.2.2.1 Dynamic Configuration ........................ 87
+ 6.2.2.2 Loading Phase ................................ 89
+ 6.3 REMOTE MANAGEMENT ...................................... 90
+ 6.3.1 INTRODUCTION ...................................... 90
+ 6.3.2 PROTOCOL WALK-THROUGH ............................. 90
+ 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92
+
+ 7. REFERENCES ................................................. 93
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 4]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+1. INTRODUCTION
+
+ This document is one of a pair that defines and discusses the
+ requirements for host system implementations of the Internet protocol
+ suite. This RFC covers the applications layer and support protocols.
+ Its companion RFC, "Requirements for Internet Hosts -- Communications
+ Layers" [INTRO:1] covers the lower layer protocols: transport layer,
+ IP layer, and link layer.
+
+ These documents are intended to provide guidance for vendors,
+ implementors, and users of Internet communication software. They
+ represent the consensus of a large body of technical experience and
+ wisdom, contributed by members of the Internet research and vendor
+ communities.
+
+ This RFC enumerates standard protocols that a host connected to the
+ Internet must use, and it incorporates by reference the RFCs and
+ other documents describing the current specifications for these
+ protocols. It corrects errors in the referenced documents and adds
+ additional discussion and guidance for an implementor.
+
+ For each protocol, this document also contains an explicit set of
+ requirements, recommendations, and options. The reader must
+ understand that the list of requirements in this document is
+ incomplete by itself; the complete set of requirements for an
+ Internet host is primarily defined in the standard protocol
+ specification documents, with the corrections, amendments, and
+ supplements contained in this RFC.
+
+ A good-faith implementation of the protocols that was produced after
+ careful reading of the RFC's and with some interaction with the
+ Internet technical community, and that followed good communications
+ software engineering practices, should differ from the requirements
+ of this document in only minor ways. Thus, in many cases, the
+ "requirements" in this RFC are already stated or implied in the
+ standard protocol documents, so that their inclusion here is, in a
+ sense, redundant. However, they were included because some past
+ implementation has made the wrong choice, causing problems of
+ interoperability, performance, and/or robustness.
+
+ This document includes discussion and explanation of many of the
+ requirements and recommendations. A simple list of requirements
+ would be dangerous, because:
+
+ o Some required features are more important than others, and some
+ features are optional.
+
+ o There may be valid reasons why particular vendor products that
+
+
+
+Internet Engineering Task Force [Page 5]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ are designed for restricted contexts might choose to use
+ different specifications.
+
+ However, the specifications of this document must be followed to meet
+ the general goal of arbitrary host interoperation across the
+ diversity and complexity of the Internet system. Although most
+ current implementations fail to meet these requirements in various
+ ways, some minor and some major, this specification is the ideal
+ towards which we need to move.
+
+ These requirements are based on the current level of Internet
+ architecture. This document will be updated as required to provide
+ additional clarifications or to include additional information in
+ those areas in which specifications are still evolving.
+
+ This introductory section begins with general advice to host software
+ vendors, and then gives some guidance on reading the rest of the
+ document. Section 2 contains general requirements that may be
+ applicable to all application and support protocols. Sections 3, 4,
+ and 5 contain the requirements on protocols for the three major
+ applications: Telnet, file transfer, and electronic mail,
+ respectively. Section 6 covers the support applications: the domain
+ name system, system initialization, and management. Finally, all
+ references will be found in Section 7.
+
+ 1.1 The Internet Architecture
+
+ For a brief introduction to the Internet architecture from a host
+ viewpoint, see Section 1.1 of [INTRO:1]. That section also
+ contains recommended references for general background on the
+ Internet architecture.
+
+ 1.2 General Considerations
+
+ There are two important lessons that vendors of Internet host
+ software have learned and which a new vendor should consider
+ seriously.
+
+ 1.2.1 Continuing Internet Evolution
+
+ The enormous growth of the Internet has revealed problems of
+ management and scaling in a large datagram-based packet
+ communication system. These problems are being addressed, and
+ as a result there will be continuing evolution of the
+ specifications described in this document. These changes will
+ be carefully planned and controlled, since there is extensive
+ participation in this planning by the vendors and by the
+ organizations responsible for operations of the networks.
+
+
+
+Internet Engineering Task Force [Page 6]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ Development, evolution, and revision are characteristic of
+ computer network protocols today, and this situation will
+ persist for some years. A vendor who develops computer
+ communication software for the Internet protocol suite (or any
+ other protocol suite!) and then fails to maintain and update
+ that software for changing specifications is going to leave a
+ trail of unhappy customers. The Internet is a large
+ communication network, and the users are in constant contact
+ through it. Experience has shown that knowledge of
+ deficiencies in vendor software propagates quickly through the
+ Internet technical community.
+
+ 1.2.2 Robustness Principle
+
+ At every layer of the protocols, there is a general rule whose
+ application can lead to enormous benefits in robustness and
+ interoperability:
+
+ "Be liberal in what you accept, and
+ conservative in what you send"
+
+ Software should be written to deal with every conceivable
+ error, no matter how unlikely; sooner or later a packet will
+ come in with that particular combination of errors and
+ attributes, and unless the software is prepared, chaos can
+ ensue. In general, it is best to assume that the network is
+ filled with malevolent entities that will send in packets
+ designed to have the worst possible effect. This assumption
+ will lead to suitable protective design, although the most
+ serious problems in the Internet have been caused by
+ unenvisaged mechanisms triggered by low-probability events;
+ mere human malice would never have taken so devious a course!
+
+ Adaptability to change must be designed into all levels of
+ Internet host software. As a simple example, consider a
+ protocol specification that contains an enumeration of values
+ for a particular header field -- e.g., a type field, a port
+ number, or an error code; this enumeration must be assumed to
+ be incomplete. Thus, if a protocol specification defines four
+ possible error codes, the software must not break when a fifth
+ code shows up. An undefined code might be logged (see below),
+ but it must not cause a failure.
+
+ The second part of the principle is almost as important:
+ software on other hosts may contain deficiencies that make it
+ unwise to exploit legal but obscure protocol features. It is
+ unwise to stray far from the obvious and simple, lest untoward
+ effects result elsewhere. A corollary of this is "watch out
+
+
+
+Internet Engineering Task Force [Page 7]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ for misbehaving hosts"; host software should be prepared, not
+ just to survive other misbehaving hosts, but also to cooperate
+ to limit the amount of disruption such hosts can cause to the
+ shared communication facility.
+
+ 1.2.3 Error Logging
+
+ The Internet includes a great variety of host and gateway
+ systems, each implementing many protocols and protocol layers,
+ and some of these contain bugs and mis-features in their
+ Internet protocol software. As a result of complexity,
+ diversity, and distribution of function, the diagnosis of user
+ problems is often very difficult.
+
+ Problem diagnosis will be aided if host implementations include
+ a carefully designed facility for logging erroneous or
+ "strange" protocol events. It is important to include as much
+ diagnostic information as possible when an error is logged. In
+ particular, it is often useful to record the header(s) of a
+ packet that caused an error. However, care must be taken to
+ ensure that error logging does not consume prohibitive amounts
+ of resources or otherwise interfere with the operation of the
+ host.
+
+ There is a tendency for abnormal but harmless protocol events
+ to overflow error logging files; this can be avoided by using a
+ "circular" log, or by enabling logging only while diagnosing a
+ known failure. It may be useful to filter and count duplicate
+ successive messages. One strategy that seems to work well is:
+ (1) always count abnormalities and make such counts accessible
+ through the management protocol (see Section 6.3); and (2)
+ allow the logging of a great variety of events to be
+ selectively enabled. For example, it might useful to be able
+ to "log everything" or to "log everything for host X".
+
+ Note that different managements may have differing policies
+ about the amount of error logging that they want normally
+ enabled in a host. Some will say, "if it doesn't hurt me, I
+ don't want to know about it", while others will want to take a
+ more watchful and aggressive attitude about detecting and
+ removing protocol abnormalities.
+
+ 1.2.4 Configuration
+
+ It would be ideal if a host implementation of the Internet
+ protocol suite could be entirely self-configuring. This would
+ allow the whole suite to be implemented in ROM or cast into
+ silicon, it would simplify diskless workstations, and it would
+
+
+
+Internet Engineering Task Force [Page 8]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ be an immense boon to harried LAN administrators as well as
+ system vendors. We have not reached this ideal; in fact, we
+ are not even close.
+
+ At many points in this document, you will find a requirement
+ that a parameter be a configurable option. There are several
+ different reasons behind such requirements. In a few cases,
+ there is current uncertainty or disagreement about the best
+ value, and it may be necessary to update the recommended value
+ in the future. In other cases, the value really depends on
+ external factors -- e.g., the size of the host and the
+ distribution of its communication load, or the speeds and
+ topology of nearby networks -- and self-tuning algorithms are
+ unavailable and may be insufficient. In some cases,
+ configurability is needed because of administrative
+ requirements.
+
+ Finally, some configuration options are required to communicate
+ with obsolete or incorrect implementations of the protocols,
+ distributed without sources, that unfortunately persist in many
+ parts of the Internet. To make correct systems coexist with
+ these faulty systems, administrators often have to "mis-
+ configure" the correct systems. This problem will correct
+ itself gradually as the faulty systems are retired, but it
+ cannot be ignored by vendors.
+
+ When we say that a parameter must be configurable, we do not
+ intend to require that its value be explicitly read from a
+ configuration file at every boot time. We recommend that
+ implementors set up a default for each parameter, so a
+ configuration file is only necessary to override those defaults
+ that are inappropriate in a particular installation. Thus, the
+ configurability requirement is an assurance that it will be
+ POSSIBLE to override the default when necessary, even in a
+ binary-only or ROM-based product.
+
+ This document requires a particular value for such defaults in
+ some cases. The choice of default is a sensitive issue when
+ the configuration item controls the accommodation to existing
+ faulty systems. If the Internet is to converge successfully to
+ complete interoperability, the default values built into
+ implementations must implement the official protocol, not
+ "mis-configurations" to accommodate faulty implementations.
+ Although marketing considerations have led some vendors to
+ choose mis-configuration defaults, we urge vendors to choose
+ defaults that will conform to the standard.
+
+ Finally, we note that a vendor needs to provide adequate
+
+
+
+Internet Engineering Task Force [Page 9]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ documentation on all configuration parameters, their limits and
+ effects.
+
+
+ 1.3 Reading this Document
+
+ 1.3.1 Organization
+
+ In general, each major section is organized into the following
+ subsections:
+
+ (1) Introduction
+
+ (2) Protocol Walk-Through -- considers the protocol
+ specification documents section-by-section, correcting
+ errors, stating requirements that may be ambiguous or
+ ill-defined, and providing further clarification or
+ explanation.
+
+ (3) Specific Issues -- discusses protocol design and
+ implementation issues that were not included in the walk-
+ through.
+
+ (4) Interfaces -- discusses the service interface to the next
+ higher layer.
+
+ (5) Summary -- contains a summary of the requirements of the
+ section.
+
+ Under many of the individual topics in this document, there is
+ parenthetical material labeled "DISCUSSION" or
+ "IMPLEMENTATION". This material is intended to give
+ clarification and explanation of the preceding requirements
+ text. It also includes some suggestions on possible future
+ directions or developments. The implementation material
+ contains suggested approaches that an implementor may want to
+ consider.
+
+ The summary sections are intended to be guides and indexes to
+ the text, but are necessarily cryptic and incomplete. The
+ summaries should never be used or referenced separately from
+ the complete RFC.
+
+ 1.3.2 Requirements
+
+ In this document, the words that are used to define the
+ significance of each particular requirement are capitalized.
+ These words are:
+
+
+
+Internet Engineering Task Force [Page 10]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ * "MUST"
+
+ This word or the adjective "REQUIRED" means that the item
+ is an absolute requirement of the specification.
+
+ * "SHOULD"
+
+ This word or the adjective "RECOMMENDED" means that there
+ may exist valid reasons in particular circumstances to
+ ignore this item, but the full implications should be
+ understood and the case carefully weighed before choosing
+ a different course.
+
+ * "MAY"
+
+ This word or the adjective "OPTIONAL" means that this item
+ is truly optional. One vendor may choose to include the
+ item because a particular marketplace requires it or
+ because it enhances the product, for example; another
+ vendor may omit the same item.
+
+
+ An implementation is not compliant if it fails to satisfy one
+ or more of the MUST requirements for the protocols it
+ implements. An implementation that satisfies all the MUST and
+ all the SHOULD requirements for its protocols is said to be
+ "unconditionally compliant"; one that satisfies all the MUST
+ requirements but not all the SHOULD requirements for its
+ protocols is said to be "conditionally compliant".
+
+ 1.3.3 Terminology
+
+ This document uses the following technical terms:
+
+ Segment
+ A segment is the unit of end-to-end transmission in the
+ TCP protocol. A segment consists of a TCP header followed
+ by application data. A segment is transmitted by
+ encapsulation in an IP datagram.
+
+ Message
+ This term is used by some application layer protocols
+ (particularly SMTP) for an application data unit.
+
+ Datagram
+ A [UDP] datagram is the unit of end-to-end transmission in
+ the UDP protocol.
+
+
+
+
+Internet Engineering Task Force [Page 11]
+
+
+
+
+RFC1123 INTRODUCTION October 1989
+
+
+ Multihomed
+ A host is said to be multihomed if it has multiple IP
+ addresses to connected networks.
+
+
+
+ 1.4 Acknowledgments
+
+ This document incorporates contributions and comments from a large
+ group of Internet protocol experts, including representatives of
+ university and research labs, vendors, and government agencies.
+ It was assembled primarily by the Host Requirements Working Group
+ of the Internet Engineering Task Force (IETF).
+
+ The Editor would especially like to acknowledge the tireless
+ dedication of the following people, who attended many long
+ meetings and generated 3 million bytes of electronic mail over the
+ past 18 months in pursuit of this document: Philip Almquist, Dave
+ Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
+ Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
+ John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
+ Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
+ (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
+
+ In addition, the following people made major contributions to the
+ effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
+ (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
+ Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
+ John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
+ Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
+ (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
+ Technology), and Mike StJohns (DCA). The following also made
+ significant contributions to particular areas: Eric Allman
+ (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
+ (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
+ (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
+ (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
+ Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
+ (Toronto).
+
+ We are grateful to all, including any contributors who may have
+ been inadvertently omitted from this list.
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 12]
+
+
+
+
+RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
+
+
+2. GENERAL ISSUES
+
+ This section contains general requirements that may be applicable to
+ all application-layer protocols.
+
+ 2.1 Host Names and Numbers
+
+ The syntax of a legal Internet host name was specified in RFC-952
+ [DNS:4]. One aspect of host name syntax is hereby changed: the
+ restriction on the first character is relaxed to allow either a
+ letter or a digit. Host software MUST support this more liberal
+ syntax.
+
+ Host software MUST handle host names of up to 63 characters and
+ SHOULD handle host names of up to 255 characters.
+
+ Whenever a user inputs the identity of an Internet host, it SHOULD
+ be possible to enter either (1) a host domain name or (2) an IP
+ address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
+ the string syntactically for a dotted-decimal number before
+ looking it up in the Domain Name System.
+
+ DISCUSSION:
+ This last requirement is not intended to specify the complete
+ syntactic form for entering a dotted-decimal host number;
+ that is considered to be a user-interface issue. For
+ example, a dotted-decimal number must be enclosed within
+ "[ ]" brackets for SMTP mail (see Section 5.2.17). This
+ notation could be made universal within a host system,
+ simplifying the syntactic checking for a dotted-decimal
+ number.
+
+ If a dotted-decimal number can be entered without such
+ identifying delimiters, then a full syntactic check must be
+ made, because a segment of a host domain name is now allowed
+ to begin with a digit and could legally be entirely numeric
+ (see Section 6.1.2.4). However, a valid host name can never
+ have the dotted-decimal form #.#.#.#, since at least the
+ highest-level component label will be alphabetic.
+
+ 2.2 Using Domain Name Service
+
+ Host domain names MUST be translated to IP addresses as described
+ in Section 6.1.
+
+ Applications using domain name services MUST be able to cope with
+ soft error conditions. Applications MUST wait a reasonable
+ interval between successive retries due to a soft error, and MUST
+
+
+
+Internet Engineering Task Force [Page 13]
+
+
+
+
+RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
+
+
+ allow for the possibility that network problems may deny service
+ for hours or even days.
+
+ An application SHOULD NOT rely on the ability to locate a WKS
+ record containing an accurate listing of all services at a
+ particular host address, since the WKS RR type is not often used
+ by Internet sites. To confirm that a service is present, simply
+ attempt to use it.
+
+ 2.3 Applications on Multihomed hosts
+
+ When the remote host is multihomed, the name-to-address
+ translation will return a list of alternative IP addresses. As
+ specified in Section 6.1.3.4, this list should be in order of
+ decreasing preference. Application protocol implementations
+ SHOULD be prepared to try multiple addresses from the list until
+ success is obtained. More specific requirements for SMTP are
+ given in Section 5.3.4.
+
+ When the local host is multihomed, a UDP-based request/response
+ application SHOULD send the response with an IP source address
+ that is the same as the specific destination address of the UDP
+ request datagram. The "specific destination address" is defined
+ in the "IP Addressing" section of the companion RFC [INTRO:1].
+
+ Similarly, a server application that opens multiple TCP
+ connections to the same client SHOULD use the same local IP
+ address for all.
+
+ 2.4 Type-of-Service
+
+ Applications MUST select appropriate TOS values when they invoke
+ transport layer services, and these values MUST be configurable.
+ Note that a TOS value contains 5 bits, of which only the most-
+ significant 3 bits are currently defined; the other two bits MUST
+ be zero.
+
+ DISCUSSION:
+ As gateway algorithms are developed to implement Type-of-
+ Service, the recommended values for various application
+ protocols may change. In addition, it is likely that
+ particular combinations of users and Internet paths will want
+ non-standard TOS values. For these reasons, the TOS values
+ must be configurable.
+
+ See the latest version of the "Assigned Numbers" RFC
+ [INTRO:5] for the recommended TOS values for the major
+ application protocols.
+
+
+
+Internet Engineering Task Force [Page 14]
+
+
+
+
+RFC1123 APPLICATIONS LAYER -- GENERAL October 1989
+
+
+ 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY
+
+ | | | | |S| |
+ | | | | |H| |F
+ | | | | |O|M|o
+ | | |S| |U|U|o
+ | | |H| |L|S|t
+ | |M|O| |D|T|n
+ | |U|U|M| | |o
+ | |S|L|A|N|N|t
+ | |T|D|Y|O|O|t
+FEATURE |SECTION | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+ | | | | | | |
+User interfaces: | | | | | | |
+ Allow host name to begin with digit |2.1 |x| | | | |
+ Host names of up to 635 characters |2.1 |x| | | | |
+ Host names of up to 255 characters |2.1 | |x| | | |
+ Support dotted-decimal host numbers |2.1 | |x| | | |
+ Check syntactically for dotted-dec first |2.1 | |x| | | |
+ | | | | | | |
+Map domain names per Section 6.1 |2.2 |x| | | | |
+Cope with soft DNS errors |2.2 |x| | | | |
+ Reasonable interval between retries |2.2 |x| | | | |
+ Allow for long outages |2.2 |x| | | | |
+Expect WKS records to be available |2.2 | | | |x| |
+ | | | | | | |
+Try multiple addr's for remote multihomed host |2.3 | |x| | | |
+UDP reply src addr is specific dest of request |2.3 | |x| | | |
+Use same IP addr for related TCP connections |2.3 | |x| | | |
+Specify appropriate TOS values |2.4 |x| | | | |
+ TOS values configurable |2.4 |x| | | | |
+ Unused TOS bits zero |2.4 |x| | | | |
+ | | | | | | |
+ | | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 15]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+3. REMOTE LOGIN -- TELNET PROTOCOL
+
+ 3.1 INTRODUCTION
+
+ Telnet is the standard Internet application protocol for remote
+ login. It provides the encoding rules to link a user's
+ keyboard/display on a client ("user") system with a command
+ interpreter on a remote server system. A subset of the Telnet
+ protocol is also incorporated within other application protocols,
+ e.g., FTP and SMTP.
+
+ Telnet uses a single TCP connection, and its normal data stream
+ ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
+ escape sequences to embed control functions. Telnet also allows
+ the negotiation of many optional modes and functions.
+
+ The primary Telnet specification is to be found in RFC-854
+ [TELNET:1], while the options are defined in many other RFCs; see
+ Section 7 for references.
+
+ 3.2 PROTOCOL WALK-THROUGH
+
+ 3.2.1 Option Negotiation: RFC-854, pp. 2-3
+
+ Every Telnet implementation MUST include option negotiation and
+ subnegotiation machinery [TELNET:2].
+
+ A host MUST carefully follow the rules of RFC-854 to avoid
+ option-negotiation loops. A host MUST refuse (i.e, reply
+ WONT/DONT to a DO/WILL) an unsupported option. Option
+ negotiation SHOULD continue to function (even if all requests
+ are refused) throughout the lifetime of a Telnet connection.
+
+ If all option negotiations fail, a Telnet implementation MUST
+ default to, and support, an NVT.
+
+ DISCUSSION:
+ Even though more sophisticated "terminals" and supporting
+ option negotiations are becoming the norm, all
+ implementations must be prepared to support an NVT for any
+ user-server communication.
+
+ 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
+
+ On a host that never sends the Telnet command Go Ahead (GA),
+ the Telnet Server MUST attempt to negotiate the Suppress Go
+ Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or
+ Server Telnet MUST always accept negotiation of the Suppress Go
+
+
+
+Internet Engineering Task Force [Page 16]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ Ahead option.
+
+ When it is driving a full-duplex terminal for which GA has no
+ meaning, a User Telnet implementation MAY ignore GA commands.
+
+ DISCUSSION:
+ Half-duplex ("locked-keyboard") line-at-a-time terminals
+ for which the Go-Ahead mechanism was designed have largely
+ disappeared from the scene. It turned out to be difficult
+ to implement sending the Go-Ahead signal in many operating
+ systems, even some systems that support native half-duplex
+ terminals. The difficulty is typically that the Telnet
+ server code does not have access to information about
+ whether the user process is blocked awaiting input from
+ the Telnet connection, i.e., it cannot reliably determine
+ when to send a GA command. Therefore, most Telnet Server
+ hosts do not send GA commands.
+
+ The effect of the rules in this section is to allow either
+ end of a Telnet connection to veto the use of GA commands.
+
+ There is a class of half-duplex terminals that is still
+ commercially important: "data entry terminals," which
+ interact in a full-screen manner. However, supporting
+ data entry terminals using the Telnet protocol does not
+ require the Go Ahead signal; see Section 3.3.2.
+
+ 3.2.3 Control Functions: RFC-854, pp. 7-8
+
+ The list of Telnet commands has been extended to include EOR
+ (End-of-Record), with code 239 [TELNET:9].
+
+ Both User and Server Telnets MAY support the control functions
+ EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
+ SB, and SE.
+
+ A host MUST be able to receive and ignore any Telnet control
+ functions that it does not support.
+
+ DISCUSSION:
+ Note that a Server Telnet is required to support the
+ Telnet IP (Interrupt Process) function, even if the server
+ host has an equivalent in-stream function (e.g., Control-C
+ in many systems). The Telnet IP function may be stronger
+ than an in-stream interrupt command, because of the out-
+ of-band effect of TCP urgent data.
+
+ The EOR control function may be used to delimit the
+
+
+
+Internet Engineering Task Force [Page 17]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ stream. An important application is data entry terminal
+ support (see Section 3.3.2). There was concern that since
+ EOR had not been defined in RFC-854, a host that was not
+ prepared to correctly ignore unknown Telnet commands might
+ crash if it received an EOR. To protect such hosts, the
+ End-of-Record option [TELNET:9] was introduced; however, a
+ properly implemented Telnet program will not require this
+ protection.
+
+ 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10
+
+ When it receives "urgent" TCP data, a User or Server Telnet
+ MUST discard all data except Telnet commands until the DM (and
+ end of urgent) is reached.
+
+ When it sends Telnet IP (Interrupt Process), a User Telnet
+ SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
+ TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent
+ pointer points to the DM octet.
+
+ When it receives a Telnet IP command, a Server Telnet MAY send
+ a Telnet "Synch" sequence back to the user, to flush the output
+ stream. The choice ought to be consistent with the way the
+ server operating system behaves when a local user interrupts a
+ process.
+
+ When it receives a Telnet AO command, a Server Telnet MUST send
+ a Telnet "Synch" sequence back to the user, to flush the output
+ stream.
+
+ A User Telnet SHOULD have the capability of flushing output
+ when it sends a Telnet IP; see also Section 3.4.5.
+
+ DISCUSSION:
+ There are three possible ways for a User Telnet to flush
+ the stream of server output data:
+
+ (1) Send AO after IP.
+
+ This will cause the server host to send a "flush-
+ buffered-output" signal to its operating system.
+ However, the AO may not take effect locally, i.e.,
+ stop terminal output at the User Telnet end, until
+ the Server Telnet has received and processed the AO
+ and has sent back a "Synch".
+
+ (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard
+ all output locally until a WILL/WONT TIMING-MARK is
+
+
+
+Internet Engineering Task Force [Page 18]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ received from the Server Telnet.
+
+ Since the DO TIMING-MARK will be processed after the
+ IP at the server, the reply to it should be in the
+ right place in the output data stream. However, the
+ TIMING-MARK will not send a "flush buffered output"
+ signal to the server operating system. Whether or
+ not this is needed is dependent upon the server
+ system.
+
+ (3) Do both.
+
+ The best method is not entirely clear, since it must
+ accommodate a number of existing server hosts that do not
+ follow the Telnet standards in various ways. The safest
+ approach is probably to provide a user-controllable option
+ to select (1), (2), or (3).
+
+ 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11
+
+ In NVT mode, a Telnet SHOULD NOT send characters with the
+ high-order bit 1, and MUST NOT send it as a parity bit.
+ Implementations that pass the high-order bit to applications
+ SHOULD negotiate binary mode (see Section 3.2.6).
+
+
+ DISCUSSION:
+ Implementors should be aware that a strict reading of
+ RFC-854 allows a client or server expecting NVT ASCII to
+ ignore characters with the high-order bit set. In
+ general, binary mode is expected to be used for
+ transmission of an extended (beyond 7-bit) character set
+ with Telnet.
+
+ However, there exist applications that really need an 8-
+ bit NVT mode, which is currently not defined, and these
+ existing applications do set the high-order bit during
+ part or all of the life of a Telnet connection. Note that
+ binary mode is not the same as 8-bit NVT mode, since
+ binary mode turns off end-of-line processing. For this
+ reason, the requirements on the high-order bit are stated
+ as SHOULD, not MUST.
+
+ RFC-854 defines a minimal set of properties of a "network
+ virtual terminal" or NVT; this is not meant to preclude
+ additional features in a real terminal. A Telnet
+ connection is fully transparent to all 7-bit ASCII
+ characters, including arbitrary ASCII control characters.
+
+
+
+Internet Engineering Task Force [Page 19]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ For example, a terminal might support full-screen commands
+ coded as ASCII escape sequences; a Telnet implementation
+ would pass these sequences as uninterpreted data. Thus,
+ an NVT should not be conceived as a terminal type of a
+ highly-restricted device.
+
+ 3.2.6 Telnet Command Structure: RFC-854, p. 13
+
+ Since options may appear at any point in the data stream, a
+ Telnet escape character (known as IAC, with the value 255) to
+ be sent as data MUST be doubled.
+
+ 3.2.7 Telnet Binary Option: RFC-856
+
+ When the Binary option has been successfully negotiated,
+ arbitrary 8-bit characters are allowed. However, the data
+ stream MUST still be scanned for IAC characters, any embedded
+ Telnet commands MUST be obeyed, and data bytes equal to IAC
+ MUST be doubled. Other character processing (e.g., replacing
+ CR by CR NUL or by CR LF) MUST NOT be done. In particular,
+ there is no end-of-line convention (see Section 3.3.1) in
+ binary mode.
+
+ DISCUSSION:
+ The Binary option is normally negotiated in both
+ directions, to change the Telnet connection from NVT mode
+ to "binary mode".
+
+ The sequence IAC EOR can be used to delimit blocks of data
+ within a binary-mode Telnet stream.
+
+ 3.2.8 Telnet Terminal-Type Option: RFC-1091
+
+ The Terminal-Type option MUST use the terminal type names
+ officially defined in the Assigned Numbers RFC [INTRO:5], when
+ they are available for the particular terminal. However, the
+ receiver of a Terminal-Type option MUST accept any name.
+
+ DISCUSSION:
+ RFC-1091 [TELNET:10] updates an earlier version of the
+ Terminal-Type option defined in RFC-930. The earlier
+ version allowed a server host capable of supporting
+ multiple terminal types to learn the type of a particular
+ client's terminal, assuming that each physical terminal
+ had an intrinsic type. However, today a "terminal" is
+ often really a terminal emulator program running in a PC,
+ perhaps capable of emulating a range of terminal types.
+ Therefore, RFC-1091 extends the specification to allow a
+
+
+
+Internet Engineering Task Force [Page 20]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ more general terminal-type negotiation between User and
+ Server Telnets.
+
+ 3.3 SPECIFIC ISSUES
+
+ 3.3.1 Telnet End-of-Line Convention
+
+ The Telnet protocol defines the sequence CR LF to mean "end-
+ of-line". For terminal input, this corresponds to a command-
+ completion or "end-of-line" key being pressed on a user
+ terminal; on an ASCII terminal, this is the CR key, but it may
+ also be labelled "Return" or "Enter".
+
+ When a Server Telnet receives the Telnet end-of-line sequence
+ CR LF as input from a remote terminal, the effect MUST be the
+ same as if the user had pressed the "end-of-line" key on a
+ local terminal. On server hosts that use ASCII, in particular,
+ receipt of the Telnet sequence CR LF must cause the same effect
+ as a local user pressing the CR key on a local terminal. Thus,
+ CR LF and CR NUL MUST have the same effect on an ASCII server
+ host when received as input over a Telnet connection.
+
+ A User Telnet MUST be able to send any of the forms: CR LF, CR
+ NUL, and LF. A User Telnet on an ASCII host SHOULD have a
+ user-controllable mode to send either CR LF or CR NUL when the
+ user presses the "end-of-line" key, and CR LF SHOULD be the
+ default.
+
+ The Telnet end-of-line sequence CR LF MUST be used to send
+ Telnet data that is not terminal-to-computer (e.g., for Server
+ Telnet sending output, or the Telnet protocol incorporated
+ another application protocol).
+
+ DISCUSSION:
+ To allow interoperability between arbitrary Telnet clients
+ and servers, the Telnet protocol defined a standard
+ representation for a line terminator. Since the ASCII
+ character set includes no explicit end-of-line character,
+ systems have chosen various representations, e.g., CR, LF,
+ and the sequence CR LF. The Telnet protocol chose the CR
+ LF sequence as the standard for network transmission.
+
+ Unfortunately, the Telnet protocol specification in RFC-
+ 854 [TELNET:1] has turned out to be somewhat ambiguous on
+ what character(s) should be sent from client to server for
+ the "end-of-line" key. The result has been a massive and
+ continuing interoperability headache, made worse by
+ various faulty implementations of both User and Server
+
+
+
+Internet Engineering Task Force [Page 21]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ Telnets.
+
+ Although the Telnet protocol is based on a perfectly
+ symmetric model, in a remote login session the role of the
+ user at a terminal differs from the role of the server
+ host. For example, RFC-854 defines the meaning of CR, LF,
+ and CR LF as output from the server, but does not specify
+ what the User Telnet should send when the user presses the
+ "end-of-line" key on the terminal; this turns out to be
+ the point at issue.
+
+ When a user presses the "end-of-line" key, some User
+ Telnet implementations send CR LF, while others send CR
+ NUL (based on a different interpretation of the same
+ sentence in RFC-854). These will be equivalent for a
+ correctly-implemented ASCII server host, as discussed
+ above. For other servers, a mode in the User Telnet is
+ needed.
+
+ The existence of User Telnets that send only CR NUL when
+ CR is pressed creates a dilemma for non-ASCII hosts: they
+ can either treat CR NUL as equivalent to CR LF in input,
+ thus precluding the possibility of entering a "bare" CR,
+ or else lose complete interworking.
+
+ Suppose a user on host A uses Telnet to log into a server
+ host B, and then execute B's User Telnet program to log
+ into server host C. It is desirable for the Server/User
+ Telnet combination on B to be as transparent as possible,
+ i.e., to appear as if A were connected directly to C. In
+ particular, correct implementation will make B transparent
+ to Telnet end-of-line sequences, except that CR LF may be
+ translated to CR NUL or vice versa.
+
+ IMPLEMENTATION:
+ To understand Telnet end-of-line issues, one must have at
+ least a general model of the relationship of Telnet to the
+ local operating system. The Server Telnet process is
+ typically coupled into the terminal driver software of the
+ operating system as a pseudo-terminal. A Telnet end-of-
+ line sequence received by the Server Telnet must have the
+ same effect as pressing the end-of-line key on a real
+ locally-connected terminal.
+
+ Operating systems that support interactive character-at-
+ a-time applications (e.g., editors) typically have two
+ internal modes for their terminal I/O: a formatted mode,
+ in which local conventions for end-of-line and other
+
+
+
+Internet Engineering Task Force [Page 22]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ formatting rules have been applied to the data stream, and
+ a "raw" mode, in which the application has direct access
+ to every character as it was entered. A Server Telnet
+ must be implemented in such a way that these modes have
+ the same effect for remote as for local terminals. For
+ example, suppose a CR LF or CR NUL is received by the
+ Server Telnet on an ASCII host. In raw mode, a CR
+ character is passed to the application; in formatted mode,
+ the local system's end-of-line convention is used.
+
+ 3.3.2 Data Entry Terminals
+
+ DISCUSSION:
+ In addition to the line-oriented and character-oriented
+ ASCII terminals for which Telnet was designed, there are
+ several families of video display terminals that are
+ sometimes known as "data entry terminals" or DETs. The
+ IBM 3270 family is a well-known example.
+
+ Two Internet protocols have been designed to support
+ generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
+ option [TELNET:18, TELNET:19]. The DET option drives a
+ data entry terminal over a Telnet connection using (sub-)
+ negotiation. SUPDUP is a completely separate terminal
+ protocol, which can be entered from Telnet by negotiation.
+ Although both SUPDUP and the DET option have been used
+ successfully in particular environments, neither has
+ gained general acceptance or wide implementation.
+
+ A different approach to DET interaction has been developed
+ for supporting the IBM 3270 family through Telnet,
+ although the same approach would be applicable to any DET.
+ The idea is to enter a "native DET" mode, in which the
+ native DET input/output stream is sent as binary data.
+ The Telnet EOR command is used to delimit logical records
+ (e.g., "screens") within this binary stream.
+
+ IMPLEMENTATION:
+ The rules for entering and leaving native DET mode are as
+ follows:
+
+ o The Server uses the Terminal-Type option [TELNET:10]
+ to learn that the client is a DET.
+
+ o It is conventional, but not required, that both ends
+ negotiate the EOR option [TELNET:9].
+
+ o Both ends negotiate the Binary option [TELNET:3] to
+
+
+
+Internet Engineering Task Force [Page 23]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ enter native DET mode.
+
+ o When either end negotiates out of binary mode, the
+ other end does too, and the mode then reverts to
+ normal NVT.
+
+
+ 3.3.3 Option Requirements
+
+ Every Telnet implementation MUST support the Binary option
+ [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
+ SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
+ Record [TELNET:9], and Extended Options List [TELNET:8]
+ options.
+
+ A User or Server Telnet SHOULD support the Window Size Option
+ [TELNET:12] if the local operating system provides the
+ corresponding capability.
+
+ DISCUSSION:
+ Note that the End-of-Record option only signifies that a
+ Telnet can receive a Telnet EOR without crashing;
+ therefore, every Telnet ought to be willing to accept
+ negotiation of the End-of-Record option. See also the
+ discussion in Section 3.2.3.
+
+ 3.3.4 Option Initiation
+
+ When the Telnet protocol is used in a client/server situation,
+ the server SHOULD initiate negotiation of the terminal
+ interaction mode it expects.
+
+ DISCUSSION:
+ The Telnet protocol was defined to be perfectly
+ symmetrical, but its application is generally asymmetric.
+ Remote login has been known to fail because NEITHER side
+ initiated negotiation of the required non-default terminal
+ modes. It is generally the server that determines the
+ preferred mode, so the server needs to initiate the
+ negotiation; since the negotiation is symmetric, the user
+ can also initiate it.
+
+ A client (User Telnet) SHOULD provide a means for users to
+ enable and disable the initiation of option negotiation.
+
+ DISCUSSION:
+ A user sometimes needs to connect to an application
+ service (e.g., FTP or SMTP) that uses Telnet for its
+
+
+
+Internet Engineering Task Force [Page 24]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ control stream but does not support Telnet options. User
+ Telnet may be used for this purpose if initiation of
+ option negotiation is disabled.
+
+ 3.3.5 Telnet Linemode Option
+
+ DISCUSSION:
+ An important new Telnet option, LINEMODE [TELNET:12], has
+ been proposed. The LINEMODE option provides a standard
+ way for a User Telnet and a Server Telnet to agree that
+ the client rather than the server will perform terminal
+ character processing. When the client has prepared a
+ complete line of text, it will send it to the server in
+ (usually) one TCP packet. This option will greatly
+ decrease the packet cost of Telnet sessions and will also
+ give much better user response over congested or long-
+ delay networks.
+
+ The LINEMODE option allows dynamic switching between local
+ and remote character processing. For example, the Telnet
+ connection will automatically negotiate into single-
+ character mode while a full screen editor is running, and
+ then return to linemode when the editor is finished.
+
+ We expect that when this RFC is released, hosts should
+ implement the client side of this option, and may
+ implement the server side of this option. To properly
+ implement the server side, the server needs to be able to
+ tell the local system not to do any input character
+ processing, but to remember its current terminal state and
+ notify the Server Telnet process whenever the state
+ changes. This will allow password echoing and full screen
+ editors to be handled properly, for example.
+
+ 3.4 TELNET/USER INTERFACE
+
+ 3.4.1 Character Set Transparency
+
+ User Telnet implementations SHOULD be able to send or receive
+ any 7-bit ASCII character. Where possible, any special
+ character interpretations by the user host's operating system
+ SHOULD be bypassed so that these characters can conveniently be
+ sent and received on the connection.
+
+ Some character value MUST be reserved as "escape to command
+ mode"; conventionally, doubling this character allows it to be
+ entered as data. The specific character used SHOULD be user
+ selectable.
+
+
+
+Internet Engineering Task Force [Page 25]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ On binary-mode connections, a User Telnet program MAY provide
+ an escape mechanism for entering arbitrary 8-bit values, if the
+ host operating system doesn't allow them to be entered directly
+ from the keyboard.
+
+ IMPLEMENTATION:
+ The transparency issues are less pressing on servers, but
+ implementors should take care in dealing with issues like:
+ masking off parity bits (sent by an older, non-conforming
+ client) before they reach programs that expect only NVT
+ ASCII, and properly handling programs that request 8-bit
+ data streams.
+
+ 3.4.2 Telnet Commands
+
+ A User Telnet program MUST provide a user the capability of
+ entering any of the Telnet control functions IP, AO, or AYT,
+ and SHOULD provide the capability of entering EC, EL, and
+ Break.
+
+ 3.4.3 TCP Connection Errors
+
+ A User Telnet program SHOULD report to the user any TCP errors
+ that are reported by the transport layer (see "TCP/Application
+ Layer Interface" section in [INTRO:1]).
+
+ 3.4.4 Non-Default Telnet Contact Port
+
+ A User Telnet program SHOULD allow the user to optionally
+ specify a non-standard contact port number at the Server Telnet
+ host.
+
+ 3.4.5 Flushing Output
+
+ A User Telnet program SHOULD provide the user the ability to
+ specify whether or not output should be flushed when an IP is
+ sent; see Section 3.2.4.
+
+ For any output flushing scheme that causes the User Telnet to
+ flush output locally until a Telnet signal is received from the
+ Server, there SHOULD be a way for the user to manually restore
+ normal output, in case the Server fails to send the expected
+ signal.
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 26]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ 3.5. TELNET REQUIREMENTS SUMMARY
+
+
+ | | | | |S| |
+ | | | | |H| |F
+ | | | | |O|M|o
+ | | |S| |U|U|o
+ | | |H| |L|S|t
+ | |M|O| |D|T|n
+ | |U|U|M| | |o
+ | |S|L|A|N|N|t
+ | |T|D|Y|O|O|t
+FEATURE |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+ | | | | | | |
+Option Negotiation |3.2.1 |x| | | | |
+ Avoid negotiation loops |3.2.1 |x| | | | |
+ Refuse unsupported options |3.2.1 |x| | | | |
+ Negotiation OK anytime on connection |3.2.1 | |x| | | |
+ Default to NVT |3.2.1 |x| | | | |
+ Send official name in Term-Type option |3.2.8 |x| | | | |
+ Accept any name in Term-Type option |3.2.8 |x| | | | |
+ Implement Binary, Suppress-GA options |3.3.3 |x| | | | |
+ Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | |
+ Implement Window-Size option if appropriate |3.3.3 | |x| | | |
+ Server initiate mode negotiations |3.3.4 | |x| | | |
+ User can enable/disable init negotiations |3.3.4 | |x| | | |
+ | | | | | | |
+Go-Aheads | | | | | | |
+ Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | |
+ User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | |
+ User Telnet ignore GA's |3.2.2 | | |x| | |
+ | | | | | | |
+Control Functions | | | | | | |
+ Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | |
+ Support EOR EC EL Break |3.2.3 | | |x| | |
+ Ignore unsupported control functions |3.2.3 |x| | | | |
+ User, Server discard urgent data up to DM |3.2.4 |x| | | | |
+ User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | |
+ Server Telnet reply Synch to IP |3.2.4 | | |x| | |
+ Server Telnet reply Synch to AO |3.2.4 |x| | | | |
+ User Telnet can flush output when send IP |3.2.4 | |x| | | |
+ | | | | | | |
+Encoding | | | | | | |
+ Send high-order bit in NVT mode |3.2.5 | | | |x| |
+ Send high-order bit as parity bit |3.2.5 | | | | |x|
+ Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | |
+ Always double IAC data byte |3.2.6 |x| | | | |
+
+
+
+Internet Engineering Task Force [Page 27]
+
+
+
+
+RFC1123 REMOTE LOGIN -- TELNET October 1989
+
+
+ Double IAC data byte in binary mode |3.2.7 |x| | | | |
+ Obey Telnet cmds in binary mode |3.2.7 |x| | | | |
+ End-of-line, CR NUL in binary mode |3.2.7 | | | | |x|
+ | | | | | | |
+End-of-Line | | | | | | |
+ EOL at Server same as local end-of-line |3.3.1 |x| | | | |
+ ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | |
+ User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | |
+ ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | |
+ User Telnet default mode is CR LF |3.3.1 | |x| | | |
+ Non-interactive uses CR LF for EOL |3.3.1 |x| | | | |
+ | | | | | | |
+User Telnet interface | | | | | | |
+ Input & output all 7-bit characters |3.4.1 | |x| | | |
+ Bypass local op sys interpretation |3.4.1 | |x| | | |
+ Escape character |3.4.1 |x| | | | |
+ User-settable escape character |3.4.1 | |x| | | |
+ Escape to enter 8-bit values |3.4.1 | | |x| | |
+ Can input IP, AO, AYT |3.4.2 |x| | | | |
+ Can input EC, EL, Break |3.4.2 | |x| | | |
+ Report TCP connection errors to user |3.4.3 | |x| | | |
+ Optional non-default contact port |3.4.4 | |x| | | |
+ Can spec: output flushed when IP sent |3.4.5 | |x| | | |
+ Can manually restore output mode |3.4.5 | |x| | | |
+ | | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 28]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+4. FILE TRANSFER
+
+ 4.1 FILE TRANSFER PROTOCOL -- FTP
+
+ 4.1.1 INTRODUCTION
+
+ The File Transfer Protocol FTP is the primary Internet standard
+ for file transfer. The current specification is contained in
+ RFC-959 [FTP:1].
+
+ FTP uses separate simultaneous TCP connections for control and
+ for data transfer. The FTP protocol includes many features,
+ some of which are not commonly implemented. However, for every
+ feature in FTP, there exists at least one implementation. The
+ minimum implementation defined in RFC-959 was too small, so a
+ somewhat larger minimum implementation is defined here.
+
+ Internet users have been unnecessarily burdened for years by
+ deficient FTP implementations. Protocol implementors have
+ suffered from the erroneous opinion that implementing FTP ought
+ to be a small and trivial task. This is wrong, because FTP has
+ a user interface, because it has to deal (correctly) with the
+ whole variety of communication and operating system errors that
+ may occur, and because it has to handle the great diversity of
+ real file systems in the world.
+
+ 4.1.2. PROTOCOL WALK-THROUGH
+
+ 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4
+
+ An FTP program MUST support TYPE I ("IMAGE" or binary type)
+ as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
+ A machine whose memory is organized into m-bit words, where
+ m is not a multiple of 8, MAY also support TYPE L m.
+
+ DISCUSSION:
+ The command "TYPE L 8" is often required to transfer
+ binary data between a machine whose memory is organized
+ into (e.g.) 36-bit words and a machine with an 8-bit
+ byte organization. For an 8-bit byte machine, TYPE L 8
+ is equivalent to IMAGE.
+
+ "TYPE L m" is sometimes specified to the FTP programs
+ on two m-bit word machines to ensure the correct
+ transfer of a native-mode binary file from one machine
+ to the other. However, this command should have the
+ same effect on these machines as "TYPE I".
+
+
+
+
+Internet Engineering Task Force [Page 29]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2
+
+ A host that makes no distinction between TYPE N and TYPE T
+ SHOULD implement TYPE T to be identical to TYPE N.
+
+ DISCUSSION:
+ This provision should ease interoperation with hosts
+ that do make this distinction.
+
+ Many hosts represent text files internally as strings
+ of ASCII characters, using the embedded ASCII format
+ effector characters (LF, BS, FF, ...) to control the
+ format when a file is printed. For such hosts, there
+ is no distinction between "print" files and other
+ files. However, systems that use record structured
+ files typically need a special format for printable
+ files (e.g., ASA carriage control). For the latter
+ hosts, FTP allows a choice of TYPE N or TYPE T.
+
+ 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
+
+ Implementation of page structure is NOT RECOMMENDED in
+ general. However, if a host system does need to implement
+ FTP for "random access" or "holey" files, it MUST use the
+ defined page structure format rather than define a new
+ private FTP format.
+
+ 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2
+
+ An FTP transformation between record-structure and file-
+ structure SHOULD be invertible, to the extent possible while
+ making the result useful on the target host.
+
+ DISCUSSION:
+ RFC-959 required strict invertibility between record-
+ structure and file-structure, but in practice,
+ efficiency and convenience often preclude it.
+ Therefore, the requirement is being relaxed. There are
+ two different objectives for transferring a file:
+ processing it on the target host, or just storage. For
+ storage, strict invertibility is important. For
+ processing, the file created on the target host needs
+ to be in the format expected by application programs on
+ that host.
+
+ As an example of the conflict, imagine a record-
+ oriented operating system that requires some data files
+ to have exactly 80 bytes in each record. While STORing
+
+
+
+Internet Engineering Task Force [Page 30]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ a file on such a host, an FTP Server must be able to
+ pad each line or record to 80 bytes; a later retrieval
+ of such a file cannot be strictly invertible.
+
+ 4.1.2.5 Data Connection Management: RFC-959 Section 3.3
+
+ A User-FTP that uses STREAM mode SHOULD send a PORT command
+ to assign a non-default data port before each transfer
+ command is issued.
+
+ DISCUSSION:
+ This is required because of the long delay after a TCP
+ connection is closed until its socket pair can be
+ reused, to allow multiple transfers during a single FTP
+ session. Sending a port command can avoided if a
+ transfer mode other than stream is used, by leaving the
+ data transfer connection open between transfers.
+
+ 4.1.2.6 PASV Command: RFC-959 Section 4.1.2
+
+ A server-FTP MUST implement the PASV command.
+
+ If multiple third-party transfers are to be executed during
+ the same session, a new PASV command MUST be issued before
+ each transfer command, to obtain a unique port pair.
+
+ IMPLEMENTATION:
+ The format of the 227 reply to a PASV command is not
+ well standardized. In particular, an FTP client cannot
+ assume that the parentheses shown on page 40 of RFC-959
+ will be present (and in fact, Figure 3 on page 43 omits
+ them). Therefore, a User-FTP program that interprets
+ the PASV reply must scan the reply for the first digit
+ of the host and port numbers.
+
+ Note that the host number h1,h2,h3,h4 is the IP address
+ of the server host that is sending the reply, and that
+ p1,p2 is a non-default data transfer port that PASV has
+ assigned.
+
+ 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3
+
+ The data returned by an NLST command MUST contain only a
+ simple list of legal pathnames, such that the server can use
+ them directly as the arguments of subsequent data transfer
+ commands for the individual files.
+
+ The data returned by a LIST or NLST command SHOULD use an
+
+
+
+Internet Engineering Task Force [Page 31]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ implied TYPE AN, unless the current type is EBCDIC, in which
+ case an implied TYPE EN SHOULD be used.
+
+ DISCUSSION:
+ Many FTP clients support macro-commands that will get
+ or put files matching a wildcard specification, using
+ NLST to obtain a list of pathnames. The expansion of
+ "multiple-put" is local to the client, but "multiple-
+ get" requires cooperation by the server.
+
+ The implied type for LIST and NLST is designed to
+ provide compatibility with existing User-FTPs, and in
+ particular with multiple-get commands.
+
+ 4.1.2.8 SITE Command: RFC-959 Section 4.1.3
+
+ A Server-FTP SHOULD use the SITE command for non-standard
+ features, rather than invent new private commands or
+ unstandardized extensions to existing commands.
+
+ 4.1.2.9 STOU Command: RFC-959 Section 4.1.3
+
+ The STOU command stores into a uniquely named file. When it
+ receives an STOU command, a Server-FTP MUST return the
+ actual file name in the "125 Transfer Starting" or the "150
+ Opening Data Connection" message that precedes the transfer
+ (the 250 reply code mentioned in RFC-959 is incorrect). The
+ exact format of these messages is hereby defined to be as
+ follows:
+
+ 125 FILE: pppp
+ 150 FILE: pppp
+
+ where pppp represents the unique pathname of the file that
+ will be written.
+
+ 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34
+
+ Implementors MUST NOT assume any correspondence between READ
+ boundaries on the control connection and the Telnet EOL
+ sequences (CR LF).
+
+ DISCUSSION:
+ Thus, a server-FTP (or User-FTP) must continue reading
+ characters from the control connection until a complete
+ Telnet EOL sequence is encountered, before processing
+ the command (or response, respectively). Conversely, a
+ single READ from the control connection may include
+
+
+
+Internet Engineering Task Force [Page 32]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ more than one FTP command.
+
+ 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35
+
+ A Server-FTP MUST send only correctly formatted replies on
+ the control connection. Note that RFC-959 (unlike earlier
+ versions of the FTP spec) contains no provision for a
+ "spontaneous" reply message.
+
+ A Server-FTP SHOULD use the reply codes defined in RFC-959
+ whenever they apply. However, a server-FTP MAY use a
+ different reply code when needed, as long as the general
+ rules of Section 4.2 are followed. When the implementor has
+ a choice between a 4xx and 5xx reply code, a Server-FTP
+ SHOULD send a 4xx (temporary failure) code when there is any
+ reasonable possibility that a failed FTP will succeed a few
+ hours later.
+
+ A User-FTP SHOULD generally use only the highest-order digit
+ of a 3-digit reply code for making a procedural decision, to
+ prevent difficulties when a Server-FTP uses non-standard
+ reply codes.
+
+ A User-FTP MUST be able to handle multi-line replies. If
+ the implementation imposes a limit on the number of lines
+ and if this limit is exceeded, the User-FTP MUST recover,
+ e.g., by ignoring the excess lines until the end of the
+ multi-line reply is reached.
+
+ A User-FTP SHOULD NOT interpret a 421 reply code ("Service
+ not available, closing control connection") specially, but
+ SHOULD detect closing of the control connection by the
+ server.
+
+ DISCUSSION:
+ Server implementations that fail to strictly follow the
+ reply rules often cause FTP user programs to hang.
+ Note that RFC-959 resolved ambiguities in the reply
+ rules found in earlier FTP specifications and must be
+ followed.
+
+ It is important to choose FTP reply codes that properly
+ distinguish between temporary and permanent failures,
+ to allow the successful use of file transfer client
+ daemons. These programs depend on the reply codes to
+ decide whether or not to retry a failed transfer; using
+ a permanent failure code (5xx) for a temporary error
+ will cause these programs to give up unnecessarily.
+
+
+
+Internet Engineering Task Force [Page 33]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ When the meaning of a reply matches exactly the text
+ shown in RFC-959, uniformity will be enhanced by using
+ the RFC-959 text verbatim. However, a Server-FTP
+ implementor is encouraged to choose reply text that
+ conveys specific system-dependent information, when
+ appropriate.
+
+ 4.1.2.12 Connections: RFC-959 Section 5.2
+
+ The words "and the port used" in the second paragraph of
+ this section of RFC-959 are erroneous (historical), and they
+ should be ignored.
+
+ On a multihomed server host, the default data transfer port
+ (L-1) MUST be associated with the same local IP address as
+ the corresponding control connection to port L.
+
+ A user-FTP MUST NOT send any Telnet controls other than
+ SYNCH and IP on an FTP control connection. In particular, it
+ MUST NOT attempt to negotiate Telnet options on the control
+ connection. However, a server-FTP MUST be capable of
+ accepting and refusing Telnet negotiations (i.e., sending
+ DONT/WONT).
+
+ DISCUSSION:
+ Although the RFC says: "Server- and User- processes
+ should follow the conventions for the Telnet
+ protocol...[on the control connection]", it is not the
+ intent that Telnet option negotiation is to be
+ employed.
+
+ 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1
+
+ The following commands and options MUST be supported by
+ every server-FTP and user-FTP, except in cases where the
+ underlying file system or operating system does not allow or
+ support a particular command.
+
+ Type: ASCII Non-print, IMAGE, LOCAL 8
+ Mode: Stream
+ Structure: File, Record*
+ Commands:
+ USER, PASS, ACCT,
+ PORT, PASV,
+ TYPE, MODE, STRU,
+ RETR, STOR, APPE,
+ RNFR, RNTO, DELE,
+ CWD, CDUP, RMD, MKD, PWD,
+
+
+
+Internet Engineering Task Force [Page 34]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ LIST, NLST,
+ SYST, STAT,
+ HELP, NOOP, QUIT.
+
+ *Record structure is REQUIRED only for hosts whose file
+ systems support record structure.
+
+ DISCUSSION:
+ Vendors are encouraged to implement a larger subset of
+ the protocol. For example, there are important
+ robustness features in the protocol (e.g., Restart,
+ ABOR, block mode) that would be an aid to some Internet
+ users but are not widely implemented.
+
+ A host that does not have record structures in its file
+ system may still accept files with STRU R, recording
+ the byte stream literally.
+
+ 4.1.3 SPECIFIC ISSUES
+
+ 4.1.3.1 Non-standard Command Verbs
+
+ FTP allows "experimental" commands, whose names begin with
+ "X". If these commands are subsequently adopted as
+ standards, there may still be existing implementations using
+ the "X" form. At present, this is true for the directory
+ commands:
+
+ RFC-959 "Experimental"
+
+ MKD XMKD
+ RMD XRMD
+ PWD XPWD
+ CDUP XCUP
+ CWD XCWD
+
+ All FTP implementations SHOULD recognize both forms of these
+ commands, by simply equating them with extra entries in the
+ command lookup table.
+
+ IMPLEMENTATION:
+ A User-FTP can access a server that supports only the
+ "X" forms by implementing a mode switch, or
+ automatically using the following procedure: if the
+ RFC-959 form of one of the above commands is rejected
+ with a 500 or 502 response code, then try the
+ experimental form; any other response would be passed
+ to the user.
+
+
+
+Internet Engineering Task Force [Page 35]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ 4.1.3.2 Idle Timeout
+
+ A Server-FTP process SHOULD have an idle timeout, which will
+ terminate the process and close the control connection if
+ the server is inactive (i.e., no command or data transfer in
+ progress) for a long period of time. The idle timeout time
+ SHOULD be configurable, and the default should be at least 5
+ minutes.
+
+ A client FTP process ("User-PI" in RFC-959) will need
+ timeouts on responses only if it is invoked from a program.
+
+ DISCUSSION:
+ Without a timeout, a Server-FTP process may be left
+ pending indefinitely if the corresponding client
+ crashes without closing the control connection.
+
+ 4.1.3.3 Concurrency of Data and Control
+
+ DISCUSSION:
+ The intent of the designers of FTP was that a user
+ should be able to send a STAT command at any time while
+ data transfer was in progress and that the server-FTP
+ would reply immediately with status -- e.g., the number
+ of bytes transferred so far. Similarly, an ABOR
+ command should be possible at any time during a data
+ transfer.
+
+ Unfortunately, some small-machine operating systems
+ make such concurrent programming difficult, and some
+ other implementers seek minimal solutions, so some FTP
+ implementations do not allow concurrent use of the data
+ and control connections. Even such a minimal server
+ must be prepared to accept and defer a STAT or ABOR
+ command that arrives during data transfer.
+
+ 4.1.3.4 FTP Restart Mechanism
+
+ The description of the 110 reply on pp. 40-41 of RFC-959 is
+ incorrect; the correct description is as follows. A restart
+ reply message, sent over the control connection from the
+ receiving FTP to the User-FTP, has the format:
+
+ 110 MARK ssss = rrrr
+
+ Here:
+
+ * ssss is a text string that appeared in a Restart Marker
+
+
+
+Internet Engineering Task Force [Page 36]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ in the data stream and encodes a position in the
+ sender's file system;
+
+ * rrrr encodes the corresponding position in the
+ receiver's file system.
+
+ The encoding, which is specific to a particular file system
+ and network implementation, is always generated and
+ interpreted by the same system, either sender or receiver.
+
+ When an FTP that implements restart receives a Restart
+ Marker in the data stream, it SHOULD force the data to that
+ point to be written to stable storage before encoding the
+ corresponding position rrrr. An FTP sending Restart Markers
+ MUST NOT assume that 110 replies will be returned
+ synchronously with the data, i.e., it must not await a 110
+ reply before sending more data.
+
+ Two new reply codes are hereby defined for errors
+ encountered in restarting a transfer:
+
+ 554 Requested action not taken: invalid REST parameter.
+
+ A 554 reply may result from a FTP service command that
+ follows a REST command. The reply indicates that the
+ existing file at the Server-FTP cannot be repositioned
+ as specified in the REST.
+
+ 555 Requested action not taken: type or stru mismatch.
+
+ A 555 reply may result from an APPE command or from any
+ FTP service command following a REST command. The
+ reply indicates that there is some mismatch between the
+ current transfer parameters (type and stru) and the
+ attributes of the existing file.
+
+ DISCUSSION:
+ Note that the FTP Restart mechanism requires that Block
+ or Compressed mode be used for data transfer, to allow
+ the Restart Markers to be included within the data
+ stream. The frequency of Restart Markers can be low.
+
+ Restart Markers mark a place in the data stream, but
+ the receiver may be performing some transformation on
+ the data as it is stored into stable storage. In
+ general, the receiver's encoding must include any state
+ information necessary to restart this transformation at
+ any point of the FTP data stream. For example, in TYPE
+
+
+
+Internet Engineering Task Force [Page 37]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ A transfers, some receiver hosts transform CR LF
+ sequences into a single LF character on disk. If a
+ Restart Marker happens to fall between CR and LF, the
+ receiver must encode in rrrr that the transfer must be
+ restarted in a "CR has been seen and discarded" state.
+
+ Note that the Restart Marker is required to be encoded
+ as a string of printable ASCII characters, regardless
+ of the type of the data.
+
+ RFC-959 says that restart information is to be returned
+ "to the user". This should not be taken literally. In
+ general, the User-FTP should save the restart
+ information (ssss,rrrr) in stable storage, e.g., append
+ it to a restart control file. An empty restart control
+ file should be created when the transfer first starts
+ and deleted automatically when the transfer completes
+ successfully. It is suggested that this file have a
+ name derived in an easily-identifiable manner from the
+ name of the file being transferred and the remote host
+ name; this is analogous to the means used by many text
+ editors for naming "backup" files.
+
+ There are three cases for FTP restart.
+
+ (1) User-to-Server Transfer
+
+ The User-FTP puts Restart Markers <ssss> at
+ convenient places in the data stream. When the
+ Server-FTP receives a Marker, it writes all prior
+ data to disk, encodes its file system position and
+ transformation state as rrrr, and returns a "110
+ MARK ssss = rrrr" reply over the control
+ connection. The User-FTP appends the pair
+ (ssss,rrrr) to its restart control file.
+
+ To restart the transfer, the User-FTP fetches the
+ last (ssss,rrrr) pair from the restart control
+ file, repositions its local file system and
+ transformation state using ssss, and sends the
+ command "REST rrrr" to the Server-FTP.
+
+ (2) Server-to-User Transfer
+
+ The Server-FTP puts Restart Markers <ssss> at
+ convenient places in the data stream. When the
+ User-FTP receives a Marker, it writes all prior
+ data to disk, encodes its file system position and
+
+
+
+Internet Engineering Task Force [Page 38]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ transformation state as rrrr, and appends the pair
+ (rrrr,ssss) to its restart control file.
+
+ To restart the transfer, the User-FTP fetches the
+ last (rrrr,ssss) pair from the restart control
+ file, repositions its local file system and
+ transformation state using rrrr, and sends the
+ command "REST ssss" to the Server-FTP.
+
+ (3) Server-to-Server ("Third-Party") Transfer
+
+ The sending Server-FTP puts Restart Markers <ssss>
+ at convenient places in the data stream. When it
+ receives a Marker, the receiving Server-FTP writes
+ all prior data to disk, encodes its file system
+ position and transformation state as rrrr, and
+ sends a "110 MARK ssss = rrrr" reply over the
+ control connection to the User. The User-FTP
+ appends the pair (ssss,rrrr) to its restart
+ control file.
+
+ To restart the transfer, the User-FTP fetches the
+ last (ssss,rrrr) pair from the restart control
+ file, sends "REST ssss" to the sending Server-FTP,
+ and sends "REST rrrr" to the receiving Server-FTP.
+
+
+ 4.1.4 FTP/USER INTERFACE
+
+ This section discusses the user interface for a User-FTP
+ program.
+
+ 4.1.4.1 Pathname Specification
+
+ Since FTP is intended for use in a heterogeneous
+ environment, User-FTP implementations MUST support remote
+ pathnames as arbitrary character strings, so that their form
+ and content are not limited by the conventions of the local
+ operating system.
+
+ DISCUSSION:
+ In particular, remote pathnames can be of arbitrary
+ length, and all the printing ASCII characters as well
+ as space (0x20) must be allowed. RFC-959 allows a
+ pathname to contain any 7-bit ASCII character except CR
+ or LF.
+
+
+
+
+
+Internet Engineering Task Force [Page 39]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ 4.1.4.2 "QUOTE" Command
+
+ A User-FTP program MUST implement a "QUOTE" command that
+ will pass an arbitrary character string to the server and
+ display all resulting response messages to the user.
+
+ To make the "QUOTE" command useful, a User-FTP SHOULD send
+ transfer control commands to the server as the user enters
+ them, rather than saving all the commands and sending them
+ to the server only when a data transfer is started.
+
+ DISCUSSION:
+ The "QUOTE" command is essential to allow the user to
+ access servers that require system-specific commands
+ (e.g., SITE or ALLO), or to invoke new or optional
+ features that are not implemented by the User-FTP. For
+ example, "QUOTE" may be used to specify "TYPE A T" to
+ send a print file to hosts that require the
+ distinction, even if the User-FTP does not recognize
+ that TYPE.
+
+ 4.1.4.3 Displaying Replies to User
+
+ A User-FTP SHOULD display to the user the full text of all
+ error reply messages it receives. It SHOULD have a
+ "verbose" mode in which all commands it sends and the full
+ text and reply codes it receives are displayed, for
+ diagnosis of problems.
+
+ 4.1.4.4 Maintaining Synchronization
+
+ The state machine in a User-FTP SHOULD be forgiving of
+ missing and unexpected reply messages, in order to maintain
+ command synchronization with the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 40]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ 4.1.5 FTP REQUIREMENTS SUMMARY
+
+ | | | | |S| |
+ | | | | |H| |F
+ | | | | |O|M|o
+ | | |S| |U|U|o
+ | | |H| |L|S|t
+ | |M|O| |D|T|n
+ | |U|U|M| | |o
+ | |S|L|A|N|N|t
+ | |T|D|Y|O|O|t
+FEATURE |SECTION | | | |T|T|e
+-------------------------------------------|---------------|-|-|-|-|-|--
+Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | |
+File/Record transform invertible if poss. |4.1.2.4 | |x| | | |
+User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | |
+Server-FTP implement PASV |4.1.2.6 |x| | | | |
+ PASV is per-transfer |4.1.2.6 |x| | | | |
+NLST reply usable in RETR cmds |4.1.2.7 |x| | | | |
+Implied type for LIST and NLST |4.1.2.7 | |x| | | |
+SITE cmd for non-standard features |4.1.2.8 | |x| | | |
+STOU cmd return pathname as specified |4.1.2.9 |x| | | | |
+Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x|
+ | | | | | | |
+Server-FTP send only correct reply format |4.1.2.11 |x| | | | |
+Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | |
+ New reply code following Section 4.2 |4.1.2.11 | | |x| | |
+User-FTP use only high digit of reply |4.1.2.11 | |x| | | |
+User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | |
+User-FTP handle 421 reply specially |4.1.2.11 | | | |x| |
+ | | | | | | |
+Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | |
+User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x|
+User-FTP negotiate Telnet options |4.1.2.12 | | | | |x|
+Server-FTP handle Telnet options |4.1.2.12 |x| | | | |
+Handle "Experimental" directory cmds |4.1.3.1 | |x| | | |
+Idle timeout in server-FTP |4.1.3.2 | |x| | | |
+ Configurable idle timeout |4.1.3.2 | |x| | | |
+Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | |
+Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x|
+ | | | | | | |
+Support TYPE: | | | | | | |
+ ASCII - Non-Print (AN) |4.1.2.13 |x| | | | |
+ ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | |
+ ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | |
+ EBCDIC - (any form) |959 3.1.1.2 | | |x| | |
+ IMAGE |4.1.2.1 |x| | | | |
+ LOCAL 8 |4.1.2.1 |x| | | | |
+
+
+
+Internet Engineering Task Force [Page 41]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+ LOCAL m |4.1.2.1 | | |x| | |2
+ | | | | | | |
+Support MODE: | | | | | | |
+ Stream |4.1.2.13 |x| | | | |
+ Block |959 3.4.2 | | |x| | |
+ | | | | | | |
+Support STRUCTURE: | | | | | | |
+ File |4.1.2.13 |x| | | | |
+ Record |4.1.2.13 |x| | | | |3
+ Page |4.1.2.3 | | | |x| |
+ | | | | | | |
+Support commands: | | | | | | |
+ USER |4.1.2.13 |x| | | | |
+ PASS |4.1.2.13 |x| | | | |
+ ACCT |4.1.2.13 |x| | | | |
+ CWD |4.1.2.13 |x| | | | |
+ CDUP |4.1.2.13 |x| | | | |
+ SMNT |959 5.3.1 | | |x| | |
+ REIN |959 5.3.1 | | |x| | |
+ QUIT |4.1.2.13 |x| | | | |
+ | | | | | | |
+ PORT |4.1.2.13 |x| | | | |
+ PASV |4.1.2.6 |x| | | | |
+ TYPE |4.1.2.13 |x| | | | |1
+ STRU |4.1.2.13 |x| | | | |1
+ MODE |4.1.2.13 |x| | | | |1
+ | | | | | | |
+ RETR |4.1.2.13 |x| | | | |
+ STOR |4.1.2.13 |x| | | | |
+ STOU |959 5.3.1 | | |x| | |
+ APPE |4.1.2.13 |x| | | | |
+ ALLO |959 5.3.1 | | |x| | |
+ REST |959 5.3.1 | | |x| | |
+ RNFR |4.1.2.13 |x| | | | |
+ RNTO |4.1.2.13 |x| | | | |
+ ABOR |959 5.3.1 | | |x| | |
+ DELE |4.1.2.13 |x| | | | |
+ RMD |4.1.2.13 |x| | | | |
+ MKD |4.1.2.13 |x| | | | |
+ PWD |4.1.2.13 |x| | | | |
+ LIST |4.1.2.13 |x| | | | |
+ NLST |4.1.2.13 |x| | | | |
+ SITE |4.1.2.8 | | |x| | |
+ STAT |4.1.2.13 |x| | | | |
+ SYST |4.1.2.13 |x| | | | |
+ HELP |4.1.2.13 |x| | | | |
+ NOOP |4.1.2.13 |x| | | | |
+ | | | | | | |
+
+
+
+Internet Engineering Task Force [Page 42]
+
+
+
+
+RFC1123 FILE TRANSFER -- FTP October 1989
+
+
+User Interface: | | | | | | |
+ Arbitrary pathnames |4.1.4.1 |x| | | | |
+ Implement "QUOTE" command |4.1.4.2 |x| | | | |
+ Transfer control commands immediately |4.1.4.2 | |x| | | |
+ Display error messages to user |4.1.4.3 | |x| | | |
+ Verbose mode |4.1.4.3 | |x| | | |
+ Maintain synchronization with server |4.1.4.4 | |x| | | |
+
+Footnotes:
+
+(1) For the values shown earlier.
+
+(2) Here m is number of bits in a memory word.
+
+(3) Required for host with record-structured file system, optional
+ otherwise.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 43]
+
+
+
+
+RFC1123 FILE TRANSFER -- TFTP October 1989
+
+
+ 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
+
+ 4.2.1 INTRODUCTION
+
+ The Trivial File Transfer Protocol TFTP is defined in RFC-783
+ [TFTP:1].
+
+ TFTP provides its own reliable delivery with UDP as its
+ transport protocol, using a simple stop-and-wait acknowledgment
+ system. Since TFTP has an effective window of only one 512
+ octet segment, it can provide good performance only over paths
+ that have a small delay*bandwidth product. The TFTP file
+ interface is very simple, providing no access control or
+ security.
+
+ TFTP's most important application is bootstrapping a host over
+ a local network, since it is simple and small enough to be
+ easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are
+ urged to support TFTP for booting.
+
+ 4.2.2 PROTOCOL WALK-THROUGH
+
+ The TFTP specification [TFTP:1] is written in an open style,
+ and does not fully specify many parts of the protocol.
+
+ 4.2.2.1 Transfer Modes: RFC-783, Page 3
+
+ The transfer mode "mail" SHOULD NOT be supported.
+
+ 4.2.2.2 UDP Header: RFC-783, Page 17
+
+ The Length field of a UDP header is incorrectly defined; it
+ includes the UDP header length (8).
+
+ 4.2.3 SPECIFIC ISSUES
+
+ 4.2.3.1 Sorcerer's Apprentice Syndrome
+
+ There is a serious bug, known as the "Sorcerer's Apprentice
+ Syndrome," in the protocol specification. While it does not
+ cause incorrect operation of the transfer (the file will
+ always be transferred correctly if the transfer completes),
+ this bug may cause excessive retransmission, which may cause
+ the transfer to time out.
+
+ Implementations MUST contain the fix for this problem: the
+ sender (i.e., the side originating the DATA packets) must
+ never resend the current DATA packet on receipt of a
+
+
+
+Internet Engineering Task Force [Page 44]
+
+
+
+
+RFC1123 FILE TRANSFER -- TFTP October 1989
+
+
+ duplicate ACK.
+
+ DISCUSSION:
+ The bug is caused by the protocol rule that either
+ side, on receiving an old duplicate datagram, may
+ resend the current datagram. If a packet is delayed in
+ the network but later successfully delivered after
+ either side has timed out and retransmitted a packet, a
+ duplicate copy of the response may be generated. If
+ the other side responds to this duplicate with a
+ duplicate of its own, then every datagram will be sent
+ in duplicate for the remainder of the transfer (unless
+ a datagram is lost, breaking the repetition). Worse
+ yet, since the delay is often caused by congestion,
+ this duplicate transmission will usually causes more
+ congestion, leading to more delayed packets, etc.
+
+ The following example may help to clarify this problem.
+
+ TFTP A TFTP B
+
+ (1) Receive ACK X-1
+ Send DATA X
+ (2) Receive DATA X
+ Send ACK X
+ (ACK X is delayed in network,
+ and A times out):
+ (3) Retransmit DATA X
+
+ (4) Receive DATA X again
+ Send ACK X again
+ (5) Receive (delayed) ACK X
+ Send DATA X+1
+ (6) Receive DATA X+1
+ Send ACK X+1
+ (7) Receive ACK X again
+ Send DATA X+1 again
+ (8) Receive DATA X+1 again
+ Send ACK X+1 again
+ (9) Receive ACK X+1
+ Send DATA X+2
+ (10) Receive DATA X+2
+ Send ACK X+3
+ (11) Receive ACK X+1 again
+ Send DATA X+2 again
+ (12) Receive DATA X+2 again
+ Send ACK X+3 again
+
+
+
+
+Internet Engineering Task Force [Page 45]
+
+
+
+
+RFC1123 FILE TRANSFER -- TFTP October 1989
+
+
+ Notice that once the delayed ACK arrives, the protocol
+ settles down to duplicate all further packets
+ (sequences 5-8 and 9-12). The problem is caused not by
+ either side timing out, but by both sides
+ retransmitting the current packet when they receive a
+ duplicate.
+
+ The fix is to break the retransmission loop, as
+ indicated above. This is analogous to the behavior of
+ TCP. It is then possible to remove the retransmission
+ timer on the receiver, since the resent ACK will never
+ cause any action; this is a useful simplification where
+ TFTP is used in a bootstrap program. It is OK to allow
+ the timer to remain, and it may be helpful if the
+ retransmitted ACK replaces one that was genuinely lost
+ in the network. The sender still requires a retransmit
+ timer, of course.
+
+ 4.2.3.2 Timeout Algorithms
+
+ A TFTP implementation MUST use an adaptive timeout.
+
+ IMPLEMENTATION:
+ TCP retransmission algorithms provide a useful base to
+ work from. At least an exponential backoff of
+ retransmission timeout is necessary.
+
+ 4.2.3.3 Extensions
+
+ A variety of non-standard extensions have been made to TFTP,
+ including additional transfer modes and a secure operation
+ mode (with passwords). None of these have been
+ standardized.
+
+ 4.2.3.4 Access Control
+
+ A server TFTP implementation SHOULD include some
+ configurable access control over what pathnames are allowed
+ in TFTP operations.
+
+ 4.2.3.5 Broadcast Request
+
+ A TFTP request directed to a broadcast address SHOULD be
+ silently ignored.
+
+ DISCUSSION:
+ Due to the weak access control capability of TFTP,
+ directed broadcasts of TFTP requests to random networks
+
+
+
+Internet Engineering Task Force [Page 46]
+
+
+
+
+RFC1123 FILE TRANSFER -- TFTP October 1989
+
+
+ could create a significant security hole.
+
+ 4.2.4 TFTP REQUIREMENTS SUMMARY
+
+ | | | | |S| |
+ | | | | |H| |F
+ | | | | |O|M|o
+ | | |S| |U|U|o
+ | | |H| |L|S|t
+ | |M|O| |D|T|n
+ | |U|U|M| | |o
+ | |S|L|A|N|N|t
+ | |T|D|Y|O|O|t
+FEATURE |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | |
+Transfer modes: | | | | | | |
+ netascii |RFC-783 |x| | | | |
+ octet |RFC-783 |x| | | | |
+ mail |4.2.2.1 | | | |x| |
+ extensions |4.2.3.3 | | |x| | |
+Use adaptive timeout |4.2.3.2 |x| | | | |
+Configurable access control |4.2.3.4 | |x| | | |
+Silently ignore broadcast request |4.2.3.5 | |x| | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+-------------------------------------------------|--------|-|-|-|-|-|--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 47]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+5. ELECTRONIC MAIL -- SMTP and RFC-822
+
+ 5.1 INTRODUCTION
+
+ In the TCP/IP protocol suite, electronic mail in a format
+ specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
+ Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
+
+ While SMTP has remained unchanged over the years, the Internet
+ community has made several changes in the way SMTP is used. In
+ particular, the conversion to the Domain Name System (DNS) has
+ caused changes in address formats and in mail routing. In this
+ section, we assume familiarity with the concepts and terminology
+ of the DNS, whose requirements are given in Section 6.1.
+
+ RFC-822 specifies the Internet standard format for electronic mail
+ messages. RFC-822 supercedes an older standard, RFC-733, that may
+ still be in use in a few places, although it is obsolete. The two
+ formats are sometimes referred to simply by number ("822" and
+ "733").
+
+ RFC-822 is used in some non-Internet mail environments with
+ different mail transfer protocols than SMTP, and SMTP has also
+ been adapted for use in some non-Internet environments. Note that
+ this document presents the rules for the use of SMTP and RFC-822
+ for the Internet environment only; other mail environments that
+ use these protocols may be expected to have their own rules.
+
+ 5.2 PROTOCOL WALK-THROUGH
+
+ This section covers both RFC-821 and RFC-822.
+
+ The SMTP specification in RFC-821 is clear and contains numerous
+ examples, so implementors should not find it difficult to
+ understand. This section simply updates or annotates portions of
+ RFC-821 to conform with current usage.
+
+ RFC-822 is a long and dense document, defining a rich syntax.
+ Unfortunately, incomplete or defective implementations of RFC-822
+ are common. In fact, nearly all of the many formats of RFC-822
+ are actually used, so an implementation generally needs to
+ recognize and correctly interpret all of the RFC-822 syntax.
+
+ 5.2.1 The SMTP Model: RFC-821 Section 2
+
+ DISCUSSION:
+ Mail is sent by a series of request/response transactions
+ between a client, the "sender-SMTP," and a server, the
+
+
+
+Internet Engineering Task Force [Page 48]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ "receiver-SMTP". These transactions pass (1) the message
+ proper, which is composed of header and body, and (2) SMTP
+ source and destination addresses, referred to as the
+ "envelope".
+
+ The SMTP programs are analogous to Message Transfer Agents
+ (MTAs) of X.400. There will be another level of protocol
+ software, closer to the end user, that is responsible for
+ composing and analyzing RFC-822 message headers; this
+ component is known as the "User Agent" in X.400, and we
+ use that term in this document. There is a clear logical
+ distinction between the User Agent and the SMTP
+ implementation, since they operate on different levels of
+ protocol. Note, however, that this distinction is may not
+ be exactly reflected the structure of typical
+ implementations of Internet mail. Often there is a
+ program known as the "mailer" that implements SMTP and
+ also some of the User Agent functions; the rest of the
+ User Agent functions are included in a user interface used
+ for entering and reading mail.
+
+ The SMTP envelope is constructed at the originating site,
+ typically by the User Agent when the message is first
+ queued for the Sender-SMTP program. The envelope
+ addresses may be derived from information in the message
+ header, supplied by the user interface (e.g., to implement
+ a bcc: request), or derived from local configuration
+ information (e.g., expansion of a mailing list). The SMTP
+ envelope cannot in general be re-derived from the header
+ at a later stage in message delivery, so the envelope is
+ transmitted separately from the message itself using the
+ MAIL and RCPT commands of SMTP.
+
+ The text of RFC-821 suggests that mail is to be delivered
+ to an individual user at a host. With the advent of the
+ domain system and of mail routing using mail-exchange (MX)
+ resource records, implementors should now think of
+ delivering mail to a user at a domain, which may or may
+ not be a particular host. This DOES NOT change the fact
+ that SMTP is a host-to-host mail exchange protocol.
+
+ 5.2.2 Canonicalization: RFC-821 Section 3.1
+
+ The domain names that a Sender-SMTP sends in MAIL and RCPT
+ commands MUST have been "canonicalized," i.e., they must be
+ fully-qualified principal names or domain literals, not
+ nicknames or domain abbreviations. A canonicalized name either
+ identifies a host directly or is an MX name; it cannot be a
+
+
+
+Internet Engineering Task Force [Page 49]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ CNAME.
+
+ 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3
+
+ A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
+ (this requirement overrides RFC-821). However, there MAY be
+ configuration information to disable VRFY and EXPN in a
+ particular installation; this might even allow EXPN to be
+ disabled for selected lists.
+
+ A new reply code is defined for the VRFY command:
+
+ 252 Cannot VRFY user (e.g., info is not local), but will
+ take message for this user and attempt delivery.
+
+ DISCUSSION:
+ SMTP users and administrators make regular use of these
+ commands for diagnosing mail delivery problems. With the
+ increasing use of multi-level mailing list expansion
+ (sometimes more than two levels), EXPN has been
+ increasingly important for diagnosing inadvertent mail
+ loops. On the other hand, some feel that EXPN represents
+ a significant privacy, and perhaps even a security,
+ exposure.
+
+ 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4
+
+ An SMTP MAY implement the commands to send a message to a
+ user's terminal: SEND, SOML, and SAML.
+
+ DISCUSSION:
+ It has been suggested that the use of mail relaying
+ through an MX record is inconsistent with the intent of
+ SEND to deliver a message immediately and directly to a
+ user's terminal. However, an SMTP receiver that is unable
+ to write directly to the user terminal can return a "251
+ User Not Local" reply to the RCPT following a SEND, to
+ inform the originator of possibly deferred delivery.
+
+ 5.2.5 HELO Command: RFC-821 Section 3.5
+
+ The sender-SMTP MUST ensure that the <domain> parameter in a
+ HELO command is a valid principal host domain name for the
+ client host. As a result, the receiver-SMTP will not have to
+ perform MX resolution on this name in order to validate the
+ HELO parameter.
+
+ The HELO receiver MAY verify that the HELO parameter really
+
+
+
+Internet Engineering Task Force [Page 50]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ corresponds to the IP address of the sender. However, the
+ receiver MUST NOT refuse to accept a message, even if the
+ sender's HELO command fails verification.
+
+ DISCUSSION:
+ Verifying the HELO parameter requires a domain name lookup
+ and may therefore take considerable time. An alternative
+ tool for tracking bogus mail sources is suggested below
+ (see "DATA Command").
+
+ Note also that the HELO argument is still required to have
+ valid <domain> syntax, since it will appear in a Received:
+ line; otherwise, a 501 error is to be sent.
+
+ IMPLEMENTATION:
+ When HELO parameter validation fails, a suggested
+ procedure is to insert a note about the unknown
+ authenticity of the sender into the message header (e.g.,
+ in the "Received:" line).
+
+ 5.2.6 Mail Relay: RFC-821 Section 3.6
+
+ We distinguish three types of mail (store-and-) forwarding:
+
+ (1) A simple forwarder or "mail exchanger" forwards a message
+ using private knowledge about the recipient; see section
+ 3.2 of RFC-821.
+
+ (2) An SMTP mail "relay" forwards a message within an SMTP
+ mail environment as the result of an explicit source route
+ (as defined in section 3.6 of RFC-821). The SMTP relay
+ function uses the "@...:" form of source route from RFC-
+ 822 (see Section 5.2.19 below).
+
+ (3) A mail "gateway" passes a message between different
+ environments. The rules for mail gateways are discussed
+ below in Section 5.3.7.
+
+ An Internet host that is forwarding a message but is not a
+ gateway to a different mail environment (i.e., it falls under
+ (1) or (2)) SHOULD NOT alter any existing header fields,
+ although the host will add an appropriate Received: line as
+ required in Section 5.2.8.
+
+ A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
+ explicit source route using the "@...:" address form. Thus,
+ the relay function defined in section 3.6 of RFC-821 should
+ not be used.
+
+
+
+Internet Engineering Task Force [Page 51]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ DISCUSSION:
+ The intent is to discourage all source routing and to
+ abolish explicit source routing for mail delivery within
+ the Internet environment. Source-routing is unnecessary;
+ the simple target address "user@domain" should always
+ suffice. This is the result of an explicit architectural
+ decision to use universal naming rather than source
+ routing for mail. Thus, SMTP provides end-to-end
+ connectivity, and the DNS provides globally-unique,
+ location-independent names. MX records handle the major
+ case where source routing might otherwise be needed.
+
+ A receiver-SMTP MUST accept the explicit source route syntax in
+ the envelope, but it MAY implement the relay function as
+ defined in section 3.6 of RFC-821. If it does not implement
+ the relay function, it SHOULD attempt to deliver the message
+ directly to the host to the right of the right-most "@" sign.
+
+ DISCUSSION:
+ For example, suppose a host that does not implement the
+ relay function receives a message with the SMTP command:
+ "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
+ GAMMA represent domain names. Rather than immediately
+ refusing the message with a 550 error reply as suggested
+ on page 20 of RFC-821, the host should try to forward the
+ message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
+ Since this host does not support relaying, it is not
+ required to update the reverse path.
+
+ Some have suggested that source routing may be needed
+ occasionally for manually routing mail around failures;
+ however, the reality and importance of this need is
+ controversial. The use of explicit SMTP mail relaying for
+ this purpose is discouraged, and in fact it may not be
+ successful, as many host systems do not support it. Some
+ have used the "%-hack" (see Section 5.2.16) for this
+ purpose.
+
+ 5.2.7 RCPT Command: RFC-821 Section 4.1.1
+
+ A host that supports a receiver-SMTP MUST support the reserved
+ mailbox "Postmaster".
+
+ The receiver-SMTP MAY verify RCPT parameters as they arrive;
+ however, RCPT responses MUST NOT be delayed beyond a reasonable
+ time (see Section 5.3.2).
+
+ Therefore, a "250 OK" response to a RCPT does not necessarily
+
+
+
+Internet Engineering Task Force [Page 52]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ imply that the delivery address(es) are valid. Errors found
+ after message acceptance will be reported by mailing a
+ notification message to an appropriate address (see Section
+ 5.3.3).
+
+ DISCUSSION:
+ The set of conditions under which a RCPT parameter can be
+ validated immediately is an engineering design choice.
+ Reporting destination mailbox errors to the Sender-SMTP
+ before mail is transferred is generally desirable to save
+ time and network bandwidth, but this advantage is lost if
+ RCPT verification is lengthy.
+
+ For example, the receiver can verify immediately any
+ simple local reference, such as a single locally-
+ registered mailbox. On the other hand, the "reasonable
+ time" limitation generally implies deferring verification
+ of a mailing list until after the message has been
+ transferred and accepted, since verifying a large mailing
+ list can take a very long time. An implementation might
+ or might not choose to defer validation of addresses that
+ are non-local and therefore require a DNS lookup. If a
+ DNS lookup is performed but a soft domain system error
+ (e.g., timeout) occurs, validity must be assumed.
+
+ 5.2.8 DATA Command: RFC-821 Section 4.1.1
+
+ Every receiver-SMTP (not just one that "accepts a message for
+ relaying or for final delivery" [SMTP:1]) MUST insert a
+ "Received:" line at the beginning of a message. In this line,
+ called a "time stamp line" in RFC-821:
+
+ * The FROM field SHOULD contain both (1) the name of the
+ source host as presented in the HELO command and (2) a
+ domain literal containing the IP address of the source,
+ determined from the TCP connection.
+
+ * The ID field MAY contain an "@" as suggested in RFC-822,
+ but this is not required.
+
+ * The FOR field MAY contain a list of <path> entries when
+ multiple RCPT commands have been given.
+
+
+ An Internet mail program MUST NOT change a Received: line that
+ was previously added to the message header.
+
+
+
+
+
+Internet Engineering Task Force [Page 53]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ DISCUSSION:
+ Including both the source host and the IP source address
+ in the Received: line may provide enough information for
+ tracking illicit mail sources and eliminate a need to
+ explicitly verify the HELO parameter.
+
+ Received: lines are primarily intended for humans tracing
+ mail routes, primarily of diagnosis of faults. See also
+ the discussion under 5.3.7.
+
+ When the receiver-SMTP makes "final delivery" of a message,
+ then it MUST pass the MAIL FROM: address from the SMTP envelope
+ with the message, for use if an error notification message must
+ be sent later (see Section 5.3.3). There is an analogous
+ requirement when gatewaying from the Internet into a different
+ mail environment; see Section 5.3.7.
+
+ DISCUSSION:
+ Note that the final reply to the DATA command depends only
+ upon the successful transfer and storage of the message.
+ Any problem with the destination address(es) must either
+ (1) have been reported in an SMTP error reply to the RCPT
+ command(s), or (2) be reported in a later error message
+ mailed to the originator.
+
+ IMPLEMENTATION:
+ The MAIL FROM: information may be passed as a parameter or
+ in a Return-Path: line inserted at the beginning of the
+ message.
+
+ 5.2.9 Command Syntax: RFC-821 Section 4.1.2
+
+ The syntax shown in RFC-821 for the MAIL FROM: command omits
+ the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page
+ 15). An empty reverse path MUST be supported.
+
+ 5.2.10 SMTP Replies: RFC-821 Section 4.2
+
+ A receiver-SMTP SHOULD send only the reply codes listed in
+ section 4.2.2 of RFC-821 or in this document. A receiver-SMTP
+ SHOULD use the text shown in examples in RFC-821 whenever
+ appropriate.
+
+ A sender-SMTP MUST determine its actions only by the reply
+ code, not by the text (except for 251 and 551 replies); any
+ text, including no text at all, must be acceptable. The space
+ (blank) following the reply code is considered part of the
+ text. Whenever possible, a sender-SMTP SHOULD test only the
+
+
+
+Internet Engineering Task Force [Page 54]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ first digit of the reply code, as specified in Appendix E of
+ RFC-821.
+
+ DISCUSSION:
+ Interoperability problems have arisen with SMTP systems
+ using reply codes that are not listed explicitly in RFC-
+ 821 Section 4.3 but are legal according to the theory of
+ reply codes explained in Appendix E.
+
+ 5.2.11 Transparency: RFC-821 Section 4.5.2
+
+ Implementors MUST be sure that their mail systems always add
+ and delete periods to ensure message transparency.
+
+ 5.2.12 WKS Use in MX Processing: RFC-974, p. 5
+
+ RFC-974 [SMTP:3] recommended that the domain system be queried
+ for WKS ("Well-Known Service") records, to verify that each
+ proposed mail target does support SMTP. Later experience has
+ shown that WKS is not widely supported, so the WKS step in MX
+ processing SHOULD NOT be used.
+
+ The following are notes on RFC-822, organized by section of that
+ document.
+
+ 5.2.13 RFC-822 Message Specification: RFC-822 Section 4
+
+ The syntax shown for the Return-path line omits the possibility
+ of a null return path, which is used to prevent looping of
+ error notifications (see Section 5.3.3). The complete syntax
+ is:
+
+ return = "Return-path" ":" route-addr
+ / "Return-path" ":" "<" ">"
+
+ The set of optional header fields is hereby expanded to include
+ the Content-Type field defined in RFC-1049 [SMTP:7]. This
+ field "allows mail reading systems to automatically identify
+ the type of a structured message body and to process it for
+ display accordingly". [SMTP:7] A User Agent MAY support this
+ field.
+
+ 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5
+
+ The syntax for the date is hereby changed to:
+
+ date = 1*2DIGIT month 2*4DIGIT
+
+
+
+
+Internet Engineering Task Force [Page 55]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ All mail software SHOULD use 4-digit years in dates, to ease
+ the transition to the next century.
+
+ There is a strong trend towards the use of numeric timezone
+ indicators, and implementations SHOULD use numeric timezones
+ instead of timezone names. However, all implementations MUST
+ accept either notation. If timezone names are used, they MUST
+ be exactly as defined in RFC-822.
+
+ The military time zones are specified incorrectly in RFC-822:
+ they count the wrong way from UT (the signs are reversed). As
+ a result, military time zones in RFC-822 headers carry no
+ information.
+
+ Finally, note that there is a typo in the definition of "zone"
+ in the syntax summary of appendix D; the correct definition
+ occurs in Section 3 of RFC-822.
+
+ 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1
+
+ The syntactic definition of "mailbox" in RFC-822 is hereby
+ changed to:
+
+ mailbox = addr-spec ; simple address
+ / [phrase] route-addr ; name & addr-spec
+
+ That is, the phrase preceding a route address is now OPTIONAL.
+ This change makes the following header field legal, for
+ example:
+
+ From: <craig@nnsc.nsf.net>
+
+ 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2
+
+ The basic mailbox address specification has the form: "local-
+ part@domain". Here "local-part", sometimes called the "left-
+ hand side" of the address, is domain-dependent.
+
+ A host that is forwarding the message but is not the
+ destination host implied by the right-hand side "domain" MUST
+ NOT interpret or modify the "local-part" of the address.
+
+ When mail is to be gatewayed from the Internet mail environment
+ into a foreign mail environment (see Section 5.3.7), routing
+ information for that foreign environment MAY be embedded within
+ the "local-part" of the address. The gateway will then
+ interpret this local part appropriately for the foreign mail
+ environment.
+
+
+
+Internet Engineering Task Force [Page 56]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ DISCUSSION:
+ Although source routes are discouraged within the Internet
+ (see Section 5.2.6), there are non-Internet mail
+ environments whose delivery mechanisms do depend upon
+ source routes. Source routes for extra-Internet
+ environments can generally be buried in the "local-part"
+ of the address (see Section 5.2.16) while mail traverses
+ the Internet. When the mail reaches the appropriate
+ Internet mail gateway, the gateway will interpret the
+ local-part and build the necessary address or route for
+ the target mail environment.
+
+ For example, an Internet host might send mail to:
+ "a!b!c!user@gateway-domain". The complex local part
+ "a!b!c!user" would be uninterpreted within the Internet
+ domain, but could be parsed and understood by the
+ specified mail gateway.
+
+ An embedded source route is sometimes encoded in the
+ "local-part" using "%" as a right-binding routing
+ operator. For example, in:
+
+ user%domain%relay3%relay2@relay1
+
+ the "%" convention implies that the mail is to be routed
+ from "relay1" through "relay2", "relay3", and finally to
+ "user" at "domain". This is commonly known as the "%-
+ hack". It is suggested that "%" have lower precedence
+ than any other routing operator (e.g., "!") hidden in the
+ local-part; for example, "a!b%c" would be interpreted as
+ "(a!b)%c".
+
+ Only the target host (in this case, "relay1") is permitted
+ to analyze the local-part "user%domain%relay3%relay2".
+
+ 5.2.17 Domain Literals: RFC-822 Section 6.2.3
+
+ A mailer MUST be able to accept and parse an Internet domain
+ literal whose content ("dtext"; see RFC-822) is a dotted-
+ decimal host address. This satisfies the requirement of
+ Section 2.1 for the case of mail.
+
+ An SMTP MUST accept and recognize a domain literal for any of
+ its own IP addresses.
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 57]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1
+
+ Errors in formatting or parsing 822 addresses are unfortunately
+ common. This section mentions only the most common errors. A
+ User Agent MUST accept all valid RFC-822 address formats, and
+ MUST NOT generate illegal address syntax.
+
+ o A common error is to leave out the semicolon after a group
+ identifier.
+
+ o Some systems fail to fully-qualify domain names in
+ messages they generate. The right-hand side of an "@"
+ sign in a header address field MUST be a fully-qualified
+ domain name.
+
+ For example, some systems fail to fully-qualify the From:
+ address; this prevents a "reply" command in the user
+ interface from automatically constructing a return
+ address.
+
+ DISCUSSION:
+ Although RFC-822 allows the local use of abbreviated
+ domain names within a domain, the application of
+ RFC-822 in Internet mail does not allow this. The
+ intent is that an Internet host must not send an SMTP
+ message header containing an abbreviated domain name
+ in an address field. This allows the address fields
+ of the header to be passed without alteration across
+ the Internet, as required in Section 5.2.6.
+
+ o Some systems mis-parse multiple-hop explicit source routes
+ such as:
+
+ @relay1,@relay2,@relay3:user@domain.
+
+
+ o Some systems over-qualify domain names by adding a
+ trailing dot to some or all domain names in addresses or
+ message-ids. This violates RFC-822 syntax.
+
+
+ 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7
+
+ Internet host software SHOULD NOT create an RFC-822 header
+ containing an address with an explicit source route, but MUST
+ accept such headers for compatibility with earlier systems.
+
+ DISCUSSION:
+
+
+
+Internet Engineering Task Force [Page 58]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ In an understatement, RFC-822 says "The use of explicit
+ source routing is discouraged". Many hosts implemented
+ RFC-822 source routes incorrectly, so the syntax cannot be
+ used unambiguously in practice. Many users feel the
+ syntax is ugly. Explicit source routes are not needed in
+ the mail envelope for delivery; see Section 5.2.6. For
+ all these reasons, explicit source routes using the RFC-
+ 822 notations are not to be used in Internet mail headers.
+
+ As stated in Section 5.2.16, it is necessary to allow an
+ explicit source route to be buried in the local-part of an
+ address, e.g., using the "%-hack", in order to allow mail
+ to be gatewayed into another environment in which explicit
+ source routing is necessary. The vigilant will observe
+ that there is no way for a User Agent to detect and
+ prevent the use of such implicit source routing when the
+ destination is within the Internet. We can only
+ discourage source routing of any kind within the Internet,
+ as unnecessary and undesirable.
+
+ 5.3 SPECIFIC ISSUES
+
+ 5.3.1 SMTP Queueing Strategies
+
+ The common structure of a host SMTP implementation includes
+ user mailboxes, one or more areas for queueing messages in
+ transit, and one or more daemon processes for sending and
+ receiving mail. The exact structure will vary depending on the
+ needs of the users on the host and the number and size of
+ mailing lists supported by the host. We describe several
+ optimizations that have proved helpful, particularly for
+ mailers supporting high traffic levels.
+
+ Any queueing strategy MUST include:
+
+ o Timeouts on all activities. See Section 5.3.2.
+
+ o Never sending error messages in response to error
+ messages.
+
+
+ 5.3.1.1 Sending Strategy
+
+ The general model of a sender-SMTP is one or more processes
+ that periodically attempt to transmit outgoing mail. In a
+ typical system, the program that composes a message has some
+ method for requesting immediate attention for a new piece of
+ outgoing mail, while mail that cannot be transmitted
+
+
+
+Internet Engineering Task Force [Page 59]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ immediately MUST be queued and periodically retried by the
+ sender. A mail queue entry will include not only the
+ message itself but also the envelope information.
+
+ The sender MUST delay retrying a particular destination
+ after one attempt has failed. In general, the retry
+ interval SHOULD be at least 30 minutes; however, more
+ sophisticated and variable strategies will be beneficial
+ when the sender-SMTP can determine the reason for non-
+ delivery.
+
+ Retries continue until the message is transmitted or the
+ sender gives up; the give-up time generally needs to be at
+ least 4-5 days. The parameters to the retry algorithm MUST
+ be configurable.
+
+ A sender SHOULD keep a list of hosts it cannot reach and
+ corresponding timeouts, rather than just retrying queued
+ mail items.
+
+ DISCUSSION:
+ Experience suggests that failures are typically
+ transient (the target system has crashed), favoring a
+ policy of two connection attempts in the first hour the
+ message is in the queue, and then backing off to once
+ every two or three hours.
+
+ The sender-SMTP can shorten the queueing delay by
+ cooperation with the receiver-SMTP. In particular, if
+ mail is received from a particular address, it is good
+ evidence that any mail queued for that host can now be
+ sent.
+
+ The strategy may be further modified as a result of
+ multiple addresses per host (see Section 5.3.4), to
+ optimize delivery time vs. resource usage.
+
+ A sender-SMTP may have a large queue of messages for
+ each unavailable destination host, and if it retried
+ all these messages in every retry cycle, there would be
+ excessive Internet overhead and the daemon would be
+ blocked for a long period. Note that an SMTP can
+ generally determine that a delivery attempt has failed
+ only after a timeout of a minute or more; a one minute
+ timeout per connection will result in a very large
+ delay if it is repeated for dozens or even hundreds of
+ queued messages.
+
+
+
+
+Internet Engineering Task Force [Page 60]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ When the same message is to be delivered to several users on
+ the same host, only one copy of the message SHOULD be
+ transmitted. That is, the sender-SMTP should use the
+ command sequence: RCPT, RCPT,... RCPT, DATA instead of the
+ sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
+ Implementation of this efficiency feature is strongly urged.
+
+ Similarly, the sender-SMTP MAY support multiple concurrent
+ outgoing mail transactions to achieve timely delivery.
+ However, some limit SHOULD be imposed to protect the host
+ from devoting all its resources to mail.
+
+ The use of the different addresses of a multihomed host is
+ discussed below.
+
+ 5.3.1.2 Receiving strategy
+
+ The receiver-SMTP SHOULD attempt to keep a pending listen on
+ the SMTP port at all times. This will require the support
+ of multiple incoming TCP connections for SMTP. Some limit
+ MAY be imposed.
+
+ IMPLEMENTATION:
+ When the receiver-SMTP receives mail from a particular
+ host address, it could notify the sender-SMTP to retry
+ any mail pending for that host address.
+
+ 5.3.2 Timeouts in SMTP
+
+ There are two approaches to timeouts in the sender-SMTP: (a)
+ limit the time for each SMTP command separately, or (b) limit
+ the time for the entire SMTP dialogue for a single mail
+ message. A sender-SMTP SHOULD use option (a), per-command
+ timeouts. Timeouts SHOULD be easily reconfigurable, preferably
+ without recompiling the SMTP code.
+
+ DISCUSSION:
+ Timeouts are an essential feature of an SMTP
+ implementation. If the timeouts are too long (or worse,
+ there are no timeouts), Internet communication failures or
+ software bugs in receiver-SMTP programs can tie up SMTP
+ processes indefinitely. If the timeouts are too short,
+ resources will be wasted with attempts that time out part
+ way through message delivery.
+
+ If option (b) is used, the timeout has to be very large,
+ e.g., an hour, to allow time to expand very large mailing
+ lists. The timeout may also need to increase linearly
+
+
+
+Internet Engineering Task Force [Page 61]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ with the size of the message, to account for the time to
+ transmit a very large message. A large fixed timeout
+ leads to two problems: a failure can still tie up the
+ sender for a very long time, and very large messages may
+ still spuriously time out (which is a wasteful failure!).
+
+ Using the recommended option (a), a timer is set for each
+ SMTP command and for each buffer of the data transfer.
+ The latter means that the overall timeout is inherently
+ proportional to the size of the message.
+
+ Based on extensive experience with busy mail-relay hosts, the
+ minimum per-command timeout values SHOULD be as follows:
+
+ o Initial 220 Message: 5 minutes
+
+ A Sender-SMTP process needs to distinguish between a
+ failed TCP connection and a delay in receiving the initial
+ 220 greeting message. Many receiver-SMTPs will accept a
+ TCP connection but delay delivery of the 220 message until
+ their system load will permit more mail to be processed.
+
+ o MAIL Command: 5 minutes
+
+
+ o RCPT Command: 5 minutes
+
+ A longer timeout would be required if processing of
+ mailing lists and aliases were not deferred until after
+ the message was accepted.
+
+ o DATA Initiation: 2 minutes
+
+ This is while awaiting the "354 Start Input" reply to a
+ DATA command.
+
+ o Data Block: 3 minutes
+
+ This is while awaiting the completion of each TCP SEND
+ call transmitting a chunk of data.
+
+ o DATA Termination: 10 minutes.
+
+ This is while awaiting the "250 OK" reply. When the
+ receiver gets the final period terminating the message
+ data, it typically performs processing to deliver the
+ message to a user mailbox. A spurious timeout at this
+ point would be very wasteful, since the message has been
+
+
+
+Internet Engineering Task Force [Page 62]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ successfully sent.
+
+ A receiver-SMTP SHOULD have a timeout of at least 5 minutes
+ while it is awaiting the next command from the sender.
+
+ 5.3.3 Reliable Mail Receipt
+
+ When the receiver-SMTP accepts a piece of mail (by sending a
+ "250 OK" message in response to DATA), it is accepting
+ responsibility for delivering or relaying the message. It must
+ take this responsibility seriously, i.e., it MUST NOT lose the
+ message for frivolous reasons, e.g., because the host later
+ crashes or because of a predictable resource shortage.
+
+ If there is a delivery failure after acceptance of a message,
+ the receiver-SMTP MUST formulate and mail a notification
+ message. This notification MUST be sent using a null ("<>")
+ reverse path in the envelope; see Section 3.6 of RFC-821. The
+ recipient of this notification SHOULD be the address from the
+ envelope return path (or the Return-Path: line). However, if
+ this address is null ("<>"), the receiver-SMTP MUST NOT send a
+ notification. If the address is an explicit source route, it
+ SHOULD be stripped down to its final hop.
+
+ DISCUSSION:
+ For example, suppose that an error notification must be
+ sent for a message that arrived with:
+ "MAIL FROM:<@a,@b:user@d>". The notification message
+ should be sent to: "RCPT TO:<user@d>".
+
+ Some delivery failures after the message is accepted by
+ SMTP will be unavoidable. For example, it may be
+ impossible for the receiver-SMTP to validate all the
+ delivery addresses in RCPT command(s) due to a "soft"
+ domain system error or because the target is a mailing
+ list (see earlier discussion of RCPT).
+
+ To avoid receiving duplicate messages as the result of
+ timeouts, a receiver-SMTP MUST seek to minimize the time
+ required to respond to the final "." that ends a message
+ transfer. See RFC-1047 [SMTP:4] for a discussion of this
+ problem.
+
+ 5.3.4 Reliable Mail Transmission
+
+ To transmit a message, a sender-SMTP determines the IP address
+ of the target host from the destination address in the
+ envelope. Specifically, it maps the string to the right of the
+
+
+
+Internet Engineering Task Force [Page 63]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ "@" sign into an IP address. This mapping or the transfer
+ itself may fail with a soft error, in which case the sender-
+ SMTP will requeue the outgoing mail for a later retry, as
+ required in Section 5.3.1.1.
+
+ When it succeeds, the mapping can result in a list of
+ alternative delivery addresses rather than a single address,
+ because of (a) multiple MX records, (b) multihoming, or both.
+ To provide reliable mail transmission, the sender-SMTP MUST be
+ able to try (and retry) each of the addresses in this list in
+ order, until a delivery attempt succeeds. However, there MAY
+ also be a configurable limit on the number of alternate
+ addresses that can be tried. In any case, a host SHOULD try at
+ least two addresses.
+
+ The following information is to be used to rank the host
+ addresses:
+
+ (1) Multiple MX Records -- these contain a preference
+ indication that should be used in sorting. If there are
+ multiple destinations with the same preference and there
+ is no clear reason to favor one (e.g., by address
+ preference), then the sender-SMTP SHOULD pick one at
+ random to spread the load across multiple mail exchanges
+ for a specific organization; note that this is a
+ refinement of the procedure in [DNS:3].
+
+ (2) Multihomed host -- The destination host (perhaps taken
+ from the preferred MX record) may be multihomed, in which
+ case the domain name resolver will return a list of
+ alternative IP addresses. It is the responsibility of the
+ domain name resolver interface (see Section 6.1.3.4 below)
+ to have ordered this list by decreasing preference, and
+ SMTP MUST try them in the order presented.
+
+ DISCUSSION:
+ Although the capability to try multiple alternative
+ addresses is required, there may be circumstances where
+ specific installations want to limit or disable the use of
+ alternative addresses. The question of whether a sender
+ should attempt retries using the different addresses of a
+ multihomed host has been controversial. The main argument
+ for using the multiple addresses is that it maximizes the
+ probability of timely delivery, and indeed sometimes the
+ probability of any delivery; the counter argument is that
+ it may result in unnecessary resource use.
+
+ Note that resource use is also strongly determined by the
+
+
+
+Internet Engineering Task Force [Page 64]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ sending strategy discussed in Section 5.3.1.
+
+ 5.3.5 Domain Name Support
+
+ SMTP implementations MUST use the mechanism defined in Section
+ 6.1 for mapping between domain names and IP addresses. This
+ means that every Internet SMTP MUST include support for the
+ Internet DNS.
+
+ In particular, a sender-SMTP MUST support the MX record scheme
+ [SMTP:3]. See also Section 7.4 of [DNS:2] for information on
+ domain name support for SMTP.
+
+ 5.3.6 Mailing Lists and Aliases
+
+ An SMTP-capable host SHOULD support both the alias and the list
+ form of address expansion for multiple delivery. When a
+ message is delivered or forwarded to each address of an
+ expanded list form, the return address in the envelope
+ ("MAIL FROM:") MUST be changed to be the address of a person
+ who administers the list, but the message header MUST be left
+ unchanged; in particular, the "From" field of the message is
+ unaffected.
+
+ DISCUSSION:
+ An important mail facility is a mechanism for multi-
+ destination delivery of a single message, by transforming
+ or "expanding" a pseudo-mailbox address into a list of
+ destination mailbox addresses. When a message is sent to
+ such a pseudo-mailbox (sometimes called an "exploder"),
+ copies are forwarded or redistributed to each mailbox in
+ the expanded list. We classify such a pseudo-mailbox as
+ an "alias" or a "list", depending upon the expansion
+ rules:
+
+ (a) Alias
+
+ To expand an alias, the recipient mailer simply
+ replaces the pseudo-mailbox address in the envelope
+ with each of the expanded addresses in turn; the rest
+ of the envelope and the message body are left
+ unchanged. The message is then delivered or
+ forwarded to each expanded address.
+
+ (b) List
+
+ A mailing list may be said to operate by
+ "redistribution" rather than by "forwarding". To
+
+
+
+Internet Engineering Task Force [Page 65]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ expand a list, the recipient mailer replaces the
+ pseudo-mailbox address in the envelope with each of
+ the expanded addresses in turn. The return address in
+ the envelope is changed so that all error messages
+ generated by the final deliveries will be returned to
+ a list administrator, not to the message originator,
+ who generally has no control over the contents of the
+ list and will typically find error messages annoying.
+
+
+ 5.3.7 Mail Gatewaying
+
+ Gatewaying mail between different mail environments, i.e.,
+ different mail formats and protocols, is complex and does not
+ easily yield to standardization. See for example [SMTP:5a],
+ [SMTP:5b]. However, some general requirements may be given for
+ a gateway between the Internet and another mail environment.
+
+ (A) Header fields MAY be rewritten when necessary as messages
+ are gatewayed across mail environment boundaries.
+
+ DISCUSSION:
+ This may involve interpreting the local-part of the
+ destination address, as suggested in Section 5.2.16.
+
+ The other mail systems gatewayed to the Internet
+ generally use a subset of RFC-822 headers, but some
+ of them do not have an equivalent to the SMTP
+ envelope. Therefore, when a message leaves the
+ Internet environment, it may be necessary to fold the
+ SMTP envelope information into the message header. A
+ possible solution would be to create new header
+ fields to carry the envelope information (e.g., "X-
+ SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
+ require changes in mail programs in the foreign
+ environment.
+
+ (B) When forwarding a message into or out of the Internet
+ environment, a gateway MUST prepend a Received: line, but
+ it MUST NOT alter in any way a Received: line that is
+ already in the header.
+
+ DISCUSSION:
+ This requirement is a subset of the general
+ "Received:" line requirement of Section 5.2.8; it is
+ restated here for emphasis.
+
+ Received: fields of messages originating from other
+
+
+
+Internet Engineering Task Force [Page 66]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ environments may not conform exactly to RFC822.
+ However, the most important use of Received: lines is
+ for debugging mail faults, and this debugging can be
+ severely hampered by well-meaning gateways that try
+ to "fix" a Received: line.
+
+ The gateway is strongly encouraged to indicate the
+ environment and protocol in the "via" clauses of
+ Received field(s) that it supplies.
+
+ (C) From the Internet side, the gateway SHOULD accept all
+ valid address formats in SMTP commands and in RFC-822
+ headers, and all valid RFC-822 messages. Although a
+ gateway must accept an RFC-822 explicit source route
+ ("@...:" format) in either the RFC-822 header or in the
+ envelope, it MAY or may not act on the source route; see
+ Sections 5.2.6 and 5.2.19.
+
+ DISCUSSION:
+ It is often tempting to restrict the range of
+ addresses accepted at the mail gateway to simplify
+ the translation into addresses for the remote
+ environment. This practice is based on the
+ assumption that mail users have control over the
+ addresses their mailers send to the mail gateway. In
+ practice, however, users have little control over the
+ addresses that are finally sent; their mailers are
+ free to change addresses into any legal RFC-822
+ format.
+
+ (D) The gateway MUST ensure that all header fields of a
+ message that it forwards into the Internet meet the
+ requirements for Internet mail. In particular, all
+ addresses in "From:", "To:", "Cc:", etc., fields must be
+ transformed (if necessary) to satisfy RFC-822 syntax, and
+ they must be effective and useful for sending replies.
+
+
+ (E) The translation algorithm used to convert mail from the
+ Internet protocols to another environment's protocol
+ SHOULD try to ensure that error messages from the foreign
+ mail environment are delivered to the return path from the
+ SMTP envelope, not to the sender listed in the "From:"
+ field of the RFC-822 message.
+
+ DISCUSSION:
+ Internet mail lists usually place the address of the
+ mail list maintainer in the envelope but leave the
+
+
+
+Internet Engineering Task Force [Page 67]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ original message header intact (with the "From:"
+ field containing the original sender). This yields
+ the behavior the average recipient expects: a reply
+ to the header gets sent to the original sender, not
+ to a mail list maintainer; however, errors get sent
+ to the maintainer (who can fix the problem) and not
+ the sender (who probably cannot).
+
+ (F) Similarly, when forwarding a message from another
+ environment into the Internet, the gateway SHOULD set the
+ envelope return path in accordance with an error message
+ return address, if any, supplied by the foreign
+ environment.
+
+
+ 5.3.8 Maximum Message Size
+
+ Mailer software MUST be able to send and receive messages of at
+ least 64K bytes in length (including header), and a much larger
+ maximum size is highly desirable.
+
+ DISCUSSION:
+ Although SMTP does not define the maximum size of a
+ message, many systems impose implementation limits.
+
+ The current de facto minimum limit in the Internet is 64K
+ bytes. However, electronic mail is used for a variety of
+ purposes that create much larger messages. For example,
+ mail is often used instead of FTP for transmitting ASCII
+ files, and in particular to transmit entire documents. As
+ a result, messages can be 1 megabyte or even larger. We
+ note that the present document together with its lower-
+ layer companion contains 0.5 megabytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 68]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ 5.4 SMTP REQUIREMENTS SUMMARY
+
+ | | | | |S| |
+ | | | | |H| |F
+ | | | | |O|M|o
+ | | |S| |U|U|o
+ | | |H| |L|S|t
+ | |M|O| |D|T|n
+ | |U|U|M| | |o
+ | |S|L|A|N|N|t
+ | |T|D|Y|O|O|t
+FEATURE |SECTION | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+ | | | | | | |
+RECEIVER-SMTP: | | | | | | |
+ Implement VRFY |5.2.3 |x| | | | |
+ Implement EXPN |5.2.3 | |x| | | |
+ EXPN, VRFY configurable |5.2.3 | | |x| | |
+ Implement SEND, SOML, SAML |5.2.4 | | |x| | |
+ Verify HELO parameter |5.2.5 | | |x| | |
+ Refuse message with bad HELO |5.2.5 | | | | |x|
+ Accept explicit src-route syntax in env. |5.2.6 |x| | | | |
+ Support "postmaster" |5.2.7 |x| | | | |
+ Process RCPT when received (except lists) |5.2.7 | | |x| | |
+ Long delay of RCPT responses |5.2.7 | | | | |x|
+ | | | | | | |
+ Add Received: line |5.2.8 |x| | | | |
+ Received: line include domain literal |5.2.8 | |x| | | |
+ Change previous Received: line |5.2.8 | | | | |x|
+ Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | |
+ Support empty reverse path |5.2.9 |x| | | | |
+ Send only official reply codes |5.2.10 | |x| | | |
+ Send text from RFC-821 when appropriate |5.2.10 | |x| | | |
+ Delete "." for transparency |5.2.11 |x| | | | |
+ Accept and recognize self domain literal(s) |5.2.17 |x| | | | |
+ | | | | | | |
+ Error message about error message |5.3.1 | | | | |x|
+ Keep pending listen on SMTP port |5.3.1.2 | |x| | | |
+ Provide limit on recv concurrency |5.3.1.2 | | |x| | |
+ Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | |
+ Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x|
+ Send error notification msg after accept |5.3.3 |x| | | | |
+ Send using null return path |5.3.3 |x| | | | |
+ Send to envelope return path |5.3.3 | |x| | | |
+ Send to null address |5.3.3 | | | | |x|
+ Strip off explicit src route |5.3.3 | |x| | | |
+ Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | |
+-----------------------------------------------|----------|-|-|-|-|-|--
+
+
+
+Internet Engineering Task Force [Page 69]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ | | | | | | |
+SENDER-SMTP: | | | | | | |
+ Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | |
+ Implement SEND, SOML, SAML |5.2.4 | | |x| | |
+ Send valid principal host name in HELO |5.2.5 |x| | | | |
+ Send explicit source route in RCPT TO: |5.2.6 | | | |x| |
+ Use only reply code to determine action |5.2.10 |x| | | | |
+ Use only high digit of reply code when poss. |5.2.10 | |x| | | |
+ Add "." for transparency |5.2.11 |x| | | | |
+ | | | | | | |
+ Retry messages after soft failure |5.3.1.1 |x| | | | |
+ Delay before retry |5.3.1.1 |x| | | | |
+ Configurable retry parameters |5.3.1.1 |x| | | | |
+ Retry once per each queued dest host |5.3.1.1 | |x| | | |
+ Multiple RCPT's for same DATA |5.3.1.1 | |x| | | |
+ Support multiple concurrent transactions |5.3.1.1 | | |x| | |
+ Provide limit on concurrency |5.3.1.1 | |x| | | |
+ | | | | | | |
+ Timeouts on all activities |5.3.1 |x| | | | |
+ Per-command timeouts |5.3.2 | |x| | | |
+ Timeouts easily reconfigurable |5.3.2 | |x| | | |
+ Recommended times |5.3.2 | |x| | | |
+ Try alternate addr's in order |5.3.4 |x| | | | |
+ Configurable limit on alternate tries |5.3.4 | | |x| | |
+ Try at least two alternates |5.3.4 | |x| | | |
+ Load-split across equal MX alternates |5.3.4 | |x| | | |
+ Use the Domain Name System |5.3.5 |x| | | | |
+ Support MX records |5.3.5 |x| | | | |
+ Use WKS records in MX processing |5.2.12 | | | |x| |
+-----------------------------------------------|----------|-|-|-|-|-|--
+ | | | | | | |
+MAIL FORWARDING: | | | | | | |
+ Alter existing header field(s) |5.2.6 | | | |x| |
+ Implement relay function: 821/section 3.6 |5.2.6 | | |x| | |
+ If not, deliver to RHS domain |5.2.6 | |x| | | |
+ Interpret 'local-part' of addr |5.2.16 | | | | |x|
+ | | | | | | |
+MAILING LISTS AND ALIASES | | | | | | |
+ Support both |5.3.6 | |x| | | |
+ Report mail list error to local admin. |5.3.6 |x| | | | |
+ | | | | | | |
+MAIL GATEWAYS: | | | | | | |
+ Embed foreign mail route in local-part |5.2.16 | | |x| | |
+ Rewrite header fields when necessary |5.3.7 | | |x| | |
+ Prepend Received: line |5.3.7 |x| | | | |
+ Change existing Received: line |5.3.7 | | | | |x|
+ Accept full RFC-822 on Internet side |5.3.7 | |x| | | |
+ Act on RFC-822 explicit source route |5.3.7 | | |x| | |
+
+
+
+Internet Engineering Task Force [Page 70]
+
+
+
+
+RFC1123 MAIL -- SMTP & RFC-822 October 1989
+
+
+ Send only valid RFC-822 on Internet side |5.3.7 |x| | | | |
+ Deliver error msgs to envelope addr |5.3.7 | |x| | | |
+ Set env return path from err return addr |5.3.7 | |x| | | |
+ | | | | | | |
+USER AGENT -- RFC-822 | | | | | | |
+ Allow user to enter <route> address |5.2.6 | | | |x| |
+ Support RFC-1049 Content Type field |5.2.13 | | |x| | |
+ Use 4-digit years |5.2.14 | |x| | | |
+ Generate numeric timezones |5.2.14 | |x| | | |
+ Accept all timezones |5.2.14 |x| | | | |
+ Use non-num timezones from RFC-822 |5.2.14 |x| | | | |
+ Omit phrase before route-addr |5.2.15 | | |x| | |
+ Accept and parse dot.dec. domain literals |5.2.17 |x| | | | |
+ Accept all RFC-822 address formats |5.2.18 |x| | | | |
+ Generate invalid RFC-822 address format |5.2.18 | | | | |x|
+ Fully-qualified domain names in header |5.2.18 |x| | | | |
+ Create explicit src route in header |5.2.19 | | | |x| |
+ Accept explicit src route in header |5.2.19 |x| | | | |
+ | | | | | | |
+Send/recv at least 64KB messages |5.3.8 |x| | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 71]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+6. SUPPORT SERVICES
+
+ 6.1 DOMAIN NAME TRANSLATION
+
+ 6.1.1 INTRODUCTION
+
+ Every host MUST implement a resolver for the Domain Name System
+ (DNS), and it MUST implement a mechanism using this DNS
+ resolver to convert host names to IP addresses and vice-versa
+ [DNS:1, DNS:2].
+
+ In addition to the DNS, a host MAY also implement a host name
+ translation mechanism that searches a local Internet host
+ table. See Section 6.1.3.8 for more information on this
+ option.
+
+ DISCUSSION:
+ Internet host name translation was originally performed by
+ searching local copies of a table of all hosts. This
+ table became too large to update and distribute in a
+ timely manner and too large to fit into many hosts, so the
+ DNS was invented.
+
+ The DNS creates a distributed database used primarily for
+ the translation between host names and host addresses.
+ Implementation of DNS software is required. The DNS
+ consists of two logically distinct parts: name servers and
+ resolvers (although implementations often combine these
+ two logical parts in the interest of efficiency) [DNS:2].
+
+ Domain name servers store authoritative data about certain
+ sections of the database and answer queries about the
+ data. Domain resolvers query domain name servers for data
+ on behalf of user processes. Every host therefore needs a
+ DNS resolver; some host machines will also need to run
+ domain name servers. Since no name server has complete
+ information, in general it is necessary to obtain
+ information from more than one name server to resolve a
+ query.
+
+ 6.1.2 PROTOCOL WALK-THROUGH
+
+ An implementor must study references [DNS:1] and [DNS:2]
+ carefully. They provide a thorough description of the theory,
+ protocol, and implementation of the domain name system, and
+ reflect several years of experience.
+
+
+
+
+
+Internet Engineering Task Force [Page 72]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1
+
+ All DNS name servers and resolvers MUST properly handle RRs
+ with a zero TTL: return the RR to the client but do not
+ cache it.
+
+ DISCUSSION:
+ Zero TTL values are interpreted to mean that the RR can
+ only be used for the transaction in progress, and
+ should not be cached; they are useful for extremely
+ volatile data.
+
+ 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5
+
+ A query with "QCLASS=*" SHOULD NOT be used unless the
+ requestor is seeking data from more than one class. In
+ particular, if the requestor is only interested in Internet
+ data types, QCLASS=IN MUST be used.
+
+ 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1
+
+ Unused fields in a query or response message MUST be zero.
+
+ 6.1.2.4 Compression: RFC-1035 Section 4.1.4
+
+ Name servers MUST use compression in responses.
+
+ DISCUSSION:
+ Compression is essential to avoid overflowing UDP
+ datagrams; see Section 6.1.3.2.
+
+ 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2
+
+ Recursive name servers and full-service resolvers generally
+ have some configuration information containing hints about
+ the location of root or local name servers. An
+ implementation MUST NOT include any of these hints in a
+ response.
+
+ DISCUSSION:
+ Many implementors have found it convenient to store
+ these hints as if they were cached data, but some
+ neglected to ensure that this "cached data" was not
+ included in responses. This has caused serious
+ problems in the Internet when the hints were obsolete
+ or incorrect.
+
+
+
+
+
+Internet Engineering Task Force [Page 73]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ 6.1.3 SPECIFIC ISSUES
+
+ 6.1.3.1 Resolver Implementation
+
+ A name resolver SHOULD be able to multiplex concurrent
+ requests if the host supports concurrent processes.
+
+ In implementing a DNS resolver, one of two different models
+ MAY optionally be chosen: a full-service resolver, or a stub
+ resolver.
+
+
+ (A) Full-Service Resolver
+
+ A full-service resolver is a complete implementation of
+ the resolver service, and is capable of dealing with
+ communication failures, failure of individual name
+ servers, location of the proper name server for a given
+ name, etc. It must satisfy the following requirements:
+
+ o The resolver MUST implement a local caching
+ function to avoid repeated remote access for
+ identical requests, and MUST time out information
+ in the cache.
+
+ o The resolver SHOULD be configurable with start-up
+ information pointing to multiple root name servers
+ and multiple name servers for the local domain.
+ This insures that the resolver will be able to
+ access the whole name space in normal cases, and
+ will be able to access local domain information
+ should the local network become disconnected from
+ the rest of the Internet.
+
+
+ (B) Stub Resolver
+
+ A "stub resolver" relies on the services of a recursive
+ name server on the connected network or a "nearby"
+ network. This scheme allows the host to pass on the
+ burden of the resolver function to a name server on
+ another host. This model is often essential for less
+ capable hosts, such as PCs, and is also recommended
+ when the host is one of several workstations on a local
+ network, because it allows all of the workstations to
+ share the cache of the recursive name server and hence
+ reduce the number of domain requests exported by the
+ local network.
+
+
+
+Internet Engineering Task Force [Page 74]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ At a minimum, the stub resolver MUST be capable of
+ directing its requests to redundant recursive name
+ servers. Note that recursive name servers are allowed
+ to restrict the sources of requests that they will
+ honor, so the host administrator must verify that the
+ service will be provided. Stub resolvers MAY implement
+ caching if they choose, but if so, MUST timeout cached
+ information.
+
+
+ 6.1.3.2 Transport Protocols
+
+ DNS resolvers and recursive servers MUST support UDP, and
+ SHOULD support TCP, for sending (non-zone-transfer) queries.
+ Specifically, a DNS resolver or server that is sending a
+ non-zone-transfer query MUST send a UDP query first. If the
+ Answer section of the response is truncated and if the
+ requester supports TCP, it SHOULD try the query again using
+ TCP.
+
+ DNS servers MUST be able to service UDP queries and SHOULD
+ be able to service TCP queries. A name server MAY limit the
+ resources it devotes to TCP queries, but it SHOULD NOT
+ refuse to service a TCP query just because it would have
+ succeeded with UDP.
+
+ Truncated responses MUST NOT be saved (cached) and later
+ used in such a way that the fact that they are truncated is
+ lost.
+
+ DISCUSSION:
+ UDP is preferred over TCP for queries because UDP
+ queries have much lower overhead, both in packet count
+ and in connection state. The use of UDP is essential
+ for heavily-loaded servers, especially the root
+ servers. UDP also offers additional robustness, since
+ a resolver can attempt several UDP queries to different
+ servers for the cost of a single TCP query.
+
+ It is possible for a DNS response to be truncated,
+ although this is a very rare occurrence in the present
+ Internet DNS. Practically speaking, truncation cannot
+ be predicted, since it is data-dependent. The
+ dependencies include the number of RRs in the answer,
+ the size of each RR, and the savings in space realized
+ by the name compression algorithm. As a rule of thumb,
+ truncation in NS and MX lists should not occur for
+ answers containing 15 or fewer RRs.
+
+
+
+Internet Engineering Task Force [Page 75]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ Whether it is possible to use a truncated answer
+ depends on the application. A mailer must not use a
+ truncated MX response, since this could lead to mail
+ loops.
+
+ Responsible practices can make UDP suffice in the vast
+ majority of cases. Name servers must use compression
+ in responses. Resolvers must differentiate truncation
+ of the Additional section of a response (which only
+ loses extra information) from truncation of the Answer
+ section (which for MX records renders the response
+ unusable by mailers). Database administrators should
+ list only a reasonable number of primary names in lists
+ of name servers, MX alternatives, etc.
+
+ However, it is also clear that some new DNS record
+ types defined in the future will contain information
+ exceeding the 512 byte limit that applies to UDP, and
+ hence will require TCP. Thus, resolvers and name
+ servers should implement TCP services as a backup to
+ UDP today, with the knowledge that they will require
+ the TCP service in the future.
+
+ By private agreement, name servers and resolvers MAY arrange
+ to use TCP for all traffic between themselves. TCP MUST be
+ used for zone transfers.
+
+ A DNS server MUST have sufficient internal concurrency that
+ it can continue to process UDP queries while awaiting a
+ response or performing a zone transfer on an open TCP
+ connection [DNS:2].
+
+ A server MAY support a UDP query that is delivered using an
+ IP broadcast or multicast address. However, the Recursion
+ Desired bit MUST NOT be set in a query that is multicast,
+ and MUST be ignored by name servers receiving queries via a
+ broadcast or multicast address. A host that sends broadcast
+ or multicast DNS queries SHOULD send them only as occasional
+ probes, caching the IP address(es) it obtains from the
+ response(s) so it can normally send unicast queries.
+
+ DISCUSSION:
+ Broadcast or (especially) IP multicast can provide a
+ way to locate nearby name servers without knowing their
+ IP addresses in advance. However, general broadcasting
+ of recursive queries can result in excessive and
+ unnecessary load on both network and servers.
+
+
+
+
+Internet Engineering Task Force [Page 76]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ 6.1.3.3 Efficient Resource Usage
+
+ The following requirements on servers and resolvers are very
+ important to the health of the Internet as a whole,
+ particularly when DNS services are invoked repeatedly by
+ higher level automatic servers, such as mailers.
+
+ (1) The resolver MUST implement retransmission controls to
+ insure that it does not waste communication bandwidth,
+ and MUST impose finite bounds on the resources consumed
+ to respond to a single request. See [DNS:2] pages 43-
+ 44 for specific recommendations.
+
+ (2) After a query has been retransmitted several times
+ without a response, an implementation MUST give up and
+ return a soft error to the application.
+
+ (3) All DNS name servers and resolvers SHOULD cache
+ temporary failures, with a timeout period of the order
+ of minutes.
+
+ DISCUSSION:
+ This will prevent applications that immediately
+ retry soft failures (in violation of Section 2.2
+ of this document) from generating excessive DNS
+ traffic.
+
+ (4) All DNS name servers and resolvers SHOULD cache
+ negative responses that indicate the specified name, or
+ data of the specified type, does not exist, as
+ described in [DNS:2].
+
+ (5) When a DNS server or resolver retries a UDP query, the
+ retry interval SHOULD be constrained by an exponential
+ backoff algorithm, and SHOULD also have upper and lower
+ bounds.
+
+ IMPLEMENTATION:
+ A measured RTT and variance (if available) should
+ be used to calculate an initial retransmission
+ interval. If this information is not available, a
+ default of no less than 5 seconds should be used.
+ Implementations may limit the retransmission
+ interval, but this limit must exceed twice the
+ Internet maximum segment lifetime plus service
+ delay at the name server.
+
+ (6) When a resolver or server receives a Source Quench for
+
+
+
+Internet Engineering Task Force [Page 77]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ a query it has issued, it SHOULD take steps to reduce
+ the rate of querying that server in the near future. A
+ server MAY ignore a Source Quench that it receives as
+ the result of sending a response datagram.
+
+ IMPLEMENTATION:
+ One recommended action to reduce the rate is to
+ send the next query attempt to an alternate
+ server, if there is one available. Another is to
+ backoff the retry interval for the same server.
+
+
+ 6.1.3.4 Multihomed Hosts
+
+ When the host name-to-address function encounters a host
+ with multiple addresses, it SHOULD rank or sort the
+ addresses using knowledge of the immediately connected
+ network number(s) and any other applicable performance or
+ history information.
+
+ DISCUSSION:
+ The different addresses of a multihomed host generally
+ imply different Internet paths, and some paths may be
+ preferable to others in performance, reliability, or
+ administrative restrictions. There is no general way
+ for the domain system to determine the best path. A
+ recommended approach is to base this decision on local
+ configuration information set by the system
+ administrator.
+
+ IMPLEMENTATION:
+ The following scheme has been used successfully:
+
+ (a) Incorporate into the host configuration data a
+ Network-Preference List, that is simply a list of
+ networks in preferred order. This list may be
+ empty if there is no preference.
+
+ (b) When a host name is mapped into a list of IP
+ addresses, these addresses should be sorted by
+ network number, into the same order as the
+ corresponding networks in the Network-Preference
+ List. IP addresses whose networks do not appear
+ in the Network-Preference List should be placed at
+ the end of the list.
+
+
+
+
+
+
+Internet Engineering Task Force [Page 78]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ 6.1.3.5 Extensibility
+
+ DNS software MUST support all well-known, class-independent
+ formats [DNS:2], and SHOULD be written to minimize the
+ trauma associated with the introduction of new well-known
+ types and local experimentation with non-standard types.
+
+ DISCUSSION:
+ The data types and classes used by the DNS are
+ extensible, and thus new types will be added and old
+ types deleted or redefined. Introduction of new data
+ types ought to be dependent only upon the rules for
+ compression of domain names inside DNS messages, and
+ the translation between printable (i.e., master file)
+ and internal formats for Resource Records (RRs).
+
+ Compression relies on knowledge of the format of data
+ inside a particular RR. Hence compression must only be
+ used for the contents of well-known, class-independent
+ RRs, and must never be used for class-specific RRs or
+ RR types that are not well-known. The owner name of an
+ RR is always eligible for compression.
+
+ A name server may acquire, via zone transfer, RRs that
+ the server doesn't know how to convert to printable
+ format. A resolver can receive similar information as
+ the result of queries. For proper operation, this data
+ must be preserved, and hence the implication is that
+ DNS software cannot use textual formats for internal
+ storage.
+
+ The DNS defines domain name syntax very generally -- a
+ string of labels each containing up to 63 8-bit octets,
+ separated by dots, and with a maximum total of 255
+ octets. Particular applications of the DNS are
+ permitted to further constrain the syntax of the domain
+ names they use, although the DNS deployment has led to
+ some applications allowing more general names. In
+ particular, Section 2.1 of this document liberalizes
+ slightly the syntax of a legal Internet host name that
+ was defined in RFC-952 [DNS:4].
+
+ 6.1.3.6 Status of RR Types
+
+ Name servers MUST be able to load all RR types except MD and
+ MF from configuration files. The MD and MF types are
+ obsolete and MUST NOT be implemented; in particular, name
+ servers MUST NOT load these types from configuration files.
+
+
+
+Internet Engineering Task Force [Page 79]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ DISCUSSION:
+ The RR types MB, MG, MR, NULL, MINFO and RP are
+ considered experimental, and applications that use the
+ DNS cannot expect these RR types to be supported by
+ most domains. Furthermore these types are subject to
+ redefinition.
+
+ The TXT and WKS RR types have not been widely used by
+ Internet sites; as a result, an application cannot rely
+ on the the existence of a TXT or WKS RR in most
+ domains.
+
+ 6.1.3.7 Robustness
+
+ DNS software may need to operate in environments where the
+ root servers or other servers are unavailable due to network
+ connectivity or other problems. In this situation, DNS name
+ servers and resolvers MUST continue to provide service for
+ the reachable part of the name space, while giving temporary
+ failures for the rest.
+
+ DISCUSSION:
+ Although the DNS is meant to be used primarily in the
+ connected Internet, it should be possible to use the
+ system in networks which are unconnected to the
+ Internet. Hence implementations must not depend on
+ access to root servers before providing service for
+ local names.
+
+ 6.1.3.8 Local Host Table
+
+ DISCUSSION:
+ A host may use a local host table as a backup or
+ supplement to the DNS. This raises the question of
+ which takes precedence, the DNS or the host table; the
+ most flexible approach would make this a configuration
+ option.
+
+ Typically, the contents of such a supplementary host
+ table will be determined locally by the site. However,
+ a publically-available table of Internet hosts is
+ maintained by the DDN Network Information Center (DDN
+ NIC), with a format documented in [DNS:4]. This table
+ can be retrieved from the DDN NIC using a protocol
+ described in [DNS:5]. It must be noted that this table
+ contains only a small fraction of all Internet hosts.
+ Hosts using this protocol to retrieve the DDN NIC host
+ table should use the VERSION command to check if the
+
+
+
+Internet Engineering Task Force [Page 80]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ table has changed before requesting the entire table
+ with the ALL command. The VERSION identifier should be
+ treated as an arbitrary string and tested only for
+ equality; no numerical sequence may be assumed.
+
+ The DDN NIC host table includes administrative
+ information that is not needed for host operation and
+ is therefore not currently included in the DNS
+ database; examples include network and gateway entries.
+ However, much of this additional information will be
+ added to the DNS in the future. Conversely, the DNS
+ provides essential services (in particular, MX records)
+ that are not available from the DDN NIC host table.
+
+ 6.1.4 DNS USER INTERFACE
+
+ 6.1.4.1 DNS Administration
+
+ This document is concerned with design and implementation
+ issues in host software, not with administrative or
+ operational issues. However, administrative issues are of
+ particular importance in the DNS, since errors in particular
+ segments of this large distributed database can cause poor
+ or erroneous performance for many sites. These issues are
+ discussed in [DNS:6] and [DNS:7].
+
+ 6.1.4.2 DNS User Interface
+
+ Hosts MUST provide an interface to the DNS for all
+ application programs running on the host. This interface
+ will typically direct requests to a system process to
+ perform the resolver function [DNS:1, 6.1:2].
+
+ At a minimum, the basic interface MUST support a request for
+ all information of a specific type and class associated with
+ a specific name, and it MUST return either all of the
+ requested information, a hard error code, or a soft error
+ indication. When there is no error, the basic interface
+ returns the complete response information without
+ modification, deletion, or ordering, so that the basic
+ interface will not need to be changed to accommodate new
+ data types.
+
+ DISCUSSION:
+ The soft error indication is an essential part of the
+ interface, since it may not always be possible to
+ access particular information from the DNS; see Section
+ 6.1.3.3.
+
+
+
+Internet Engineering Task Force [Page 81]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ A host MAY provide other DNS interfaces tailored to
+ particular functions, transforming the raw domain data into
+ formats more suited to these functions. In particular, a
+ host MUST provide a DNS interface to facilitate translation
+ between host addresses and host names.
+
+ 6.1.4.3 Interface Abbreviation Facilities
+
+ User interfaces MAY provide a method for users to enter
+ abbreviations for commonly-used names. Although the
+ definition of such methods is outside of the scope of the
+ DNS specification, certain rules are necessary to insure
+ that these methods allow access to the entire DNS name space
+ and to prevent excessive use of Internet resources.
+
+ If an abbreviation method is provided, then:
+
+ (a) There MUST be some convention for denoting that a name
+ is already complete, so that the abbreviation method(s)
+ are suppressed. A trailing dot is the usual method.
+
+ (b) Abbreviation expansion MUST be done exactly once, and
+ MUST be done in the context in which the name was
+ entered.
+
+
+ DISCUSSION:
+ For example, if an abbreviation is used in a mail
+ program for a destination, the abbreviation should be
+ expanded into a full domain name and stored in the
+ queued message with an indication that it is already
+ complete. Otherwise, the abbreviation might be
+ expanded with a mail system search list, not the
+ user's, or a name could grow due to repeated
+ canonicalizations attempts interacting with wildcards.
+
+ The two most common abbreviation methods are:
+
+ (1) Interface-level aliases
+
+ Interface-level aliases are conceptually implemented as
+ a list of alias/domain name pairs. The list can be
+ per-user or per-host, and separate lists can be
+ associated with different functions, e.g. one list for
+ host name-to-address translation, and a different list
+ for mail domains. When the user enters a name, the
+ interface attempts to match the name to the alias
+ component of a list entry, and if a matching entry can
+
+
+
+Internet Engineering Task Force [Page 82]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ be found, the name is replaced by the domain name found
+ in the pair.
+
+ Note that interface-level aliases and CNAMEs are
+ completely separate mechanisms; interface-level aliases
+ are a local matter while CNAMEs are an Internet-wide
+ aliasing mechanism which is a required part of any DNS
+ implementation.
+
+ (2) Search Lists
+
+ A search list is conceptually implemented as an ordered
+ list of domain names. When the user enters a name, the
+ domain names in the search list are used as suffixes to
+ the user-supplied name, one by one, until a domain name
+ with the desired associated data is found, or the
+ search list is exhausted. Search lists often contain
+ the name of the local host's parent domain or other
+ ancestor domains. Search lists are often per-user or
+ per-process.
+
+ It SHOULD be possible for an administrator to disable a
+ DNS search-list facility. Administrative denial may be
+ warranted in some cases, to prevent abuse of the DNS.
+
+ There is danger that a search-list mechanism will
+ generate excessive queries to the root servers while
+ testing whether user input is a complete domain name,
+ lacking a final period to mark it as complete. A
+ search-list mechanism MUST have one of, and SHOULD have
+ both of, the following two provisions to prevent this:
+
+ (a) The local resolver/name server can implement
+ caching of negative responses (see Section
+ 6.1.3.3).
+
+ (b) The search list expander can require two or more
+ interior dots in a generated domain name before it
+ tries using the name in a query to non-local
+ domain servers, such as the root.
+
+ DISCUSSION:
+ The intent of this requirement is to avoid
+ excessive delay for the user as the search list is
+ tested, and more importantly to prevent excessive
+ traffic to the root and other high-level servers.
+ For example, if the user supplied a name "X" and
+ the search list contained the root as a component,
+
+
+
+Internet Engineering Task Force [Page 83]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ a query would have to consult a root server before
+ the next search list alternative could be tried.
+ The resulting load seen by the root servers and
+ gateways near the root would be multiplied by the
+ number of hosts in the Internet.
+
+ The negative caching alternative limits the effect
+ to the first time a name is used. The interior
+ dot rule is simpler to implement but can prevent
+ easy use of some top-level names.
+
+
+ 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
+
+ | | | | |S| |
+ | | | | |H| |F
+ | | | | |O|M|o
+ | | |S| |U|U|o
+ | | |H| |L|S|t
+ | |M|O| |D|T|n
+ | |U|U|M| | |o
+ | |S|L|A|N|N|t
+ | |T|D|Y|O|O|t
+FEATURE |SECTION | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+GENERAL ISSUES | | | | | | |
+ | | | | | | |
+Implement DNS name-to-address conversion |6.1.1 |x| | | | |
+Implement DNS address-to-name conversion |6.1.1 |x| | | | |
+Support conversions using host table |6.1.1 | | |x| | |
+Properly handle RR with zero TTL |6.1.2.1 |x| | | | |
+Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | |
+ Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | |
+Unused fields zero |6.1.2.3 |x| | | | |
+Use compression in responses |6.1.2.4 |x| | | | |
+ | | | | | | |
+Include config info in responses |6.1.2.5 | | | | |x|
+Support all well-known, class-indep. types |6.1.3.5 |x| | | | |
+Easily expand type list |6.1.3.5 | |x| | | |
+Load all RR types (except MD and MF) |6.1.3.6 |x| | | | |
+Load MD or MF type |6.1.3.6 | | | | |x|
+Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOLVER ISSUES: | | | | | | |
+ | | | | | | |
+Resolver support multiple concurrent requests |6.1.3.1 | |x| | | |
+Full-service resolver: |6.1.3.1 | | |x| | |
+ Local caching |6.1.3.1 |x| | | | |
+
+
+
+Internet Engineering Task Force [Page 84]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ Information in local cache times out |6.1.3.1 |x| | | | |
+ Configurable with starting info |6.1.3.1 | |x| | | |
+Stub resolver: |6.1.3.1 | | |x| | |
+ Use redundant recursive name servers |6.1.3.1 |x| | | | |
+ Local caching |6.1.3.1 | | |x| | |
+ Information in local cache times out |6.1.3.1 |x| | | | |
+Support for remote multi-homed hosts: | | | | | | |
+ Sort multiple addresses by preference list |6.1.3.4 | |x| | | |
+ | | | | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+TRANSPORT PROTOCOLS: | | | | | | |
+ | | | | | | |
+Support UDP queries |6.1.3.2 |x| | | | |
+Support TCP queries |6.1.3.2 | |x| | | |
+ Send query using UDP first |6.1.3.2 |x| | | | |1
+ Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | |
+Name server limit TCP query resources |6.1.3.2 | | |x| | |
+ Punish unnecessary TCP query |6.1.3.2 | | | |x| |
+Use truncated data as if it were not |6.1.3.2 | | | | |x|
+Private agreement to use only TCP |6.1.3.2 | | |x| | |
+Use TCP for zone transfers |6.1.3.2 |x| | | | |
+TCP usage not block UDP queries |6.1.3.2 |x| | | | |
+Support broadcast or multicast queries |6.1.3.2 | | |x| | |
+ RD bit set in query |6.1.3.2 | | | | |x|
+ RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | |
+ Send only as occasional probe for addr's |6.1.3.2 | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOURCE USAGE: | | | | | | |
+ | | | | | | |
+Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | |
+ Finite bounds per request |6.1.3.3 |x| | | | |
+Failure after retries => soft error |6.1.3.3 |x| | | | |
+Cache temporary failures |6.1.3.3 | |x| | | |
+Cache negative responses |6.1.3.3 | |x| | | |
+Retries use exponential backoff |6.1.3.3 | |x| | | |
+ Upper, lower bounds |6.1.3.3 | |x| | | |
+Client handle Source Quench |6.1.3.3 | |x| | | |
+Server ignore Source Quench |6.1.3.3 | | |x| | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+USER INTERFACE: | | | | | | |
+ | | | | | | |
+All programs have access to DNS interface |6.1.4.2 |x| | | | |
+Able to request all info for given name |6.1.4.2 |x| | | | |
+Returns complete info or error |6.1.4.2 |x| | | | |
+Special interfaces |6.1.4.2 | | |x| | |
+ Name<->Address translation |6.1.4.2 |x| | | | |
+ | | | | | | |
+Abbreviation Facilities: |6.1.4.3 | | |x| | |
+
+
+
+Internet Engineering Task Force [Page 85]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- DOMAINS October 1989
+
+
+ Convention for complete names |6.1.4.3 |x| | | | |
+ Conversion exactly once |6.1.4.3 |x| | | | |
+ Conversion in proper context |6.1.4.3 |x| | | | |
+ Search list: |6.1.4.3 | | |x| | |
+ Administrator can disable |6.1.4.3 | |x| | | |
+ Prevention of excessive root queries |6.1.4.3 |x| | | | |
+ Both methods |6.1.4.3 | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+-----------------------------------------------|-----------|-|-|-|-|-|--
+
+1. Unless there is private agreement between particular resolver and
+ particular server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 86]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
+
+
+ 6.2 HOST INITIALIZATION
+
+ 6.2.1 INTRODUCTION
+
+ This section discusses the initialization of host software
+ across a connected network, or more generally across an
+ Internet path. This is necessary for a diskless host, and may
+ optionally be used for a host with disk drives. For a diskless
+ host, the initialization process is called "network booting"
+ and is controlled by a bootstrap program located in a boot ROM.
+
+ To initialize a diskless host across the network, there are two
+ distinct phases:
+
+ (1) Configure the IP layer.
+
+ Diskless machines often have no permanent storage in which
+ to store network configuration information, so that
+ sufficient configuration information must be obtained
+ dynamically to support the loading phase that follows.
+ This information must include at least the IP addresses of
+ the host and of the boot server. To support booting
+ across a gateway, the address mask and a list of default
+ gateways are also required.
+
+ (2) Load the host system code.
+
+ During the loading phase, an appropriate file transfer
+ protocol is used to copy the system code across the
+ network from the boot server.
+
+ A host with a disk may perform the first step, dynamic
+ configuration. This is important for microcomputers, whose
+ floppy disks allow network configuration information to be
+ mistakenly duplicated on more than one host. Also,
+ installation of new hosts is much simpler if they automatically
+ obtain their configuration information from a central server,
+ saving administrator time and decreasing the probability of
+ mistakes.
+
+ 6.2.2 REQUIREMENTS
+
+ 6.2.2.1 Dynamic Configuration
+
+ A number of protocol provisions have been made for dynamic
+ configuration.
+
+ o ICMP Information Request/Reply messages
+
+
+
+Internet Engineering Task Force [Page 87]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
+
+
+ This obsolete message pair was designed to allow a host
+ to find the number of the network it is on.
+ Unfortunately, it was useful only if the host already
+ knew the host number part of its IP address,
+ information that hosts requiring dynamic configuration
+ seldom had.
+
+ o Reverse Address Resolution Protocol (RARP) [BOOT:4]
+
+ RARP is a link-layer protocol for a broadcast medium
+ that allows a host to find its IP address given its
+ link layer address. Unfortunately, RARP does not work
+ across IP gateways and therefore requires a RARP server
+ on every network. In addition, RARP does not provide
+ any other configuration information.
+
+ o ICMP Address Mask Request/Reply messages
+
+ These ICMP messages allow a host to learn the address
+ mask for a particular network interface.
+
+ o BOOTP Protocol [BOOT:2]
+
+ This protocol allows a host to determine the IP
+ addresses of the local host and the boot server, the
+ name of an appropriate boot file, and optionally the
+ address mask and list of default gateways. To locate a
+ BOOTP server, the host broadcasts a BOOTP request using
+ UDP. Ad hoc gateway extensions have been used to
+ transmit the BOOTP broadcast through gateways, and in
+ the future the IP Multicasting facility will provide a
+ standard mechanism for this purpose.
+
+
+ The suggested approach to dynamic configuration is to use
+ the BOOTP protocol with the extensions defined in "BOOTP
+ Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084
+ defines some important general (not vendor-specific)
+ extensions. In particular, these extensions allow the
+ address mask to be supplied in BOOTP; we RECOMMEND that the
+ address mask be supplied in this manner.
+
+ DISCUSSION:
+ Historically, subnetting was defined long after IP, and
+ so a separate mechanism (ICMP Address Mask messages)
+ was designed to supply the address mask to a host.
+ However, the IP address mask and the corresponding IP
+ address conceptually form a pair, and for operational
+
+
+
+Internet Engineering Task Force [Page 88]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989
+
+
+ simplicity they ought to be defined at the same time
+ and by the same mechanism, whether a configuration file
+ or a dynamic mechanism like BOOTP.
+
+ Note that BOOTP is not sufficiently general to specify
+ the configurations of all interfaces of a multihomed
+ host. A multihomed host must either use BOOTP
+ separately for each interface, or configure one
+ interface using BOOTP to perform the loading, and
+ perform the complete initialization from a file later.
+
+ Application layer configuration information is expected
+ to be obtained from files after loading of the system
+ code.
+
+ 6.2.2.2 Loading Phase
+
+ A suggested approach for the loading phase is to use TFTP
+ [BOOT:1] between the IP addresses established by BOOTP.
+
+ TFTP to a broadcast address SHOULD NOT be used, for reasons
+ explained in Section 4.2.3.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 89]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
+
+
+ 6.3 REMOTE MANAGEMENT
+
+ 6.3.1 INTRODUCTION
+
+ The Internet community has recently put considerable effort
+ into the development of network management protocols. The
+ result has been a two-pronged approach [MGT:1, MGT:6]: the
+ Simple Network Management Protocol (SNMP) [MGT:4] and the
+ Common Management Information Protocol over TCP (CMOT) [MGT:5].
+
+ In order to be managed using SNMP or CMOT, a host will need to
+ implement an appropriate management agent. An Internet host
+ SHOULD include an agent for either SNMP or CMOT.
+
+ Both SNMP and CMOT operate on a Management Information Base
+ (MIB) that defines a collection of management values. By
+ reading and setting these values, a remote application may
+ query and change the state of the managed system.
+
+ A standard MIB [MGT:3] has been defined for use by both
+ management protocols, using data types defined by the Structure
+ of Management Information (SMI) defined in [MGT:2]. Additional
+ MIB variables can be introduced under the "enterprises" and
+ "experimental" subtrees of the MIB naming space [MGT:2].
+
+ Every protocol module in the host SHOULD implement the relevant
+ MIB variables. A host SHOULD implement the MIB variables as
+ defined in the most recent standard MIB, and MAY implement
+ other MIB variables when appropriate and useful.
+
+ 6.3.2 PROTOCOL WALK-THROUGH
+
+ The MIB is intended to cover both hosts and gateways, although
+ there may be detailed differences in MIB application to the two
+ cases. This section contains the appropriate interpretation of
+ the MIB for hosts. It is likely that later versions of the MIB
+ will include more entries for host management.
+
+ A managed host must implement the following groups of MIB
+ object definitions: System, Interfaces, Address Translation,
+ IP, ICMP, TCP, and UDP.
+
+ The following specific interpretations apply to hosts:
+
+ o ipInHdrErrors
+
+ Note that the error "time-to-live exceeded" can occur in a
+ host only when it is forwarding a source-routed datagram.
+
+
+
+Internet Engineering Task Force [Page 90]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
+
+
+ o ipOutNoRoutes
+
+ This object counts datagrams discarded because no route
+ can be found. This may happen in a host if all the
+ default gateways in the host's configuration are down.
+
+ o ipFragOKs, ipFragFails, ipFragCreates
+
+ A host that does not implement intentional fragmentation
+ (see "Fragmentation" section of [INTRO:1]) MUST return the
+ value zero for these three objects.
+
+ o icmpOutRedirects
+
+ For a host, this object MUST always be zero, since hosts
+ do not send Redirects.
+
+ o icmpOutAddrMaskReps
+
+ For a host, this object MUST always be zero, unless the
+ host is an authoritative source of address mask
+ information.
+
+ o ipAddrTable
+
+ For a host, the "IP Address Table" object is effectively a
+ table of logical interfaces.
+
+ o ipRoutingTable
+
+ For a host, the "IP Routing Table" object is effectively a
+ combination of the host's Routing Cache and the static
+ route table described in "Routing Outbound Datagrams"
+ section of [INTRO:1].
+
+ Within each ipRouteEntry, ipRouteMetric1...4 normally will
+ have no meaning for a host and SHOULD always be -1, while
+ ipRouteType will normally have the value "remote".
+
+ If destinations on the connected network do not appear in
+ the Route Cache (see "Routing Outbound Datagrams section
+ of [INTRO:1]), there will be no entries with ipRouteType
+ of "direct".
+
+
+ DISCUSSION:
+ The current MIB does not include Type-of-Service in an
+ ipRouteEntry, but a future revision is expected to make
+
+
+
+Internet Engineering Task Force [Page 91]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
+
+
+ this addition.
+
+ We also expect the MIB to be expanded to allow the remote
+ management of applications (e.g., the ability to partially
+ reconfigure mail systems). Network service applications
+ such as mail systems should therefore be written with the
+ "hooks" for remote management.
+
+ 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY
+
+ | | | | |S| |
+ | | | | |H| |F
+ | | | | |O|M|o
+ | | |S| |U|U|o
+ | | |H| |L|S|t
+ | |M|O| |D|T|n
+ | |U|U|M| | |o
+ | |S|L|A|N|N|t
+ | |T|D|Y|O|O|t
+FEATURE |SECTION | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+Support SNMP or CMOT agent |6.3.1 | |x| | | |
+Implement specified objects in standard MIB |6.3.1 | |x| | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 92]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
+
+
+7. REFERENCES
+
+ This section lists the primary references with which every
+ implementer must be thoroughly familiar. It also lists some
+ secondary references that are suggested additional reading.
+
+ INTRODUCTORY REFERENCES:
+
+
+ [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
+ IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
+ October 1989.
+
+ [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
+ (three volumes), SRI International, December 1985.
+
+ [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel,
+ RFC-1011, May 1987.
+
+ This document is republished periodically with new RFC numbers;
+ the latest version must be used.
+
+ [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J.
+ Postel, RFC-980, March 1986.
+
+ [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
+ May 1987.
+
+ This document is republished periodically with new RFC numbers;
+ the latest version must be used.
+
+
+ TELNET REFERENCES:
+
+
+ [TELNET:1] "Telnet Protocol Specification," J. Postel and J.
+ Reynolds, RFC-854, May 1983.
+
+ [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds,
+ RFC-855, May 1983.
+
+ [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds,
+ RFC-856, May 1983.
+
+ [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
+ May 1983.
+
+ [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J.
+
+
+
+Internet Engineering Task Force [Page 93]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
+
+
+ Reynolds, RFC-858, May 1983.
+
+ [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC-
+ 859, May 1983.
+
+ [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds,
+ RFC-860, May 1983.
+
+ [TELNET:8] "Telnet Extended Options List," J. Postel and J.
+ Reynolds, RFC-861, May 1983.
+
+ [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855,
+ December 1983.
+
+ [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
+ February 1989.
+
+ This document supercedes RFC-930.
+
+ [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
+ October 1988.
+
+ [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
+ 1989.
+
+ [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
+ December 1988.
+
+ [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
+ 1080, November 1988.
+
+
+ SECONDARY TELNET REFERENCES:
+
+
+ [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
+ Defense, May 1984.
+
+ This document is intended to describe the same protocol as RFC-
+ 854. In case of conflict, RFC-854 takes precedence, and the
+ present document takes precedence over both.
+
+ [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
+
+ [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
+ 1977.
+
+ [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
+
+
+
+Internet Engineering Task Force [Page 94]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
+
+
+ [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
+ Implementation," A. Yasuda and T. Thompson, RFC-1043, February
+ 1988.
+
+
+ FTP REFERENCES:
+
+
+ [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
+ 959, October 1985.
+
+ [FTP:2] "Document File Format Standards," J. Postel, RFC-678,
+ December 1974.
+
+ [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of
+ Defense, May 1984.
+
+ This document is based on an earlier version of the FTP
+ specification (RFC-765) and is obsolete.
+
+
+ TFTP REFERENCES:
+
+
+ [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
+ 1981.
+
+
+ MAIL REFERENCES:
+
+
+ [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
+ 1982.
+
+ [SMTP:2] "Standard For The Format of ARPA Internet Text Messages,"
+ D. Crocker, RFC-822, August 1982.
+
+ This document obsoleted an earlier specification, RFC-733.
+
+ [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC-
+ 974, January 1986.
+
+ This RFC describes the use of MX records, a mandatory extension
+ to the mail delivery process.
+
+ [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
+ February 1988.
+
+
+
+
+Internet Engineering Task Force [Page 95]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
+
+
+ [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
+ June 1986.
+
+ [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
+
+ The two preceding RFC's define a proposed standard for
+ gatewaying mail between the Internet and the X.400 environments.
+
+ [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S.
+ Department of Defense, May 1984.
+
+ This specification is intended to describe the same protocol as
+ does RFC-821. However, MIL-STD-1781 is incomplete; in
+ particular, it does not include MX records [SMTP:3].
+
+ [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu,
+ RFC-1049, March 1988.
+
+
+ DOMAIN NAME SYSTEM REFERENCES:
+
+
+ [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris,
+ RFC-1034, November 1987.
+
+ This document and the following one obsolete RFC-882, RFC-883,
+ and RFC-973.
+
+ [DNS:2] "Domain Names - Implementation and Specification," RFC-1035,
+ P. Mockapetris, November 1987.
+
+
+ [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974,
+ January 1986.
+
+
+ [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein,
+ RFC-952, M. Stahl, E. Feinler, October 1985.
+
+ SECONDARY DNS REFERENCES:
+
+
+ [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
+ RFC-953, October 1985.
+
+ [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November
+ 1987.
+
+
+
+
+Internet Engineering Task Force [Page 96]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
+
+
+ [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC-
+ 1033, November 1987.
+
+ [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet
+ Protocol Handbook, NIC 50007, SRI Network Information Center,
+ August 1989.
+
+
+ SYSTEM INITIALIZATION REFERENCES:
+
+
+ [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
+ 1984.
+
+ [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
+ 951, September 1985.
+
+ [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
+ 1084, December 1988.
+
+ Note: this RFC revised and obsoleted RFC-1048.
+
+ [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
+ Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
+
+
+ MANAGEMENT REFERENCES:
+
+
+ [MGT:1] "IAB Recommendations for the Development of Internet Network
+ Management Standards," V. Cerf, RFC-1052, April 1988.
+
+ [MGT:2] "Structure and Identification of Management Information for
+ TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
+ August 1988.
+
+ [MGT:3] "Management Information Base for Network Management of
+ TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
+ August 1988.
+
+ [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor,
+ M. Schoffstall, and C. Davin, RFC-1098, April 1989.
+
+ [MGT:5] "The Common Management Information Services and Protocol
+ over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
+
+ [MGT:6] "Report of the Second Ad Hoc Network Management Review
+ Group," V. Cerf, RFC-1109, August 1989.
+
+
+
+Internet Engineering Task Force [Page 97]
+
+
+
+
+RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989
+
+
+Security Considerations
+
+ There are many security issues in the application and support
+ programs of host software, but a full discussion is beyond the scope
+ of this RFC. Security-related issues are mentioned in sections
+ concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
+ EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
+ SMTP DATA command (Section 5.2.8).
+
+Author's Address
+
+ Robert Braden
+ USC/Information Sciences Institute
+ 4676 Admiralty Way
+ Marina del Rey, CA 90292-6695
+
+ Phone: (213) 822 1511
+
+ EMail: Braden@ISI.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force [Page 98]
+
diff --git a/Documentation/en/rfc/rfc1413.txt b/Documentation/en/rfc/rfc1413.txt
new file mode 100644
index 00000000..17ede58a
--- /dev/null
+++ b/Documentation/en/rfc/rfc1413.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group M. St. Johns
+Request for Comments: 1413 US Department of Defense
+Obsoletes: 931 February 1993
+
+
+ Identification Protocol
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+1. INTRODUCTION
+
+ The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident
+ Protocol") provides a means to determine the identity of a user of a
+ particular TCP connection. Given a TCP port number pair, it returns
+ a character string which identifies the owner of that connection on
+ the server's system.
+
+ The Identification Protocol was formerly called the Authentication
+ Server Protocol. It has been renamed to better reflect its function.
+ This document is a product of the TCP Client Identity Protocol
+ Working Group of the Internet Engineering Task Force (IETF).
+
+2. OVERVIEW
+
+ This is a connection based application on TCP. A server listens for
+ TCP connections on TCP port 113 (decimal). Once a connection is
+ established, the server reads a line of data which specifies the
+ connection of interest. If it exists, the system dependent user
+ identifier of the connection of interest is sent as the reply. The
+ server may then either shut the connection down or it may continue to
+ read/respond to multiple queries.
+
+ The server should close the connection down after a configurable
+ amount of time with no queries - a 60-180 second idle timeout is
+ recommended. The client may close the connection down at any time;
+ however to allow for network delays the client should wait at least
+ 30 seconds (or longer) after a query before abandoning the query and
+ closing the connection.
+
+
+
+
+
+
+
+St. Johns [Page 1]
+
+RFC 1413 Identification Protocol February 1993
+
+
+3. RESTRICTIONS
+
+ Queries are permitted only for fully specified connections. The
+ query contains the local/foreign port pair -- the local/foreign
+ address pair used to fully specify the connection is taken from the
+ local and foreign address of query connection. This means a user on
+ address A may only query the server on address B about connections
+ between A and B.
+
+4. QUERY/RESPONSE FORMAT
+
+ The server accepts simple text query requests of the form:
+
+ <port-on-server> , <port-on-client>
+
+ where <port-on-server> is the TCP port (decimal) on the target (where
+ the "ident" server is running) system, and <port-on-client> is the
+ TCP port (decimal) on the source (client) system.
+
+ N.B - If a client on host A wants to ask a server on host B about a
+ connection specified locally (on the client's machine) as 23, 6191
+ (an inbound TELNET connection), the client must actually ask about
+ 6191, 23 - which is how the connection would be specified on host B.
+
+ For example:
+
+ 6191, 23
+
+ The response is of the form
+
+ <port-on-server> , <port-on-client> : <resp-type> : <add-info>
+
+ where <port-on-server>,<port-on-client> are the same pair as the
+ query, <resp-type> is a keyword identifying the type of response, and
+ <add-info> is context dependent.
+
+ The information returned is that associated with the fully specified
+ TCP connection identified by <server-address>, <client-address>,
+ <port-on-server>, <port-on-client>, where <server-address> and
+ <client-address> are the local and foreign IP addresses of the
+ querying connection -- i.e., the TCP connection to the Identification
+ Protocol Server. (<port-on-server> and <port-on-client> are taken
+ from the query.)
+
+ For example:
+
+ 6193, 23 : USERID : UNIX : stjohns
+ 6195, 23 : ERROR : NO-USER
+
+
+
+St. Johns [Page 2]
+
+RFC 1413 Identification Protocol February 1993
+
+
+5. RESPONSE TYPES
+
+A response can be one of two types:
+
+USERID
+
+ In this case, <add-info> is a string consisting of an
+ operating system name (with an optional character set
+ identifier), followed by ":", followed by an
+ identification string.
+
+ The character set (if present) is separated from the
+ operating system name by ",". The character set
+ identifier is used to indicate the character set of the
+ identification string. The character set identifier,
+ if omitted, defaults to "US-ASCII" (see below).
+
+ Permitted operating system names and character set
+ names are specified in RFC 1340, "Assigned Numbers" or
+ its successors.
+
+ In addition to those operating system and character set
+ names specified in "Assigned Numbers" there is one
+ special case operating system identifier - "OTHER".
+
+ Unless "OTHER" is specified as the operating system
+ type, the server is expected to return the "normal"
+ user identification of the owner of this connection.
+ "Normal" in this context may be taken to mean a string
+ of characters which uniquely identifies the connection
+ owner such as a user identifier assigned by the system
+ administrator and used by such user as a mail
+ identifier, or as the "user" part of a user/password
+ pair used to gain access to system resources. When an
+ operating system is specified (e.g., anything but
+ "OTHER"), the user identifier is expected to be in a
+ more or less immediately useful form - e.g., something
+ that could be used as an argument to "finger" or as a
+ mail address.
+
+ "OTHER" indicates the identifier is an unformatted
+ character string consisting of printable characters in
+ the specified character set. "OTHER" should be
+ specified if the user identifier does not meet the
+ constraints of the previous paragraph. Sending an
+ encrypted audit token, or returning other non-userid
+ information about a user (such as the real name and
+ phone number of a user from a UNIX passwd file) are
+
+
+
+St. Johns [Page 3]
+
+RFC 1413 Identification Protocol February 1993
+
+
+ both examples of when "OTHER" should be used.
+
+ Returned user identifiers are expected to be printable
+ in the character set indicated.
+
+ The identifier is an unformatted octet string - - all
+ octets are permissible EXCEPT octal 000 (NUL), 012 (LF)
+ and 015 (CR). N.B. - space characters (040) following the
+ colon separator ARE part of the identifier string and
+ may not be ignored. A response string is still
+ terminated normally by a CR/LF. N.B. A string may be
+ printable, but is not *necessarily* printable.
+
+ERROR
+
+ For some reason the port owner could not be determined, <add-info>
+ tells why. The following are the permitted values of <add-info> and
+ their meanings:
+
+ INVALID-PORT
+
+ Either the local or foreign port was improperly
+ specified. This should be returned if either or
+ both of the port ids were out of range (TCP port
+ numbers are from 1-65535), negative integers, reals or
+ in any fashion not recognized as a non-negative
+ integer.
+
+ NO-USER
+
+ The connection specified by the port pair is not
+ currently in use or currently not owned by an
+ identifiable entity.
+
+ HIDDEN-USER
+
+ The server was able to identify the user of this
+ port, but the information was not returned at the
+ request of the user.
+
+ UNKNOWN-ERROR
+
+ Can't determine connection owner; reason unknown.
+ Any error not covered above should return this
+ error code value. Optionally, this code MAY be
+ returned in lieu of any other specific error code
+ if, for example, the server desires to hide
+ information implied by the return of that error
+
+
+
+St. Johns [Page 4]
+
+RFC 1413 Identification Protocol February 1993
+
+
+ code, or for any other reason. If a server
+ implements such a feature, it MUST be configurable
+ and it MUST default to returning the proper error
+ message.
+
+ Other values may eventually be specified and defined in future
+ revisions to this document. If an implementer has a need to specify
+ a non-standard error code, that code must begin with "X".
+
+ In addition, the server is allowed to drop the query connection
+ without responding. Any premature close (i.e., one where the client
+ does not receive the EOL, whether graceful or an abort should be
+ considered to have the same meaning as "ERROR : UNKNOWN-ERROR".
+
+FORMAL SYNTAX
+
+ <request> ::= <port-pair> <EOL>
+
+ <port-pair> ::= <integer> "," <integer>
+
+ <reply> ::= <reply-text> <EOL>
+
+ <EOL> ::= "015 012" ; CR-LF End of Line Indicator
+
+ <reply-text> ::= <error-reply> | <ident-reply>
+
+ <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>
+
+ <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>
+ ":" <user-id>
+
+ <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
+ | "HIDDEN-USER" | <error-token>
+
+ <opsys-field> ::= <opsys> [ "," <charset>]
+
+ <opsys> ::= "OTHER" | "UNIX" | <token> ...etc.
+ ; (See "Assigned Numbers")
+
+ <charset> ::= "US-ASCII" | ...etc.
+ ; (See "Assigned Numbers")
+
+ <user-id> ::= <octet-string>
+
+ <token> ::= 1*64<token-characters> ; 1-64 characters
+
+ <error-token> ::= "X"1*63<token-characters>
+ ; 2-64 chars beginning w/X
+
+
+
+St. Johns [Page 5]
+
+RFC 1413 Identification Protocol February 1993
+
+
+ <integer> ::= 1*5<digit> ; 1-5 digits.
+
+ <digit> ::= "0" | "1" ... "8" | "9" ; 0-9
+
+ <token-characters> ::=
+ <Any of these ASCII characters: a-z, A-Z,
+ - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >
+ ; upper and lowercase a-z plus
+ ; printables minus the colon ":"
+ ; character.
+
+ <octet-string> ::= 1*512<octet-characters>
+
+ <octet-characters> ::=
+ <any octet from 00 to 377 (octal) except for
+ ASCII NUL (000), CR (015) and LF (012)>
+
+Notes on Syntax:
+
+ 1) To promote interoperability among variant
+ implementations, with respect to white space the above
+ syntax is understood to embody the "be conservative in
+ what you send and be liberal in what you accept"
+ philosophy. Clients and servers should not generate
+ unnecessary white space (space and tab characters) but
+ should accept white space anywhere except within a
+ token. In parsing responses, white space may occur
+ anywhere, except within a token. Specifically, any
+ amount of white space is permitted at the beginning or
+ end of a line both for queries and responses. This
+ does not apply for responses that contain a user ID
+ because everything after the colon after the operating
+ system type until the terminating CR/LF is taken as
+ part of the user ID. The terminating CR/LF is NOT
+ considered part of the user ID.
+
+ 2) The above notwithstanding, servers should restrict the
+ amount of inter-token white space they send to the
+ smallest amount reasonable or useful. Clients should
+ feel free to abort a connection if they receive 1000
+ characters without receiving an <EOL>.
+
+ 3) The 512 character limit on user IDs and the 64
+ character limit on tokens should be understood to mean
+ as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
+ token will be defined that has a length greater than 64
+ and b) a server SHOULD NOT send more than 512 octets of
+ user ID and a client MUST accept at least 512 octets of
+
+
+
+St. Johns [Page 6]
+
+RFC 1413 Identification Protocol February 1993
+
+
+ user ID. Because of this limitation, a server MUST
+ return the most significant portion of the user ID in
+ the first 512 octets.
+
+ 4) The character sets and character set identifiers should
+ map directly to those defined in or referenced by RFC 1340,
+ "Assigned Numbers" or its successors. Character set
+ identifiers only apply to the user identification field
+ - all other fields will be defined in and must be sent
+ as US-ASCII.
+
+ 5) Although <user-id> is defined as an <octet-string>
+ above, it must follow the format and character set
+ constraints implied by the <opsys-field>; see the
+ discussion above.
+
+ 6) The character set provides context for the client to
+ print or store the returned user identification string.
+ If the client does not recognize or implement the
+ returned character set, it should handle the returned
+ identification string as OCTET, but should in addition
+ store or report the character set. An OCTET string
+ should be printed, stored or handled in hex notation
+ (0-9a-f) in addition to any other representation the
+ client implements - this provides a standard
+ representation among differing implementations.
+
+6. Security Considerations
+
+ The information returned by this protocol is at most as trustworthy
+ as the host providing it OR the organization operating the host. For
+ example, a PC in an open lab has few if any controls on it to prevent
+ a user from having this protocol return any identifier the user
+ wants. Likewise, if the host has been compromised the information
+ returned may be completely erroneous and misleading.
+
+ The Identification Protocol is not intended as an authorization or
+ access control protocol. At best, it provides some additional
+ auditing information with respect to TCP connections. At worst, it
+ can provide misleading, incorrect, or maliciously incorrect
+ information.
+
+ The use of the information returned by this protocol for other than
+ auditing is strongly discouraged. Specifically, using Identification
+ Protocol information to make access control decisions - either as the
+ primary method (i.e., no other checks) or as an adjunct to other
+ methods may result in a weakening of normal host security.
+
+
+
+
+St. Johns [Page 7]
+
+RFC 1413 Identification Protocol February 1993
+
+
+ An Identification server may reveal information about users,
+ entities, objects or processes which might normally be considered
+ private. An Identification server provides service which is a rough
+ analog of the CallerID services provided by some phone companies and
+ many of the same privacy considerations and arguments that apply to
+ the CallerID service apply to Identification. If you wouldn't run a
+ "finger" server due to privacy considerations you may not want to run
+ this protocol.
+
+7. ACKNOWLEDGEMENTS
+
+ Acknowledgement is given to Dan Bernstein who is primarily
+ responsible for renewing interest in this protocol and for pointing
+ out some annoying errors in RFC 931.
+
+References
+
+ [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January
+ 1985.
+
+ [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+ USC/Information Sciences Institute, July 1992.
+
+Author's Address
+
+ Michael C. St. Johns
+ DARPA/CSTO
+ 3701 N. Fairfax Dr
+ Arlington, VA 22203
+
+ Phone: (703) 696-2271
+ EMail: stjohns@DARPA.MIL
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+St. Johns [Page 8]
+ \ No newline at end of file
diff --git a/Documentation/en/rfc/rfc1428.txt b/Documentation/en/rfc/rfc1428.txt
new file mode 100644
index 00000000..9053b4fe
--- /dev/null
+++ b/Documentation/en/rfc/rfc1428.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group G. Vaudreuil
+Request for Comments: 1428 CNRI
+ February 1993
+
+
+ Transition of Internet Mail from
+ Just-Send-8
+ to 8bit-SMTP/MIME
+
+Status of this Memo
+
+ This RFC provides information for the Internet community. It does
+ not specify an Internet standard. Distribution of this memo is
+ unlimited.
+
+Abstract
+
+ Protocols for extending SMTP to pass 8bit characters have been
+ defined [3] [4]. These protocols require that messages transported by
+ the extended SMTP are to be encoded in MIME [1] [2]. Before work
+ began on these protocols, several SMTP implementations adopted ad-hoc
+ mechanisms for sending 8bit data. It is desirable for the extended
+ SMTP environment and these ad hoc mechanisms interoperate. This
+ document outlines the problems in this environment and an approach to
+ minimizing the cost of transition from current usage of non-MIME 8bit
+ messages to MIME.
+
+1. Terminology
+
+ RFC 821 defines a 7bit transport. A transport agent which does not
+ clear the high order bit upon receipt of octets with this bit set in
+ SMTP messages is called 8 bit transparent in this document. An
+ implementation of the general SMTP Extensions document [3] and the
+ 8bit extensions protocol [4] which passes MIME messages using all 8
+ bits of an octet is called 8bit ESMTP. An implementation of extended
+ SMTP which does not accept 8bit characters is called 7bit ESMTP. A
+ gateway is defined to be a transport agent with User Agent authority
+ to alter or convert the content of a message.
+
+2. The Problem
+
+ SMTP as defined in RFC 821 limits the sending of Internet Mail to
+ US-ASCII [5] characters. As the Internet has grown to include non-
+ English correspondents, the need to communicate with character sets
+ other than US-ASCII has prompted many vendors and users to extend
+ SMTP or RFC 822 to use non-ASCII character sets. Common approaches
+ are to send 7 bit national variant ISO 646 character sets over
+ current RFC822/SMTP, to extend SMTP and RFC822 to use 8bit ISO 8859
+
+
+
+Vaudreuil [Page 1]
+
+RFC 1428 Transition to 8bit-SMTP/MIME February 1993
+
+
+ character sets, and to use proprietary PC character sets.
+
+ A third approach is used for Japanese mail. Japanese characters are
+ represented by pairs of octets with the high order bit cleared.
+ Switching between 14 bit character sets and 7 bit character sets is
+ indicated within the message by ISO 2022 escape sequences.
+
+ So long as these implementations can communicate without intermediate
+ transformations and have a loose private agreement on the use of a
+ specific character set without tagging, basic mail service can be
+ provided.
+
+ In the transition to the negotiated 8bit ESMTP/MIME environment, it
+ is important that mail sent by a currently non-conforming user can be
+ read by another non-conforming user. This existing functionality is
+ reduced by conversion from 8bit text to text encoded in unreadable
+ Base-64 or "garbled" text encoded in quoted printable.
+
+ There are several interesting non-interoperable cases that currently
+ exist in non US-ASCII mail and several new ones likely to emerge in a
+ transition to 8bit/MIME. Below is a listing of the transition-to-
+ mime cases. Only solutions to (4) in the context of a translating
+ gateway are discussed in this memo.
+
+ \ Receiver
+ \ 7bit 8bit MIME/
+ Sender \| only | transparent | ESMTP
+ ----------------------------------------
+ 7bit only | (1) | (1) | (1)
+ ----------------------------------------
+ 8bit transparent | (2) | (3) | (4)
+ ----------------------------------------
+ MIME/ESMTP | (5) | (5) | (6)
+
+
+ (1) 7Bit non-MIME sender to 7bit, MIME, or 8bit transparent receiver
+
+ This will continue to work unchanged with nationally varient ISO
+ 646 or ISO 2022 character set shifting if an external "out of
+ band" agreement exists between the sender and the receiver. A
+ 7bit to 8bit/ESMTP gateway need not alter the content of this
+ message.
+
+ (2) 8bit sender to 7bit non-MIME receiver
+
+ The receiver will receive bit-stripped mail which results in the
+ mis-interpretation of the data and the wrong character being
+ displayed or printed. Mail sent using languages where most
+
+
+
+Vaudreuil [Page 2]
+
+RFC 1428 Transition to 8bit-SMTP/MIME February 1993
+
+
+ characters are in the US-ASCII subset of ISO 8859 may be somewhat
+ readable.
+
+ (3) 8bit transparent sender to 8bit transparent receiver
+
+ Will work if an external agreement "out of band" to use a
+ particular character set without tagging exists between the sender
+ and the receiver.
+
+ (4) 8bit transparent sender to MIME/ESMTP conformant receiver
+
+ Will work if a reasonable upgrade path is provided via gateways,
+ the indicated character set tag inserted by the gateway is correct
+ and the receiver supports the character set chosen by the sender.
+ This case is the focus of this memo.
+
+ (5) MIME/ESMTP sender to non-MIME 7bit receiver
+
+ Because the ESMTP/MIME sender cannot know if the receiver will
+ understand 8bits, the sender will encode the text into base-64 or
+ quoted-printable which may be considered "garbled" by the
+ receiver. To provide a useful downgrade path the gateway must
+ have some knowledge about the capabilities of the receiver. When
+ the character set can be clearly identified, techniques like the
+ menmonic MNEM encoding described in RFC 1345 may be helpful in
+ this case.
+
+ (6) MIME/ESMTP sender to MIME/ESMTP receiver
+
+ Interoperability will be attained provided the receiver supports
+ the character set chosen by the sender.
+
+3. Upgrade Path from 8bit Transparent to ESMTP/MIME
+
+ A gateway which has been upgraded to support Extended SMTP may
+ upgrade an 8bit message received to MIME. This is consistent with
+ the requirement that all 8bit mail sent by ESMTP be encoded in MIME.
+ The upgrade should be done using the best available information.
+
+ A site may "upgrade" to MIME en-masse by implementing MIME conversion
+ for all messages leaving the site. For text messages, the body can
+ be converted by adding a MIME-version header and a Content-Type:
+ Text/Plain with the character set in use in the site, provided the
+ site uses a single character set.
+
+ An appropriate Content-Transfer-Encoding header line must be added to
+ indicate any encoding that may be necessary.
+
+
+
+
+Vaudreuil [Page 3]
+
+RFC 1428 Transition to 8bit-SMTP/MIME February 1993
+
+
+ Example:
+
+ MIME-Version: 1.0
+ Content-Type: Text/Plain; Charset = ISO-8859-1
+ Content-Transfer-Encoding: 8bit
+
+ If no information about the character set in use is available, the
+ gateway should upgrade the content by using the character set
+ "unknown-8bit". The unknown-8bit value of the charset parameter
+ indicates only that no reliable information about the character
+ set(s) used in the message was available.
+
+ If a message body has been upgraded to MIME, the RFC 822 headers
+ containing non US-ASCII characters must be upgraded to conform with
+ the header encoding rules of RFC1342. A gateway should recode all
+ unstructered header fields as well as RFC 822 "comment"s and
+ "phrase"s according to the rules of RFC 1342. There is no equivalent
+ in RFC 1342 to the "8bit" Content-Transfer-Encoding value for message
+ bodies so all 8bit header text must be transformed according to
+ either the "B" or the "Q" encoding method. For ISO 8859 character
+ sets, the "Q" encoding will generally result in somewhat readable
+ headers.
+
+ Trace information should be added to the document with a convert
+ clause: "rfc822-to-8bit", "rfc822-to-base-64" or "rfc822-to-quoted-
+ printable" e.g.,
+
+ Received: from dbc.mtview.ca.us by dbc.mtview.ca.us
+ convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700
+
+Appendix - The "unknown-8bit" Character Set
+
+ This section defines a "charset" parameter, for use in a MIME
+ Content-Type field.
+
+ A special purpose character set called "unknown-8bit" is defined to
+ be an unknown 8bit character set, encoded into a sequence of octets.
+ It can be used as a label for any character set from any language,
+ using any encoding. It must not be further defined.
+
+ The use of this token in a "charset=" field of a message indicates
+ that nothing is known about the character set used. This marker is
+ intended for use by non-MIME to MIME gateways; specifically in those
+ which translate from SMTP to 8bit ESMTP/MIME.
+
+ This character set is not intended to be used by mail composers. It
+ is assumed that the mail composer knows the character set in use and
+ will mark it with a character set value as specified in [1], as
+
+
+
+Vaudreuil [Page 4]
+
+RFC 1428 Transition to 8bit-SMTP/MIME February 1993
+
+
+ amended by current Assigned Numbers documents [6].
+
+ The use of the "unknown-8bit" label is intended only by mail gateway
+ agents which cannot determine via out-of-band information the
+ intended character set.
+
+ The interpretation of the "unknown-8bit" is up to the mail reader.
+ It is assumed that in many cases the human user will be able to
+ interpret the information and choose an appropriate character set or
+ pre-processor.
+
+Acknowledgements
+
+ This document originated as a hallway conversation between Ned Freed,
+ Neil Katin, and the author. Substantive input was received from
+ Jonathan Laventhol, Craig Everhart, Olle Jarnefors, and Olafur
+ Gudmundsson. The document was refined with the input of many
+ participants in the IETF SMTP Extensions Working Group.
+
+References
+
+ [1] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+ Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
+
+ [2] Moore, K., "Representation of Non-ASCII Text in Internet Message
+ Headers", RFC 1342, University of Tennessee, June 1992.
+
+ [3] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+ E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
+ Nations University, Innosoft International, Inc., Dover Beach
+ Consulting, Inc., Network Management Associates, Inc., The Branch
+ Office, February 1993.
+
+ [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+ E., and D. Crocker, "SMTP Service Extensions for 8bit
+ MIMEtransport", RFC 1426, United Nations University, Innosoft
+ International, Inc., Dover Beach Consulting, Inc., Network
+ Management Associates, Inc., The Branch Office, February 1993.
+
+ [5] Coded Character Set--7-Bit American Standard Code for Information
+ Interchange, ANSI X3.4-1986.
+
+ [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+ USC/Information Sciences Institute, July 1992.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+Vaudreuil [Page 5]
+
+RFC 1428 Transition to 8bit-SMTP/MIME February 1993
+
+
+Author's Address
+
+ Greg Vaudreuil
+ Corporation for National Research Initiatives
+ 1895 Preston White Drive, Suite 100
+ Reston, VA 22091 USA
+
+ Phone: (703) 620-8990
+ EMail: GVaudre@CNRI.Reston.VA.US
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil [Page 6]
+ \ No newline at end of file
diff --git a/Documentation/en/rfc/rfc1521.txt b/Documentation/en/rfc/rfc1521.txt
new file mode 100644
index 00000000..074ba415
--- /dev/null
+++ b/Documentation/en/rfc/rfc1521.txt
@@ -0,0 +1,4539 @@
+
+
+
+
+
+
+Network Working Group N. Borenstein
+Request for Comments: 1521 Bellcore
+Obsoletes: 1341 N. Freed
+Category: Standards Track Innosoft
+ September 1993
+
+
+ MIME (Multipurpose Internet Mail Extensions) Part One:
+ Mechanisms for Specifying and Describing
+ the Format of Internet Message Bodies
+
+Status of this Memo
+
+ This RFC specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" for the standardization state and status
+ of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ STD 11, RFC 822 defines a message representation protocol which
+ specifies considerable detail about message headers, but which leaves
+ the message content, or message body, as flat ASCII text. This
+ document redefines the format of message bodies to allow multi-part
+ textual and non-textual message bodies to be represented and
+ exchanged without loss of information. This is based on earlier work
+ documented in RFC 934 and STD 11, RFC 1049, but extends and revises
+ that work. Because RFC 822 said so little about message bodies, this
+ document is largely orthogonal to (rather than a revision of) RFC
+ 822.
+
+ In particular, this document is designed to provide facilities to
+ include multiple objects in a single message, to represent body text
+ in character sets other than US-ASCII, to represent formatted multi-
+ font text messages, to represent non-textual material such as images
+ and audio fragments, and generally to facilitate later extensions
+ defining new types of Internet mail for use by cooperating mail
+ agents.
+
+ This document does NOT extend Internet mail header fields to permit
+ anything other than US-ASCII text data. Such extensions are the
+ subject of a companion document [RFC-1522].
+
+ This document is a revision of RFC 1341. Significant differences
+ from RFC 1341 are summarized in Appendix H.
+
+
+
+
+
+Borenstein & Freed [Page 1]
+
+RFC 1521 MIME September 1993
+
+
+Table of Contents
+
+ 1. Introduction....................................... 3
+ 2. Notations, Conventions, and Generic BNF Grammar.... 6
+ 3. The MIME-Version Header Field...................... 7
+ 4. The Content-Type Header Field...................... 9
+ 5. The Content-Transfer-Encoding Header Field......... 13
+ 5.1. Quoted-Printable Content-Transfer-Encoding......... 18
+ 5.2. Base64 Content-Transfer-Encoding................... 21
+ 6. Additional Content-Header Fields................... 23
+ 6.1. Optional Content-ID Header Field................... 23
+ 6.2. Optional Content-Description Header Field.......... 24
+ 7. The Predefined Content-Type Values................. 24
+ 7.1. The Text Content-Type.............................. 24
+ 7.1.1. The charset parameter.............................. 25
+ 7.1.2. The Text/plain subtype............................. 28
+ 7.2. The Multipart Content-Type......................... 28
+ 7.2.1. Multipart: The common syntax...................... 29
+ 7.2.2. The Multipart/mixed (primary) subtype.............. 34
+ 7.2.3. The Multipart/alternative subtype.................. 34
+ 7.2.4. The Multipart/digest subtype....................... 36
+ 7.2.5. The Multipart/parallel subtype..................... 37
+ 7.2.6. Other Multipart subtypes........................... 37
+ 7.3. The Message Content-Type........................... 38
+ 7.3.1. The Message/rfc822 (primary) subtype............... 38
+ 7.3.2. The Message/Partial subtype........................ 39
+ 7.3.3. The Message/External-Body subtype.................. 42
+ 7.3.3.1. The "ftp" and "tftp" access-types............... 44
+ 7.3.3.2. The "anon-ftp" access-type...................... 45
+ 7.3.3.3. The "local-file" and "afs" access-types......... 45
+ 7.3.3.4. The "mail-server" access-type................... 45
+ 7.3.3.5. Examples and Further Explanations............... 46
+ 7.4. The Application Content-Type....................... 49
+ 7.4.1. The Application/Octet-Stream (primary) subtype..... 50
+ 7.4.2. The Application/PostScript subtype................. 50
+ 7.4.3. Other Application subtypes......................... 53
+ 7.5. The Image Content-Type............................. 53
+ 7.6. The Audio Content-Type............................. 54
+ 7.7. The Video Content-Type............................. 54
+ 7.8. Experimental Content-Type Values................... 54
+ 8. Summary............................................ 56
+ 9. Security Considerations............................ 56
+ 10. Authors' Addresses................................. 57
+ 11. Acknowledgements................................... 58
+ Appendix A -- Minimal MIME-Conformance.................... 60
+ Appendix B -- General Guidelines For Sending Email Data... 63
+ Appendix C -- A Complex Multipart Example................. 66
+ Appendix D -- Collected Grammar........................... 68
+
+
+
+Borenstein & Freed [Page 2]
+
+RFC 1521 MIME September 1993
+
+
+ Appendix E -- IANA Registration Procedures................ 72
+ E.1 Registration of New Content-type/subtype Values...... 72
+ E.2 Registration of New Access-type Values
+ for Message/external-body............................ 73
+ Appendix F -- Summary of the Seven Content-types.......... 74
+ Appendix G -- Canonical Encoding Model.................... 76
+ Appendix H -- Changes from RFC 1341....................... 78
+ References................................................ 80
+
+1. Introduction
+
+ Since its publication in 1982, STD 11, RFC 822 [RFC-822] has defined
+ the standard format of textual mail messages on the Internet. Its
+ success has been such that the RFC 822 format has been adopted,
+ wholly or partially, well beyond the confines of the Internet and the
+ Internet SMTP transport defined by STD 10, RFC 821 [RFC-821]. As the
+ format has seen wider use, a number of limitations have proven
+ increasingly restrictive for the user community.
+
+ RFC 822 was intended to specify a format for text messages. As such,
+ non-text messages, such as multimedia messages that might include
+ audio or images, are simply not mentioned. Even in the case of text,
+ however, RFC 822 is inadequate for the needs of mail users whose
+ languages require the use of character sets richer than US ASCII
+ [US-ASCII]. Since RFC 822 does not specify mechanisms for mail
+ containing audio, video, Asian language text, or even text in most
+ European languages, additional specifications are needed.
+
+ One of the notable limitations of RFC 821/822 based mail systems is
+ the fact that they limit the contents of electronic mail messages to
+ relatively short lines of seven-bit ASCII. This forces users to
+ convert any non-textual data that they may wish to send into seven-
+ bit bytes representable as printable ASCII characters before invoking
+ a local mail UA (User Agent, a program with which human users send
+ and receive mail). Examples of such encodings currently used in the
+ Internet include pure hexadecimal, uuencode, the 3-in-4 base 64
+ scheme specified in RFC 1421, the Andrew Toolkit Representation
+ [ATK], and many others.
+
+ The limitations of RFC 822 mail become even more apparent as gateways
+ are designed to allow for the exchange of mail messages between RFC
+ 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
+ inclusion of non-textual body parts within electronic mail messages.
+ The current standards for the mapping of X.400 messages to RFC 822
+ messages specify either that X.400 non-textual body parts must be
+ converted to (not encoded in) an ASCII format, or that they must be
+ discarded, notifying the RFC 822 user that discarding has occurred.
+ This is clearly undesirable, as information that a user may wish to
+
+
+
+Borenstein & Freed [Page 3]
+
+RFC 1521 MIME September 1993
+
+
+ receive is lost. Even though a user's UA may not have the capability
+ of dealing with the non-textual body part, the user might have some
+ mechanism external to the UA that can extract useful information from
+ the body part. Moreover, it does not allow for the fact that the
+ message may eventually be gatewayed back into an X.400 message
+ handling system (i.e., the X.400 message is "tunneled" through
+ Internet mail), where the non-textual information would definitely
+ become useful again.
+
+ This document describes several mechanisms that combine to solve most
+ of these problems without introducing any serious incompatibilities
+ with the existing world of RFC 822 mail. In particular, it
+ describes:
+
+ 1. A MIME-Version header field, which uses a version number to
+ declare a message to be conformant with this specification and
+ allows mail processing agents to distinguish between such
+ messages and those generated by older or non-conformant software,
+ which is presumed to lack such a field.
+
+ 2. A Content-Type header field, generalized from RFC 1049 [RFC-1049],
+ which can be used to specify the type and subtype of data in the
+ body of a message and to fully specify the native representation
+ (encoding) of such data.
+
+ 2.a. A "text" Content-Type value, which can be used to represent
+ textual information in a number of character sets and
+ formatted text description languages in a standardized
+ manner.
+
+ 2.b. A "multipart" Content-Type value, which can be used to
+ combine several body parts, possibly of differing types of
+ data, into a single message.
+
+ 2.c. An "application" Content-Type value, which can be used to
+ transmit application data or binary data, and hence, among
+ other uses, to implement an electronic mail file transfer
+ service.
+
+ 2.d. A "message" Content-Type value, for encapsulating another
+ mail message.
+
+ 2.e An "image" Content-Type value, for transmitting still image
+ (picture) data.
+
+ 2.f. An "audio" Content-Type value, for transmitting audio or
+ voice data.
+
+
+
+
+Borenstein & Freed [Page 4]
+
+RFC 1521 MIME September 1993
+
+
+ 2.g. A "video" Content-Type value, for transmitting video or
+ moving image data, possibly with audio as part of the
+ composite video data format.
+
+ 3. A Content-Transfer-Encoding header field, which can be used to
+ specify an auxiliary encoding that was applied to the data in
+ order to allow it to pass through mail transport mechanisms which
+ may have data or character set limitations.
+
+ 4. Two additional header fields that can be used to further describe
+ the data in a message body, the Content-ID and Content-
+ Description header fields.
+
+ MIME has been carefully designed as an extensible mechanism, and it
+ is expected that the set of content-type/subtype pairs and their
+ associated parameters will grow significantly with time. Several
+ other MIME fields, notably including character set names, are likely
+ to have new values defined over time. In order to ensure that the
+ set of such values is developed in an orderly, well-specified, and
+ public manner, MIME defines a registration process which uses the
+ Internet Assigned Numbers Authority (IANA) as a central registry for
+ such values. Appendix E provides details about how IANA registration
+ is accomplished.
+
+ Finally, to specify and promote interoperability, Appendix A of this
+ document provides a basic applicability statement for a subset of the
+ above mechanisms that defines a minimal level of "conformance" with
+ this document.
+
+ HISTORICAL NOTE: Several of the mechanisms described in this
+ document may seem somewhat strange or even baroque at first
+ reading. It is important to note that compatibility with existing
+ standards AND robustness across existing practice were two of the
+ highest priorities of the working group that developed this
+ document. In particular, compatibility was always favored over
+ elegance.
+
+ MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341]
+ [RFC-1342]. This document is a relatively minor updating of RFC
+ 1341, and is intended to supersede it. The differences between this
+ document and RFC 1341 are summarized in Appendix H. Please refer to
+ the current edition of the "IAB Official Protocol Standards" for the
+ standardization state and status of this protocol. Several other RFC
+ documents will be of interest to the MIME implementor, in particular
+ [RFC 1343], [RFC-1344], and [RFC-1345].
+
+
+
+
+
+
+Borenstein & Freed [Page 5]
+
+RFC 1521 MIME September 1993
+
+
+2. Notations, Conventions, and Generic BNF Grammar
+
+ This document is being published in two versions, one as plain ASCII
+ text and one as PostScript (PostScript is a trademark of Adobe
+ Systems Incorporated.). While the text version is the official
+ specification, some will find the PostScript version easier to read.
+ The textual contents are identical. An Andrew-format copy of this
+ document is also available from the first author (Borenstein).
+
+ Although the mechanisms specified in this document are all described
+ in prose, most are also described formally in the modified BNF
+ notation of RFC 822. Implementors will need to be familiar with this
+ notation in order to understand this specification, and are referred
+ to RFC 822 for a complete explanation of the modified BNF notation.
+
+ Some of the modified BNF in this document makes reference to
+ syntactic entities that are defined in RFC 822 and not in this
+ document. A complete formal grammar, then, is obtained by combining
+ the collected grammar appendix of this document with that of RFC 822
+ plus the modifications to RFC 822 defined in RFC 1123, which
+ specifically changes the syntax for `return', `date' and `mailbox'.
+
+ The term CRLF, in this document, refers to the sequence of the two
+ ASCII characters CR (13) and LF (10) which, taken together, in this
+ order, denote a line break in RFC 822 mail.
+
+ The term "character set" is used in this document to refer to a
+ method used with one or more tables to convert encoded text to a
+ series of octets. This definition is intended to allow various kinds
+ of text encodings, from simple single-table mappings such as ASCII to
+ complex table switching methods such as those that use ISO 2022's
+ techniques. However, a MIME character set name must fully specify
+ the mapping to be performed.
+
+ The term "message", when not further qualified, means either the
+ (complete or "top-level") message being transferred on a network, or
+ a message encapsulated in a body of type "message".
+
+ The term "body part", in this document, means one of the parts of the
+ body of a multipart entity. A body part has a header and a body, so
+ it makes sense to speak about the body of a body part.
+
+ The term "entity", in this document, means either a message or a body
+ part. All kinds of entities share the property that they have a
+ header and a body.
+
+ The term "body", when not further qualified, means the body of an
+ entity, that is the body of either a message or of a body part.
+
+
+
+Borenstein & Freed [Page 6]
+
+RFC 1521 MIME September 1993
+
+
+ NOTE: The previous four definitions are clearly circular. This is
+ unavoidable, since the overall structure of a MIME message is
+ indeed recursive.
+
+ In this document, all numeric and octet values are given in decimal
+ notation.
+
+ It must be noted that Content-Type values, subtypes, and parameter
+ names as defined in this document are case-insensitive. However,
+ parameter values are case-sensitive unless otherwise specified for
+ the specific parameter.
+
+ FORMATTING NOTE: This document has been carefully formatted for
+ ease of reading. The PostScript version of this document, in
+ particular, places notes like this one, which may be skipped by
+ the reader, in a smaller, italicized, font, and indents it as
+ well. In the text version, only the indentation is preserved, so
+ if you are reading the text version of this you might consider
+ using the PostScript version instead. However, all such notes will
+ be indented and preceded by "NOTE:" or some similar introduction,
+ even in the text version.
+
+ The primary purpose of these non-essential notes is to convey
+ information about the rationale of this document, or to place this
+ document in the proper historical or evolutionary context. Such
+ information may be skipped by those who are focused entirely on
+ building a conformant implementation, but may be of use to those
+ who wish to understand why this document is written as it is.
+
+ For ease of recognition, all BNF definitions have been placed in a
+ fixed-width font in the PostScript version of this document.
+
+3. The MIME-Version Header Field
+
+ Since RFC 822 was published in 1982, there has really been only one
+ format standard for Internet messages, and there has been little
+ perceived need to declare the format standard in use. This document
+ is an independent document that complements RFC 822. Although the
+ extensions in this document have been defined in such a way as to be
+ compatible with RFC 822, there are still circumstances in which it
+ might be desirable for a mail-processing agent to know whether a
+ message was composed with the new standard in mind.
+
+ Therefore, this document defines a new header field, "MIME-Version",
+ which is to be used to declare the version of the Internet message
+ body format standard in use.
+
+ Messages composed in accordance with this document MUST include such
+
+
+
+Borenstein & Freed [Page 7]
+
+RFC 1521 MIME September 1993
+
+
+ a header field, with the following verbatim text:
+
+ MIME-Version: 1.0
+
+ The presence of this header field is an assertion that the message
+ has been composed in compliance with this document.
+
+ Since it is possible that a future document might extend the message
+ format standard again, a formal BNF is given for the content of the
+ MIME-Version field:
+
+ version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+ Thus, future format specifiers, which might replace or extend "1.0",
+ are constrained to be two integer fields, separated by a period. If
+ a message is received with a MIME-version value other than "1.0", it
+ cannot be assumed to conform with this specification.
+
+ Note that the MIME-Version header field is required at the top level
+ of a message. It is not required for each body part of a multipart
+ entity. It is required for the embedded headers of a body of type
+ "message" if and only if the embedded message is itself claimed to be
+ MIME-conformant.
+
+ It is not possible to fully specify how a mail reader that conforms
+ with MIME as defined in this document should treat a message that
+ might arrive in the future with some value of MIME-Version other than
+ "1.0". However, conformant software is encouraged to check the
+ version number and at least warn the user if an unrecognized MIME-
+ version is encountered.
+
+ It is also worth noting that version control for specific content-
+ types is not accomplished using the MIME-Version mechanism. In
+ particular, some formats (such as application/postscript) have
+ version numbering conventions that are internal to the document
+ format. Where such conventions exist, MIME does nothing to supersede
+ them. Where no such conventions exist, a MIME type might use a
+ "version" parameter in the content-type field if necessary.
+
+ NOTE TO IMPLEMENTORS: All header fields defined in this document,
+ including MIME-Version, Content-type, etc., are subject to the
+ general syntactic rules for header fields specified in RFC 822. In
+ particular, all can include comments, which means that the following
+ two MIME-Version fields are equivalent:
+
+ MIME-Version: 1.0
+ MIME-Version: 1.0 (Generated by GBD-killer 3.7)
+
+
+
+
+Borenstein & Freed [Page 8]
+
+RFC 1521 MIME September 1993
+
+
+4. The Content-Type Header Field
+
+ The purpose of the Content-Type field is to describe the data
+ contained in the body fully enough that the receiving user agent can
+ pick an appropriate agent or mechanism to present the data to the
+ user, or otherwise deal with the data in an appropriate manner.
+
+ HISTORICAL NOTE: The Content-Type header field was first defined in
+ RFC 1049. RFC 1049 Content-types used a simpler and less powerful
+ syntax, but one that is largely compatible with the mechanism given
+ here.
+
+ The Content-Type header field is used to specify the nature of the
+ data in the body of an entity, by giving type and subtype
+ identifiers, and by providing auxiliary information that may be
+ required for certain types. After the type and subtype names, the
+ remainder of the header field is simply a set of parameters,
+ specified in an attribute/value notation. The set of meaningful
+ parameters differs for the different types. In particular, there are
+ NO globally-meaningful parameters that apply to all content-types.
+ Global mechanisms are best addressed, in the MIME model, by the
+ definition of additional Content-* header fields. The ordering of
+ parameters is not significant. Among the defined parameters is a
+ "charset" parameter by which the character set used in the body may
+ be declared. Comments are allowed in accordance with RFC 822 rules
+ for structured header fields.
+
+ In general, the top-level Content-Type is used to declare the general
+ type of data, while the subtype specifies a specific format for that
+ type of data. Thus, a Content-Type of "image/xyz" is enough to tell
+ a user agent that the data is an image, even if the user agent has no
+ knowledge of the specific image format "xyz". Such information can
+ be used, for example, to decide whether or not to show a user the raw
+ data from an unrecognized subtype -- such an action might be
+ reasonable for unrecognized subtypes of text, but not for
+ unrecognized subtypes of image or audio. For this reason, registered
+ subtypes of audio, image, text, and video, should not contain
+ embedded information that is really of a different type. Such
+ compound types should be represented using the "multipart" or
+ "application" types.
+
+ Parameters are modifiers of the content-subtype, and do not
+ fundamentally affect the requirements of the host system. Although
+ most parameters make sense only with certain content-types, others
+ are "global" in the sense that they might apply to any subtype. For
+ example, the "boundary" parameter makes sense only for the
+ "multipart" content-type, but the "charset" parameter might make
+ sense with several content-types.
+
+
+
+Borenstein & Freed [Page 9]
+
+RFC 1521 MIME September 1993
+
+
+ An initial set of seven Content-Types is defined by this document.
+ This set of top-level names is intended to be substantially complete.
+ It is expected that additions to the larger set of supported types
+ can generally be accomplished by the creation of new subtypes of
+ these initial types. In the future, more top-level types may be
+ defined only by an extension to this standard. If another primary
+ type is to be used for any reason, it must be given a name starting
+ with "X-" to indicate its non-standard status and to avoid a
+ potential conflict with a future official name.
+
+ In the Augmented BNF notation of RFC 822, a Content-Type header field
+ value is defined as follows:
+
+ content := "Content-Type" ":" type "/" subtype *(";"
+ parameter)
+ ; case-insensitive matching of type and subtype
+
+ type := "application" / "audio"
+ / "image" / "message"
+ / "multipart" / "text"
+ / "video" / extension-token
+ ; All values case-insensitive
+
+ extension-token := x-token / iana-token
+
+ iana-token := <a publicly-defined extension token,
+ registered with IANA, as specified in
+ appendix E>
+
+ x-token := <The two characters "X-" or "x-" followed, with
+ no intervening white space, by any token>
+
+ subtype := token ; case-insensitive
+
+ parameter := attribute "=" value
+
+ attribute := token ; case-insensitive
+
+ value := token / quoted-string
+
+ token := 1*<any (ASCII) CHAR except SPACE, CTLs,
+ or tspecials>
+
+ tspecials := "(" / ")" / "<" / ">" / "@"
+ / "," / ";" / ":" / "\" / <">
+ / "/" / "[" / "]" / "?" / "="
+ ; Must be in quoted-string,
+ ; to use within parameter values
+
+
+
+Borenstein & Freed [Page 10]
+
+RFC 1521 MIME September 1993
+
+
+ Note that the definition of "tspecials" is the same as the RFC 822
+ definition of "specials" with the addition of the three characters
+ "/", "?", and "=", and the removal of ".".
+
+ Note also that a subtype specification is MANDATORY. There are no
+ default subtypes.
+
+ The type, subtype, and parameter names are not case sensitive. For
+ example, TEXT, Text, and TeXt are all equivalent. Parameter values
+ are normally case sensitive, but certain parameters are interpreted
+ to be case-insensitive, depending on the intended use. (For example,
+ multipart boundaries are case-sensitive, but the "access-type" for
+ message/External-body is not case-sensitive.)
+
+ Beyond this syntax, the only constraint on the definition of subtype
+ names is the desire that their uses must not conflict. That is, it
+ would be undesirable to have two different communities using
+ "Content-Type: application/foobar" to mean two different things. The
+ process of defining new content-subtypes, then, is not intended to be
+ a mechanism for imposing restrictions, but simply a mechanism for
+ publicizing the usages. There are, therefore, two acceptable
+ mechanisms for defining new Content-Type subtypes:
+
+ 1. Private values (starting with "X-") may be
+ defined bilaterally between two cooperating
+ agents without outside registration or
+ standardization.
+
+ 2. New standard values must be documented,
+ registered with, and approved by IANA, as
+ described in Appendix E. Where intended for
+ public use, the formats they refer to must
+ also be defined by a published specification,
+ and possibly offered for standardization.
+
+ The seven standard initial predefined Content-Types are detailed in
+ the bulk of this document. They are:
+
+ text -- textual information. The primary subtype,
+ "plain", indicates plain (unformatted) text. No
+ special software is required to get the full
+ meaning of the text, aside from support for the
+ indicated character set. Subtypes are to be used
+ for enriched text in forms where application
+ software may enhance the appearance of the text,
+ but such software must not be required in order to
+ get the general idea of the content. Possible
+ subtypes thus include any readable word processor
+
+
+
+Borenstein & Freed [Page 11]
+
+RFC 1521 MIME September 1993
+
+
+ format. A very simple and portable subtype,
+ richtext, was defined in RFC 1341, with a future
+ revision expected.
+
+ multipart -- data consisting of multiple parts of
+ independent data types. Four initial subtypes
+ are defined, including the primary "mixed"
+ subtype, "alternative" for representing the same
+ data in multiple formats, "parallel" for parts
+ intended to be viewed simultaneously, and "digest"
+ for multipart entities in which each part is of
+ type "message".
+
+ message -- an encapsulated message. A body of
+ Content-Type "message" is itself all or part of a
+ fully formatted RFC 822 conformant message which
+ may contain its own different Content-Type header
+ field. The primary subtype is "rfc822". The
+ "partial" subtype is defined for partial messages,
+ to permit the fragmented transmission of bodies
+ that are thought to be too large to be passed
+ through mail transport facilities. Another
+ subtype, "External-body", is defined for
+ specifying large bodies by reference to an
+ external data source.
+
+ image -- image data. Image requires a display device
+ (such as a graphical display, a printer, or a FAX
+ machine) to view the information. Initial
+ subtypes are defined for two widely-used image
+ formats, jpeg and gif.
+
+ audio -- audio data, with initial subtype "basic".
+ Audio requires an audio output device (such as a
+ speaker or a telephone) to "display" the contents.
+
+ video -- video data. Video requires the capability to
+ display moving images, typically including
+ specialized hardware and software. The initial
+ subtype is "mpeg".
+
+ application -- some other kind of data, typically
+ either uninterpreted binary data or information to
+ be processed by a mail-based application. The
+ primary subtype, "octet-stream", is to be used in
+ the case of uninterpreted binary data, in which
+ case the simplest recommended action is to offer
+ to write the information into a file for the user.
+
+
+
+Borenstein & Freed [Page 12]
+
+RFC 1521 MIME September 1993
+
+
+ An additional subtype, "PostScript", is defined
+ for transporting PostScript documents in bodies.
+ Other expected uses for "application" include
+ spreadsheets, data for mail-based scheduling
+ systems, and languages for "active"
+ (computational) email. (Note that active email
+ and other application data may entail several
+ security considerations, which are discussed later
+ in this memo, particularly in the context of
+ application/PostScript.)
+
+ Default RFC 822 messages are typed by this protocol as plain text in
+ the US-ASCII character set, which can be explicitly specified as
+ "Content-type: text/plain; charset=us-ascii". If no Content-Type is
+ specified, this default is assumed. In the presence of a MIME-
+ Version header field, a receiving User Agent can also assume that
+ plain US-ASCII text was the sender's intent. In the absence of a
+ MIME-Version specification, plain US-ASCII text must still be
+ assumed, but the sender's intent might have been otherwise.
+
+ RATIONALE: In the absence of any Content-Type header field or
+ MIME-Version header field, it is impossible to be certain that a
+ message is actually text in the US-ASCII character set, since it
+ might well be a message that, using the conventions that predate
+ this document, includes text in another character set or non-
+ textual data in a manner that cannot be automatically recognized
+ (e.g., a uuencoded compressed UNIX tar file). Although there is
+ no fully acceptable alternative to treating such untyped messages
+ as "text/plain; charset=us-ascii", implementors should remain
+ aware that if a message lacks both the MIME-Version and the
+ Content-Type header fields, it may in practice contain almost
+ anything.
+
+ It should be noted that the list of Content-Type values given here
+ may be augmented in time, via the mechanisms described above, and
+ that the set of subtypes is expected to grow substantially.
+
+ When a mail reader encounters mail with an unknown Content-type
+ value, it should generally treat it as equivalent to
+ "application/octet-stream", as described later in this document.
+
+5. The Content-Transfer-Encoding Header Field
+
+ Many Content-Types which could usefully be transported via email are
+ represented, in their "natural" format, as 8-bit character or binary
+ data. Such data cannot be transmitted over some transport protocols.
+ For example, RFC 821 restricts mail messages to 7-bit US-ASCII data
+ with lines no longer than 1000 characters.
+
+
+
+Borenstein & Freed [Page 13]
+
+RFC 1521 MIME September 1993
+
+
+ It is necessary, therefore, to define a standard mechanism for re-
+ encoding such data into a 7-bit short-line format. This document
+ specifies that such encodings will be indicated by a new "Content-
+ Transfer-Encoding" header field. The Content-Transfer-Encoding field
+ is used to indicate the type of transformation that has been used in
+ order to represent the body in an acceptable manner for transport.
+
+ Unlike Content-Types, a proliferation of Content-Transfer-Encoding
+ values is undesirable and unnecessary. However, establishing only a
+ single Content-Transfer-Encoding mechanism does not seem possible.
+ There is a tradeoff between the desire for a compact and efficient
+ encoding of largely-binary data and the desire for a readable
+ encoding of data that is mostly, but not entirely, 7-bit data. For
+ this reason, at least two encoding mechanisms are necessary: a
+ "readable" encoding and a "dense" encoding.
+
+ The Content-Transfer-Encoding field is designed to specify an
+ invertible mapping between the "native" representation of a type of
+ data and a representation that can be readily exchanged using 7 bit
+ mail transport protocols, such as those defined by RFC 821 (SMTP).
+ This field has not been defined by any previous standard. The field's
+ value is a single token specifying the type of encoding, as
+ enumerated below. Formally:
+
+ encoding := "Content-Transfer-Encoding" ":" mechanism
+
+ mechanism := "7bit" ; case-insensitive
+ / "quoted-printable"
+ / "base64"
+ / "8bit"
+ / "binary"
+ / x-token
+
+ These values are not case sensitive. That is, Base64 and BASE64 and
+ bAsE64 are all equivalent. An encoding type of 7BIT requires that
+ the body is already in a seven-bit mail-ready representation. This
+ is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is
+ assumed if the Content-Transfer-Encoding header field is not present.
+
+ The values "8bit", "7bit", and "binary" all mean that NO encoding has
+ been performed. However, they are potentially useful as indications
+ of the kind of data contained in the object, and therefore of the
+ kind of encoding that might need to be performed for transmission in
+ a given transport system. In particular:
+
+ "7bit" means that the data is all represented as short
+ lines of US-ASCII data.
+
+
+
+
+Borenstein & Freed [Page 14]
+
+RFC 1521 MIME September 1993
+
+
+ "8bit" means that the lines are short, but there may be
+ non-ASCII characters (octets with the high-order
+ bit set).
+
+ "Binary" means that not only may non-ASCII characters
+ be present, but also that the lines are not
+ necessarily short enough for SMTP transport.
+
+ The difference between "8bit" (or any other conceivable bit-width
+ token) and the "binary" token is that "binary" does not require
+ adherence to any limits on line length or to the SMTP CRLF semantics,
+ while the bit-width tokens do require such adherence. If the body
+ contains data in any bit-width other than 7-bit, the appropriate
+ bit-width Content-Transfer-Encoding token must be used (e.g., "8bit"
+ for unencoded 8 bit wide data). If the body contains binary data,
+ the "binary" Content-Transfer-Encoding token must be used.
+
+ NOTE: The distinction between the Content-Transfer-Encoding values
+ of "binary", "8bit", etc. may seem unimportant, in that all of
+ them really mean "none" -- that is, there has been no encoding of
+ the data for transport. However, clear labeling will be of
+ enormous value to gateways between future mail transport systems
+ with differing capabilities in transporting data that do not meet
+ the restrictions of RFC 821 transport.
+
+ Mail transport for unencoded 8-bit data is defined in RFC-1426
+ [RFC-1426]. As of the publication of this document, there are no
+ standardized Internet mail transports for which it is legitimate
+ to include unencoded binary data in mail bodies. Thus there are
+ no circumstances in which the "binary" Content-Transfer-Encoding
+ is actually legal on the Internet. However, in the event that
+ binary mail transport becomes a reality in Internet mail, or when
+ this document is used in conjunction with any other binary-capable
+ transport mechanism, binary bodies should be labeled as such using
+ this mechanism.
+
+ NOTE: The five values defined for the Content-Transfer-Encoding
+ field imply nothing about the Content-Type other than the
+ algorithm by which it was encoded or the transport system
+ requirements if unencoded.
+
+ Implementors may, if necessary, define new Content-Transfer-Encoding
+ values, but must use an x-token, which is a name prefixed by "X-" to
+ indicate its non-standard status, e.g., "Content-Transfer-Encoding:
+ x-my-new-encoding". However, unlike Content-Types and subtypes, the
+ creation of new Content-Transfer-Encoding values is explicitly and
+ strongly discouraged, as it seems likely to hinder interoperability
+ with little potential benefit. Their use is allowed only as the
+
+
+
+Borenstein & Freed [Page 15]
+
+RFC 1521 MIME September 1993
+
+
+ result of an agreement between cooperating user agents.
+
+ If a Content-Transfer-Encoding header field appears as part of a
+ message header, it applies to the entire body of that message. If a
+ Content-Transfer-Encoding header field appears as part of a body
+ part's headers, it applies only to the body of that body part. If an
+ entity is of type "multipart" or "message", the Content-Transfer-
+ Encoding is not permitted to have any value other than a bit width
+ (e.g., "7bit", "8bit", etc.) or "binary".
+
+ It should be noted that email is character-oriented, so that the
+ mechanisms described here are mechanisms for encoding arbitrary octet
+ streams, not bit streams. If a bit stream is to be encoded via one
+ of these mechanisms, it must first be converted to an 8-bit byte
+ stream using the network standard bit order ("big-endian"), in which
+ the earlier bits in a stream become the higher-order bits in a byte.
+ A bit stream not ending at an 8-bit boundary must be padded with
+ zeroes. This document provides a mechanism for noting the addition
+ of such padding in the case of the application Content-Type, which
+ has a "padding" parameter.
+
+ The encoding mechanisms defined here explicitly encode all data in
+ ASCII. Thus, for example, suppose an entity has header fields such
+ as:
+
+ Content-Type: text/plain; charset=ISO-8859-1
+ Content-transfer-encoding: base64
+
+ This must be interpreted to mean that the body is a base64 ASCII
+ encoding of data that was originally in ISO-8859-1, and will be in
+ that character set again after decoding.
+
+ The following sections will define the two standard encoding
+ mechanisms. The definition of new content-transfer-encodings is
+ explicitly discouraged and should only occur when absolutely
+ necessary. All content-transfer-encoding namespace except that
+ beginning with "X-" is explicitly reserved to the IANA for future
+ use. Private agreements about content-transfer-encodings are also
+ explicitly discouraged.
+
+ Certain Content-Transfer-Encoding values may only be used on certain
+ Content-Types. In particular, it is expressly forbidden to use any
+ encodings other than "7bit", "8bit", or "binary" with any Content-
+ Type that recursively includes other Content-Type fields, notably the
+ "multipart" and "message" Content-Types. All encodings that are
+ desired for bodies of type multipart or message must be done at the
+ innermost level, by encoding the actual body that needs to be
+ encoded.
+
+
+
+Borenstein & Freed [Page 16]
+
+RFC 1521 MIME September 1993
+
+
+ NOTE ON ENCODING RESTRICTIONS: Though the prohibition against
+ using content-transfer-encodings on data of type multipart or
+ message may seem overly restrictive, it is necessary to prevent
+ nested encodings, in which data are passed through an encoding
+ algorithm multiple times, and must be decoded multiple times in
+ order to be properly viewed. Nested encodings add considerable
+ complexity to user agents: aside from the obvious efficiency
+ problems with such multiple encodings, they can obscure the basic
+ structure of a message. In particular, they can imply that
+ several decoding operations are necessary simply to find out what
+ types of objects a message contains. Banning nested encodings may
+ complicate the job of certain mail gateways, but this seems less
+ of a problem than the effect of nested encodings on user agents.
+
+ NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
+ TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding
+ could be inferred from the characteristics of the Content-Type
+ that is to be encoded, or, at the very least, that certain
+ Content-Transfer-Encodings could be mandated for use with specific
+ Content-Types. There are several reasons why this is not the case.
+ First, given the varying types of transports used for mail, some
+ encodings may be appropriate for some Content-Type/transport
+ combinations and not for others. (For example, in an 8-bit
+ transport, no encoding would be required for text in certain
+ character sets, while such encodings are clearly required for 7-
+ bit SMTP.) Second, certain Content-Types may require different
+ types of transfer encoding under different circumstances. For
+ example, many PostScript bodies might consist entirely of short
+ lines of 7-bit data and hence require little or no encoding.
+ Other PostScript bodies (especially those using Level 2
+ PostScript's binary encoding mechanism) may only be reasonably
+ represented using a binary transport encoding. Finally, since
+ Content-Type is intended to be an open-ended specification
+ mechanism, strict specification of an association between
+ Content-Types and encodings effectively couples the specification
+ of an application protocol with a specific lower-level transport.
+ This is not desirable since the developers of a Content-Type
+ should not have to be aware of all the transports in use and what
+ their limitations are.
+
+ NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64
+ encodings are designed so that conversion between them is
+ possible. The only issue that arises in such a conversion is the
+ handling of line breaks. When converting from quoted-printable to
+ base64 a line break must be converted into a CRLF sequence.
+ Similarly, a CRLF sequence in base64 data must be converted to a
+ quoted-printable line break, but ONLY when converting text data.
+
+
+
+
+Borenstein & Freed [Page 17]
+
+RFC 1521 MIME September 1993
+
+
+ NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in
+ earlier drafts of this memo, regarding the model for when email
+ data was to be converted to canonical form and encoded, and in
+ particular how this process would affect the treatment of CRLFs,
+ given that the representation of newlines varies greatly from
+ system to system, and the relationship between content-transfer-
+ encodings and character sets. For this reason, a canonical model
+ for encoding is presented as Appendix G.
+
+5.1. Quoted-Printable Content-Transfer-Encoding
+
+ The Quoted-Printable encoding is intended to represent data that
+ largely consists of octets that correspond to printable characters in
+ the ASCII character set. It encodes the data in such a way that the
+ resulting octets are unlikely to be modified by mail transport. If
+ the data being encoded are mostly ASCII text, the encoded form of the
+ data remains largely recognizable by humans. A body which is
+ entirely ASCII may also be encoded in Quoted-Printable to ensure the
+ integrity of the data should the message pass through a character-
+ translating, and/or line-wrapping gateway.
+
+ In this encoding, octets are to be represented as determined by the
+ following rules:
+
+ Rule #1: (General 8-bit representation) Any octet, except those
+ indicating a line break according to the newline convention of the
+ canonical (standard) form of the data being encoded, may be
+ represented by an "=" followed by a two digit hexadecimal
+ representation of the octet's value. The digits of the
+ hexadecimal alphabet, for this purpose, are "0123456789ABCDEF".
+ Uppercase letters must be used when sending hexadecimal data,
+ though a robust implementation may choose to recognize lowercase
+ letters on receipt. Thus, for example, the value 12 (ASCII form
+ feed) can be represented by "=0C", and the value 61 (ASCII EQUAL
+ SIGN) can be represented by "=3D". Except when the following
+ rules allow an alternative encoding, this rule is mandatory.
+
+ Rule #2: (Literal representation) Octets with decimal values of 33
+ through 60 inclusive, and 62 through 126, inclusive, MAY be
+ represented as the ASCII characters which correspond to those
+ octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN
+ through TILDE, respectively).
+
+ Rule #3: (White Space): Octets with values of 9 and 32 MAY be
+ represented as ASCII TAB (HT) and SPACE characters, respectively,
+ but MUST NOT be so represented at the end of an encoded line. Any
+ TAB (HT) or SPACE characters on an encoded line MUST thus be
+ followed on that line by a printable character. In particular, an
+
+
+
+Borenstein & Freed [Page 18]
+
+RFC 1521 MIME September 1993
+
+
+ "=" at the end of an encoded line, indicating a soft line break
+ (see rule #5) may follow one or more TAB (HT) or SPACE characters.
+ It follows that an octet with value 9 or 32 appearing at the end
+ of an encoded line must be represented according to Rule #1. This
+ rule is necessary because some MTAs (Message Transport Agents,
+ programs which transport messages from one user to another, or
+ perform a part of such transfers) are known to pad lines of text
+ with SPACEs, and others are known to remove "white space"
+ characters from the end of a line. Therefore, when decoding a
+ Quoted-Printable body, any trailing white space on a line must be
+ deleted, as it will necessarily have been added by intermediate
+ transport agents.
+
+ Rule #4 (Line Breaks): A line break in a text body, independent of
+ what its representation is following the canonical representation
+ of the data being encoded, must be represented by a (RFC 822) line
+ break, which is a CRLF sequence, in the Quoted-Printable encoding.
+ Since the canonical representation of types other than text do not
+ generally include the representation of line breaks, no hard line
+ breaks (i.e. line breaks that are intended to be meaningful and
+ to be displayed to the user) should occur in the quoted-printable
+ encoding of such types. Of course, occurrences of "=0D", "=0A",
+ "0A=0D" and "=0D=0A" will eventually be encountered. In general,
+ however, base64 is preferred over quoted-printable for binary
+ data.
+
+ Note that many implementations may elect to encode the local
+ representation of various content types directly, as described in
+ Appendix G. In particular, this may apply to plain text material
+ on systems that use newline conventions other than CRLF
+ delimiters. Such an implementation is permissible, but the
+ generation of line breaks must be generalized to account for the
+ case where alternate representations of newline sequences are
+ used.
+
+ Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES
+ that encoded lines be no more than 76 characters long. If longer
+ lines are to be encoded with the Quoted-Printable encoding, 'soft'
+ line breaks must be used. An equal sign as the last character on a
+ encoded line indicates such a non-significant ('soft') line break
+ in the encoded text. Thus if the "raw" form of the line is a
+ single unencoded line that says:
+
+ Now's the time for all folk to come to the aid of
+ their country.
+
+ This can be represented, in the Quoted-Printable encoding, as
+
+
+
+
+Borenstein & Freed [Page 19]
+
+RFC 1521 MIME September 1993
+
+
+ Now's the time =
+ for all folk to come=
+ to the aid of their country.
+
+ This provides a mechanism with which long lines are encoded in
+ such a way as to be restored by the user agent. The 76 character
+ limit does not count the trailing CRLF, but counts all other
+ characters, including any equal signs.
+
+ Since the hyphen character ("-") is represented as itself in the
+ Quoted-Printable encoding, care must be taken, when encapsulating a
+ quoted-printable encoded body in a multipart entity, to ensure that
+ the encapsulation boundary does not appear anywhere in the encoded
+ body. (A good strategy is to choose a boundary that includes a
+ character sequence such as "=_" which can never appear in a quoted-
+ printable body. See the definition of multipart messages later in
+ this document.)
+
+ NOTE: The quoted-printable encoding represents something of a
+ compromise between readability and reliability in transport.
+ Bodies encoded with the quoted-printable encoding will work
+ reliably over most mail gateways, but may not work perfectly over
+ a few gateways, notably those involving translation into EBCDIC.
+ (In theory, an EBCDIC gateway could decode a quoted-printable body
+ and re-encode it using base64, but such gateways do not yet
+ exist.) A higher level of confidence is offered by the base64
+ Content-Transfer-Encoding. A way to get reasonably reliable
+ transport through EBCDIC gateways is to also quote the ASCII
+ characters
+
+ !"#$@[\]^`{|}~
+
+ according to rule #1. See Appendix B for more information.
+
+ Because quoted-printable data is generally assumed to be line-
+ oriented, it is to be expected that the representation of the breaks
+ between the lines of quoted printable data may be altered in
+ transport, in the same manner that plain text mail has always been
+ altered in Internet mail when passing between systems with differing
+ newline conventions. If such alterations are likely to constitute a
+ corruption of the data, it is probably more sensible to use the
+ base64 encoding rather than the quoted-printable encoding.
+
+ WARNING TO IMPLEMENTORS: If binary data are encoded in quoted-
+ printable, care must be taken to encode CR and LF characters as "=0D"
+ and "=0A", respectively. In particular, a CRLF sequence in binary
+ data should be encoded as "=0D=0A". Otherwise, if CRLF were
+ represented as a hard line break, it might be incorrectly decoded on
+
+
+
+Borenstein & Freed [Page 20]
+
+RFC 1521 MIME September 1993
+
+
+ platforms with different line break conventions.
+
+ For formalists, the syntax of quoted-printable data is described by
+ the following grammar:
+
+ quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
+ ; Maximum line length of 76 characters excluding CRLF
+
+ ptext := octet /<any ASCII character except "=", SPACE, or TAB>
+ ; characters not listed as "mail-safe" in Appendix B
+ ; are also not recommended.
+
+ octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
+ ; octet must be used for characters > 127, =, SPACE, or TAB,
+ ; and is recommended for any characters not listed in
+ ; Appendix B as "mail-safe".
+
+5.2. Base64 Content-Transfer-Encoding
+
+ The Base64 Content-Transfer-Encoding is designed to represent
+ arbitrary sequences of octets in a form that need not be humanly
+ readable. The encoding and decoding algorithms are simple, but the
+ encoded data are consistently only about 33 percent larger than the
+ unencoded data. This encoding is virtually identical to the one used
+ in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
+ The base64 encoding is adapted from RFC 1421, with one change: base64
+ eliminates the "*" mechanism for embedded clear text.
+
+ A 65-character subset of US-ASCII is used, enabling 6 bits to be
+ represented per printable character. (The extra 65th character, "=",
+ is used to signify a special processing function.)
+
+ NOTE: This subset has the important property that it is
+ represented identically in all versions of ISO 646, including US
+ ASCII, and all characters in the subset are also represented
+ identically in all versions of EBCDIC. Other popular encodings,
+ such as the encoding used by the uuencode utility and the base85
+ encoding specified as part of Level 2 PostScript, do not share
+ these properties, and thus do not fulfill the portability
+ requirements a binary transport encoding for mail must meet.
+
+ The encoding process represents 24-bit groups of input bits as output
+ strings of 4 encoded characters. Proceeding from left to right, a
+ 24-bit input group is formed by concatenating 3 8-bit input groups.
+ These 24 bits are then treated as 4 concatenated 6-bit groups, each
+ of which is translated into a single digit in the base64 alphabet.
+ When encoding a bit stream via the base64 encoding, the bit stream
+ must be presumed to be ordered with the most-significant-bit first.
+
+
+
+Borenstein & Freed [Page 21]
+
+RFC 1521 MIME September 1993
+
+
+ That is, the first bit in the stream will be the high-order bit in
+ the first byte, and the eighth bit will be the low-order bit in the
+ first byte, and so on.
+
+ Each 6-bit group is used as an index into an array of 64 printable
+ characters. The character referenced by the index is placed in the
+ output string. These characters, identified in Table 1, below, are
+ selected so as to be universally representable, and the set excludes
+ characters with particular significance to SMTP (e.g., ".", CR, LF)
+ and to the encapsulation boundaries defined in this document (e.g.,
+ "-").
+
+ Table 1: The Base64 Alphabet
+
+ Value Encoding Value Encoding Value Encoding Value Encoding
+ 0 A 17 R 34 i 51 z
+ 1 B 18 S 35 j 52 0
+ 2 C 19 T 36 k 53 1
+ 3 D 20 U 37 l 54 2
+ 4 E 21 V 38 m 55 3
+ 5 F 22 W 39 n 56 4
+ 6 G 23 X 40 o 57 5
+ 7 H 24 Y 41 p 58 6
+ 8 I 25 Z 42 q 59 7
+ 9 J 26 a 43 r 60 8
+ 10 K 27 b 44 s 61 9
+ 11 L 28 c 45 t 62 +
+ 12 M 29 d 46 u 63 /
+ 13 N 30 e 47 v
+ 14 O 31 f 48 w (pad) =
+ 15 P 32 g 49 x
+ 16 Q 33 h 50 y
+
+ The output stream (encoded bytes) must be represented in lines of no
+ more than 76 characters each. All line breaks or other characters
+ not found in Table 1 must be ignored by decoding software. In base64
+ data, characters other than those in Table 1, line breaks, and other
+ white space probably indicate a transmission error, about which a
+ warning message or even a message rejection might be appropriate
+ under some circumstances.
+
+ Special processing is performed if fewer than 24 bits are available
+ at the end of the data being encoded. A full encoding quantum is
+ always completed at the end of a body. When fewer than 24 input bits
+ are available in an input group, zero bits are added (on the right)
+ to form an integral number of 6-bit groups. Padding at the end of
+ the data is performed using the '=' character. Since all base64
+ input is an integral number of octets, only the following cases can
+
+
+
+Borenstein & Freed [Page 22]
+
+RFC 1521 MIME September 1993
+
+
+ arise: (1) the final quantum of encoding input is an integral
+ multiple of 24 bits; here, the final unit of encoded output will be
+ an integral multiple of 4 characters with no "=" padding, (2) the
+ final quantum of encoding input is exactly 8 bits; here, the final
+ unit of encoded output will be two characters followed by two "="
+ padding characters, or (3) the final quantum of encoding input is
+ exactly 16 bits; here, the final unit of encoded output will be three
+ characters followed by one "=" padding character.
+
+ Because it is used only for padding at the end of the data, the
+ occurrence of any '=' characters may be taken as evidence that the
+ end of the data has been reached (without truncation in transit). No
+ such assurance is possible, however, when the number of octets
+ transmitted was a multiple of three.
+
+ Any characters outside of the base64 alphabet are to be ignored in
+ base64-encoded data. The same applies to any illegal sequence of
+ characters in the base64 encoding, such as "====="
+
+ Care must be taken to use the proper octets for line breaks if base64
+ encoding is applied directly to text material that has not been
+ converted to canonical form. In particular, text line breaks must be
+ converted into CRLF sequences prior to base64 encoding. The important
+ thing to note is that this may be done directly by the encoder rather
+ than in a prior canonicalization step in some implementations.
+
+ NOTE: There is no need to worry about quoting apparent
+ encapsulation boundaries within base64-encoded parts of multipart
+ entities because no hyphen characters are used in the base64
+ encoding.
+
+6. Additional Content-Header Fields
+
+6.1. Optional Content-ID Header Field
+
+ In constructing a high-level user agent, it may be desirable to allow
+ one body to make reference to another. Accordingly, bodies may be
+ labeled using the "Content-ID" header field, which is syntactically
+ identical to the "Message-ID" header field:
+
+ id := "Content-ID" ":" msg-id
+ Like the Message-ID values, Content-ID values must be generated to be
+ world-unique.
+
+ The Content-ID value may be used for uniquely identifying MIME
+ entities in several contexts, particularly for cacheing data
+ referenced by the message/external-body mechanism. Although the
+ Content-ID header is generally optional, its use is mandatory in
+
+
+
+Borenstein & Freed [Page 23]
+
+RFC 1521 MIME September 1993
+
+
+ implementations which generate data of the optional MIME Content-type
+ "message/external-body". That is, each message/external-body entity
+ must have a Content-ID field to permit cacheing of such data.
+
+ It is also worth noting that the Content-ID value has special
+ semantics in the case of the multipart/alternative content-type.
+ This is explained in the section of this document dealing with
+ multipart/alternative.
+
+6.2. Optional Content-Description Header Field
+
+ The ability to associate some descriptive information with a given
+ body is often desirable. For example, it may be useful to mark an
+ "image" body as "a picture of the Space Shuttle Endeavor." Such text
+ may be placed in the Content-Description header field.
+
+ description := "Content-Description" ":" *text
+
+ The description is presumed to be given in the US-ASCII character
+ set, although the mechanism specified in [RFC-1522] may be used for
+ non-US-ASCII Content-Description values.
+
+7. The Predefined Content-Type Values
+
+ This document defines seven initial Content-Type values and an
+ extension mechanism for private or experimental types. Further
+ standard types must be defined by new published specifications. It
+ is expected that most innovation in new types of mail will take place
+ as subtypes of the seven types defined here. The most essential
+ characteristics of the seven content-types are summarized in Appendix
+ F.
+
+7.1 The Text Content-Type
+
+ The text Content-Type is intended for sending material which is
+ principally textual in form. It is the default Content-Type. A
+ "charset" parameter may be used to indicate the character set of the
+ body text for some text subtypes, notably including the primary
+ subtype, "text/plain", which indicates plain (unformatted) text. The
+ default Content-Type for Internet mail is "text/plain; charset=us-
+ ascii".
+
+ Beyond plain text, there are many formats for representing what might
+ be known as "extended text" -- text with embedded formatting and
+ presentation information. An interesting characteristic of many such
+ representations is that they are to some extent readable even without
+ the software that interprets them. It is useful, then, to
+ distinguish them, at the highest level, from such unreadable data as
+
+
+
+Borenstein & Freed [Page 24]
+
+RFC 1521 MIME September 1993
+
+
+ images, audio, or text represented in an unreadable form. In the
+ absence of appropriate interpretation software, it is reasonable to
+ show subtypes of text to the user, while it is not reasonable to do
+ so with most nontextual data.
+
+ Such formatted textual data should be represented using subtypes of
+ text. Plausible subtypes of text are typically given by the common
+ name of the representation format, e.g., "text/richtext" [RFC-1341].
+
+7.1.1. The charset parameter
+
+ A critical parameter that may be specified in the Content-Type field
+ for text/plain data is the character set. This is specified with a
+ "charset" parameter, as in:
+
+ Content-type: text/plain; charset=us-ascii
+
+ Unlike some other parameter values, the values of the charset
+ parameter are NOT case sensitive. The default character set, which
+ must be assumed in the absence of a charset parameter, is US-ASCII.
+
+ The specification for any future subtypes of "text" must specify
+ whether or not they will also utilize a "charset" parameter, and may
+ possibly restrict its values as well. When used with a particular
+ body, the semantics of the "charset" parameter should be identical to
+ those specified here for "text/plain", i.e., the body consists
+ entirely of characters in the given charset. In particular, definers
+ of future text subtypes should pay close attention the the
+ implications of multibyte character sets for their subtype
+ definitions.
+
+ This RFC specifies the definition of the charset parameter for the
+ purposes of MIME to be a unique mapping of a byte stream to glyphs, a
+ mapping which does not require external profiling information.
+
+ An initial list of predefined character set names can be found at the
+ end of this section. Additional character sets may be registered
+ with IANA, although the standardization of their use requires the
+ usual IESG [RFC-1340] review and approval. Note that if the
+ specified character set includes 8-bit data, a Content-Transfer-
+ Encoding header field and a corresponding encoding on the data are
+ required in order to transmit the body via some mail transfer
+ protocols, such as SMTP.
+
+ The default character set, US-ASCII, has been the subject of some
+ confusion and ambiguity in the past. Not only were there some
+ ambiguities in the definition, there have been wide variations in
+ practice. In order to eliminate such ambiguity and variations in the
+
+
+
+Borenstein & Freed [Page 25]
+
+RFC 1521 MIME September 1993
+
+
+ future, it is strongly recommended that new user agents explicitly
+ specify a character set via the Content-Type header field. "US-
+ ASCII" does not indicate an arbitrary seven-bit character code, but
+ specifies that the body uses character coding that uses the exact
+ correspondence of codes to characters specified in ASCII. National
+ use variations of ISO 646 [ISO-646] are NOT ASCII and their use in
+ Internet mail is explicitly discouraged. The omission of the ISO 646
+ character set is deliberate in this regard. The character set name
+ of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
+ The character set name "ASCII" is reserved and must not be used for
+ any purpose.
+
+ NOTE: RFC 821 explicitly specifies "ASCII", and references an
+ earlier version of the American Standard. Insofar as one of the
+ purposes of specifying a Content-Type and character set is to
+ permit the receiver to unambiguously determine how the sender
+ intended the coded message to be interpreted, assuming anything
+ other than "strict ASCII" as the default would risk unintentional
+ and incompatible changes to the semantics of messages now being
+ transmitted. This also implies that messages containing
+ characters coded according to national variations on ISO 646, or
+ using code-switching procedures (e.g., those of ISO 2022), as well
+ as 8-bit or multiple octet character encodings MUST use an
+ appropriate character set specification to be consistent with this
+ specification.
+
+ The complete US-ASCII character set is listed in [US-ASCII]. Note
+ that the control characters including DEL (0-31, 127) have no defined
+ meaning apart from the combination CRLF (ASCII values 13 and 10)
+ indicating a new line. Two of the characters have de facto meanings
+ in wide use: FF (12) often means "start subsequent text on the
+ beginning of a new page"; and TAB or HT (9) often (though not always)
+ means "move the cursor to the next available column after the current
+ position where the column number is a multiple of 8 (counting the
+ first column as column 0)." Apart from this, any use of the control
+ characters or DEL in a body must be part of a private agreement
+ between the sender and recipient. Such private agreements are
+ discouraged and should be replaced by the other capabilities of this
+ document.
+
+ NOTE: Beyond US-ASCII, an enormous proliferation of character sets
+ is possible. It is the opinion of the IETF working group that a
+ large number of character sets is NOT a good thing. We would
+ prefer to specify a single character set that can be used
+ universally for representing all of the world's languages in
+ electronic mail. Unfortunately, existing practice in several
+ communities seems to point to the continued use of multiple
+ character sets in the near future. For this reason, we define
+
+
+
+Borenstein & Freed [Page 26]
+
+RFC 1521 MIME September 1993
+
+
+ names for a small number of character sets for which a strong
+ constituent base exists.
+
+ The defined charset values are:
+
+ US-ASCII -- as defined in [US-ASCII].
+
+ ISO-8859-X -- where "X" is to be replaced, as necessary, for the
+ parts of ISO-8859 [ISO-8859]. Note that the ISO 646
+ character sets have deliberately been omitted in favor of
+ their 8859 replacements, which are the designated character
+ sets for Internet mail. As of the publication of this
+ document, the legitimate values for "X" are the digits 1
+ through 9.
+
+ The character sets specified above are the ones that were relatively
+ uncontroversial during the drafting of MIME. This document does not
+ endorse the use of any particular character set other than US-ASCII,
+ and recognizes that the future evolution of world character sets
+ remains unclear. It is expected that in the future, additional
+ character sets will be registered for use in MIME.
+
+ Note that the character set used, if anything other than US-ASCII,
+ must always be explicitly specified in the Content-Type field.
+
+ No other character set name may be used in Internet mail without the
+ publication of a formal specification and its registration with IANA,
+ or by private agreement, in which case the character set name must
+ begin with "X-".
+
+ Implementors are discouraged from defining new character sets for
+ mail use unless absolutely necessary.
+
+ The "charset" parameter has been defined primarily for the purpose of
+ textual data, and is described in this section for that reason.
+ However, it is conceivable that non-textual data might also wish to
+ specify a charset value for some purpose, in which case the same
+ syntax and values should be used.
+
+ In general, mail-sending software must always use the "lowest common
+ denominator" character set possible. For example, if a body contains
+ only US-ASCII characters, it must be marked as being in the US-ASCII
+ character set, not ISO-8859-1, which, like all the ISO-8859 family of
+ character sets, is a superset of US-ASCII. More generally, if a
+ widely-used character set is a subset of another character set, and a
+ body contains only characters in the widely-used subset, it must be
+ labeled as being in that subset. This will increase the chances that
+ the recipient will be able to view the mail correctly.
+
+
+
+Borenstein & Freed [Page 27]
+
+RFC 1521 MIME September 1993
+
+
+7.1.2. The Text/plain subtype
+
+ The primary subtype of text is "plain". This indicates plain
+ (unformatted) text. The default Content-Type for Internet mail,
+ "text/plain; charset=us-ascii", describes existing Internet practice.
+ That is, it is the type of body defined by RFC 822.
+
+ No other text subtype is defined by this document.
+
+ The formal grammar for the content-type header field for text is as
+ follows:
+
+ text-type := "text" "/" text-subtype [";" "charset" "=" charset]
+
+ text-subtype := "plain" / extension-token
+
+ charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3"
+ / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7"
+ / "iso-8859-8" / "iso-8859-9" / extension-token
+ ; case insensitive
+
+7.2. The Multipart Content-Type
+
+ In the case of multiple part entities, in which one or more different
+ sets of data are combined in a single body, a "multipart" Content-
+ Type field must appear in the entity's header. The body must then
+ contain one or more "body parts," each preceded by an encapsulation
+ boundary, and the last one followed by a closing boundary. Each part
+ starts with an encapsulation boundary, and then contains a body part
+ consisting of header area, a blank line, and a body area. Thus a
+ body part is similar to an RFC 822 message in syntax, but different
+ in meaning.
+
+ A body part is NOT to be interpreted as actually being an RFC 822
+ message. To begin with, NO header fields are actually required in
+ body parts. A body part that starts with a blank line, therefore, is
+ allowed and is a body part for which all default values are to be
+ assumed. In such a case, the absence of a Content-Type header field
+ implies that the corresponding body is plain US-ASCII text. The only
+ header fields that have defined meaning for body parts are those the
+ names of which begin with "Content-". All other header fields are
+ generally to be ignored in body parts. Although they should
+ generally be retained in mail processing, they may be discarded by
+ gateways if necessary. Such other fields are permitted to appear in
+ body parts but must not be depended on. "X-" fields may be created
+ for experimental or private purposes, with the recognition that the
+ information they contain may be lost at some gateways.
+
+
+
+
+Borenstein & Freed [Page 28]
+
+RFC 1521 MIME September 1993
+
+
+ NOTE: The distinction between an RFC 822 message and a body part
+ is subtle, but important. A gateway between Internet and X.400
+ mail, for example, must be able to tell the difference between a
+ body part that contains an image and a body part that contains an
+ encapsulated message, the body of which is an image. In order to
+ represent the latter, the body part must have "Content-Type:
+ message", and its body (after the blank line) must be the
+ encapsulated message, with its own "Content-Type: image" header
+ field. The use of similar syntax facilitates the conversion of
+ messages to body parts, and vice versa, but the distinction
+ between the two must be understood by implementors. (For the
+ special case in which all parts actually are messages, a "digest"
+ subtype is also defined.)
+
+ As stated previously, each body part is preceded by an encapsulation
+ boundary. The encapsulation boundary MUST NOT appear inside any of
+ the encapsulated parts. Thus, it is crucial that the composing agent
+ be able to choose and specify the unique boundary that will separate
+ the parts.
+
+ All present and future subtypes of the "multipart" type must use an
+ identical syntax. Subtypes may differ in their semantics, and may
+ impose additional restrictions on syntax, but must conform to the
+ required syntax for the multipart type. This requirement ensures
+ that all conformant user agents will at least be able to recognize
+ and separate the parts of any multipart entity, even of an
+ unrecognized subtype.
+
+ As stated in the definition of the Content-Transfer-Encoding field,
+ no encoding other than "7bit", "8bit", or "binary" is permitted for
+ entities of type "multipart". The multipart delimiters and header
+ fields are always represented as 7-bit ASCII in any case (though the
+ header fields may encode non-ASCII header text as per [RFC-1522]),
+ and data within the body parts can be encoded on a part-by-part
+ basis, with Content-Transfer-Encoding fields for each appropriate
+ body part.
+
+ Mail gateways, relays, and other mail handling agents are commonly
+ known to alter the top-level header of an RFC 822 message. In
+ particular, they frequently add, remove, or reorder header fields.
+ Such alterations are explicitly forbidden for the body part headers
+ embedded in the bodies of messages of type "multipart."
+
+7.2.1. Multipart: The common syntax
+
+ All subtypes of "multipart" share a common syntax, defined in this
+ section. A simple example of a multipart message also appears in
+ this section. An example of a more complex multipart message is
+
+
+
+Borenstein & Freed [Page 29]
+
+RFC 1521 MIME September 1993
+
+
+ given in Appendix C.
+
+ The Content-Type field for multipart entities requires one parameter,
+ "boundary", which is used to specify the encapsulation boundary. The
+ encapsulation boundary is defined as a line consisting entirely of
+ two hyphen characters ("-", decimal code 45) followed by the boundary
+ parameter value from the Content-Type header field.
+
+ NOTE: The hyphens are for rough compatibility with the earlier RFC
+ 934 method of message encapsulation, and for ease of searching for
+ the boundaries in some implementations. However, it should be
+ noted that multipart messages are NOT completely compatible with
+ RFC 934 encapsulations; in particular, they do not obey RFC 934
+ quoting conventions for embedded lines that begin with hyphens.
+ This mechanism was chosen over the RFC 934 mechanism because the
+ latter causes lines to grow with each level of quoting. The
+ combination of this growth with the fact that SMTP implementations
+ sometimes wrap long lines made the RFC 934 mechanism unsuitable
+ for use in the event that deeply-nested multipart structuring is
+ ever desired.
+
+ WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-
+ type field is such that it is often necessary to enclose the
+ boundaries in quotes on the Content-type line. This is not always
+ necessary, but never hurts. Implementors should be sure to study the
+ grammar carefully in order to avoid producing illegal Content-type
+ fields. Thus, a typical multipart Content-Type header field might
+ look like this:
+
+ Content-Type: multipart/mixed;
+ boundary=gc0p4Jq0M2Yt08jU534c0p
+
+ But the following is illegal:
+
+ Content-Type: multipart/mixed;
+ boundary=gc0p4Jq0M:2Yt08jU534c0p
+
+ (because of the colon) and must instead be represented as
+
+ Content-Type: multipart/mixed;
+ boundary="gc0p4Jq0M:2Yt08jU534c0p"
+
+ This indicates that the entity consists of several parts, each itself
+ with a structure that is syntactically identical to an RFC 822
+ message, except that the header area might be completely empty, and
+ that the parts are each preceded by the line
+
+ --gc0p4Jq0M:2Yt08jU534c0p
+
+
+
+Borenstein & Freed [Page 30]
+
+RFC 1521 MIME September 1993
+
+
+ Note that the encapsulation boundary must occur at the beginning of a
+ line, i.e., following a CRLF, and that the initial CRLF is considered
+ to be attached to the encapsulation boundary rather than part of the
+ preceding part. The boundary must be followed immediately either by
+ another CRLF and the header fields for the next part, or by two
+ CRLFs, in which case there are no header fields for the next part
+ (and it is therefore assumed to be of Content-Type text/plain).
+
+ NOTE: The CRLF preceding the encapsulation line is conceptually
+ attached to the boundary so that it is possible to have a part
+ that does not end with a CRLF (line break). Body parts that must
+ be considered to end with line breaks, therefore, must have two
+ CRLFs preceding the encapsulation line, the first of which is part
+ of the preceding body part, and the second of which is part of the
+ encapsulation boundary.
+
+ Encapsulation boundaries must not appear within the encapsulations,
+ and must be no longer than 70 characters, not counting the two
+ leading hyphens.
+
+ The encapsulation boundary following the last body part is a
+ distinguished delimiter that indicates that no further body parts
+ will follow. Such a delimiter is identical to the previous
+ delimiters, with the addition of two more hyphens at the end of the
+ line:
+
+ --gc0p4Jq0M2Yt08jU534c0p--
+
+ There appears to be room for additional information prior to the
+ first encapsulation boundary and following the final boundary. These
+ areas should generally be left blank, and implementations must ignore
+ anything that appears before the first boundary or after the last
+ one.
+
+ NOTE: These "preamble" and "epilogue" areas are generally not used
+ because of the lack of proper typing of these parts and the lack
+ of clear semantics for handling these areas at gateways,
+ particularly X.400 gateways. However, rather than leaving the
+ preamble area blank, many MIME implementations have found this to
+ be a convenient place to insert an explanatory note for recipients
+ who read the message with pre-MIME software, since such notes will
+ be ignored by MIME-compliant software.
+
+ NOTE: Because encapsulation boundaries must not appear in the body
+ parts being encapsulated, a user agent must exercise care to
+ choose a unique boundary. The boundary in the example above could
+ have been the result of an algorithm designed to produce
+ boundaries with a very low probability of already existing in the
+
+
+
+Borenstein & Freed [Page 31]
+
+RFC 1521 MIME September 1993
+
+
+ data to be encapsulated without having to prescan the data.
+ Alternate algorithms might result in more 'readable' boundaries
+ for a recipient with an old user agent, but would require more
+ attention to the possibility that the boundary might appear in the
+ encapsulated part. The simplest boundary possible is something
+ like "---", with a closing boundary of "-----".
+
+ As a very simple example, the following multipart message has two
+ parts, both of them plain text, one of them explicitly typed and one
+ of them implicitly typed:
+
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Subject: Sample message
+ MIME-Version: 1.0
+ Content-type: multipart/mixed; boundary="simple
+ boundary"
+
+ This is the preamble. It is to be ignored, though it
+ is a handy place for mail composers to include an
+ explanatory note to non-MIME conformant readers.
+ --simple boundary
+
+ This is implicitly typed plain ASCII text.
+ It does NOT end with a linebreak.
+ --simple boundary
+ Content-type: text/plain; charset=us-ascii
+
+ This is explicitly typed plain ASCII text.
+ It DOES end with a linebreak.
+
+ --simple boundary--
+ This is the epilogue. It is also to be ignored.
+
+ The use of a Content-Type of multipart in a body part within another
+ multipart entity is explicitly allowed. In such cases, for obvious
+ reasons, care must be taken to ensure that each nested multipart
+ entity must use a different boundary delimiter. See Appendix C for an
+ example of nested multipart entities.
+
+ The use of the multipart Content-Type with only a single body part
+ may be useful in certain contexts, and is explicitly permitted.
+
+ The only mandatory parameter for the multipart Content-Type is the
+ boundary parameter, which consists of 1 to 70 characters from a set
+ of characters known to be very robust through email gateways, and NOT
+ ending with white space. (If a boundary appears to end with white
+ space, the white space must be presumed to have been added by a
+
+
+
+Borenstein & Freed [Page 32]
+
+RFC 1521 MIME September 1993
+
+
+ gateway, and must be deleted.) It is formally specified by the
+ following BNF:
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_"
+ / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+ Overall, the body of a multipart entity may be specified as
+ follows:
+
+ multipart-body := preamble 1*encapsulation
+ close-delimiter epilogue
+
+ encapsulation := delimiter body-part CRLF
+
+ delimiter := "--" boundary CRLF ; taken from Content-Type field.
+ ; There must be no space
+ ; between "--" and boundary.
+
+ close-delimiter := "--" boundary "--" CRLF ; Again, no space
+ by "--",
+
+ preamble := discard-text ; to be ignored upon receipt.
+
+ epilogue := discard-text ; to be ignored upon receipt.
+
+ discard-text := *(*text CRLF)
+
+ body-part := <"message" as defined in RFC 822,
+ with all header fields optional, and with the
+ specified delimiter not occurring anywhere in
+ the message body, either on a line by itself
+ or as a substring anywhere. Note that the
+ semantics of a part differ from the semantics
+ of a message, as described in the text.>
+
+ NOTE: In certain transport enclaves, RFC 822 restrictions such as
+ the one that limits bodies to printable ASCII characters may not
+ be in force. (That is, the transport domains may resemble
+ standard Internet mail transport as specified in RFC821 and
+ assumed by RFC822, but without certain restrictions.) The
+ relaxation of these restrictions should be construed as locally
+ extending the definition of bodies, for example to include octets
+ outside of the ASCII range, as long as these extensions are
+ supported by the transport and adequately documented in the
+
+
+
+Borenstein & Freed [Page 33]
+
+RFC 1521 MIME September 1993
+
+
+ Content-Transfer-Encoding header field. However, in no event are
+ headers (either message headers or body-part headers) allowed to
+ contain anything other than ASCII characters.
+
+ NOTE: Conspicuously missing from the multipart type is a notion of
+ structured, related body parts. In general, it seems premature to
+ try to standardize interpart structure yet. It is recommended
+ that those wishing to provide a more structured or integrated
+ multipart messaging facility should define a subtype of multipart
+ that is syntactically identical, but that always expects the
+ inclusion of a distinguished part that can be used to specify the
+ structure and integration of the other parts, probably referring
+ to them by their Content-ID field. If this approach is used,
+ other implementations will not recognize the new subtype, but will
+ treat it as the primary subtype (multipart/mixed) and will thus be
+ able to show the user the parts that are recognized.
+
+7.2.2. The Multipart/mixed (primary) subtype
+
+ The primary subtype for multipart, "mixed", is intended for use when
+ the body parts are independent and need to be bundled in a particular
+ order. Any multipart subtypes that an implementation does not
+ recognize must be treated as being of subtype "mixed".
+
+7.2.3. The Multipart/alternative subtype
+
+ The multipart/alternative type is syntactically identical to
+ multipart/mixed, but the semantics are different. In particular,
+ each of the parts is an "alternative" version of the same
+ information.
+
+ Systems should recognize that the content of the various parts are
+ interchangeable. Systems should choose the "best" type based on the
+ local environment and preferences, in some cases even through user
+ interaction. As with multipart/mixed, the order of body parts is
+ significant. In this case, the alternatives appear in an order of
+ increasing faithfulness to the original content. In general, the best
+ choice is the LAST part of a type supported by the recipient system's
+ local environment.
+
+ Multipart/alternative may be used, for example, to send mail in a
+ fancy text format in such a way that it can easily be displayed
+ anywhere:
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 34]
+
+RFC 1521 MIME September 1993
+
+
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Subject: Formatted text mail
+ MIME-Version: 1.0
+ Content-Type: multipart/alternative; boundary=boundary42
+
+ --boundary42
+
+ Content-Type: text/plain; charset=us-ascii
+
+ ...plain text version of message goes here....
+ --boundary42
+ Content-Type: text/richtext
+
+ .... RFC 1341 richtext version of same message goes here ...
+ --boundary42
+ Content-Type: text/x-whatever
+
+ .... fanciest formatted version of same message goes here
+ ...
+ --boundary42--
+
+ In this example, users whose mail system understood the "text/x-
+ whatever" format would see only the fancy version, while other users
+ would see only the richtext or plain text version, depending on the
+ capabilities of their system.
+
+ In general, user agents that compose multipart/alternative entities
+ must place the body parts in increasing order of preference, that is,
+ with the preferred format last. For fancy text, the sending user
+ agent should put the plainest format first and the richest format
+ last. Receiving user agents should pick and display the last format
+ they are capable of displaying. In the case where one of the
+ alternatives is itself of type "multipart" and contains unrecognized
+ sub-parts, the user agent may choose either to show that alternative,
+ an earlier alternative, or both.
+
+ NOTE: From an implementor's perspective, it might seem more
+ sensible to reverse this ordering, and have the plainest
+ alternative last. However, placing the plainest alternative first
+ is the friendliest possible option when multipart/alternative
+ entities are viewed using a non-MIME-conformant mail reader.
+ While this approach does impose some burden on conformant mail
+ readers, interoperability with older mail readers was deemed to be
+ more important in this case.
+
+ It may be the case that some user agents, if they can recognize more
+ than one of the formats, will prefer to offer the user the choice of
+
+
+
+Borenstein & Freed [Page 35]
+
+RFC 1521 MIME September 1993
+
+
+ which format to view. This makes sense, for example, if mail
+ includes both a nicely-formatted image version and an easily-edited
+ text version. What is most critical, however, is that the user not
+ automatically be shown multiple versions of the same data. Either
+ the user should be shown the last recognized version or should be
+ given the choice.
+
+ NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each
+ part of a multipart/alternative entity represents the same data, but
+ the mappings between the two are not necessarily without information
+ loss. For example, information is lost when translating ODA to
+ PostScript or plain text. It is recommended that each part should
+ have a different Content-ID value in the case where the information
+ content of the two parts is not identical. However, where the
+ information content is identical -- for example, where several parts
+ of type "application/external- body" specify alternate ways to access
+ the identical data -- the same Content-ID field value should be used,
+ to optimize any cacheing mechanisms that might be present on the
+ recipient's end. However, it is recommended that the Content-ID
+ values used by the parts should not be the same Content-ID value that
+ describes the multipart/alternative as a whole, if there is any such
+ Content-ID field. That is, one Content-ID value will refer to the
+ multipart/alternative entity, while one or more other Content-ID
+ values will refer to the parts inside it.
+
+7.2.4. The Multipart/digest subtype
+
+ This document defines a "digest" subtype of the multipart Content-
+ Type. This type is syntactically identical to multipart/mixed, but
+ the semantics are different. In particular, in a digest, the default
+ Content-Type value for a body part is changed from "text/plain" to
+ "message/rfc822". This is done to allow a more readable digest
+ format that is largely compatible (except for the quoting convention)
+ with RFC 934.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 36]
+
+RFC 1521 MIME September 1993
+
+
+ A digest in this format might, then, look something like this:
+
+ From: Moderator-Address
+ To: Recipient-List
+ MIME-Version: 1.0
+ Subject: Internet Digest, volume 42
+ Content-Type: multipart/digest;
+ boundary="---- next message ----"
+
+ ------ next message ----
+
+ From: someone-else
+ Subject: my opinion
+
+ ...body goes here ...
+
+ ------ next message ----
+
+ From: someone-else-again
+ Subject: my different opinion
+
+ ... another body goes here...
+
+ ------ next message ------
+
+7.2.5. The Multipart/parallel subtype
+
+ This document defines a "parallel" subtype of the multipart Content-
+ Type. This type is syntactically identical to multipart/mixed, but
+ the semantics are different. In particular, in a parallel entity,
+ the order of body parts is not significant.
+
+ A common presentation of this type is to display all of the parts
+ simultaneously on hardware and software that are capable of doing so.
+ However, composing agents should be aware that many mail readers will
+ lack this capability and will show the parts serially in any event.
+
+7.2.6. Other Multipart subtypes
+
+ Other multipart subtypes are expected in the future. MIME
+ implementations must in general treat unrecognized subtypes of
+ multipart as being equivalent to "multipart/mixed".
+
+ The formal grammar for content-type header fields for multipart data
+ is given by:
+
+ multipart-type := "multipart" "/" multipart-subtype
+ ";" "boundary" "=" boundary
+
+
+
+Borenstein & Freed [Page 37]
+
+RFC 1521 MIME September 1993
+
+
+ multipart-subtype := "mixed" / "parallel" / "digest"
+ / "alternative" / extension-token
+
+7.3. The Message Content-Type
+
+ It is frequently desirable, in sending mail, to encapsulate another
+ mail message. For this common operation, a special Content-Type,
+ "message", is defined. The primary subtype, message/rfc822, has no
+ required parameters in the Content-Type field. Additional subtypes,
+ "partial" and "External-body", do have required parameters. These
+ subtypes are explained below.
+
+ NOTE: It has been suggested that subtypes of message might be
+ defined for forwarded or rejected messages. However, forwarded
+ and rejected messages can be handled as multipart messages in
+ which the first part contains any control or descriptive
+ information, and a second part, of type message/rfc822, is the
+ forwarded or rejected message. Composing rejection and forwarding
+ messages in this manner will preserve the type information on the
+ original message and allow it to be correctly presented to the
+ recipient, and hence is strongly encouraged.
+
+ As stated in the definition of the Content-Transfer-Encoding field,
+ no encoding other than "7bit", "8bit", or "binary" is permitted for
+ messages or parts of type "message". Even stronger restrictions
+ apply to the subtypes "message/partial" and "message/external-body",
+ as specified below. The message header fields are always US-ASCII in
+ any case, and data within the body can still be encoded, in which
+ case the Content-Transfer-Encoding header field in the encapsulated
+ message will reflect this. Non-ASCII text in the headers of an
+ encapsulated message can be specified using the mechanisms described
+ in [RFC-1522].
+
+ Mail gateways, relays, and other mail handling agents are commonly
+ known to alter the top-level header of an RFC 822 message. In
+ particular, they frequently add, remove, or reorder header fields.
+ Such alterations are explicitly forbidden for the encapsulated
+ headers embedded in the bodies of messages of type "message."
+
+7.3.1. The Message/rfc822 (primary) subtype
+
+ A Content-Type of "message/rfc822" indicates that the body contains
+ an encapsulated message, with the syntax of an RFC 822 message.
+ However, unlike top-level RFC 822 messages, it is not required that
+ each message/rfc822 body must include a "From", "Subject", and at
+ least one destination header.
+
+ It should be noted that, despite the use of the numbers "822", a
+
+
+
+Borenstein & Freed [Page 38]
+
+RFC 1521 MIME September 1993
+
+
+ message/rfc822 entity can include enhanced information as defined in
+ this document. In other words, a message/rfc822 message may be a
+ MIME message.
+
+7.3.2. The Message/Partial subtype
+
+ A subtype of message, "partial", is defined in order to allow large
+ objects to be delivered as several separate pieces of mail and
+ automatically reassembled by the receiving user agent. (The concept
+ is similar to IP fragmentation/reassembly in the basic Internet
+ Protocols.) This mechanism can be used when intermediate transport
+ agents limit the size of individual messages that can be sent.
+ Content-Type "message/partial" thus indicates that the body contains
+ a fragment of a larger message.
+
+ Three parameters must be specified in the Content-Type field of type
+ message/partial: The first, "id", is a unique identifier, as close to
+ a world-unique identifier as possible, to be used to match the parts
+ together. (In general, the identifier is essentially a message-id;
+ if placed in double quotes, it can be any message-id, in accordance
+ with the BNF for "parameter" given earlier in this specification.)
+ The second, "number", an integer, is the part number, which indicates
+ where this part fits into the sequence of fragments. The third,
+ "total", another integer, is the total number of parts. This third
+ subfield is required on the final part, and is optional (though
+ encouraged) on the earlier parts. Note also that these parameters
+ may be given in any order.
+
+ Thus, part 2 of a 3-part message may have either of the following
+ header fields:
+
+ Content-Type: Message/Partial;
+ number=2; total=3;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
+
+ Content-Type: Message/Partial;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
+ number=2
+
+ But part 3 MUST specify the total number of parts:
+
+ Content-Type: Message/Partial;
+ number=3; total=3;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
+
+ Note that part numbering begins with 1, not 0.
+
+ When the parts of a message broken up in this manner are put
+
+
+
+Borenstein & Freed [Page 39]
+
+RFC 1521 MIME September 1993
+
+
+ together, the result is a complete MIME entity, which may have its
+ own Content-Type header field, and thus may contain any other data
+ type.
+
+ Message fragmentation and reassembly: The semantics of a reassembled
+ partial message must be those of the "inner" message, rather than of
+ a message containing the inner message. This makes it possible, for
+ example, to send a large audio message as several partial messages,
+ and still have it appear to the recipient as a simple audio message
+ rather than as an encapsulated message containing an audio message.
+ That is, the encapsulation of the message is considered to be
+ "transparent".
+
+ When generating and reassembling the parts of a message/partial
+ message, the headers of the encapsulated message must be merged with
+ the headers of the enclosing entities. In this process the following
+ rules must be observed:
+
+ (1) All of the header fields from the initial enclosing entity
+ (part one), except those that start with "Content-" and the
+ specific header fields "Message-ID", "Encrypted", and "MIME-
+ Version", must be copied, in order, to the new message.
+
+ (2) Only those header fields in the enclosed message which start
+ with "Content-" and "Message-ID", "Encrypted", and "MIME-Version"
+ must be appended, in order, to the header fields of the new
+ message. Any header fields in the enclosed message which do not
+ start with "Content-" (except for "Message-ID", "Encrypted", and
+ "MIME-Version") will be ignored.
+
+ (3) All of the header fields from the second and any subsequent
+ messages will be ignored.
+
+ For example, if an audio message is broken into two parts, the first
+ part might look something like this:
+
+ X-Weird-Header-1: Foo
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Subject: Audio mail
+ Message-ID: <id1@host.com>
+ MIME-Version: 1.0
+ Content-type: message/partial;
+ id="ABC@host.com";
+ number=1; total=2
+
+ X-Weird-Header-1: Bar
+ X-Weird-Header-2: Hello
+
+
+
+Borenstein & Freed [Page 40]
+
+RFC 1521 MIME September 1993
+
+
+ Message-ID: <anotherid@foo.com>
+ MIME-Version: 1.0
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here...
+
+ and the second half might look something like this:
+
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Subject: Audio mail
+ MIME-Version: 1.0
+ Message-ID: <id2@host.com>
+ Content-type: message/partial;
+ id="ABC@host.com"; number=2; total=2
+
+ ... second half of encoded audio data goes here...
+
+ Then, when the fragmented message is reassembled, the resulting
+ message to be displayed to the user should look something like this:
+
+ X-Weird-Header-1: Foo
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Subject: Audio mail
+ Message-ID: <anotherid@foo.com>
+ MIME-Version: 1.0
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here...
+ ... second half of encoded audio data goes here...
+
+ Note on encoding of MIME entities encapsulated inside message/partial
+ entities: Because data of type "message" may never be encoded in
+ base64 or quoted-printable, a problem might arise if message/partial
+ entities are constructed in an environment that supports binary or
+ 8-bit transport. The problem is that the binary data would be split
+ into multiple message/partial objects, each of them requiring binary
+ transport. If such objects were encountered at a gateway into a 7-
+ bit transport environment, there would be no way to properly encode
+ them for the 7-bit world, aside from waiting for all of the parts,
+ reassembling the message, and then encoding the reassembled data in
+ base64 or quoted-printable. Since it is possible that different
+ parts might go through different gateways, even this is not an
+ acceptable solution. For this reason, it is specified that MIME
+ entities of type message/partial must always have a content-
+
+
+
+Borenstein & Freed [Page 41]
+
+RFC 1521 MIME September 1993
+
+
+ transfer-encoding of 7-bit (the default). In particular, even in
+ environments that support binary or 8-bit transport, the use of a
+ content-transfer-encoding of "8bit" or "binary" is explicitly
+ prohibited for entities of type message/partial.
+
+ It should be noted that, because some message transfer agents may
+ choose to automatically fragment large messages, and because such
+ agents may use different fragmentation thresholds, it is possible
+ that the pieces of a partial message, upon reassembly, may prove
+ themselves to comprise a partial message. This is explicitly
+ permitted.
+
+ It should also be noted that the inclusion of a "References" field in
+ the headers of the second and subsequent pieces of a fragmented
+ message that references the Message-Id on the previous piece may be
+ of benefit to mail readers that understand and track references.
+ However, the generation of such "References" fields is entirely
+ optional.
+
+ Finally, it should be noted that the "Encrypted" header field has
+ been made obsolete by Privacy Enhanced Messaging (PEM), but the rules
+ above are believed to describe the correct way to treat it if it is
+ encountered in the context of conversion to and from message/partial
+ fragments.
+
+7.3.3. The Message/External-Body subtype
+
+ The external-body subtype indicates that the actual body data are not
+ included, but merely referenced. In this case, the parameters
+ describe a mechanism for accessing the external data.
+
+ When an entity is of type "message/external-body", it consists of a
+ header, two consecutive CRLFs, and the message header for the
+ encapsulated message. If another pair of consecutive CRLFs appears,
+ this of course ends the message header for the encapsulated message.
+ However, since the encapsulated message's body is itself external, it
+ does NOT appear in the area that follows. For example, consider the
+ following message:
+
+ Content-type: message/external-body; access-
+ type=local-file;
+
+ name="/u/nsb/Me.gif"
+
+ Content-type: image/gif
+ Content-ID: <id42@guppylake.bellcore.com>
+ Content-Transfer-Encoding: binary
+
+
+
+
+Borenstein & Freed [Page 42]
+
+RFC 1521 MIME September 1993
+
+
+ THIS IS NOT REALLY THE BODY!
+
+ The area at the end, which might be called the "phantom body", is
+ ignored for most external-body messages. However, it may be used to
+ contain auxiliary information for some such messages, as indeed it is
+ when the access-type is "mail-server". Of the access-types defined
+ by this document, the phantom body is used only when the access-type
+ is "mail-server". In all other cases, the phantom body is ignored.
+
+ The only always-mandatory parameter for message/external-body is
+ "access-type"; all of the other parameters may be mandatory or
+ optional depending on the value of access-type.
+
+ ACCESS-TYPE -- A case-insensitive word, indicating the supported
+ access mechanism by which the file or data may be obtained.
+ Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP",
+ "AFS", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for
+ experimental values beginning with "X-" must be registered with
+ IANA, as described in Appendix E .
+
+ In addition, the following three parameters are optional for ALL
+ access-types:
+
+ EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as
+ extended by RFC 1123 to permit 4 digits in the year field) after
+ which the existence of the external data is not guaranteed.
+
+ SIZE -- The size (in octets) of the data. The intent of this
+ parameter is to help the recipient decide whether or not to expend
+ the necessary resources to retrieve the external data. Note that
+ this describes the size of the data in its canonical form, that
+ is, before any Content- Transfer-Encoding has been applied or
+ after the data have been decoded.
+
+ PERMISSION -- A case-insensitive field that indicates whether or
+ not it is expected that clients might also attempt to overwrite
+ the data. By default, or if permission is "read", the assumption
+ is that they are not, and that if the data is retrieved once, it
+ is never needed again. If PERMISSION is "read-write", this
+ assumption is invalid, and any local copy must be considered no
+ more than a cache. "Read" and "Read-write" are the only defined
+ values of permission.
+
+ The precise semantics of the access-types defined here are described
+ in the sections that follow.
+
+ The encapsulated headers in ALL message/external-body entities MUST
+ include a Content-ID header field to give a unique identifier by
+
+
+
+Borenstein & Freed [Page 43]
+
+RFC 1521 MIME September 1993
+
+
+ which to reference the data. This identifier may be used for
+ cacheing mechanisms, and for recognizing the receipt of the data when
+ the access-type is "mail-server".
+
+ Note that, as specified here, the tokens that describe external-body
+ data, such as file names and mail server commands, are required to be
+ in the US-ASCII character set. If this proves problematic in
+ practice, a new mechanism may be required as a future extension to
+ MIME, either as newly defined access-types for message/external-body
+ or by some other mechanism.
+
+ As with message/partial, it is specified that MIME entities of type
+ message/external-body must always have a content-transfer-encoding of
+ 7-bit (the default). In particular, even in environments that
+ support binary or 8-bit transport, the use of a content-transfer-
+ encoding of "8bit" or "binary" is explicitly prohibited for entities
+ of type message/external-body.
+
+7.3.3.1. The "ftp" and "tftp" access-types
+
+ An access-type of FTP or TFTP indicates that the message body is
+ accessible as a file using the FTP [RFC-959] or TFTP [RFC-783]
+ protocols, respectively. For these access-types, the following
+ additional parameters are mandatory:
+
+ NAME -- The name of the file that contains the actual body data.
+
+ SITE -- A machine from which the file may be obtained, using the
+ given protocol. This must be a fully qualified domain name, not a
+ nickname.
+
+ Before any data are retrieved, using FTP, the user will generally
+ need to be asked to provide a login id and a password for the machine
+ named by the site parameter. For security reasons, such an id and
+ password are not specified as content-type parameters, but must be
+ obtained from the user.
+
+ In addition, the following parameters are optional:
+
+ DIRECTORY -- A directory from which the data named by NAME should
+ be retrieved.
+
+ MODE -- A case-insensitive string indicating the mode to be used
+ when retrieving the information. The legal values for access-type
+ "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the
+ TFTP protocol [RFC-783]. The legal values for access-type "FTP"
+ are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
+ decimal integer, typically 8. These correspond to the
+
+
+
+Borenstein & Freed [Page 44]
+
+RFC 1521 MIME September 1993
+
+
+ representation types "A" "E" "I" and "L n" as specified by the FTP
+ protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid
+ values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be
+ used instead. IF MODE is not specified, the default value is
+ "NETASCII" for TFTP and "ASCII" otherwise.
+
+7.3.3.2. The "anon-ftp" access-type
+
+ The "anon-ftp" access-type is identical to the "ftp" access type,
+ except that the user need not be asked to provide a name and password
+ for the specified site. Instead, the ftp protocol will be used with
+ login "anonymous" and a password that corresponds to the user's email
+ address.
+
+7.3.3.3. The "local-file" and "afs" access-types
+
+ An access-type of "local-file" indicates that the actual body is
+ accessible as a file on the local machine. An access-type of "afs"
+ indicates that the file is accessible via the global AFS file system.
+ In both cases, only a single parameter is required:
+
+ NAME -- The name of the file that contains the actual body data.
+
+ The following optional parameter may be used to describe the locality
+ of reference for the data, that is, the site or sites at which the
+ file is expected to be visible:
+
+ SITE -- A domain specifier for a machine or set of machines that
+ are known to have access to the data file. Asterisks may be used
+ for wildcard matching to a part of a domain name, such as
+ "*.bellcore.com", to indicate a set of machines on which the data
+ should be directly visible, while a single asterisk may be used to
+ indicate a file that is expected to be universally available,
+ e.g., via a global file system.
+
+7.3.3.4. The "mail-server" access-type
+
+ The "mail-server" access-type indicates that the actual body is
+ available from a mail server. The mandatory parameter for this
+ access-type is:
+
+ SERVER -- The email address of the mail server from which the
+ actual body data can be obtained.
+
+ Because mail servers accept a variety of syntaxes, some of which is
+ multiline, the full command to be sent to a mail server is not
+ included as a parameter on the content-type line. Instead, it is
+ provided as the "phantom body" when the content-type is
+
+
+
+Borenstein & Freed [Page 45]
+
+RFC 1521 MIME September 1993
+
+
+ message/external-body and the access- type is mail-server.
+
+ An optional parameter for this access-type is:
+
+ SUBJECT -- The subject that is to be used in the mail that is sent
+ to obtain the data. Note that keying mail servers on Subject lines
+ is NOT recommended, but such mail servers are known to exist.
+
+ Note that MIME does not define a mail server syntax. Rather, it
+ allows the inclusion of arbitrary mail server commands in the phantom
+ body. Implementations must include the phantom body in the body of
+ the message it sends to the mail server address to retrieve the
+ relevant data.
+
+ It is worth noting that, unlike other access-types, mail-server
+ access is asynchronous and will happen at an unpredictable time in
+ the future. For this reason, it is important that there be a
+ mechanism by which the returned data can be matched up with the
+ original message/external-body entity. MIME mailservers must use the
+ same Content-ID field on the returned message that was used in the
+ original message/external-body entity, to facilitate such matching.
+
+7.3.3.5. Examples and Further Explanations
+
+ With the emerging possibility of very wide-area file systems, it
+ becomes very hard to know in advance the set of machines where a file
+ will and will not be accessible directly from the file system.
+ Therefore it may make sense to provide both a file name, to be tried
+ directly, and the name of one or more sites from which the file is
+ known to be accessible. An implementation can try to retrieve remote
+ files using FTP or any other protocol, using anonymous file retrieval
+ or prompting the user for the necessary name and password. If an
+ external body is accessible via multiple mechanisms, the sender may
+ include multiple parts of type message/external-body within an entity
+ of type multipart/alternative.
+
+ However, the external-body mechanism is not intended to be limited to
+ file retrieval, as shown by the mail-server access-type. Beyond
+ this, one can imagine, for example, using a video server for external
+ references to video clips.
+
+ If an entity is of type "message/external-body", then the body of the
+ entity will contain the header fields of the encapsulated message.
+ The body itself is to be found in the external location. This means
+ that if the body of the "message/external-body" message contains two
+ consecutive CRLFs, everything after those pairs is NOT part of the
+ message itself. For most message/external-body messages, this
+ trailing area must simply be ignored. However, it is a convenient
+
+
+
+Borenstein & Freed [Page 46]
+
+RFC 1521 MIME September 1993
+
+
+ place for additional data that cannot be included in the content-type
+ header field. In particular, if the "access-type" value is "mail-
+ server", then the trailing area must contain commands to be sent to
+ the mail server at the address given by the value of the SERVER
+ parameter.
+
+ The embedded message header fields which appear in the body of the
+ message/external-body data must be used to declare the Content-type
+ of the external body if it is anything other than plain ASCII text,
+ since the external body does not have a header section to declare its
+ type. Similarly, any Content-transfer-encoding other than "7bit"
+ must also be declared here. Thus a complete message/external-body
+ message, referring to a document in PostScript format, might look
+ like this:
+
+ From: Whomever
+ To: Someone
+ Subject: whatever
+ MIME-Version: 1.0
+ Message-ID: <id1@host.com>
+ Content-Type: multipart/alternative; boundary=42
+ Content-ID: <id001@guppylake.bellcore.com>
+
+ --42
+ Content-Type: message/external-body;
+ name="BodyFormats.ps";
+ site="thumper.bellcore.com";
+ access-type=ANON-FTP;
+ directory="pub";
+ mode="image";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+ Content-ID: <id42@guppylake.bellcore.com>
+
+ --42
+ Content-Type: message/external-body;
+ name="/u/nsb/writing/rfcs/RFC-MIME.ps";
+ site="thumper.bellcore.com";
+ access-type=AFS
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+ Content-ID: <id42@guppylake.bellcore.com>
+
+ --42
+ Content-Type: message/external-body;
+ access-type=mail-server
+
+
+
+Borenstein & Freed [Page 47]
+
+RFC 1521 MIME September 1993
+
+
+ server="listserv@bogus.bitnet";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+ Content-ID: <id42@guppylake.bellcore.com>
+
+ get RFC-MIME.DOC
+
+ --42--
+
+ Note that in the above examples, the default Content-transfer-
+ encoding of "7bit" is assumed for the external postscript data.
+
+ Like the message/partial type, the message/external-body type is
+ intended to be transparent, that is, to convey the data type in the
+ external body rather than to convey a message with a body of that
+ type. Thus the headers on the outer and inner parts must be merged
+ using the same rules as for message/partial. In particular, this
+ means that the Content-type header is overridden, but the From and
+ Subject headers are preserved.
+
+ Note that since the external bodies are not transported as mail, they
+ need not conform to the 7-bit and line length requirements, but might
+ in fact be binary files. Thus a Content-Transfer-Encoding is not
+ generally necessary, though it is permitted.
+
+ Note that the body of a message of type "message/external-body" is
+ governed by the basic syntax for an RFC 822 message. In particular,
+ anything before the first consecutive pair of CRLFs is header
+ information, while anything after it is body information, which is
+ ignored for most access-types.
+
+ The formal grammar for content-type header fields for data of type
+ message is given by:
+
+ message-type := "message" "/" message-subtype
+
+ message-subtype := "rfc822"
+ / "partial" 2#3partial-param
+ / "external-body" 1*external-param
+ / extension-token
+
+ partial-param := (";" "id" "=" value)
+ / (";" "number" "=" 1*DIGIT)
+ / (";" "total" "=" 1*DIGIT)
+ ; id & number required; total required for last part
+
+ external-param := (";" "access-type" "=" atype)
+
+
+
+Borenstein & Freed [Page 48]
+
+RFC 1521 MIME September 1993
+
+
+ / (";" "expiration" "=" date-time)
+ ; Note that date-time is quoted
+ / (";" "size" "=" 1*DIGIT)
+ / (";" "permission" "=" ("read" / "read-write"))
+ ; Permission is case-insensitive
+ / (";" "name" "=" value)
+ / (";" "site" "=" value)
+ / (";" "dir" "=" value)
+ / (";" "mode" "=" value)
+ / (";" "server" "=" value)
+ / (";" "subject" "=" value)
+ ; access-type required;others required based on access-type
+
+ atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
+ / "afs" / "mail-server" / extension-token
+ ; Case-insensitive
+
+7.4. The Application Content-Type
+
+ The "application" Content-Type is to be used for data which do not
+ fit in any of the other categories, and particularly for data to be
+ processed by mail-based uses of application programs. This is
+ information which must be processed by an application before it is
+ viewable or usable to a user. Expected uses for Content-Type
+ application include mail-based file transfer, spreadsheets, data for
+ mail-based scheduling systems, and languages for "active"
+ (computational) email. (The latter, in particular, can pose security
+ problems which must be understood by implementors, and are considered
+ in detail in the discussion of the application/PostScript content-
+ type.)
+
+ For example, a meeting scheduler might define a standard
+ representation for information about proposed meeting dates. An
+ intelligent user agent would use this information to conduct a dialog
+ with the user, and might then send further mail based on that dialog.
+ More generally, there have been several "active" messaging languages
+ developed in which programs in a suitably specialized language are
+ sent through the mail and automatically run in the recipient's
+ environment.
+
+ Such applications may be defined as subtypes of the "application"
+ Content-Type. This document defines two subtypes: octet-stream, and
+ PostScript.
+
+ In general, the subtype of application will often be the name of the
+ application for which the data are intended. This does not mean,
+ however, that any application program name may be used freely as a
+ subtype of application. Such usages (other than subtypes beginning
+
+
+
+Borenstein & Freed [Page 49]
+
+RFC 1521 MIME September 1993
+
+
+ with "x-") must be registered with IANA, as described in Appendix E.
+
+7.4.1. The Application/Octet-Stream (primary) subtype
+
+ The primary subtype of application, "octet-stream", may be used to
+ indicate that a body contains binary data. The set of possible
+ parameters includes, but is not limited to:
+
+ TYPE -- the general type or category of binary data. This is
+ intended as information for the human recipient rather than for
+ any automatic processing.
+
+ PADDING -- the number of bits of padding that were appended to the
+ bit-stream comprising the actual contents to produce the enclosed
+ byte-oriented data. This is useful for enclosing a bit-stream in
+ a body when the total number of bits is not a multiple of the byte
+ size.
+
+ An additional parameter, "conversions", was defined in [RFC-1341] but
+ has been removed.
+
+ RFC 1341 also defined the use of a "NAME" parameter which gave a
+ suggested file name to be used if the data were to be written to a
+ file. This has been deprecated in anticipation of a separate
+ Content-Disposition header field, to be defined in a subsequent RFC.
+
+ The recommended action for an implementation that receives
+ application/octet-stream mail is to simply offer to put the data in a
+ file, with any Content-Transfer-Encoding undone, or perhaps to use it
+ as input to a user-specified process.
+
+ To reduce the danger of transmitting rogue programs through the mail,
+ it is strongly recommended that implementations NOT implement a
+ path-search mechanism whereby an arbitrary program named in the
+ Content-Type parameter (e.g., an "interpreter=" parameter) is found
+ and executed using the mail body as input.
+
+7.4.2. The Application/PostScript subtype
+
+ A Content-Type of "application/postscript" indicates a PostScript
+ program. Currently two variants of the PostScript language are
+ allowed; the original level 1 variant is described in [POSTSCRIPT]
+ and the more recent level 2 variant is described in [POSTSCRIPT2].
+
+ PostScript is a registered trademark of Adobe Systems, Inc. Use of
+ the MIME content-type "application/postscript" implies recognition of
+ that trademark and all the rights it entails.
+
+
+
+
+Borenstein & Freed [Page 50]
+
+RFC 1521 MIME September 1993
+
+
+ The PostScript language definition provides facilities for internal
+ labeling of the specific language features a given program uses. This
+ labeling, called the PostScript document structuring conventions, is
+ very general and provides substantially more information than just
+ the language level.
+
+ The use of document structuring conventions, while not required, is
+ strongly recommended as an aid to interoperability. Documents which
+ lack proper structuring conventions cannot be tested to see whether
+ or not they will work in a given environment. As such, some systems
+ may assume the worst and refuse to process unstructured documents.
+
+ The execution of general-purpose PostScript interpreters entails
+ serious security risks, and implementors are discouraged from simply
+ sending PostScript email bodies to "off-the-shelf" interpreters.
+ While it is usually safe to send PostScript to a printer, where the
+ potential for harm is greatly constrained, implementors should
+ consider all of the following before they add interactive display of
+ PostScript bodies to their mail readers.
+
+ The remainder of this section outlines some, though probably not all,
+ of the possible problems with sending PostScript through the mail.
+
+ Dangerous operations in the PostScript language include, but may not
+ be limited to, the PostScript operators deletefile, renamefile,
+ filenameforall, and file. File is only dangerous when applied to
+ something other than standard input or output. Implementations may
+ also define additional nonstandard file operators; these may also
+ pose a threat to security. Filenameforall, the wildcard file search
+ operator, may appear at first glance to be harmless. Note, however,
+ that this operator has the potential to reveal information about what
+ files the recipient has access to, and this information may itself be
+ sensitive. Message senders should avoid the use of potentially
+ dangerous file operators, since these operators are quite likely to
+ be unavailable in secure PostScript implementations. Message-
+ receiving and -displaying software should either completely disable
+ all potentially dangerous file operators or take special care not to
+ delegate any special authority to their operation. These operators
+ should be viewed as being done by an outside agency when interpreting
+ PostScript documents. Such disabling and/or checking should be done
+ completely outside of the reach of the PostScript language itself;
+ care should be taken to insure that no method exists for re-enabling
+ full-function versions of these operators.
+
+ The PostScript language provides facilities for exiting the normal
+ interpreter, or server, loop. Changes made in this "outer"
+ environment are customarily retained across documents, and may in
+ some cases be retained semipermanently in nonvolatile memory. The
+
+
+
+Borenstein & Freed [Page 51]
+
+RFC 1521 MIME September 1993
+
+
+ operators associated with exiting the interpreter loop have the
+ potential to interfere with subsequent document processing. As such,
+ their unrestrained use constitutes a threat of service denial.
+ PostScript operators that exit the interpreter loop include, but may
+ not be limited to, the exitserver and startjob operators. Message-
+ sending software should not generate PostScript that depends on
+ exiting the interpreter loop to operate. The ability to exit will
+ probably be unavailable in secure PostScript implementations.
+ Message-receiving and -displaying software should, if possible,
+ disable the ability to make retained changes to the PostScript
+ environment, and eliminate the startjob and exitserver commands. If
+ these commands cannot be eliminated, the password associated with
+ them should at least be set to a hard-to-guess value.
+
+ PostScript provides operators for setting system-wide and device-
+ specific parameters. These parameter settings may be retained across
+ jobs and may potentially pose a threat to the correct operation of
+ the interpreter. The PostScript operators that set system and device
+ parameters include, but may not be limited to, the setsystemparams
+ and setdevparams operators. Message-sending software should not
+ generate PostScript that depends on the setting of system or device
+ parameters to operate correctly. The ability to set these parameters
+ will probably be unavailable in secure PostScript implementations.
+ Message-receiving and -displaying software should, if possible,
+ disable the ability to change system and device parameters. If these
+ operators cannot be disabled, the password associated with them
+ should at least be set to a hard-to-guess value.
+
+ Some PostScript implementations provide nonstandard facilities for
+ the direct loading and execution of machine code. Such facilities
+ are quite obviously open to substantial abuse. Message-sending
+ software should not make use of such features. Besides being totally
+ hardware- specific, they are also likely to be unavailable in secure
+ implementations of PostScript. Message-receiving and -displaying
+ software should not allow such operators to be used if they exist.
+
+ PostScript is an extensible language, and many, if not most,
+ implementations of it provide a number of their own extensions. This
+ document does not deal with such extensions explicitly since they
+ constitute an unknown factor. Message-sending software should not
+ make use of nonstandard extensions; they are likely to be missing
+ from some implementations. Message-receiving and -displaying software
+ should make sure that any nonstandard PostScript operators are secure
+ and don't present any kind of threat.
+
+ It is possible to write PostScript that consumes huge amounts of
+ various system resources. It is also possible to write PostScript
+ programs that loop infinitely. Both types of programs have the
+
+
+
+Borenstein & Freed [Page 52]
+
+RFC 1521 MIME September 1993
+
+
+ potential to cause damage if sent to unsuspecting recipients.
+ Message-sending software should avoid the construction and
+ dissemination of such programs, which is antisocial. Message-
+ receiving and -displaying software should provide appropriate
+ mechanisms to abort processing of a document after a reasonable
+ amount of time has elapsed. In addition, PostScript interpreters
+ should be limited to the consumption of only a reasonable amount of
+ any given system resource.
+
+ Finally, bugs may exist in some PostScript interpreters which could
+ possibly be exploited to gain unauthorized access to a recipient's
+ system. Apart from noting this possibility, there is no specific
+ action to take to prevent this, apart from the timely correction of
+ such bugs if any are found.
+
+7.4.3. Other Application subtypes
+
+ It is expected that many other subtypes of application will be
+ defined in the future. MIME implementations must generally treat any
+ unrecognized subtypes as being equivalent to application/octet-
+ stream.
+
+ The formal grammar for content-type header fields for application
+ data is given by:
+
+ application-type := "application" "/" application-subtype
+
+ application-subtype := ("octet-stream" *stream-param)
+ / "postscript" / extension-token
+
+ stream-param := (";" "type" "=" value)
+ / (";" "padding" "=" padding)
+
+ padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
+
+7.5. The Image Content-Type
+
+ A Content-Type of "image" indicates that the body contains an image.
+ The subtype names the specific image format. These names are case
+ insensitive. Two initial subtypes are "jpeg" for the JPEG format,
+ JFIF encoding, and "gif" for GIF format [GIF].
+
+ The list of image subtypes given here is neither exclusive nor
+ exhaustive, and is expected to grow as more types are registered with
+ IANA, as described in Appendix E.
+
+ The formal grammar for the content-type header field for data of type
+ image is given by:
+
+
+
+Borenstein & Freed [Page 53]
+
+RFC 1521 MIME September 1993
+
+
+ image-type := "image" "/" ("gif" / "jpeg" / extension-token)
+
+7.6. The Audio Content-Type
+
+ A Content-Type of "audio" indicates that the body contains audio
+ data. Although there is not yet a consensus on an "ideal" audio
+ format for use with computers, there is a pressing need for a format
+ capable of providing interoperable behavior.
+
+ The initial subtype of "basic" is specified to meet this requirement
+ by providing an absolutely minimal lowest common denominator audio
+ format. It is expected that richer formats for higher quality and/or
+ lower bandwidth audio will be defined by a later document.
+
+ The content of the "audio/basic" subtype is audio encoded using 8-bit
+ ISDN mu-law [PCM]. When this subtype is present, a sample rate of
+ 8000 Hz and a single channel is assumed.
+
+ The formal grammar for the content-type header field for data of type
+ audio is given by:
+
+ audio-type := "audio" "/" ("basic" / extension-token)
+
+7.7. The Video Content-Type
+
+ A Content-Type of "video" indicates that the body contains a time-
+ varying-picture image, possibly with color and coordinated sound.
+ The term "video" is used extremely generically, rather than with
+ reference to any particular technology or format, and is not meant to
+ preclude subtypes such as animated drawings encoded compactly. The
+ subtype "mpeg" refers to video coded according to the MPEG standard
+ [MPEG].
+
+ Note that although in general this document strongly discourages the
+ mixing of multiple media in a single body, it is recognized that many
+ so-called "video" formats include a representation for synchronized
+ audio, and this is explicitly permitted for subtypes of "video".
+
+ The formal grammar for the content-type header field for data of type
+ video is given by:
+
+ video-type := "video" "/" ("mpeg" / extension-token)
+
+7.8. Experimental Content-Type Values
+
+ A Content-Type value beginning with the characters "X-" is a private
+ value, to be used by consenting mail systems by mutual agreement.
+ Any format without a rigorous and public definition must be named
+
+
+
+Borenstein & Freed [Page 54]
+
+RFC 1521 MIME September 1993
+
+
+ with an "X-" prefix, and publicly specified values shall never begin
+ with "X-". (Older versions of the widely-used Andrew system use the
+ "X-BE2" name, so new systems should probably choose a different
+ name.)
+
+ In general, the use of "X-" top-level types is strongly discouraged.
+ Implementors should invent subtypes of the existing types whenever
+ possible. The invention of new types is intended to be restricted
+ primarily to the development of new media types for email, such as
+ digital odors or holography, and not for new data formats in general.
+ In many cases, a subtype of application will be more appropriate than
+ a new top-level type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 55]
+
+RFC 1521 MIME September 1993
+
+
+8. Summary
+
+ Using the MIME-Version, Content-Type, and Content-Transfer-Encoding
+ header fields, it is possible to include, in a standardized way,
+ arbitrary types of data objects with RFC 822 conformant mail
+ messages. No restrictions imposed by either RFC 821 or RFC 822 are
+ violated, and care has been taken to avoid problems caused by
+ additional restrictions imposed by the characteristics of some
+ Internet mail transport mechanisms (see Appendix B). The "multipart"
+ and "message" Content-Types allow mixing and hierarchical structuring
+ of objects of different types in a single message. Further Content-
+ Types provide a standardized mechanism for tagging messages or body
+ parts as audio, image, or several other kinds of data. A
+ distinguished parameter syntax allows further specification of data
+ format details, particularly the specification of alternate character
+ sets. Additional optional header fields provide mechanisms for
+ certain extensions deemed desirable by many implementors. Finally, a
+ number of useful Content-Types are defined for general use by
+ consenting user agents, notably message/partial, and
+ message/external-body.
+
+9. Security Considerations
+
+ Security issues are discussed in Section 7.4.2 and in Appendix F.
+ Implementors should pay special attention to the security
+ implications of any mail content-types that can cause the remote
+ execution of any actions in the recipient's environment. In such
+ cases, the discussion of the application/postscript content-type in
+ Section 7.4.2 may serve as a model for considering other content-
+ types with remote execution capabilities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 56]
+
+RFC 1521 MIME September 1993
+
+
+10. Authors' Addresses
+
+ For more information, the authors of this document may be contacted
+ via Internet mail:
+
+ Nathaniel S. Borenstein
+ MRE 2D-296, Bellcore
+ 445 South St.
+ Morristown, NJ 07962-1910
+
+ Phone: +1 201 829 4270
+ Fax: +1 201 829 7019
+ Email: nsb@bellcore.com
+
+
+ Ned Freed
+ Innosoft International, Inc.
+ 250 West First Street
+ Suite 240
+ Claremont, CA 91711
+
+ Phone: +1 909 624 7907
+ Fax: +1 909 621 5319
+ Email: ned@innosoft.com
+
+ MIME is a result of the work of the Internet Engineering Task Force
+ Working Group on Email Extensions. The chairman of that group, Greg
+ Vaudreuil, may be reached at:
+
+ Gregory M. Vaudreuil
+ Tigon Corporation
+ 17060 Dallas Parkway
+ Dallas Texas, 75248
+
+ Phone: +1 214-733-2722
+ EMail: gvaudre@cnri.reston.va.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 57]
+
+RFC 1521 MIME September 1993
+
+
+11. Acknowledgements
+
+ This document is the result of the collective effort of a large
+ number of people, at several IETF meetings, on the IETF-SMTP and
+ IETF-822 mailing lists, and elsewhere. Although any enumeration
+ seems doomed to suffer from egregious omissions, the following are
+ among the many contributors to this effort:
+
+ Harald Tveit Alvestrand Timo Lehtinen
+ Randall Atkinson John R. MacMillan
+ Philippe Brandon Rick McGowan
+ Kevin Carosso Leo Mclaughlin
+ Uhhyung Choi Goli Montaser-Kohsari
+ Cristian Constantinof Keith Moore
+ Mark Crispin Tom Moore
+ Dave Crocker Erik Naggum
+ Terry Crowley Mark Needleman
+ Walt Daniels John Noerenberg
+ Frank Dawson Mats Ohrman
+ Hitoshi Doi Julian Onions
+ Kevin Donnelly Michael Patton
+ Keith Edwards David J. Pepper
+ Chris Eich Blake C. Ramsdell
+ Johnny Eriksson Luc Rooijakkers
+ Craig Everhart Marshall T. Rose
+ Patrik Faeltstroem Jonathan Rosenberg
+ Erik E. Fair Jan Rynning
+ Roger Fajman Harri Salminen
+ Alain Fontaine Michael Sanderson
+ James M. Galvin Masahiro Sekiguchi
+ Philip Gladstone Mark Sherman
+ Thomas Gordon Keld Simonsen
+ Phill Gross Bob Smart
+ James Hamilton Peter Speck
+ Steve Hardcastle-Kille Henry Spencer
+ David Herron Einar Stefferud
+ Bruce Howard Michael Stein
+ Bill Janssen Klaus Steinberger
+ Olle Jaernefors Peter Svanberg
+ Risto Kankkunen James Thompson
+ Phil Karn Steve Uhler
+ Alan Katz Stuart Vance
+ Tim Kehres Erik van der Poel
+ Neil Katin Guido van Rossum
+ Kyuho Kim Peter Vanderbilt
+ Anders Klemets Greg Vaudreuil
+ John Klensin Ed Vielmetti
+ Valdis Kletniek Ryan Waldron
+
+
+
+Borenstein & Freed [Page 58]
+
+RFC 1521 MIME September 1993
+
+
+ Jim Knowles Wally Wedel
+ Stev Knowles Sven-Ove Westberg
+ Bob Kummerfeld Brian Wideen
+ Pekka Kytolaakso John Wobus
+ Stellan Lagerstrom Glenn Wright
+ Vincent Lau Rayan Zachariassen
+ Donald Lindsay David Zimmerman
+ Marc Andreessen Bob Braden
+ Brian Capouch Peter Clitherow
+ Dave Collier-Brown John Coonrod
+ Stephen Crocker Jim Davis
+ Axel Deininger Dana S Emery
+ Martin Forssen Stephen Gildea
+ Terry Gray Mark Horton
+ Warner Losh Carlyn Lowery
+ Laurence Lundblade Charles Lynn
+ Larry Masinter Michael J. McInerny
+ Jon Postel Christer Romson
+ Yutaka Sato Markku Savela
+ Richard Alan Schafer Larry W. Virden
+ Rhys Weatherly Jay Weber
+ Dave Wecker
+
+The authors apologize for any omissions from this list, which are
+certainly unintentional.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 59]
+
+RFC 1521 MIME September 1993
+
+
+Appendix A -- Minimal MIME-Conformance
+
+ The mechanisms described in this document are open-ended. It is
+ definitely not expected that all implementations will support all of
+ the Content-Types described, nor that they will all share the same
+ extensions. In order to promote interoperability, however, it is
+ useful to define the concept of "MIME-conformance" to define a
+ certain level of implementation that allows the useful interworking
+ of messages with content that differs from US ASCII text. In this
+ section, we specify the requirements for such conformance.
+
+ A mail user agent that is MIME-conformant MUST:
+
+ 1. Always generate a "MIME-Version: 1.0" header field.
+
+ 2. Recognize the Content-Transfer-Encoding header field, and
+ decode all received data encoded with either the quoted-printable
+ or base64 implementations. Encode any data sent that is not in
+ seven-bit mail-ready representation using one of these
+ transformations and include the appropriate Content-Transfer-
+ Encoding header field, unless the underlying transport mechanism
+ supports non-seven-bit data, as SMTP does not.
+
+ 3. Recognize and interpret the Content-Type header field, and
+ avoid showing users raw data with a Content-Type field other than
+ text. Be able to send at least text/plain messages, with the
+ character set specified as a parameter if it is not US-ASCII.
+
+ 4. Explicitly handle the following Content-Type values, to at
+ least the following extents:
+
+ Text:
+
+ -- Recognize and display "text" mail
+ with the character set "US-ASCII."
+
+ -- Recognize other character sets at
+ least to the extent of being able
+ to inform the user about what
+ character set the message uses.
+
+ -- Recognize the "ISO-8859-*" character
+ sets to the extent of being able to
+ display those characters that are
+ common to ISO-8859-* and US-ASCII,
+ namely all characters represented
+ by octet values 0-127.
+
+
+
+
+Borenstein & Freed [Page 60]
+
+RFC 1521 MIME September 1993
+
+
+ -- For unrecognized subtypes, show or
+ offer to show the user the "raw"
+ version of the data after
+ conversion of the content from
+ canonical form to local form.
+
+ Message:
+
+ -- Recognize and display at least the
+ primary (822) encapsulation.
+
+ Multipart:
+
+ -- Recognize the primary (mixed)
+ subtype. Display all relevant
+ information on the message level
+ and the body part header level and
+ then display or offer to display
+ each of the body parts individually.
+
+ -- Recognize the "alternative" subtype,
+ and avoid showing the user
+ redundant parts of
+ multipart/alternative mail.
+
+ -- Treat any unrecognized subtypes as if
+ they were "mixed".
+
+ Application:
+
+ -- Offer the ability to remove either of
+ the two types of Content-Transfer-
+ Encoding defined in this document
+ and put the resulting information
+ in a user file.
+
+ 5. Upon encountering any unrecognized Content- Type, an
+ implementation must treat it as if it had a Content-Type of
+ "application/octet-stream" with no parameter sub-arguments. How
+ such data are handled is up to an implementation, but likely
+ options for handling such unrecognized data include offering the
+ user to write it into a file (decoded from its mail transport
+ format) or offering the user to name a program to which the
+ decoded data should be passed as input. Unrecognized predefined
+ types, which in a MIME-conformant mailer might still include
+ audio, image, or video, should also be treated in this way.
+
+ A user agent that meets the above conditions is said to be MIME-
+
+
+
+Borenstein & Freed [Page 61]
+
+RFC 1521 MIME September 1993
+
+
+ conformant. The meaning of this phrase is that it is assumed to be
+ "safe" to send virtually any kind of properly-marked data to users of
+ such mail systems, because such systems will at least be able to
+ treat the data as undifferentiated binary, and will not simply splash
+ it onto the screen of unsuspecting users. There is another sense in
+ which it is always "safe" to send data in a format that is MIME-
+ conformant, which is that such data will not break or be broken by
+ any known systems that are conformant with RFC 821 and RFC 822. User
+ agents that are MIME-conformant have the additional guarantee that
+ the user will not be shown data that were never intended to be viewed
+ as text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 62]
+
+RFC 1521 MIME September 1993
+
+
+Appendix B -- General Guidelines For Sending Email Data
+
+ Internet email is not a perfect, homogeneous system. Mail may become
+ corrupted at several stages in its travel to a final destination.
+ Specifically, email sent throughout the Internet may travel across
+ many networking technologies. Many networking and mail technologies
+ do not support the full functionality possible in the SMTP transport
+ environment. Mail traversing these systems is likely to be modified
+ in such a way that it can be transported.
+
+ There exist many widely-deployed non-conformant MTAs in the Internet.
+ These MTAs, speaking the SMTP protocol, alter messages on the fly to
+ take advantage of the internal data structure of the hosts they are
+ implemented on, or are just plain broken.
+
+ The following guidelines may be useful to anyone devising a data
+ format (Content-Type) that will survive the widest range of
+ networking technologies and known broken MTAs unscathed. Note that
+ anything encoded in the base64 encoding will satisfy these rules, but
+ that some well-known mechanisms, notably the UNIX uuencode facility,
+ will not. Note also that anything encoded in the Quoted-Printable
+ encoding will survive most gateways intact, but possibly not some
+ gateways to systems that use the EBCDIC character set.
+
+ (1) Under some circumstances the encoding used for data may change
+ as part of normal gateway or user agent operation. In particular,
+ conversion from base64 to quoted-printable and vice versa may be
+ necessary. This may result in the confusion of CRLF sequences with
+ line breaks in text bodies. As such, the persistence of CRLF as
+ something other than a line break must not be relied on.
+
+ (2) Many systems may elect to represent and store text data using
+ local newline conventions. Local newline conventions may not match
+ the RFC822 CRLF convention -- systems are known that use plain CR,
+ plain LF, CRLF, or counted records. The result is that isolated
+ CR and LF characters are not well tolerated in general; they may
+ be lost or converted to delimiters on some systems, and hence must
+ not be relied on.
+
+ (3) TAB (HT) characters may be misinterpreted or may be
+ automatically converted to variable numbers of spaces. This is
+ unavoidable in some environments, notably those not based on the
+ ASCII character set. Such conversion is STRONGLY DISCOURAGED, but
+ it may occur, and mail formats must not rely on the persistence of
+ TAB (HT) characters.
+
+ (4) Lines longer than 76 characters may be wrapped or truncated in
+ some environments. Line wrapping and line truncation are STRONGLY
+
+
+
+Borenstein & Freed [Page 63]
+
+RFC 1521 MIME September 1993
+
+
+ DISCOURAGED, but unavoidable in some cases. Applications which
+ require long lines must somehow differentiate between soft and
+ hard line breaks. (A simple way to do this is to use the quoted-
+ printable encoding.)
+
+ (5) Trailing "white space" characters (SPACE, TAB (HT)) on a line
+ may be discarded by some transport agents, while other transport
+ agents may pad lines with these characters so that all lines in a
+ mail file are of equal length. The persistence of trailing white
+ space, therefore, must not be relied on.
+
+ (6) Many mail domains use variations on the ASCII character set,
+ or use character sets such as EBCDIC which contain most but not
+ all of the US-ASCII characters. The correct translation of
+ characters not in the "invariant" set cannot be depended on across
+ character converting gateways. For example, this situation is a
+ problem when sending uuencoded information across BITNET, an
+ EBCDIC system. Similar problems can occur without crossing a
+ gateway, since many Internet hosts use character sets other than
+ ASCII internally. The definition of Printable Strings in X.400
+ adds further restrictions in certain special cases. In
+ particular, the only characters that are known to be consistent
+ across all gateways are the 73 characters that correspond to the
+ upper and lower case letters A-Z and a-z, the 10 digits 0-9, and
+ the following eleven special characters:
+
+ "'" (ASCII code 39)
+ "(" (ASCII code 40)
+ ")" (ASCII code 41)
+ "+" (ASCII code 43)
+ "," (ASCII code 44)
+ "-" (ASCII code 45)
+ "." (ASCII code 46)
+ "/" (ASCII code 47)
+ ":" (ASCII code 58)
+ "=" (ASCII code 61)
+ "?" (ASCII code 63)
+
+ A maximally portable mail representation, such as the base64
+ encoding, will confine itself to relatively short lines of text in
+ which the only meaningful characters are taken from this set of 73
+ characters.
+
+ (7) Some mail transport agents will corrupt data that includes
+ certain literal strings. In particular, a period (".") alone on a
+ line is known to be corrupted by some (incorrect) SMTP
+ implementations, and a line that starts with the five characters
+ "From " (the fifth character is a SPACE) are commonly corrupted as
+
+
+
+Borenstein & Freed [Page 64]
+
+RFC 1521 MIME September 1993
+
+
+ well. A careful composition agent can prevent these corruptions
+ by encoding the data (e.g., in the quoted-printable encoding,
+ "=46rom " in place of "From " at the start of a line, and "=2E" in
+ place of "." alone on a line.
+
+ Please note that the above list is NOT a list of recommended
+ practices for MTAs. RFC 821 MTAs are prohibited from altering the
+ character of white space or wrapping long lines. These BAD and
+ illegal practices are known to occur on established networks, and
+ implementations should be robust in dealing with the bad effects they
+ can cause.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 65]
+
+RFC 1521 MIME September 1993
+
+
+Appendix C -- A Complex Multipart Example
+
+ What follows is the outline of a complex multipart message. This
+ message has five parts to be displayed serially: two introductory
+ plain text parts, an embedded multipart message, a richtext part, and
+ a closing encapsulated text message in a non-ASCII character set.
+ The embedded multipart message has two parts to be displayed in
+ parallel, a picture and an audio fragment.
+
+ MIME-Version: 1.0
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Subject: A multipart example
+ Content-Type: multipart/mixed;
+ boundary=unique-boundary-1
+
+ This is the preamble area of a multipart message.
+ Mail readers that understand multipart format
+ should ignore this preamble.
+ If you are reading this text, you might want to
+ consider changing to a mail reader that understands
+ how to properly display multipart messages.
+ --unique-boundary-1
+
+ ...Some text appears here...
+ [Note that the preceding blank line means
+ no header fields were given and this is text,
+ with charset US ASCII. It could have been
+ done with explicit typing as in the next part.]
+
+ --unique-boundary-1
+ Content-type: text/plain; charset=US-ASCII
+
+ This could have been part of the previous part,
+ but illustrates explicit versus implicit
+ typing of body parts.
+
+ --unique-boundary-1
+ Content-Type: multipart/parallel;
+ boundary=unique-boundary-2
+
+
+ --unique-boundary-2
+ Content-Type: audio/basic
+ Content-Transfer-Encoding: base64
+
+ ... base64-encoded 8000 Hz single-channel
+ mu-law-format audio data goes here....
+
+
+
+Borenstein & Freed [Page 66]
+
+RFC 1521 MIME September 1993
+
+
+ --unique-boundary-2
+ Content-Type: image/gif
+ Content-Transfer-Encoding: base64
+
+ ... base64-encoded image data goes here....
+
+ --unique-boundary-2--
+
+ --unique-boundary-1
+ Content-type: text/richtext
+
+ This is <bold><italic>richtext.</italic></bold>
+ <smaller>as defined in RFC 1341</smaller>
+ <nl><nl>Isn't it
+ <bigger><bigger>cool?</bigger></bigger>
+
+ --unique-boundary-1
+ Content-Type: message/rfc822
+
+ From: (mailbox in US-ASCII)
+ To: (address in US-ASCII)
+ Subject: (subject in US-ASCII)
+ Content-Type: Text/plain; charset=ISO-8859-1
+ Content-Transfer-Encoding: Quoted-printable
+
+ ... Additional text in ISO-8859-1 goes here ...
+
+ --unique-boundary-1--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 67]
+
+RFC 1521 MIME September 1993
+
+
+Appendix D -- Collected Grammar
+
+ This appendix contains the complete BNF grammar for all the syntax
+ specified by this document.
+
+ By itself, however, this grammar is incomplete. It refers to several
+ entities that are defined by RFC 822. Rather than reproduce those
+ definitions here, and risk unintentional differences between the two,
+ this document simply refers the reader to RFC 822 for the remaining
+ definitions. Wherever a term is undefined, it refers to the RFC 822
+ definition.
+
+ application-subtype := ("octet-stream" *stream-param)
+ / "postscript" / extension-token
+
+ application-type := "application" "/" application-subtype
+
+ attribute := token ; case-insensitive
+
+ atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
+ / "afs" / "mail-server" / extension-token
+ ; Case-insensitive
+
+ audio-type := "audio" "/" ("basic" / extension-token)
+
+ body-part := <"message" as defined in RFC 822,
+ with all header fields optional, and with the
+ specified delimiter not occurring anywhere in
+ the message body, either on a line by itself
+ or as a substring anywhere.>
+
+ NOTE: In certain transport enclaves, RFC 822 restrictions such as
+ the one that limits bodies to printable ASCII characters may not
+ be in force. (That is, the transport domains may resemble
+ standard Internet mail transport as specified in RFC821 and
+ assumed by RFC822, but without certain restrictions.) The
+ relaxation of these restrictions should be construed as locally
+ extending the definition of bodies, for example to include octets
+ outside of the ASCII range, as long as these extensions are
+ supported by the transport and adequately documented in the
+ Content-Transfer-Encoding header field. However, in no event are
+ headers (either message headers or body-part headers) allowed to
+ contain anything other than ASCII characters.
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 68]
+
+RFC 1521 MIME September 1993
+
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_"
+ / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+ charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3"
+ / "iso-8859-4" / "iso-8859-5" / "iso-8859-6" / "iso-8859-7"
+ / "iso-8859-8" / "iso-8859-9" / extension-token
+ ; case insensitive
+
+ close-delimiter := "--" boundary "--" CRLF;Again,no space by "--",
+
+ content := "Content-Type" ":" type "/" subtype *(";" parameter)
+ ; case-insensitive matching of type and subtype
+
+ delimiter := "--" boundary CRLF ;taken from Content-Type field.
+ ; There must be no space
+ ; between "--" and boundary.
+
+ description := "Content-Description" ":" *text
+
+ discard-text := *(*text CRLF)
+
+ encapsulation := delimiter body-part CRLF
+
+ encoding := "Content-Transfer-Encoding" ":" mechanism
+
+ epilogue := discard-text ; to be ignored upon receipt.
+
+ extension-token := x-token / iana-token
+
+ external-param := (";" "access-type" "=" atype)
+ / (";" "expiration" "=" date-time)
+
+ ; Note that date-time is quoted
+ / (";" "size" "=" 1*DIGIT)
+ / (";" "permission" "=" ("read" / "read-write"))
+ ; Permission is case-insensitive
+ / (";" "name" "=" value)
+ / (";" "site" "=" value)
+ / (";" "dir" "=" value)
+ / (";" "mode" "=" value)
+ / (";" "server" "=" value)
+ / (";" "subject" "=" value)
+ ;access-type required; others required based on access-type
+
+
+
+
+Borenstein & Freed [Page 69]
+
+RFC 1521 MIME September 1993
+
+
+ iana-token := <a publicly-defined extension token,
+ registered with IANA, as specified in
+ appendix E>
+
+ id := "Content-ID" ":" msg-id
+
+ image-type := "image" "/" ("gif" / "jpeg" / extension-token)
+
+ mechanism := "7bit" ; case-insensitive
+ / "quoted-printable"
+ / "base64"
+ / "8bit"
+ / "binary"
+ / x-token
+
+ message-subtype := "rfc822"
+ / "partial" 2#3partial-param
+ / "external-body" 1*external-param
+ / extension-token
+
+ message-type := "message" "/" message-subtype
+
+ multipart-body :=preamble 1*encapsulation close-delimiter epilogue
+
+ multipart-subtype := "mixed" / "parallel" / "digest"
+ / "alternative" / extension-token
+
+ multipart-type := "multipart" "/" multipart-subtype
+ ";" "boundary" "=" boundary
+
+ octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
+ ; octet must be used for characters > 127, =, SPACE, or
+ TAB,
+ ; and is recommended for any characters not listed in
+ ; Appendix B as "mail-safe".
+
+ padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
+
+ parameter := attribute "=" value
+
+ partial-param := (";" "id" "=" value)
+ / (";" "number" "=" 1*DIGIT)
+ / (";" "total" "=" 1*DIGIT)
+ ; id & number required;total required for last part
+
+ preamble := discard-text ; to be ignored upon receipt.
+
+ ptext := octet / <any ASCII character except "=", SPACE, or TAB>
+
+
+
+Borenstein & Freed [Page 70]
+
+RFC 1521 MIME September 1993
+
+
+ ; characters not listed as "mail-safe" in Appendix B
+ ; are also not recommended.
+
+ quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
+ ; Maximum line length of 76 characters excluding CRLF
+
+ stream-param := (";" "type" "=" value)
+ / (";" "padding" "=" padding)
+
+ subtype := token ; case-insensitive
+
+ text-subtype := "plain" / extension-token
+
+ text-type := "text" "/" text-subtype [";" "charset" "=" charset]
+
+ token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
+
+ tspecials := "(" / ")" / "<" / ">" / "@"
+ / "," / ";" / ":" / "\" / <">
+ / "/" / "[" / "]" / "?" / "="
+ ; Must be in quoted-string,
+ ; to use within parameter values
+
+
+ type := "application" / "audio" ; case-insensitive
+ / "image" / "message"
+ / "multipart" / "text"
+ / "video" / extension-token
+ ; All values case-insensitive
+
+ value := token / quoted-string
+
+ version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+ video-type := "video" "/" ("mpeg" / extension-token)
+
+ x-token := <The two characters "X-" or "x-" followed, with no
+ intervening white space, by any token>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 71]
+
+RFC 1521 MIME September 1993
+
+
+Appendix E -- IANA Registration Procedures
+
+ MIME has been carefully designed to have extensible mechanisms, and
+ it is expected that the set of content-type/subtype pairs and their
+ associated parameters will grow significantly with time. Several
+ other MIME fields, notably character set names, access-type
+ parameters for the message/external-body type, and possibly even
+ Content-Transfer-Encoding values, are likely to have new values
+ defined over time. In order to ensure that the set of such values is
+ developed in an orderly, well-specified, and public manner, MIME
+ defines a registration process which uses the Internet Assigned
+ Numbers Authority (IANA) as a central registry for such values.
+
+ In general, parameters in the content-type header field are used to
+ convey supplemental information for various content types, and their
+ use is defined when the content-type and subtype are defined. New
+ parameters should not be defined as a way to introduce new
+ functionality.
+
+ In order to simplify and standardize the registration process, this
+ appendix gives templates for the registration of new values with
+ IANA. Each of these is given in the form of an email message
+ template, to be filled in by the registering party.
+
+ E.1 Registration of New Content-type/subtype Values
+
+ Note that MIME is generally expected to be extended by subtypes. If
+ a new fundamental top-level type is needed, its specification must be
+ published as an RFC or submitted in a form suitable to become an RFC,
+ and be subject to the Internet standards process.
+
+ To: IANA@isi.edu
+ Subject: Registration of new MIME
+ content-type/subtype
+
+ MIME type name:
+
+ (If the above is not an existing top-level MIME type,
+ please explain why an existing type cannot be used.)
+
+ MIME subtype name:
+
+ Required parameters:
+
+ Optional parameters:
+
+ Encoding considerations:
+
+
+
+
+Borenstein & Freed [Page 72]
+
+RFC 1521 MIME September 1993
+
+
+ Security considerations:
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be if a new top-level type is being defined, and
+ must be a publicly available specification in any
+ case.)
+
+ Person & email address to contact for further information:
+
+ E.2 Registration of New Access-type Values
+ for Message/external-body
+
+ To: IANA@isi.edu
+ Subject: Registration of new MIME Access-type for
+ Message/external-body content-type
+
+ MIME access-type name:
+
+ Required parameters:
+
+ Optional parameters:
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be.)
+
+ Person & email address to contact for further information:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 73]
+
+RFC 1521 MIME September 1993
+
+
+Appendix F -- Summary of the Seven Content-types
+
+ Content-type: text
+
+ Subtypes defined by this document: plain
+
+ Important Parameters: charset
+
+ Encoding notes: quoted-printable generally preferred if an encoding
+ is needed and the character set is mostly an ASCII superset.
+
+ Security considerations: Rich text formats such as TeX and Troff
+ often contain mechanisms for executing arbitrary commands or file
+ system operations, and should not be used automatically unless
+ these security problems have been addressed. Even plain text may
+ contain control characters that can be used to exploit the
+ capabilities of "intelligent" terminals and cause security
+ violations. User interfaces designed to run on such terminals
+ should be aware of and try to prevent such problems.
+
+ ________________________________________________________
+ Content-type: multipart
+
+ Subtypes defined by this document: mixed, alternative,
+ digest, parallel.
+
+ Important Parameters: boundary
+
+ Encoding notes: No content-transfer-encoding is permitted.
+
+ ________________________________________________________
+ Content-type: message
+
+ Subtypes defined by this document: rfc822, partial, external-body
+
+ Important Parameters: id, number, total, access-type, expiration,
+ size, permission, name, site, directory, mode, server, subject
+
+ Encoding notes: No content-transfer-encoding is permitted.
+ Specifically, only "7bit" is permitted for "message/partial" or
+ "message/external-body", and only "7bit", "8bit", or "binary" are
+ permitted for other subtypes of "message".
+ ______________________________________________________________
+ Content-type: application
+
+ Subtypes defined by this document: octet-stream, postscript
+
+ Important Parameters: type, padding
+
+
+
+Borenstein & Freed [Page 74]
+
+RFC 1521 MIME September 1993
+
+
+ Deprecated Parameters: name and conversions were
+ defined in RFC 1341.
+
+ Encoding notes: base64 preferred for unreadable subtypes.
+
+ Security considerations: This type is intended for the
+ transmission of data to be interpreted by locally-installed
+ programs. If used, for example, to transmit executable
+ binary programs or programs in general-purpose interpreted
+ languages, such as LISP programs or shell scripts, severe
+ security problems could result. Authors of mail-reading
+ agents are cautioned against giving their systems the power
+ to execute mail-based application data without carefully
+ considering the security implications. While it is
+ certainly possible to define safe application formats and
+ even safe interpreters for unsafe formats, each interpreter
+ should be evaluated separately for possible security
+ problems.
+ ________________________________________________________________
+ Content-type: image
+
+ Subtypes defined by this document: jpeg, gif
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+ ________________________________________________________________
+ Content-type: audio
+
+ Subtypes defined by this document: basic
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+ ________________________________________________________________
+ Content-type: video
+
+ Subtypes defined by this document: mpeg
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 75]
+
+RFC 1521 MIME September 1993
+
+
+Appendix G -- Canonical Encoding Model
+
+ There was some confusion, in earlier drafts of this memo, regarding
+ the model for when email data was to be converted to canonical form
+ and encoded, and in particular how this process would affect the
+ treatment of CRLFs, given that the representation of newlines varies
+ greatly from system to system. For this reason, a canonical model
+ for encoding is presented below.
+
+ The process of composing a MIME entity can be modeled as being done
+ in a number of steps. Note that these steps are roughly similar to
+ those steps used in RFC 1421 and are performed for each 'innermost
+ level' body:
+
+ Step 1. Creation of local form.
+
+ The body to be transmitted is created in the system's native format.
+ The native character set is used, and where appropriate local end of
+ line conventions are used as well. The body may be a UNIX-style text
+ file, or a Sun raster image, or a VMS indexed file, or audio data in
+ a system-dependent format stored only in memory, or anything else
+ that corresponds to the local model for the representation of some
+ form of information. Fundamentally, the data is created in the
+ "native" form specified by the type/subtype information.
+
+ Step 2. Conversion to canonical form.
+
+ The entire body, including "out-of-band" information such as record
+ lengths and possibly file attribute information, is converted to a
+ universal canonical form. The specific content type of the body as
+ well as its associated attributes dictate the nature of the canonical
+ form that is used. Conversion to the proper canonical form may
+ involve character set conversion, transformation of audio data,
+ compression, or various other operations specific to the various
+ content types. If character set conversion is involved, however,
+ care must be taken to understand the semantics of the content-type,
+ which may have strong implications for any character set conversion,
+ e.g. with regard to syntactically meaningful characters in a text
+ subtype other than "plain".
+
+ For example, in the case of text/plain data, the text must be
+ converted to a supported character set and lines must be delimited
+ with CRLF delimiters in accordance with RFC822. Note that the
+ restriction on line lengths implied by RFC822 is eliminated if the
+ next step employs either quoted-printable or base64 encoding.
+
+
+
+
+
+
+Borenstein & Freed [Page 76]
+
+RFC 1521 MIME September 1993
+
+
+ Step 3. Apply transfer encoding.
+
+ A Content-Transfer-Encoding appropriate for this body is applied.
+ Note that there is no fixed relationship between the content type and
+ the transfer encoding. In particular, it may be appropriate to base
+ the choice of base64 or quoted-printable on character frequency
+ counts which are specific to a given instance of a body.
+
+ Step 4. Insertion into entity.
+
+ The encoded object is inserted into a MIME entity with appropriate
+ headers. The entity is then inserted into the body of a higher-level
+ entity (message or multipart) if needed.
+
+ It is vital to note that these steps are only a model; they are
+ specifically NOT a blueprint for how an actual system would be built.
+ In particular, the model fails to account for two common designs:
+
+ 1. In many cases the conversion to a canonical form prior to
+ encoding will be subsumed into the encoder itself, which
+ understands local formats directly. For example, the local
+ newline convention for text bodies might be carried through to the
+ encoder itself along with knowledge of what that format is.
+
+ 2. The output of the encoders may have to pass through one or
+ more additional steps prior to being transmitted as a message. As
+ such, the output of the encoder may not be conformant with the
+ formats specified by RFC822. In particular, once again it may be
+ appropriate for the converter's output to be expressed using local
+ newline conventions rather than using the standard RFC822 CRLF
+ delimiters.
+
+ Other implementation variations are conceivable as well. The vital
+ aspect of this discussion is that, in spite of any optimizations,
+ collapsings of required steps, or insertion of additional processing,
+ the resulting messages must be consistent with those produced by the
+ model described here. For example, a message with the following
+ header fields:
+
+ Content-type: text/foo; charset=bar
+ Content-Transfer-Encoding: base64
+
+ must be first represented in the text/foo form, then (if necessary)
+ represented in the "bar" character set, and finally transformed via
+ the base64 algorithm into a mail-safe form.
+
+
+
+
+
+
+Borenstein & Freed [Page 77]
+
+RFC 1521 MIME September 1993
+
+
+Appendix H -- Changes from RFC 1341
+
+ This document is a relatively minor revision of RFC 1341. For
+ the convenience of those familiar with RFC 1341, the technical
+ changes from that document are summarized in this appendix.
+
+ 1. The definition of "tspecials" has been changed to no longer
+ include ".".
+
+ 2. The Content-ID field is now mandatory for message/external-body
+ parts.
+
+ 3. The text/richtext type (including the old Section 7.1.3 and
+ Appendix D) has been moved to a separate document.
+
+ 4. The rules on header merging for message/partial data have been
+ changed to treat the Encrypted and MIME-Version headers as special
+ cases.
+
+ 5. The definition of the external-body access-type parameter has
+ been changed so that it can only indicate a single access method
+ (which was all that made sense).
+
+ 6. There is a new "Subject" parameter for message/external-body,
+ access-type mail-server, to permit MIME-based use of mail servers
+ that rely on Subject field information.
+
+ 7. The "conversions" parameter for application/octet-stream has been
+ removed.
+
+ 8. Section 7.4.1 now deprecates the use of the "name" parameter for
+ application/octet-stream, as this will be superseded in the future by
+ a Content-Disposition header.
+
+ 9. The formal grammar for multipart bodies has been changed so that
+ a CRLF is no longer required before the first boundary line.
+
+ 10. MIME entities of type "message/partial" and "message/external-
+ body" are now required to use only the "7bit" transfer-encoding.
+ (Specifically, "binary" and "8bit" are not permitted.)
+
+ 11. The "application/oda" content-type has been removed.
+
+ 12. A note has been added to the end of section 7.2.3, explaining
+ the semantics of Content-ID in a multipart/alternative MIME entity.
+
+ 13. The formal syntax for the "MIME-Version" field has been
+ tightened, but in a way that is completely compatible with the only
+
+
+
+Borenstein & Freed [Page 78]
+
+RFC 1521 MIME September 1993
+
+
+ version number defined in RFC 1341.
+
+ 14. In Section 7.3.1, the definition of message/rfc822 has been
+ relaxed regarding mandatory fields.
+
+ All other changes from RFC 1341 were editorial changes and do not
+ affect the technical content of MIME. Considerable formal grammar
+ has been added, but this reflects the prose specification that was
+ already in place.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 79]
+
+RFC 1521 MIME September 1993
+
+
+References
+
+ [US-ASCII] Coded Character Set--7-Bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+ [ATK] Borenstein, Nathaniel S., Multimedia Applications Development
+ with the Andrew Toolkit, Prentice-Hall, 1990.
+
+ [GIF] Graphics Interchange Format (Version 89a), Compuserve, Inc.,
+ Columbus, Ohio, 1990.
+
+ [ISO-2022] International Standard--Information Processing--ISO 7-bit
+ and 8-bit coded character sets--Code extension techniques, ISO
+ 2022:1986.
+
+ [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic
+ Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part
+ 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet
+ No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4,
+ 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:
+ Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek
+ alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO
+ 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
+
+ [ISO-646] International Standard--Information Processing--ISO 7-bit
+ coded character set for information interchange, ISO 646:1983.
+
+ [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/TJC1/SC2/WG11
+ (Motion Picture Experts Group), May, 1991.
+
+ [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva, 1972,
+ "Pulse Code Modulation (PCM) of Voice Frequencies".
+
+ [POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference
+ Manual, Addison-Wesley, 1985.
+
+ [POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference
+ Manual, Addison-Wesley, Second Edition, 1990.
+
+ [X400] Schicker, Pietro, "Message Handling Systems, X.400", Message
+ Handling Systems and Distributed Applications, E. Stefferud, O-j.
+ Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41.
+
+ [RFC-783] Sollins, K., "TFTP Protocol (revision 2)", RFC 783, MIT,
+ June 1981.
+
+ [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, USC/Information Sciences Institute, August 1982.
+
+
+
+Borenstein & Freed [Page 80]
+
+RFC 1521 MIME September 1993
+
+
+ [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message
+ Encapsulation", RFC 934, Delaware and NMA, January 1985.
+
+ [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol",
+ STD 9, RFC 959, USC/Information Sciences Institute, October 1985.
+
+ [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet
+ Messages", STD 11, RFC 1049, CMU, March 1988.
+
+ [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
+ Part I - Message Encryption and Authentication Procedures", RFC
+ 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.
+
+ [RFC-1154] Robinson, D. and R. Ullmann, "Encoding Header Field for
+ Internet Messages", RFC 1154, Prime Computer, Inc., April 1990.
+
+ [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
+ Mail Extensions): Mechanisms for Specifying and Describing the Format
+ of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.
+
+ [RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet
+ Message Headers", RFC 1342, University of Tennessee, June 1992.
+
+ [RFC-1343] Borenstein, N., "A User Agent Configuration Mechanism
+ for Multimedia Mail Format Information", RFC 1343, Bellcore, June
+ 1992.
+
+ [RFC-1344] Borenstein, N., "Implications of MIME for Internet
+ Mail Gateways", RFC 1344, Bellcore, June 1992.
+
+ [RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets",
+ RFC 1345, Rationel Almen Planlaegning, June 1992.
+
+ [RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,
+ Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME
+ transport", RFC 1426, United Nations Universit, Innosoft, Dover Beach
+ Consulting, Inc., Network Management Associates, Inc., The Branch
+ Office, February 1993.
+
+ [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet
+ Message Headers" RFC 1522, University of Tennessee, September 1993.
+
+ [RFC-1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1340, USC/Information Sciences Institute, July 1992.
+
+
+
+
+Borenstein & Freed [Page 81]
+ \ No newline at end of file
diff --git a/Documentation/en/rfc/rfc1651.txt b/Documentation/en/rfc/rfc1651.txt
new file mode 100644
index 00000000..6398eab0
--- /dev/null
+++ b/Documentation/en/rfc/rfc1651.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group J. Klensin, WG Chair
+Request for Comments: 1651 MCI
+Obsoletes: 1425 N. Freed, Editor
+Category: Standards Track Innosoft
+ M. Rose
+ Dover Beach Consulting, Inc.
+ E. Stefferud
+ Network Management Associates, Inc.
+ D. Crocker
+ Silicon Graphics, Inc.
+ July 1994
+
+
+ SMTP Service Extensions
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Abstract
+
+ This memo defines a framework for extending the SMTP service by
+ defining a means whereby a server SMTP can inform a client SMTP as to
+ the service extensions it supports. Standard extensions to the SMTP
+ service are registered with the IANA. This framework does not
+ require modification of existing SMTP clients or servers unless the
+ features of the service extensions are to be requested or provided.
+
+2. Introduction
+
+ The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable,
+ effective basis for the relay function of message transfer agents.
+ Although a decade old, SMTP has proven remarkably resilient.
+ Nevertheless, the need for a number of protocol extensions has become
+ evident. Rather than describing these extensions as separate and
+ haphazard entities, this document enhances SMTP in a straightforward
+ fashion that provides a framework in which all future extensions can
+ be built in a single consistent way.
+
+3. Framework for SMTP Extensions
+
+ For the purpose of service extensions to SMTP, SMTP relays a mail
+ object containing an envelope and a content.
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 1]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ (1) The SMTP envelope is straightforward, and is sent as a
+ series of SMTP protocol units: it consists of an
+ originator address (to which error reports should be
+ directed); a delivery mode (e.g., deliver to recipient
+ mailboxes); and, one or more recipient addresses.
+
+ (2) The SMTP content is sent in the SMTP DATA protocol unit
+ and has two parts: the headers and the body. The headers
+ form a collection of field/value pairs structured
+ according to STD 11, RFC 822 [2], whilst the body, if
+ structured, is defined according to MIME [3]. The content is
+ textual in nature, expressed using the US-ASCII repertoire (ANSI
+ X3.4-1986). Although extensions (such as MIME) may relax
+ this restriction for the content body, the content
+ headers are always encoded using the US-ASCII repertoire.
+ The algorithm defined in [4] is used to represent header
+ values outside the US-ASCII repertoire, whilst still
+ encoding them using the US-ASCII repertoire.
+
+ Although SMTP is widely and robustly deployed, some parts of the
+ Internet community might wish to extend the SMTP service. This memo
+ defines a means whereby both an extended SMTP client and server may
+ recognize each other as such and the server can inform the client as
+ to the service extensions that it supports.
+
+ It must be emphasized that any extension to the SMTP service should
+ not be considered lightly. SMTP's strength comes primarily from its
+ simplicity. Experience with many protocols has shown that:
+
+ protocols with few options tend towards ubiquity, whilst
+ protocols with many options tend towards obscurity.
+
+ This means that each and every extension, regardless of its benefits,
+ must be carefully scrutinized with respect to its implementation,
+ deployment, and interoperability costs. In many cases, the cost of
+ extending the SMTP service will likely outweigh the benefit.
+
+ Given this environment, the framework for the extensions described in
+ this memo consists of:
+
+ (1) a new SMTP command (section 4)
+
+ (2) a registry of SMTP service extensions (section 5)
+
+ (3) additional parameters to the SMTP MAIL FROM and RCPT TO
+ commands (section 6).
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 2]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+4. The EHLO command
+
+ A client SMTP supporting SMTP service extensions should start an SMTP
+ session by issuing the EHLO command instead of the HELO command. If
+ the SMTP server supports the SMTP service extensions it will give a
+ successful response (see section 4.3), a failure response (see 4.4),
+ or an error response (4.5). If the SMTP server does not support any
+ SMTP service extensions it will generate an error response (see
+ section 4.5).
+
+4.1. Changes to STD 10, RFC 821
+
+ STD 10, RFC 821 states that the first command in an SMTP session must
+ be the HELO command. This requirement is hereby amended to allow a
+ session to start with either EHLO or HELO.
+
+4.2. Command syntax
+
+ The syntax for this command, using the ABNF notation of [2], is:
+
+ ehlo-cmd ::= "EHLO" SP domain CR LF
+
+ If successful, the server SMTP responds with code 250. On failure,
+ the server SMTP responds with code 550. On error, the server SMTP
+ responds with one of codes 500, 501, 502, 504, or 421.
+
+ This command is issued instead of the HELO command, and may be issued
+ at any time that a HELO command would be appropriate. That is, if
+ the EHLO command is issued, and a successful response is returned,
+ then a subsequent HELO or EHLO command will result in the server SMTP
+ replying with code 503. A client SMTP must not cache any information
+ returned if the EHLO command succeeds. That is, a client SMTP must
+ issue the EHLO command at the start of each SMTP session if
+ information about extended facilities is needed.
+
+4.3. Successful response
+
+ If the server SMTP implements and is able to perform the EHLO
+ command, it will return code 250. This indicates that both the
+ server and client SMTP are in the initial state, that is, there is no
+ transaction in progress and all state tables and buffers are cleared.
+
+ Normally, this response will be a multiline reply. Each line of the
+ response contains a keyword and, optionally, one or more parameters.
+ The syntax for a positive response, using the ABNF notation of [2],
+ is:
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 3]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF
+ / ( "250-" domain [ SP greeting ] CR LF
+ *( "250-" ehlo-line CR LF )
+ "250" SP ehlo-line CR LF )
+
+ ; the usual HELO chit-chat
+ greeting ::= 1*<any character other than CR or LF>
+
+ ehlo-line ::= ehlo-keyword *( SP ehlo-param )
+
+ ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+ ; syntax and values depend on ehlo-keyword
+ ehlo-param ::= 1*<any CHAR excluding SP and all
+ control characters (US-ASCII 0-31
+ inclusive)>
+
+ ALPHA ::= <any one of the 52 alphabetic characters
+ (A through Z in upper case, and,
+ a through z in lower case)>
+ DIGIT ::= <any one of the 10 numeric characters
+ (0 through 9)>
+
+ CR ::= <the carriage-return character
+ (ASCII decimal code 13)>
+ LF ::= <the line-feed character
+ (ASCII decimal code 10)>
+ SP ::= <the space character
+ (ASCII decimal code 32)>
+
+ Although EHLO keywords may be specified in upper, lower, or mixed
+ case, they must always be recognized and processed in a case-
+ insensitive manner. This is simply an extension of practices begun in
+ RFC 821.
+
+ The IANA maintains a registry of standard SMTP service extensions.
+ Associated with each such extension is a corresponding EHLO keyword
+ value. Each service extension registered with the IANA is defined by
+ a standards-track RFC, and such a definition includes:
+
+ (1) the textual name of the SMTP service extension;
+
+ (2) the EHLO keyword value associated with the extension;
+
+ (3) the syntax and possible values of parameters associated
+ with the EHLO keyword value;
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 4]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ (4) any additional SMTP verbs associated with the extension
+ (additional verbs will usually be, but are not required
+ to be, the same as the EHLO keyword value);
+
+ (5) any new parameters the extension associates with the MAIL
+ FROM or RCPT TO verbs; and,
+
+ (6) how support for the extension affects the behavior of a
+ server and client SMTP.
+
+ In addition, any EHLO keyword value that starts with an upper or
+ lower case "X" refers to a local SMTP service extension, which is
+ used through bilateral, rather than standardized, agreement. Keywords
+ beginning with "X" may not be used in a registered service extension.
+
+ Any keyword values presented in the EHLO response that do not begin
+ with "X" must correspond to a standard or standards-track SMTP
+ service extension registered with IANA. A conforming server must not
+ offer non "X" prefixed keyword values that are not described in a
+ registered and standardized extension.
+
+ Additional verbs are bound by the same rules as EHLO keywords;
+ specifically, verbs begining with "X" are local extensions that may
+ not be standardized and verbs not beginning with "X" must always be
+ registered.
+
+4.4. Failure response
+
+ If for some reason the server SMTP is unable to list the service
+ extensions it supports, it will return code 554.
+
+ In the case of a failure response, the client SMTP should issue
+ either the HELO or QUIT command.
+
+4.5. Error responses from extended servers
+
+ If the server SMTP recognizes the EHLO command, but the command
+ argument is unacceptable, it will return code 501.
+
+ If the server SMTP recognizes, but does not implement, the EHLO
+ command, it will return code 502.
+
+ If the server SMTP determines that the SMTP service is no longer
+ available (e.g., due to imminent system shutdown), it will return
+ code 421.
+
+ In the case of any error response, the client SMTP should issue
+ either the HELO or QUIT command.
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 5]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+4.6. Responses from servers without extensions
+
+ A server SMTP that conforms to RFC 821 but does not support the
+ extensions specified here will not recognize the EHLO command and
+ will consequently return code 500, as specified in RFC 821. The
+ server SMTP should stay in the same state after returning this code
+ (see section 4.1.1 of RFC 821). The client SMTP may then issue
+ either a HELO or a QUIT command.
+
+4.7. Responses from improperly implemented servers
+
+ Some SMTP servers are known to disconnect the SMTP transmission
+ channel upon receipt of the EHLO command. The disconnect can occur
+ immediately or after sending a response. Such behavior violates
+ section 4.1.1 of RFC 821, which explicitly states that disconnection
+ should only occur after a QUIT command is issued.
+
+ Nevertheless, in order to achieve maxmimum interoperablity it is
+ suggested that extended SMTP clients using EHLO be coded to check for
+ server connection closure after EHLO is sent, either before or after
+ returning a reply. If this happens the client must decide if the
+ operation can be successfully completed without using any SMTP
+ extensions. If it can a new connection can be opened and the HELO
+ command can be used.
+
+ Other improperly-implemented servers will not accept a HELO command
+ after EHLO has been sent and rejected. In some cases, this problem
+ can be worked around by sending a RSET after the failure response to
+ EHLO, then sending the HELO. Clients that do this should be aware
+ that many implementations will return a failure code (e.g., 503 Bad
+ sequence of commands) in response to the RSET. This code can be
+ safely ignored.
+
+5. Initial IANA Registry
+
+ The IANA's initial registry of SMTP service extensions consists of
+ these entries:
+
+ Service Ext EHLO Keyword Parameters Verb Added Behavior
+ ------------- ------------ ---------- ---------- ------------------
+ Send SEND none SEND defined in RFC 821
+ Send or Mail SOML none SOML defined in RFC 821
+ Send and Mail SAML none SAML defined in RFC 821
+ Expand EXPN none EXPN defined in RFC 821
+ Help HELP none HELP defined in RFC 821
+ Turn TURN none TURN defined in RFC 821
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 6]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ which correspond to those SMTP commands which are defined as optional
+ in [5]. (The mandatory SMTP commands, according to [5], are HELO,
+ MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.)
+
+6. MAIL FROM and RCPT TO Parameters
+
+ It is recognized that several of the extensions planned for SMTP will
+ make use of additional parameters associated with the MAIL FROM and
+ RCPT TO command. The syntax for these commands, again using the ABNF
+ notation of [2] as well as underlying definitions from [1], is:
+
+ esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF
+ esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter)
+ esmtp-parameter ::= esmtp-keyword ["=" esmtp-value]
+ esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+ ; syntax and values depend on esmtp-keyword
+ esmtp-value ::= 1*<any CHAR excluding "=", SP, and all
+ control characters (US-ASCII 0-31
+ inclusive)>
+
+ ; The following commands are extended to
+ ; accept extended parameters.
+ inner-esmtp-cmd ::= ("MAIL FROM:<" reverse-path ">") /
+ ("RCPT TO:<" forward-path ">")
+
+ All esmtp-keyword values must be registered as part of the IANA
+ registration process described above. This definition only provides
+ the framework for future extension; no extended MAIL FROM or RCPT TO
+ parameters are defined by this RFC.
+
+6.1. Error responses
+
+ If the server SMTP does not recognize or cannot implement one or more
+ of the parameters associated with a particular MAIL FROM or RCPT TO
+ command, it will return code 555.
+
+ If for some reason the server is temporarily unable to accomodate one
+ or more of the parameters associated with a MAIL FROM or RCPT TO
+ command, and if the definition of the specific parameter does not
+ mandate the use of another code, it should return code 455.
+
+ Errors specific to particular parameters and their values will be
+ specified in the parameter's defining RFC.
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 7]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+7. Received: Header Field Annotation
+
+ SMTP servers are required to add an appropriate Received: field to
+ the headers of all messages they receive. A "with ESMTP" clause
+ should be added to this field when any SMTP service extensions are
+ used. "ESMTP" is hereby added to the list of standard protocol names
+ registered with IANA.
+
+8. Usage Examples
+
+ (1) An interaction of the form:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250 dbc.mtview.ca.us says hello
+ ...
+
+ indicates that the server SMTP implements only those SMTP
+ commands which are defined as mandatory in [5].
+
+
+ (2) In contrast, an interaction of the form:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250-dbc.mtview.ca.us says hello
+ S: 250-EXPN
+ S: 250-HELP
+ S: 250-8BITMIME
+ S: 250-XONE
+ S: 250 XVRB
+ ...
+
+ indicates that the server SMTP also implements the SMTP
+ EXPN and HELP commands, one standard service extension
+ (8BITMIME), and two non-standard service extensions (XONE
+ and XVRB).
+
+
+ (3) Finally, a server that does not support SMTP service
+ extensions would act as follows:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 8]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 500 Command not recognized: EHLO
+ ...
+
+ The 500 response indicates that the server SMTP does not
+ implement the extensions specified here. The client
+ would normally send a HELO command and proceed as
+ specified in RFC 821. See section 4.7 for additional
+ discussion.
+
+9. Security Considerations
+
+ This RFC does not discuss security issues and is not believed to
+ raise any security issues not already endemic in electronic mail and
+ present in fully conforming implementations of RFC-821. It does
+ provide an announcement of server mail capabilities via the response
+ to the EHLO verb. However, all information provided by announcement
+ of any of the initial set of service extensions defined by this RFC
+ can be readily deduced by selective probing of the verbs required to
+ transport and deliver mail. The security implications of service
+ extensions described in other RFCs should be dealt with in those
+ RFCs.
+
+10. Acknowledgements
+
+ This document represents a synthesis of the ideas of many people and
+ reactions to the ideas and proposals of others. Randall Atkinson,
+ Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
+ and text sufficient to be considered co-authors. Other important
+ suggestions, text, or encouragement came from Harald Alvestrand, Jim
+ Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per
+ Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A.
+ Miller, Dan Oscarsson, Julian Onions, Rayan Zachariassen, and the
+ contributions of the entire IETF SMTP Working Group. Of course, none
+ of the individuals are necessarily responsible for the combination of
+ ideas represented here. Indeed, in some cases, the response to a
+ particular criticism was to accept the problem identification but to
+ include an entirely different solution from the one originally
+ proposed.
+
+11. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 9]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+ Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
+
+ [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
+ Headers", RFC 1522, University of Tennessee, September 1993.
+
+ [5] Braden, R., "Requirements for Internet Hosts - Application and
+ Support", STD 3, RFC 1123, USC/Information Sciences Institute,
+ October 1989.
+
+12. Chair, Editor, and Authors' Addresses
+
+ John Klensin, WG Chair
+ MCI Data Services Division
+ 2100 Reston Parkway, 6th floor
+ Reston, VA 22091
+ USA
+
+ Phone:: 1 703 715 7361
+ Fax: +1 703 715 7435
+ EMail: klensin@mci.net
+
+
+ Ned Freed, Editor
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+
+ Phone:: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Moutain View, CA 94043-2186
+ USA
+
+ Phone: +1 415 968 1052
+ Fax: +1 415 968 2510
+ EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 10]
+
+RFC 1651 SMTP Service Extensions July 1994
+
+
+ Einar A. Stefferud
+ Network Management Associates, Inc.
+ 17301 Drey Lane
+ Huntington Beach, CA, 92647-5615
+ USA
+
+ Phone: +1 714 842 3711
+ Fax: +1 714 848 2091
+ EMail: stef@nma.com
+
+
+ Dave Crocker
+ Silicon Graphics, Inc.
+ 2011 N. Shoreline Blvd.
+ P.O. Box 7311
+ Mountain View, CA 94039
+ USA
+
+ Phone: +1 415 390 1804
+ Fax: +1 415 962 8404
+ EMail: dcrocker@sgi.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 11]
+
diff --git a/Documentation/en/rfc/rfc1652.txt b/Documentation/en/rfc/rfc1652.txt
new file mode 100644
index 00000000..1f3bdc39
--- /dev/null
+++ b/Documentation/en/rfc/rfc1652.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group J. Klensin, WG Chair
+Request for Comments: 1652 MCI
+Obsoletes: 1426 N. Freed, Editor
+Category: Standards Track Innosoft
+ M. Rose
+ Dover Beach Consulting, Inc.
+ E. Stefferud
+ Network Management Associates, Inc.
+ D. Crocker
+ Silicon Graphics, Inc.
+ July 1994
+
+
+ SMTP Service Extension for 8bit-MIMEtransport
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This memo defines an extension to the SMTP service whereby an SMTP
+ content body consisting of text containing octets outside of the US-
+ ASCII octet range (hex 00-7F) may be relayed using SMTP.
+
+1. Introduction
+
+ Although SMTP is widely and robustly deployed, various extensions
+ have been requested by parts of the Internet community. In
+ particular, a significant portion of the Internet community wishes to
+ exchange messages in which the content body consists of a MIME
+ message [3] containing arbitrary octet-aligned material. This memo
+ uses the mechanism described in [5] to define an extension to the
+ SMTP service whereby such contents may be exchanged. Note that this
+ extension does NOT eliminate the possibility of an SMTP server
+ limiting line length; servers are free to implement this extension
+ but nevertheless set a line length limit no lower than 1000 octets.
+ Given that this restriction still applies, this extension does NOT
+ provide a means for transferring unencoded binary via SMTP.
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 1]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+2. Framework for the 8bit MIME Transport Extension
+
+ The 8bit MIME transport extension is laid out as follows:
+
+ (1) the name of the SMTP service extension defined here is
+ 8bit-MIMEtransport;
+
+ (2) the EHLO keyword value associated with the extension is
+ 8BITMIME;
+
+ (3) no parameter is used with the 8BITMIME EHLO keyword;
+
+ (4) one optional parameter using the keyword BODY is added to
+ the MAIL FROM command. The value associated with this
+ parameter is a keyword indicating whether a 7bit message
+ (in strict compliance with [1]) or a MIME message (in
+ strict compliance with [3]) with arbitrary octet content
+ is being sent. The syntax of the value is as follows,
+ using the ABNF notation of [2]:
+
+ body-value ::= "7BIT" / "8BITMIME"
+
+ (5) no additional SMTP verbs are defined by this extension;
+ and,
+
+ (6) the next section specifies how support for the extension
+ affects the behavior of a server and client SMTP.
+
+3. The 8bit-MIMEtransport service extension
+
+ When a client SMTP wishes to submit (using the MAIL command) a
+ content body consisting of a MIME message containing arbitrary lines
+ of octet-aligned material, it first issues the EHLO command to the
+ server SMTP. If the server SMTP responds with code 250 to the EHLO
+ command, and the response includes the EHLO keyword value 8BITMIME,
+ then the server SMTP is indicating that it supports the extended MAIL
+ command and will accept MIME messages containing arbitrary octet-
+ aligned material.
+
+ The extended MAIL command is issued by a client SMTP when it wishes
+ to transmit a content body consisting of a MIME message containing
+ arbitrary lines of octet-aligned material. The syntax for this
+ command is identical to the MAIL command in [1], except that a BODY
+ parameter must appear after the address. Only one BODY parameter may
+ be used in a single MAIL command.
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 2]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+ The complete syntax of this extended command is defined in [5]. The
+ esmtp-keyword is BODY and the syntax for esmtp-value is given by the
+ syntax for body-value shown above.
+
+ The value associated with the BODY parameter indicates whether the
+ content body which will be passed using the DATA command consists of
+ a MIME message containing some arbitrary octet-aligned material
+ ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT").
+
+ A server which supports the 8-bit MIME transport service extension
+ shall preserve all bits in each octet passed using the DATA command.
+
+ Naturally, the usual SMTP data-stuffing algorithm applies so that a
+ content which contains the five-character sequence of
+
+ <CR> <LF> <DOT> <CR> <LF>
+
+ or a content that begins with the three-character sequence of
+
+ <DOT> <CR> <LF>
+
+ does not prematurely terminate the transfer of the content. Further,
+ it should be noted that the CR-LF pair immediately preceeding the
+ final dot is considered part of the content. Finally, although the
+ content body contains arbitrary lines of octet-aligned material, the
+ length of each line (number of octets between two CR-LF pairs), is
+ still subject to SMTP server line length restrictions (which may
+ allow as few as 1000 octets on a single line). This restriction means
+ that this extension MAY provide the necessary facilities for
+ transferring a MIME object with the 8BIT content-transfer-encoding,
+ it DOES NOT provide a means of transferring an object with the BINARY
+ content-transfer-encoding.
+
+ Once a server SMTP supporting the 8bit-MIMEtransport service
+ extension accepts a content body containing octets with the high-
+ order (8th) bit set, the server SMTP must deliver or relay the
+ content in such a way as to preserve all bits in each octet.
+
+ If a server SMTP does not support the 8-bit MIME transport extension
+ (either by not responding with code 250 to the EHLO command, or by
+ not including the EHLO keyword value 8BITMIME in its response), then
+ the client SMTP must not, under any circumstances, attempt to
+ transfer a content which contains characters outside the US-ASCII
+ octet range (hex 00-7F).
+
+ A client SMTP has two options in this case: first, it may implement a
+ gateway transformation to convert the message into valid 7bit MIME,
+ or second, or may treat this as a permanent error and handle it in
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 3]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+ the usual manner for delivery failures. The specifics of the
+ transformation from 8bit MIME to 7bit MIME are not described by this
+ RFC; the conversion is nevertheless constrained in the following
+ ways:
+
+ (1) it must cause no loss of information; MIME transport
+ encodings must be employed as needed to insure this is
+ the case, and
+
+ (2) the resulting message must be valid 7bit MIME.
+
+4. Usage Example
+
+ The following dialogue illustrates the use of the 8bit-MIMEtransport
+ service extension:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250-dbc.mtview.ca.us says hello
+ S: 250 8BITMIME
+ C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
+ S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
+ C: RCPT TO:<mrose@dbc.mtview.ca.us>
+ S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
+ C: DATA
+ S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
+ ...
+ C: .
+ S: 250 OK
+ C: QUIT
+ S: 250 Goodbye
+
+5. Security Considerations
+
+ This RFC does not discuss security issues and is not believed to
+ raise any security issues not already endemic in electronic mail and
+ present in fully conforming implementations of [1].
+
+6. Acknowledgements
+
+ This document represents a synthesis of the ideas of many people and
+ reactions to the ideas and proposals of others. Randall Atkinson,
+ Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
+ and text sufficient to be considered co-authors. Other important
+ suggestions, text, or encouragement came from Harald Alvestrand, Jim
+ Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 4]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+ Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A.
+ Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John
+ Wagner, Rayan Zachariassen, and the contributions of the entire IETF
+ SMTP Working Group. Of course, none of the individuals are
+ necessarily responsible for the combination of ideas represented
+ here. Indeed, in some cases, the response to a particular criticism
+ was to accept the problem identification but to include an entirely
+ different solution from the one originally proposed.
+
+7. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+ Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
+
+ [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
+ Headers", RFC 1522, University of Tennessee, September 1993.
+
+ [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
+ "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
+ Consulting, Inc., Network Management Associates, Inc., Silicon
+ Graphics, Inc., July 1994.
+
+ [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+ 974, BBN, January 1986.
+
+8. Chair, Editor, and Authors' Addresses
+
+ John Klensin, WG Chair
+ MCI Data Services Division
+ 2100 Reston Parkway, 6th floor
+ Reston, VA 22091
+ USA
+
+ Phone:: 1 703 715 7361
+ Fax: +1 703 715 7435
+ EMail: klensin@mci.net
+
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 5]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+ Ned Freed, Editor
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+
+ Phone:: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Moutain View, CA 94043-2186
+ USA
+
+ Phone: +1 415 968 1052
+ Fax: +1 415 968 2510
+ EMail: mrose@dbc.mtview.ca.us
+
+
+ Einar A. Stefferud
+ Network Management Associates, Inc.
+ 17301 Drey Lane
+ Huntington Beach, CA, 92647-5615
+ USA
+
+ Phone: +1 714 842 3711
+ Fax: +1 714 848 2091
+ EMail: stef@nma.com
+
+
+ Dave Crocker
+ Silicon Graphics, Inc.
+ 2011 N. Shoreline Blvd.
+ P.O. Box 7311
+ Mountain View, CA 94039
+ USA
+
+ Phone: +1 415 390 1804
+ Fax: +1 415 962 8404
+ EMail: dcrocker@sgi.com
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 6]
+
diff --git a/Documentation/en/rfc/rfc1869.txt b/Documentation/en/rfc/rfc1869.txt
new file mode 100644
index 00000000..cd3506ec
--- /dev/null
+++ b/Documentation/en/rfc/rfc1869.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group J. Klensin, WG Chair
+Request For Comments: 1869 MCI
+STD: 10 N. Freed, Editor
+Obsoletes: 1651 Innosoft International, Inc.
+Category: Standards Track M. Rose
+ Dover Beach Consulting, Inc.
+ E. Stefferud
+ Network Management Associates, Inc.
+ D. Crocker
+ Brandenburg Consulting
+ November 1995
+
+
+ SMTP Service Extensions
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Abstract
+
+ This memo defines a framework for extending the SMTP service by
+ defining a means whereby a server SMTP can inform a client SMTP as to
+ the service extensions it supports. Extensions to the SMTP service
+ are registered with the IANA. This framework does not require
+ modification of existing SMTP clients or servers unless the features
+ of the service extensions are to be requested or provided.
+
+2. Introduction
+
+ The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable,
+ effective basis for the relay function of message transfer agents.
+ Although a decade old, SMTP has proven remarkably resilient.
+ Nevertheless, the need for a number of protocol extensions has become
+ evident. Rather than describing these extensions as separate and
+ haphazard entities, this document enhances SMTP in a straightforward
+ fashion that provides a framework in which all future extensions can
+ be built in a single consistent way.
+
+3. Framework for SMTP Extensions
+
+ For the purpose of service extensions to SMTP, SMTP relays a mail
+ object containing an envelope and a content.
+
+
+
+
+Klensin, et al Standards Track [Page 1]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ (1) The SMTP envelope is straightforward, and is sent as a
+ series of SMTP protocol units: it consists of an
+ originator address (to which error reports should be
+ directed); a delivery mode (e.g., deliver to recipient
+ mailboxes); and, one or more recipient addresses.
+
+ (2) The SMTP content is sent in the SMTP DATA protocol unit
+ and has two parts: the headers and the body. The
+ headers form a collection of field/value pairs
+ structured according to RFC 822 [2], whilst the body,
+ if structured, is defined according to MIME [3]. The
+ content is textual in nature, expressed using the US
+ ASCII repertoire (ANSI X3.4-1986). Although extensions
+ (such as MIME) may relax this restriction for the
+ content body, the content headers are always encoded
+ using the US ASCII repertoire. The algorithm defined in
+ [4] is used to represent header values outside the US
+ ASCII repertoire, whilst still encoding them using the
+ US ASCII repertoire.
+
+ Although SMTP is widely and robustly deployed, some parts of the
+ Internet community might wish to extend the SMTP service. This memo
+ defines a means whereby both an extended SMTP client and server may
+ recognize each other as such and the server can inform the client as
+ to the service extensions that it supports.
+
+ It must be emphasized that any extension to the SMTP service should
+ not be considered lightly. SMTP's strength comes primarily from its
+ simplicity. Experience with many protocols has shown that:
+
+ protocols with few options tend towards ubiquity, whilst
+ protocols with many options tend towards obscurity.
+
+ This means that each and every extension, regardless of its benefits,
+ must be carefully scrutinized with respect to its implementation,
+ deployment, and interoperability costs. In many cases, the cost of
+ extending the SMTP service will likely outweigh the benefit.
+
+ Given this environment, the framework for the extensions described in
+ this memo consists of:
+
+ (1) a new SMTP command (section 4)
+
+ (2) a registry of SMTP service extensions (section 5)
+
+ (3) additional parameters to the SMTP MAIL FROM and RCPT TO
+ commands (section 6).
+
+
+
+
+Klensin, et al Standards Track [Page 2]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+4. The EHLO command
+
+ A client SMTP supporting SMTP service extensions should start an SMTP
+ session by issuing the EHLO command instead of the HELO command. If
+ the SMTP server supports the SMTP service extensions it will give a
+ successful response (see section 4.3), a failure response (see 4.4),
+ or an error response (4.5). If the SMTP server does not support any
+ SMTP service extensions it will generate an error response (see
+ section 4.5).
+
+4.1. Changes to STD 10, RFC 821
+
+ This specification is intended to extend STD 10, RFC 821 without
+ impacting existing services in any way. The minor changes needed are
+ enumerated below.
+
+4.1.1. First command
+
+ RFC 821 states that the first command in an SMTP session must be the
+ HELO command. This requirement is hereby amended to allow a session
+ to start with either EHLO or HELO.
+
+4.1.2. Maximum command line length
+
+ This specification extends the SMTP MAIL FROM and RCPT TO to allow
+ additional parameters and parameter values. It is possible that the
+ MAIL FROM and RCPT TO lines that result will exceed the 512 character
+ limit on command line length imposed by RFC 821. This limit is
+ hereby amended to only apply to command lines without any parameters.
+ Each specification that defines new MAIL FROM or RCPT TO parameters
+ must also specify maximum parameter value lengths for each parameter
+ so that implementors of some set of extensions know how much buffer
+ space must be allocated. The maximum command length that must be
+ supported by an SMTP implementation with extensions is 512 plus the
+ sum of all the maximum parameter lengths for all the extensions
+ supported.
+
+4.2. Command syntax
+
+ The syntax for this command, using the ABNF notation of [2], is:
+
+ ehlo-cmd ::= "EHLO" SP domain CR LF
+
+ If successful, the server SMTP responds with code 250. On failure,
+ the server SMTP responds with code 550. On error, the server SMTP
+ responds with one of codes 500, 501, 502, 504, or 421.
+
+
+
+
+
+Klensin, et al Standards Track [Page 3]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ This command is issued instead of the HELO command, and may be issued
+ at any time that a HELO command would be appropriate. That is, if
+ the EHLO command is issued, and a successful response is returned,
+ then a subsequent HELO or EHLO command will result in the server SMTP
+ replying with code 503. A client SMTP must not cache any information
+ returned if the EHLO command succeeds. That is, a client SMTP must
+ issue the EHLO command at the start of each SMTP session if
+ information about extended facilities is needed.
+
+4.3. Successful response
+
+ If the server SMTP implements and is able to perform the EHLO
+ command, it will return code 250. This indicates that both the
+ server and client SMTP are in the initial state, that is, there is no
+ transaction in progress and all state tables and buffers are cleared.
+
+ Normally, this response will be a multiline reply. Each line of the
+ response contains a keyword and, optionally, one or more parameters.
+ The syntax for a positive response, using the ABNF notation of [2],
+ is:
+
+ ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF
+ / ( "250-" domain [ SP greeting ] CR LF
+ *( "250-" ehlo-line CR LF )
+ "250" SP ehlo-line CR LF )
+
+ ; the usual HELO chit-chat
+ greeting ::= 1*<any character other than CR or LF>
+
+ ehlo-line ::= ehlo-keyword *( SP ehlo-param )
+
+ ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+ ; syntax and values depend on ehlo-keyword
+ ehlo-param ::= 1*<any CHAR excluding SP and all
+ control characters (US ASCII 0-31
+ inclusive)>
+
+ ALPHA ::= <any one of the 52 alphabetic characters
+ (A through Z in upper case, and,
+ a through z in lower case)>
+ DIGIT ::= <any one of the 10 numeric characters
+ (0 through 9)>
+
+ CR ::= <the carriage-return character
+ (ASCII decimal code 13)>
+ LF ::= <the line-feed character
+ (ASCII decimal code 10)>
+
+
+
+Klensin, et al Standards Track [Page 4]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ SP ::= <the space character
+ (ASCII decimal code 32)>
+
+ Although EHLO keywords may be specified in upper, lower, or mixed
+ case, they must always be recognized and processed in a case-
+ insensitive manner. This is simply an extension of practices begun in
+ RFC 821.
+
+ The IANA maintains a registry of SMTP service extensions. Associated
+ with each such extension is a corresponding EHLO keyword value. Each
+ service extension registered with the IANA must be defined in an RFC.
+ Such RFCs must either be on the standards-track or must define an
+ IESG-approved experimental protocol. The definition must include:
+
+ (1) the textual name of the SMTP service extension;
+
+ (2) the EHLO keyword value associated with the extension;
+
+ (3) the syntax and possible values of parameters associated
+ with the EHLO keyword value;
+
+ (4) any additional SMTP verbs associated with the extension
+ (additional verbs will usually be, but are not required
+ to be, the same as the EHLO keyword value);
+
+ (5) any new parameters the extension associates with the
+ MAIL FROM or RCPT TO verbs;
+
+ (6) how support for the extension affects the behavior of a
+ server and client SMTP; and,
+
+ (7) the increment by which the extension is increasing the
+ maximum length of the commands MAIL FROM, RCPT TO, or
+ both, over that specified in RFC 821.
+
+ In addition, any EHLO keyword value that starts with an upper or
+ lower case "X" refers to a local SMTP service extension, which is
+ used through bilateral, rather than standardized, agreement. Keywords
+ beginning with "X" may not be used in a registered service extension.
+
+ Any keyword values presented in the EHLO response that do not begin
+ with "X" must correspond to a standard, standards-track, or IESG-
+ approved experimental SMTP service extension registered with IANA. A
+ conforming server must not offer non "X" prefixed keyword values that
+ are not described in a registered extension.
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 5]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ Additional verbs are bound by the same rules as EHLO keywords;
+ specifically, verbs begining with "X" are local extensions that may
+ not be registered or standardized and verbs not beginning with "X"
+ must always be registered.
+
+4.4. Failure response
+
+ If for some reason the server SMTP is unable to list the service
+ extensions it supports, it will return code 554.
+
+ In the case of a failure response, the client SMTP should issue
+ either the HELO or QUIT command.
+
+4.5. Error responses from extended servers
+
+ If the server SMTP recognizes the EHLO command, but the command
+ argument is unacceptable, it will return code 501.
+
+ If the server SMTP recognizes, but does not implement, the EHLO
+ command, it will return code 502.
+
+ If the server SMTP determines that the SMTP service is no longer
+ available (e.g., due to imminent system shutdown), it will return
+ code 421.
+
+ In the case of any error response, the client SMTP should issue
+ either the HELO or QUIT command.
+
+4.6. Responses from servers without extensions
+
+ A server SMTP that conforms to RFC 821 but does not support the
+ extensions specified here will not recognize the EHLO command and
+ will consequently return code 500, as specified in RFC 821. The
+ server SMTP should stay in the same state after returning this code
+ (see section 4.1.1 of RFC 821). The client SMTP may then issue
+ either a HELO or a QUIT command.
+
+4.7. Responses from improperly implemented servers
+
+ Some SMTP servers are known to disconnect the SMTP transmission
+ channel upon receipt of the EHLO command. The disconnect can occur
+ immediately or after sending a response. Such behavior violates
+ section 4.1.1 of RFC 821, which explicitly states that disconnection
+ should only occur after a QUIT command is issued.
+
+ Nevertheless, in order to achieve maxmimum interoperablity it is
+ suggested that extended SMTP clients using EHLO be coded to check for
+ server connection closure after EHLO is sent, either before or after
+
+
+
+Klensin, et al Standards Track [Page 6]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ returning a reply. If this happens the client must decide if the
+ operation can be successfully completed without using any SMTP
+ extensions. If it can a new connection can be opened and the HELO
+ command can be used.
+
+ Other improperly-implemented servers will not accept a HELO command
+ after EHLO has been sent and rejected. In some cases, this problem
+ can be worked around by sending a RSET after the failure response to
+ EHLO, then sending the HELO. Clients that do this should be aware
+ that many implementations will return a failure code (e.g., 503 Bad
+ sequence of commands) in response to the RSET. This code can be
+ safely ignored.
+
+5. Initial IANA Registry
+
+ The IANA's initial registry of SMTP service extensions consists of
+ these entries:
+
+ Service Ext EHLO Keyword Parameters Verb Added Behavior
+ ------------- ------------ ---------- ---------- ------------------
+ Send SEND none SEND defined in RFC 821
+ Send or Mail SOML none SOML defined in RFC 821
+ Send and Mail SAML none SAML defined in RFC 821
+ Expand EXPN none EXPN defined in RFC 821
+ Help HELP none HELP defined in RFC 821
+ Turn TURN none TURN defined in RFC 821
+
+ which correspond to those SMTP commands which are defined as optional
+ in [5]. (The mandatory SMTP commands, according to [5], are HELO,
+ MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.)
+
+6. MAIL FROM and RCPT TO Parameters
+
+ It is recognized that several of the extensions planned for SMTP will
+ make use of additional parameters associated with the MAIL FROM and
+ RCPT TO command. The syntax for these commands, again using the ABNF
+ notation of [2] as well as underlying definitions from [1], is:
+
+ esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF
+ esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter)
+ esmtp-parameter ::= esmtp-keyword ["=" esmtp-value]
+ esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+ ; syntax and values depend on esmtp-keyword
+ esmtp-value ::= 1*<any CHAR excluding "=", SP, and all
+ control characters (US ASCII 0-31
+ inclusive)>
+
+
+
+
+Klensin, et al Standards Track [Page 7]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ ; The following commands are extended to
+ ; accept extended parameters.
+ inner-esmtp-cmd ::= ("MAIL FROM:" reverse-path) /
+ ("RCPT TO:" forward-path)
+
+ All esmtp-keyword values must be registered as part of the IANA
+ registration process described above. This definition only provides
+ the framework for future extension; no extended MAIL FROM or RCPT TO
+ parameters are defined by this RFC.
+
+6.1. Error responses
+
+ If the server SMTP does not recognize or cannot implement one or more
+ of the parameters associated with a particular MAIL FROM or RCPT TO
+ command, it will return code 555.
+
+ If for some reason the server is temporarily unable to accomodate one
+ or more of the parameters associated with a MAIL FROM or RCPT TO
+ command, and if the definition of the specific parameter does not
+ mandate the use of another code, it should return code 455.
+
+ Errors specific to particular parameters and their values will be
+ specified in the parameter's defining RFC.
+
+7. Received: Header Field Annotation
+
+ SMTP servers are required to add an appropriate Received: field to
+ the headers of all messages they receive. A "with ESMTP" clause
+ should be added to this field when any SMTP service extensions are
+ used. "ESMTP" is hereby added to the list of standard protocol names
+ registered with IANA.
+
+8. Usage Examples
+
+ (1) An interaction of the form:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250 dbc.mtview.ca.us says hello
+ ...
+
+ indicates that the server SMTP implements only those
+ SMTP commands which are defined as mandatory in [5].
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 8]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ (2) In contrast, an interaction of the form:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250-dbc.mtview.ca.us says hello
+ S: 250-EXPN
+ S: 250-HELP
+ S: 250-8BITMIME
+ S: 250-XONE
+ S: 250 XVRB
+ ...
+
+ indicates that the server SMTP also implements the SMTP
+ EXPN and HELP commands, one standard service extension
+ (8BITMIME), and two nonstandard and unregistered
+ service extensions (XONE and XVRB).
+
+ (3) Finally, a server that does not support SMTP service
+ extensions would act as follows:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 500 Command not recognized: EHLO
+ ...
+
+ The 500 response indicates that the server SMTP does
+ not implement the extensions specified here. The
+ client would normally send a HELO command and proceed
+ as specified in RFC 821. See section 4.7 for
+ additional discussion.
+
+9. Security Considerations
+
+ This RFC does not discuss security issues and is not believed to
+ raise any security issues not already endemic in electronic mail and
+ present in fully conforming implementations of RFC-821. It does
+ provide an announcement of server mail capabilities via the response
+ to the EHLO verb. However, all information provided by announcement
+ of any of the initial set of service extensions defined by this RFC
+ can be readily deduced by selective probing of the verbs required to
+ transport and deliver mail. The security implications of service
+ extensions described in other RFCs should be dealt with in those
+ RFCs.
+
+
+
+
+Klensin, et al Standards Track [Page 9]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+10. Acknowledgements
+
+ This document represents a synthesis of the ideas of many people and
+ reactions to the ideas and proposals of others. Randall Atkinson,
+ Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
+ and text sufficient to be considered co-authors. Other important
+ suggestions, text, or encouragement came from Harald Alvestrand, Jim
+ Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per
+ Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A.
+ Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan
+ Zachariassen, and the contributions of the entire IETF SMTP Working
+ Group. Of course, none of the individuals are necessarily responsible
+ for the combination of ideas represented here. Indeed, in some cases,
+ the response to a particular criticism was to accept the problem
+ identification but to include an entirely different solution from the
+ one originally proposed.
+
+11. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+ Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
+
+ [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
+ Headers", RFC 1522, University of Tennessee, September 1993.
+
+ [5] Braden, R., "Requirements for Internet Hosts - Application and
+ Support", STD 3, RFC 1123, USC/Information Sciences Institute,
+ October 1989.
+
+12. Chair, Editor, and Author Addresses
+
+ John Klensin, WG Chair
+ MCI
+ 2100 Reston Parkway
+ Reston, VA 22091
+
+ Phone: +1 703 715-7361
+ Fax: +1 703 715-7436
+ EMail: klensin@mci.net
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 10]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ Ned Freed, Editor
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Moutain View, CA 94043-2186
+ USA
+
+ Phone: +1 415 968 1052
+ Fax: +1 415 968 2510
+ EMail: mrose@dbc.mtview.ca.us
+
+
+ Einar A. Stefferud
+ Network Management Associates, Inc.
+ 17301 Drey Lane
+ Huntington Beach, CA, 92647-5615
+ USA
+
+ Phone: +1 714 842 3711
+ Fax: +1 714 848 2091
+ EMail: stef@nma.com
+
+
+ Dave Crocker
+ Brandenburg Consulting
+ 675 Spruce Dr.
+ Sunnyvale, CA 94086 USA
+ USA
+
+ Phone: +1 408 246 8253
+ Fax: +1 408 249 6205
+ EMail: dcrocker@mordor.stanford.edu
+
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 11]
+
diff --git a/Documentation/en/rfc/rfc1891.txt b/Documentation/en/rfc/rfc1891.txt
new file mode 100644
index 00000000..23b58ba9
--- /dev/null
+++ b/Documentation/en/rfc/rfc1891.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group K. Moore
+Request for Comments: 1891 University of Tennessee
+Category: Standards Track January 1996
+
+
+ SMTP Service Extension
+ for Delivery Status Notifications
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Abstract
+
+ This memo defines an extension to the SMTP service, which allows an
+ SMTP client to specify (a) that delivery status notifications (DSNs)
+ should be generated under certain conditions, (b) whether such
+ notifications should return the contents of the message, and (c)
+ additional information, to be returned with a DSN, that allows the
+ sender to identify both the recipient(s) for which the DSN was
+ issued, and the transaction in which the original message was sent.
+
+ Any questions, comments, and reports of defects or ambiguities in
+ this specification may be sent to the mailing list for the NOTARY
+ working group of the IETF, using the address
+ <notifications@cs.utk.edu>. Requests to subscribe to the mailing
+ list should be addressed to <notifications-request@cs.utk.edu>.
+ Implementors of this specification are encouraged to subscribe to the
+ mailing list, so that they will quickly be informed of any problems
+ which might hinder interoperability.
+
+ NOTE: This document is a Proposed Standard. If and when this
+ protocol is submitted for Draft Standard status, any normative text
+ (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in
+ this document will be re-evaluated in light of implementation
+ experience, and are thus subject to change.
+
+2. Introduction
+
+ The SMTP protocol [1] requires that an SMTP server provide
+ notification of delivery failure, if it determines that a message
+ cannot be delivered to one or more recipients. Traditionally, such
+ notification consists of an ordinary Internet mail message (format
+ defined by [2]), sent to the envelope sender address (the argument of
+
+
+
+Moore Standards Track [Page 1]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ the SMTP MAIL command), containing an explanation of the error and at
+ least the headers of the failed message.
+
+ Experience with large mail distribution lists [3] indicates that such
+ messages are often insufficient to diagnose problems, or even to
+ determine at which host or for which recipients a problem occurred.
+ In addition, the lack of a standardized format for delivery
+ notifications in Internet mail makes it difficult to exchange such
+ notifications with other message handling systems.
+
+ Such experience has demonstrated a need for a delivery status
+ notification service for Internet electronic mail, which:
+
+(a) is reliable, in the sense that any DSN request will either be
+ honored at the time of final delivery, or result in a response
+ that indicates that the request cannot be honored,
+
+(b) when both success and failure notifications are requested,
+ provides an unambiguous and nonconflicting indication of whether
+ delivery of a message to a recipient succeeded or failed,
+
+(c) is stable, in that a failed attempt to deliver a DSN should never
+ result in the transmission of another DSN over the network,
+
+(d) preserves sufficient information to allow the sender to identify
+ both the mail transaction and the recipient address which caused
+ the notification, even when mail is forwarded or gatewayed to
+ foreign environments, and
+
+(e) interfaces acceptably with non-SMTP and non-822-based mail
+ systems, both so that notifications returned from foreign mail
+ systems may be useful to Internet users, and so that the
+ notification requests from foreign environments may be honored.
+ Among the requirements implied by this goal are the ability to
+ request non-return-of-content, and the ability to specify whether
+ positive delivery notifications, negative delivery notifications,
+ both, or neither, should be issued.
+
+ In an attempt to provide such a service, this memo uses the mechanism
+ defined in [4] to define an extension to the SMTP protocol. Using
+ this mechanism, an SMTP client may request that an SMTP server issue
+ or not issue a delivery status notification (DSN) under certain
+ conditions. The format of a DSN is defined in [5].
+
+
+
+
+
+
+
+
+Moore Standards Track [Page 2]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+3. Framework for the Delivery Status Notification Extension
+
+ The following service extension is therefore defined:
+
+(1) The name of the SMTP service extension is "Delivery Status
+ Notification";
+
+(2) the EHLO keyword value associated with this extension is "DSN",
+ the meaning of which is defined in section 4 of this memo;
+
+(3) no parameters are allowed with this EHLO keyword value;
+
+(4) two optional parameters are added to the RCPT command, and two
+ optional parameters are added to the MAIL command:
+
+ An optional parameter for the RCPT command, using the
+ esmtp-keyword "NOTIFY", (to specify the conditions under which a
+ delivery status notification should be generated), is defined in
+ section 5.1,
+
+ An optional parameter for the RCPT command, using the
+ esmtp-keyword "ORCPT", (used to convey the "original"
+ (sender-specified) recipient address), is defined in section 5.2,
+ and
+
+ An optional parameter for the MAIL command, using the
+ esmtp-keyword "RET", (to request that DSNs containing an
+ indication of delivery failure either return the entire contents
+ of a message or only the message headers), is defined in section
+ 5.3,
+
+ An optional parameter for the MAIL command, using the
+ esmtp-keyword "ENVID", (used to propagate an identifier for this
+ message transmission envelope, which is also known to the sender
+ and will, if present, be returned in any DSNs issued for this
+ transmission), is defined in section 5.4;
+
+(5) no additional SMTP verbs are defined by this extension.
+
+ The remainder of this memo specifies how support for the extension
+ effects the behavior of a message transfer agent.
+
+4. The Delivery Status Notification service extension
+
+ An SMTP client wishing to request a DSN for a message may issue the
+ EHLO command to start an SMTP session, to determine if the server
+ supports any of several service extensions. If the server responds
+ with code 250 to the EHLO command, and the response includes the EHLO
+
+
+
+Moore Standards Track [Page 3]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ keyword DSN, then the Delivery Status Notification extension (as
+ described in this memo) is supported.
+
+ Ordinarily, when an SMTP server returns a positive (2xx) reply code
+ in response to a RCPT command, it agrees to accept responsibility for
+ either delivering the message to the named recipient, or sending a
+ notification to the sender of the message indicating that delivery
+ has failed. However, an extended SMTP ("ESMTP") server which
+ implements this service extension will accept an optional NOTIFY
+ parameter with the RCPT command. If present, the NOTIFY parameter
+ alters the conditions for generation of delivery status notifications
+ from the default (issue notifications only on failure) specified in
+ [1]. The ESMTP client may also request (via the RET parameter)
+ whether the entire contents of the original message should be
+ returned (as opposed to just the headers of that message), along with
+ the DSN.
+
+ In general, an ESMTP server which implements this service extension
+ will propagate delivery status notification requests when relaying
+ mail to other SMTP-based MTAs which also support this extension, and
+ make a "best effort" to ensure that such requests are honored when
+ messages are passed into other environments.
+
+ In order that any delivery status notifications thus generated will
+ be meaningful to the sender, any ESMTP server which supports this
+ extension will attempt to propagate the following information to any
+ other MTAs that are used to relay the message, for use in generating
+ DSNs:
+
+(a) for each recipient, a copy of the original recipient address, as
+ used by the sender of the message.
+
+ This address need not be the same as the mailbox specified in the
+ RCPT command. For example, if a message was originally addressed
+ to A@B.C and later forwarded to A@D.E, after such forwarding has
+ taken place, the RCPT command will specify a mailbox of A@D.E.
+ However, the original recipient address remains A@B.C.
+
+ Also, if the message originated from an environment which does not
+ use Internet-style user@domain addresses, and was gatewayed into
+ SMTP, the original recipient address will preserve the original
+ form of the recipient address.
+
+(b) for the entire SMTP transaction, an envelope identification
+ string, which may be used by the sender to associate any delivery
+ status notifications with the transaction used to send the
+ original message.
+
+
+
+
+Moore Standards Track [Page 4]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+5. Additional parameters for RCPT and MAIL commands
+
+ The extended RCPT and MAIL commands are issued by a client when it
+ wishes to request a DSN from the server, under certain conditions,
+ for a particular recipient. The extended RCPT and MAIL commands are
+ identical to the RCPT and MAIL commands defined in [1], except that
+ one or more of the following parameters appear after the sender or
+ recipient address, respectively. The general syntax for extended
+ SMTP commands is defined in [4].
+
+ NOTE: Although RFC 822 ABNF is used to describe the syntax of these
+ parameters, they are not, in the language of that document,
+ "structured field bodies". Therefore, while parentheses MAY appear
+ within an emstp-value, they are not recognized as comment delimiters.
+
+ The syntax for "esmtp-value" in [4] does not allow SP, "=", control
+ characters, or characters outside the traditional ASCII range of 1-
+ 127 decimal to be transmitted in an esmtp-value. Because the ENVID
+ and ORCPT parameters may need to convey values outside this range,
+ the esmtp-values for these parameters are encoded as "xtext".
+ "xtext" is formally defined as follows:
+
+ xtext = *( xchar / hexchar )
+
+ xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
+ except for "+" and "=".
+
+; "hexchar"s are intended to encode octets that cannot appear
+; as ASCII characters within an esmtp-value.
+
+ hexchar = ASCII "+" immediately followed by two upper case
+ hexadecimal digits
+
+When encoding an octet sequence as xtext:
+
++ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=",
+ MAY be encoded as itself. (A CHAR in this range MAY instead be
+ encoded as a "hexchar", at the implementor's discretion.)
+
++ ASCII CHARs that fall outside the range above must be encoded as
+ "hexchar".
+
+5.1 The NOTIFY parameter of the ESMTP RCPT command
+
+ A RCPT command issued by a client may contain the optional esmtp-
+ keyword "NOTIFY", to specify the conditions under which the SMTP
+ server should generate DSNs for that recipient. If the NOTIFY
+ esmtp-keyword is used, it MUST have an associated esmtp-value,
+
+
+
+Moore Standards Track [Page 5]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ formatted according to the following rules, using the ABNF of RFC
+ 822:
+
+ notify-esmtp-value = "NEVER" / 1#notify-list-element
+
+ notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"
+
+Notes:
+
+a. Multiple notify-list-elements, separated by commas, MAY appear in a
+ NOTIFY parameter; however, the NEVER keyword MUST appear by itself.
+
+b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled
+ in any combination of upper and lower case letters.
+
+The meaning of the NOTIFY parameter values is generally as follows:
+
++ A NOTIFY parameter value of "NEVER" requests that a DSN not be
+ returned to the sender under any conditions.
+
++ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE"
+ keywords requests that a DSN be issued on successful delivery or
+ delivery failure, respectively.
+
++ A NOTIFY parameter value containing the keyword "DELAY" indicates the
+ sender's willingness to receive "delayed" DSNs. Delayed DSNs may be
+ issued if delivery of a message has been delayed for an unusual amount
+ of time (as determined by the MTA at which the message is delayed),
+ but the final delivery status (whether successful or failure) cannot
+ be determined. The absence of the DELAY keyword in a NOTIFY parameter
+ requests that a "delayed" DSN NOT be issued under any conditions.
+
+ The actual rules governing interpretation of the NOTIFY parameter are
+ given in section 6.
+
+ For compatibility with SMTP clients that do not use the NOTIFY
+ facility, the absence of a NOTIFY parameter in a RCPT command may be
+ interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.
+
+5.2 The ORCPT parameter to the ESMTP RCPT command
+
+ The ORCPT esmtp-keyword of the RCPT command is used to specify an
+ "original" recipient address that corresponds to the actual recipient
+ to which the message is to be delivered. If the ORCPT esmtp-keyword
+ is used, it MUST have an associated esmtp-value, which consists of
+ the original recipient address, encoded according to the rules below.
+ The ABNF for the ORCPT parameter is:
+
+
+
+
+Moore Standards Track [Page 6]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ orcpt-parameter = "ORCPT=" original-recipient-address
+
+ original-recipient-address = addr-type ";" xtext
+
+ addr-type = atom
+
+ The "addr-type" portion MUST be an IANA-registered electronic mail
+ address-type (as defined in [5]), while the "xtext" portion contains
+ an encoded representation of the original recipient address using the
+ rules in section 5 of this document. The entire ORCPT parameter MAY
+ be up to 500 characters in length.
+
+ When initially submitting a message via SMTP, if the ORCPT parameter
+ is used, it MUST contain the same address as the RCPT TO address
+ (unlike the RCPT TO address, the ORCPT parameter will be encoded as
+ xtext). Likewise, when a mailing list submits a message via SMTP to
+ be distributed to the list subscribers, if ORCPT is used, the ORCPT
+ parameter MUST match the new RCPT TO address of each recipient, not
+ the address specified by the original sender of the message.)
+
+ The "addr-type" portion of the original-recipient-address is used to
+ indicate the "type" of the address which appears in the ORCPT
+ parameter value. However, the address associated with the ORCPT
+ keyword is NOT constrained to conform to the syntax rules for that
+ "addr-type".
+
+ Ideally, the "xtext" portion of the original-recipient-address should
+ contain, in encoded form, the same sequence of characters that the
+ sender used to specify the recipient. However, for a message
+ gatewayed from an environment (such as X.400) in which a recipient
+ address is not a simple string of printable characters, the
+ representation of recipient address must be defined by a
+ specification for gatewaying between DSNs and that environment.
+
+5.3 The RET parameter of the ESMTP MAIL command
+
+ The RET esmtp-keyword on the extended MAIL command specifies whether
+ or not the message should be included in any failed DSN issued for
+ this message transmission. If the RET esmtp-keyword is used, it MUST
+ have an associated esmtp-value, which is one of the following
+ keywords:
+
+ FULL requests that the entire message be returned in any "failed"
+ delivery status notification issued for this recipient.
+
+ HDRS requests that only the headers of the message be returned.
+
+
+
+
+
+Moore Standards Track [Page 7]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ The FULL and HDRS keywords may be spelled in any combination of upper
+ and lower case letters.
+
+ If no RET parameter is supplied, the MTA MAY return either the
+ headers of the message or the entire message for any DSN containing
+ indication of failed deliveries.
+
+ Note that the RET parameter only applies to DSNs that indicate
+ delivery failure for at least one recipient. If a DSN contains no
+ indications of delivery failure, only the headers of the message
+ should be returned.
+
+5.4 The ENVID parameter to the ESMTP MAIL command
+
+ The ENVID esmtp-keyword of the SMTP MAIL command is used to specify
+ an "envelope identifier" to be transmitted along with the message and
+ included in any DSNs issued for any of the recipients named in this
+ SMTP transaction. The purpose of the envelope identifier is to allow
+ the sender of a message to identify the transaction for which the DSN
+ was issued.
+
+ The ABNF for the ENVID parameter is:
+
+ envid-parameter = "ENVID=" xtext
+
+ The ENVID esmtp-keyword MUST have an associated esmtp-value. No
+ meaning is assigned by the mail system to the presence or absence of
+ this parameter or to any esmtp-value associated with this parameter;
+ the information is used only by the sender or his user agent. The
+ ENVID parameter MAY be up to 100 characters in length.
+
+5.5 Restrictions on the use of Delivery Status Notification parameters
+
+ The RET and ENVID parameters MUST NOT appear more than once each in
+ any single MAIL command. If more than one of either of these
+ parameters appears in a MAIL command, the ESMTP server SHOULD respond
+ with "501 syntax error in parameters or arguments".
+
+ The NOTIFY and ORCPT parameters MUST NOT appear more than once in any
+ RCPT command. If more than one of either of these parameters appears
+ in a RCPT command, the ESMTP server SHOULD respond with "501 syntax
+ error in parameters or arguments".
+
+6. Conformance requirements
+
+ The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer
+ Agents (MTAs) when accepting, relaying, or gatewaying mail, as well
+ as User Agents (UAs) when submitting mail to the mail transport
+
+
+
+Moore Standards Track [Page 8]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ system. The DSN extension to SMTP may be used to allow UAs to convey
+ the sender's requests as to when DSNs should be issued. A UA which
+ claims to conform to this specification must meet certain
+ requirements as described below.
+
+ Typically, a message transfer agent (MTA) which supports SMTP will
+ assume, at different times, both the role of a SMTP client and an
+ SMTP server, and may also provide local delivery, gatewaying to
+ foreign environments, forwarding, and mailing list expansion. An MTA
+ which, when acting as an SMTP server, issues the DSN keyword in
+ response to the EHLO command, MUST obey the rules below for a
+ "conforming SMTP client" when acting as a client, and a "conforming
+ SMTP server" when acting as a server. The term "conforming MTA"
+ refers to an MTA which conforms to this specification, independent of
+ its role of client or server.
+
+6.1 SMTP protocol interactions
+
+ The following rules apply to SMTP transactions in which any of the
+ ENVID, NOTIFY, RET, or ORCPT keywords are used:
+
+(a) If an SMTP client issues a MAIL command containing a valid ENVID
+ parameter and associated esmtp-value and/or a valid RET parameter
+ and associated esmtp-value, a conforming SMTP server MUST return
+ the same reply-code as it would to the same MAIL command without
+ the ENVID and/or RET parameters. A conforming SMTP server MUST
+ NOT refuse a MAIL command based on the absence or presence of
+ valid ENVID or RET parameters, or on their associated
+ esmtp-values.
+
+ However, if the associated esmtp-value is not valid (i.e. contains
+ illegal characters), or if there is more than one ENVID or RET
+ parameter in a particular MAIL command, the server MUST issue the
+ reply-code 501 with an appropriate message (e.g. "syntax error in
+ parameter").
+
+(b) If an SMTP client issues a RCPT command containing any valid
+ NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST
+ return the same response as it would to the same RCPT command
+ without those NOTIFY and/or ORCPT parameters. A conforming SMTP
+ server MUST NOT refuse a RCPT command based on the presence or
+ absence of any of these parameters.
+
+ However, if any of the associated esmtp-values are not valid, or
+ if there is more than one of any of these parameters in a
+ particular RCPT command, the server SHOULD issue the response "501
+ syntax error in parameter".
+
+
+
+
+Moore Standards Track [Page 9]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+6.2 Handling of messages received via SMTP
+
+ This section describes how a conforming MTA should handle any
+ messages received via SMTP.
+
+ NOTE: A DSN MUST NOT be returned to the sender for any message for
+ which the return address from the SMTP MAIL command was NULL ("<>"),
+ even if the sender's address is available from other sources (e.g.
+ the message header). However, the MTA which would otherwise issue a
+ DSN SHOULD inform the local postmaster of delivery failures through
+ some appropriate mechanism that will not itself result in the
+ generation of DSNs.
+
+ DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to
+ be sent with a NULL return address ("reverse-path"). This creates an
+ interesting situation when a message arrives with one or more
+ nonfunctional recipient addresses in addition to a nonfunctional
+ return address. When delivery to one of the recipient addresses
+ fails, the MTA will attempt to send a nondelivery notification to the
+ return address, setting the return address on the notification to
+ NULL. When the delivery of this notification fails, the MTA
+ attempting delivery of that notification sees a NULL return address.
+ If that MTA were not to inform anyone of the situation, the original
+ message would be silently lost. Furthermore, a nonfunctional return
+ address is often indicative of a configuration problem in the
+ sender's MTA. Reporting the condition to the local postmaster may
+ help to speed correction of such errors.
+
+6.2.1 Relay of messages to other conforming SMTP servers
+
+ The following rules govern the behavior of a conforming MTA, when
+ relaying a message which was received via the SMTP protocol, to an
+ SMTP server that supports the Delivery Status Notification service
+ extension:
+
+(a) Any ENVID parameter included in the MAIL command when a message was
+ received, MUST also appear on the MAIL command with which the
+ message is relayed, with the same associated esmtp-value. If no
+ ENVID parameter was included in the MAIL command when the message
+ was received, the ENVID parameter MUST NOT be supplied when the
+ message is relayed.
+
+(b) Any RET parameter included in the MAIL command when a message was
+ received, MUST also appear on the MAIL command with which the
+ message is relayed, with the same associated esmtp-value. If no RET
+ parameter was included in the MAIL command when the message was
+ received, the RET parameter MUST NOT supplied when the message is
+ relayed.
+
+
+
+Moore Standards Track [Page 10]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+(c) If the NOTIFY parameter was supplied for a recipient when the
+ message was received, the RCPT command issued when the message is
+ relayed MUST also contain the NOTIFY parameter along with its
+ associated esmtp-value. If the NOTIFY parameter was not supplied
+ for a recipient when the message was received, the NOTIFY parameter
+ MUST NOT be supplied for that recipient when the message is relayed.
+
+(d) If any ORCPT parameter was present in the RCPT command for a
+ recipient when the message was received, an ORCPT parameter with the
+ identical original-recipient-address MUST appear in the RCPT command
+ issued for that recipient when relaying the message. (For example,
+ the MTA therefore MUST NOT change the case of any alphabetic
+ characters in an ORCPT parameter.)
+
+ If no ORCPT parameter was present in the RCPT command when the
+ message was received, an ORCPT parameter MAY be added to the RCPT
+ command when the message is relayed. If an ORCPT parameter is added
+ by the relaying MTA, it MUST contain the recipient address from the
+ RCPT command used when the message was received by that MTA.
+
+6.2.2 Relay of messages to non-conforming SMTP servers
+
+ The following rules govern the behavior of a conforming MTA (in the
+ role of client), when relaying a message which was received via the
+ SMTP protocol, to an SMTP server that does not support the Delivery
+ Status Notification service extension:
+
+(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when
+ relaying the message.
+
+(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp-
+ value containing the keyword SUCCESS, and the SMTP server returns a
+ success (2xx) reply-code in response to the RCPT command, the client
+ MUST issue a "relayed" DSN for that recipient.
+
+(c) If the NOTIFY parameter was supplied for a recipient with an esmtp-
+ value containing the keyword FAILURE, and the SMTP server returns a
+ permanent failure (5xx) reply-code in response to the RCPT command,
+ the client MUST issue a "failed" DSN for that recipient.
+
+(d) If the NOTIFY parameter was supplied for a recipient with an esmtp-
+ value of NEVER, the client MUST NOT issue a DSN for that recipient,
+ regardless of the reply-code returned by the SMTP server. However,
+ if the server returned a failure (5xx) reply-code, the client MAY
+ inform the local postmaster of the delivery failure via an
+ appropriate mechanism that will not itself result in the generation
+ of DSNs.
+
+
+
+
+Moore Standards Track [Page 11]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ When attempting to relay a message to an SMTP server that does not
+ support this extension, and if NOTIFY=NEVER was specified for some
+ recipients of that message, a conforming SMTP client MAY relay the
+ message for those recipients in a separate SMTP transaction, using
+ an empty reverse-path in the MAIL command. This will prevent DSNs
+ from being issued for those recipients by MTAs that conform to [1].
+
+(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP
+ server returns a success (2xx) reply-code in response to a RCPT
+ command, the client MUST NOT issue any DSN for that recipient.
+
+(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP
+ server returns a permanent failure (5xx) reply-code in response to a
+ RCPT command, the client MUST issue a "failed" DSN for that
+ recipient.
+
+6.2.3 Local delivery of messages
+
+ The following rules govern the behavior of a conforming MTA upon
+ successful delivery of a message that was received via the SMTP
+ protocol, to a local recipient's mailbox:
+
+ "Delivery" means that the message has been placed in the recipient's
+ mailbox. For messages which are transmitted to a mailbox for later
+ retrieval via IMAP [6], POP [7] or a similar message access protocol,
+ "delivery" occurs when the message is made available to the IMAP
+ (POP, etc.) service, rather than when the message is retrieved by the
+ recipient's user agent.
+
+ Similarly, for a recipient address which corresponds to a mailing
+ list exploder, "delivery" occurs when the message is made available
+ to that list exploder, even though the list exploder might refuse to
+ deliver that message to the list recipients.
+
+(a) If the NOTIFY parameter was supplied for that recipient, with an
+ esmtp-value containing the SUCCESS keyword, the MTA MUST issue a
+ "delivered" DSN for that recipient.
+
+(b) If the NOTIFY parameter was supplied for that recipient which did
+ not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for
+ that recipient.
+
+(c) If the NOTIFY parameter was not supplied for that recipient, the MTA
+ MUST NOT issue a DSN.
+
+
+
+
+
+
+
+Moore Standards Track [Page 12]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+6.2.4 Gatewaying a message into a foreign environment
+
+ The following rules govern the behavior of a conforming MTA, when
+ gatewaying a message that was received via the SMTP protocol, into a
+ foreign (non-SMTP) environment:
+
+(a) If the the foreign environment is capable of issuing appropriate
+ notifications under the conditions requested by the NOTIFY
+ parameter, and the conforming MTA can ensure that any notification
+ thus issued will be translated into a DSN and delivered to the
+ original sender, then the MTA SHOULD gateway the message into the
+ foreign environment, requesting notification under the desired
+ conditions, without itself issuing a DSN.
+
+(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the
+ destination environment cannot return an appropriate notification on
+ successful delivery, the MTA SHOULD issue a "relayed" DSN for that
+ recipient.
+
+(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a
+ DSN MUST NOT be issued. If possible, the MTA SHOULD direct the
+ destination environment to not issue delivery notifications for that
+ recipient.
+
+(d) If the NOTIFY parameter was not supplied for a particular recipient,
+ a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD
+ attempt to ensure that appropriate notification will be provided by
+ the foreign mail environment if eventual delivery failure occurs,
+ and that no notification will be issued on successful delivery.
+
+(e) When gatewaying a message into a foreign environment, the return-of-
+ content conditions specified by any RET parameter are nonbinding;
+ however, the MTA SHOULD attempt to honor the request using whatever
+ mechanisms exist in the foreign environment.
+
+6.2.5 Delays in delivery
+
+ If a conforming MTA receives a message via the SMTP protocol, and is
+ unable to deliver or relay the message to one or more recipients for
+ an extended length of time (to be determined by the MTA), it MAY
+ issue a "delayed" DSN for those recipients, subject to the following
+ conditions:
+
+(a) If the NOTIFY parameter was supplied for a recipient and its value
+ included the DELAY keyword, a "delayed" DSN MAY be issued.
+
+(b) If the NOTIFY parameter was not supplied for a recipient, a
+ "delayed" DSN MAY be issued.
+
+
+
+Moore Standards Track [Page 13]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+(c) If the NOTIFY parameter was supplied which did not contain the DELAY
+ keyword, a "delayed" DSN MUST NOT be issued.
+
+ NOTE: Although delay notifications are common in present-day
+ electronic mail, a conforming MTA is never required to issue
+ "delayed" DSNs. The DELAY keyword of the NOTIFY parameter is
+ provided to allow the SMTP client to specifically request (by
+ omitting the DELAY parameter) that "delayed" DSNs NOT be issued.
+
+6.2.6 Failure of a conforming MTA to deliver a message
+
+ The following rules govern the behavior of a conforming MTA which
+ received a message via the SMTP protocol, and is unable to deliver a
+ message to a recipient specified in the SMTP transaction:
+
+(a) If a NOTIFY parameter was supplied for the recipient with an esmtp-
+ keyword containing the value FAILURE, a "failed" DSN MUST be issued
+ by the MTA.
+
+(b) If a NOTIFY parameter was supplied for the recipient which did not
+ contain the value FAILURE, a DSN MUST NOT be issued for that
+ recipient. However, the MTA MAY inform the local postmaster of the
+ delivery failure via some appropriate mechanism which does not
+ itself result in the generation of DSNs.
+
+(c) If no NOTIFY parameter was supplied for the recipient, a "failed"
+ DSN MUST be issued.
+
+ NOTE: Some MTAs are known to forward undeliverable messages to the
+ local postmaster or "dead letter" mailbox. This is still considered
+ delivery failure, and does not diminish the requirement to issue a
+ "failed" DSN under the conditions defined elsewhere in this memo. If
+ a DSN is issued for such a recipient, the Action value MUST be
+ "failed".
+
+6.2.7 Forwarding, aliases, and mailing lists
+
+ Delivery of a message to a local email address usually causes the
+ message to be stored in the recipient's mailbox. However, MTAs
+ commonly provide a facility where a local email address can be
+ designated as an "alias" or "mailing list"; delivery to that address
+ then causes the message to be forwarded to each of the (local or
+ remote) recipient addresses associated with the alias or list. It is
+ also common to allow a user to optionally "forward" her mail to one
+ or more alternate addresses. If this feature is enabled, her mail is
+ redistributed to those addresses instead of being deposited in her
+ mailbox.
+
+
+
+
+Moore Standards Track [Page 14]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ Following the example of [9] (section 5.3.6), this document defines
+ the difference between an "alias" and "mailing list" as follows: When
+ forwarding a message to the addresses associated with an "alias", the
+ envelope return address (e.g. SMTP MAIL FROM) remains intact.
+ However, when forwarding a message to the addresses associated with a
+ "mailing list", the envelope return address is changed to that of the
+ administrator of the mailing list. This causes DSNs and other
+ nondelivery reports resulting from delivery to the list members to be
+ sent to the list administrator rather than the sender of the original
+ message.
+
+ The DSN processing for aliases and mailing lists is as follows:
+
+6.2.7.1 mailing lists
+
+ When a message is delivered to a list submission address (i.e. placed
+ in the list's mailbox for incoming mail, or accepted by the process
+ that redistributes the message to the list subscribers), this is
+ considered final delivery for the original message. If the NOTIFY
+ parameter for the list submission address contained the SUCCESS
+ keyword, a "delivered" DSN MUST be returned to the sender of the
+ original message.
+
+ NOTE: Some mailing lists are able to reject message submissions,
+ based on the content of the message, the sender's address, or some
+ other criteria. While the interface between such a mailing list and
+ its MTA is not well-defined, it is important that DSNs NOT be issued
+ by both the MTA (to report successful delivery to the list), and the
+ list (to report message rejection using a "failure" DSN.)
+
+ However, even if a "delivered" DSN was issued by the MTA, a mailing
+ list which rejects a message submission MAY notify the sender that
+ the message was rejected using an ordinary message instead of a DSN.
+
+ Whenever a message is redistributed to an mailing list,
+
+(a) The envelope return address is rewritten to point to the list
+ maintainer. This address MAY be that of a process that recognizes
+ DSNs and processes them automatically, but it MUST forward
+ unrecognized messages to the human responsible for the list.
+
+(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the
+ redistributed message MUST NOT be derived from those of the original
+ message.
+
+(c) The NOTIFY and RET parameters MAY be specified by the local
+ postmaster or the list administrator. If ORCPT parameters are
+ supplied during redistribution to the list subscribers, they SHOULD
+
+
+
+Moore Standards Track [Page 15]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ contain the addresses of the list subscribers in the format used by
+ the mailing list.
+
+6.2.7.2 single-recipient aliases
+
+ Under normal circumstances, when a message arrives for an "alias"
+ which has a single forwarding address, a DSN SHOULD NOT be issued.
+ Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with
+ the message as it is redistributed to the forwarding address.
+
+6.2.7.3 multiple-recipient aliases
+
+ An "alias" with multiple recipient addresses may be handled in any of
+ the following ways:
+
+(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when
+ relaying the message to any of the forwarding addresses. If the
+ NOTIFY parameter for the alias contained the SUCCESS keyword, the
+ MTA issues a "relayed" DSN. (In effect, the MTA treats the message
+ as if it were being relayed into an environment that does not
+ support DSNs.)
+
+(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent
+ requests if the message is gatewayed) are propagated to EXACTLY one
+ of the forwarding addresses. No DSN is issued. (This is
+ appropriate when aliasing is used to forward a message to a
+ "vacation" auto-responder program in addition to the local mailbox.)
+
+(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding
+ addresses associated with that alias. The NOTIFY parameter is
+ propagated to the forwarding addresses, except that it any SUCCESS
+ keyword is removed. If the original NOTIFY parameter for the alias
+ contained the SUCCESS keyword, an "expanded" DSN is issued for the
+ alias. If the NOTIFY parameter for the alias did not contain the
+ SUCCESS keyword, no DSN is issued for the alias.
+
+6.2.7.4 confidential forwarding addresses
+
+ If it is desired to maintain the confidentiality of a recipient's
+ forwarding address, the forwarding may be treated as if it were a
+ mailing list. A DSN will be issued, if appropriate, upon "delivery"
+ to the recipient address specified by the sender. When the message
+ is forwarded it will have a new envelope return address. Any DSNs
+ which result from delivery failure of the forwarded message will not
+ be returned to the original sender of the message and thus not expose
+ the recipient's forwarding address.
+
+
+
+
+
+Moore Standards Track [Page 16]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+6.2.8 DSNs describing delivery to multiple recipients
+
+ A single DSN may describe attempts to deliver a message to multiple
+ recipients of that message. If a DSN is issued for some recipients
+ in an SMTP transaction and not for others according to the rules
+ above, the DSN SHOULD NOT contain information for recipients for whom
+ DSNs would not otherwise have been issued.
+
+6.3 Handling of messages from other sources
+
+ For messages which originated from "local" users (whatever that
+ means), the specifications under which DSNs should be generated can
+ be communicated to the MTA via any protocol agreed on between the
+ sender's mail composer (user agent) and the MTA. The local MTA can
+ then either relay the message, or issue appropriate delivery status
+ notifications. However, if such requests are transmitted within the
+ message itself (for example in the message headers), the requests
+ MUST be removed from the message before it is transmitted via SMTP.
+
+ For messages gatewayed from non-SMTP sources and further relayed by
+ SMTP, the gateway SHOULD, using the SMTP extensions described here,
+ attempt to provide the delivery reporting conditions expected by the
+ source mail environment. If appropriate, any DSNs returned to the
+ source environment SHOULD be translated into the format expected in
+ that environment.
+
+6.4 Implementation limits
+
+ A conforming MTA MUST accept ESMTP parameters of at least the
+ following sizes:
+
+ (a) ENVID parameter: 100 characters.
+
+ (b) NOTIFY parameter: 28 characters.
+
+ (c) ORCPT parameter: 500 characters.
+
+ (d) RET parameter: 8 characters.
+
+ The maximum sizes for the ENVID and ORCPT parameters are intended to
+ be adequate for the transmission of "foreign" envelope identifier and
+ original recipient addresses. However, user agents which use SMTP as
+ a message submission protocol SHOULD NOT generate ENVID parameters
+ which are longer than 38 characters in length.
+
+ A conforming MTA MUST be able to accept SMTP command-lines which are
+ at least 1036 characters long (530 characters for the ORCPT and
+ NOTIFY parameters of the RCPT command, in addition to the 512
+
+
+
+Moore Standards Track [Page 17]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ characters required by [1]). If other SMTP extensions are supported
+ by the MTA, the MTA MUST be able to accept a command-line large
+ enough for each SMTP command and any combination of ESMTP parameters
+ which may be used with that command.
+
+7. Format of delivery notifications
+
+ The format of delivery status notifications is defined in [5], which
+ uses the framework defined in [8]. Delivery status notifications are
+ to be returned to the sender of the original message as outlined
+ below.
+
+7.1 SMTP Envelope to be used with delivery status notifications
+
+ The DSN sender address (in the SMTP MAIL command) MUST be a null
+ reverse-path ("<>"), as required by section 5.3.3 of [9]. The DSN
+ recipient address (in the RCPT command) is copied from the MAIL
+ command which accompanied the message for which the DSN is being
+ issued. When transmitting a DSN via SMTP, the RET parameter MUST NOT
+ be used. The NOTIFY parameter MAY be used, but its value MUST be
+ NEVER. The ENVID parameter (with a newly generated envelope-id)
+ and/or ORCPT parameter MAY be used.
+
+7.2 Contents of the DSN
+
+ A DSN is transmitted as a MIME message with a top-level content-type
+ of multipart/report (as defined in [5]).
+
+ The multipart/report content-type may be used for any of several
+ kinds of reports generated by the mail system. When multipart/report
+ is used to convey a DSN, the report-type parameter of the
+ multipart/report content-type is "delivery-status".
+
+ As described in [8], the first component of a multipart/report
+ content-type is a human readable explanation of the report. For a
+ DSN, the second component of the multipart/report is of content-type
+ message/delivery-status (defined in [5]). The third component of the
+ multipart/report consists of the original message or some portion
+ thereof. When the value of the RET parameter is FULL, the full
+ message SHOULD be returned for any DSN which conveys notification of
+ delivery failure. (However, if the length of the message is greater
+ than some implementation-specified length, the MTA MAY return only
+ the headers even if the RET parameter specified FULL.) If a DSN
+ contains no notifications of delivery failure, the MTA SHOULD return
+ only the headers.
+
+ The third component must have an appropriate content-type label.
+ Issues concerning selection of the content-type are discussed in [8].
+
+
+
+Moore Standards Track [Page 18]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+7.3 Message/delivery-status fields
+
+ The message/delivery-status content-type defines a number of fields,
+ with general specifications for their contents. The following
+ requirements for any DSNs generated in response to a message received
+ by the SMTP protocol by a conforming SMTP server, are in addition to
+ the requirements defined in [5] for the message/delivery-status type.
+
+ When generating a DSN for a message which was received via the SMTP
+ protocol, a conforming MTA will generate the following fields of the
+ message/delivery-status body part:
+
+(a) if an ENVID parameter was present on the MAIL command, an Original-
+ Envelope-ID field MUST be supplied, and the value associated with
+ the ENVID parameter must appear in that field. If the message was
+ received via SMTP with no ENVID parameter, the Original-Envelope-ID
+ field MUST NOT be supplied.
+
+ Since the ENVID parameter is encoded as xtext, but the Original-
+ Envelope-ID header is NOT encoded as xtext, the MTA must decode the
+ xtext encoding when copying the ENVID value to the Original-
+ Envelope-ID field.
+
+(b) The Reporting-MTA field MUST be supplied. If Reporting MTA can
+ determine its fully-qualified Internet domain name, the MTA-name-
+ type subfield MUST be "dns", and the field MUST contain the fully-
+ qualified domain name of the Reporting MTA. If the fully-qualified
+ Internet domain name of the Reporting MTA is not known (for example,
+ for an SMTP server which is not directly connected to the Internet),
+ the Reporting-MTA field may contain any string identifying the MTA,
+ however, in this case the MTA-name-type subfield MUST NOT be "dns".
+ A MTA-name-type subfield value of "x-local-hostname" is suggested.
+
+(c) Other per-message fields as defined in [5] MAY be supplied as
+ appropriate.
+
+(d) If the ORCPT parameter was provided for this recipient, the
+ Original-Recipient field MUST be supplied, with its value taken from
+ the ORCPT parameter. If no ORCPT parameter was provided for this
+ recipient, the Original-Recipient field MUST NOT appear.
+
+(e) The Final-Recipient field MUST be supplied. It MUST contain the
+ recipient address from the message envelope. If the message was
+ received via SMTP, the address-type will be "rfc822".
+
+(f) The Action field MUST be supplied.
+
+
+
+
+
+Moore Standards Track [Page 19]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+(g) The Status field MUST be supplied, using a status-code from [10].
+ If there is no specific code which suitably describes a delivery
+ failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent
+ failure) MUST be used.
+
+(h) For DSNs resulting from attempts to relay a message to one or more
+ recipients via SMTP, the Remote-MTA field MUST be supplied for each
+ of those recipients. The mta-name-type subfields of those Remote-
+ MTA fields will be "dns".
+
+(i) For DSNs resulting from attempts to relay a message to one or more
+ recipients via SMTP, the Diagnostic-Code MUST be supplied for each
+ of those recipients. The diagnostic-type subfield will be "smtp".
+ See section 9.2(a) of this document for a description of the "smtp"
+ diagnostic-code.
+
+(j) For DSNs resulting from attempts to relay a message to one or more
+ recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be
+ supplied for each recipient, which contains the address of that
+ recpient which was presented to the remote SMTP server.
+
+(k) Other per-recipient fields defined in [5] MAY appear, as
+ appropriate.
+
+8. Acknowledgments
+
+ The author wishes to thank Eric Allman, Harald Alvestrand, Jim
+ Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned
+ Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios
+ Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall
+ Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for
+ improvement of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore Standards Track [Page 20]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+9. Appendix - Type-Name Definitions
+
+ The following type names are defined for use in DSN fields generated
+ by conforming SMTP-based MTAs:
+
+9.1 "rfc822" address-type
+
+ The "rfc822" address-type is to be used when reporting Internet
+ electronic mail address in the Original-Recipient and Final-Recipient
+ DSN fields.
+
+(a) address-type name: rfc822
+
+(b) syntax for mailbox addresses
+
+ RFC822 mailbox addresses are generally expected to be of the form
+
+ [route] addr-spec
+
+ where "route" and "addr-spec" are defined in [2], and the "domain"
+ portions of both "route" and "addr-spec" are fully-qualified domain
+ names that are registered in the DNS. However, an MTA MUST NOT
+ modify an address obtained from the message envelope to force it to
+ conform to syntax rules.
+
+(c) If addresses of this type are not composed entirely of graphic
+characters from the US-ASCII repertoire, a specification for how they
+are to be encoded as graphic US-ASCII characters in a DSN Original-
+Recipient or Final-Recipient DSN field.
+
+ RFC822 addresses consist entirely of graphic characters from the US-
+ ASCII repertoire, so no translation is necessary.
+
+9.2 "smtp" diagnostic-type
+
+ The "smtp" diagnostic-type is to be used when reporting SMTP reply-
+ codes in Diagnostic-Code DSN fields.
+
+(a) diagnostic-type name: SMTP
+
+(b) A description of the syntax to be used for expressing diagnostic
+codes of this type as graphic characters from the US-ASCII repertoire.
+
+ An SMTP diagnostic-code is of the form
+
+ *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text
+
+
+
+
+
+Moore Standards Track [Page 21]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ For a single-line SMTP reply to an SMTP command, the diagnostic-code
+ SHOULD be an exact transcription of the reply. For multi-line SMTP
+ replies, it is necessary to insert a SPACE before each line after
+ the first. For example, an SMTP reply of:
+
+ 550-mailbox unavailable
+ 550 user has moved with no forwarding address
+
+ could appear as follows in a Diagnostic-Code DSN field:
+
+ Diagnostic-Code: smtp ; 550-mailbox unavailable
+ 550 user has moved with no forwarding address
+
+(c) A list of valid diagnostic codes of this type and the meaning of
+each code.
+
+ SMTP reply-codes are currently defined in [1], [4], and [9].
+ Additional codes may be defined by other RFCs.
+
+9.3 "dns" MTA-name-type
+
+ The "dns" MTA-name-type should be used in the Reporting-MTA field.
+ An MTA-name of type "dns" is a fully-qualified domain name. The name
+ must be registered in the DNS, and the address Postmaster@{mta-name}
+ must be valid.
+
+(a) MTA-name-type name: dns
+
+(b) A description of the syntax of MTA names of this type, using BNF,
+regular expressions, ASN.1, or other non-ambiguous language.
+
+ MTA names of type "dns" SHOULD be valid Internet domain names. If
+ such domain names are not available, a domain-literal containing the
+ internet protocol address is acceptable. Such domain names
+ generally conform to the following syntax:
+
+ domain = real-domain / domain-literal
+
+ real-domain = sub-domain *("." sub-domain)
+
+ sub-domain = atom
+
+ domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
+
+ where "atom" and "DIGIT" are defined in [2].
+
+
+
+
+
+
+Moore Standards Track [Page 22]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+(c) If MTA names of this type do not consist entirely of graphic
+characters from the US-ASCII repertoire, a specification for how an MTA
+name of this type should be expressed as a sequence of graphic US-ASCII
+characters.
+
+ MTA names of type "dns" consist entirely of graphic US-ASCII
+ characters, so no translation is needed.
+
+10. Appendix - Example
+
+ This example traces the flow of a single message addressed to
+ multiple recipients. The message is sent by Alice@Pure-Heart.ORG to
+ Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU,
+ Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a
+ variety of per-recipient options. The message is successfully
+ delivered to Bob, Dana (via a gateway), Eric, and Fred. Delivery
+ fails for Carol and George.
+
+ NOTE: Formatting rules for RFCs require that no line be longer than
+ 72 characters. Therefore, in the following examples, some SMTP
+ commands longer than 72 characters are printed on two lines, with the
+ first line ending in "\". In an actual SMTP transaction, such a
+ command would be sent as a single line (i.e. with no embedded CRLFs),
+ and without the "\" character that appears in these examples.
+
+10.1 Submission
+
+ Alice's user agent sends the message to the SMTP server at Pure-
+ Heart.ORG. Note that while this example uses SMTP as a mail
+ submission protocol, other protocols could also be used.
+
+<<< 220 Pure-Heart.ORG SMTP server here
+>>> EHLO Pure-Heart.ORG
+<<< 250-Pure-Heart.ORG
+<<< 250-DSN
+<<< 250-EXPN
+<<< 250 SIZE
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 <Alice@Pure-Heart.ORG> sender ok
+>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
+ ORCPT=rfc822;Bob@Big-Bucks.COM
+<<< 250 <Bob@Big-Bucks.COM> recipient ok
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
+ ORCPT=rfc822;Carol@Ivory.EDU
+<<< 250 <Carol@Ivory.EDU> recipient ok
+>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
+ ORCPT=rfc822;Dana@Ivory.EDU
+<<< 250 <Dana@Ivory.EDU> recipient ok
+
+
+
+Moore Standards Track [Page 23]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+>>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
+ ORCPT=rfc822;Eric@Bombs.AF.MIL
+<<< 250 <Eric@Bombs.AF.MIL> recipient ok
+>>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
+<<< 250 <Fred@Bombs.AF.MIL> recipient ok
+>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
+ ORCPT=rfc822;George@Tax-ME.GOV
+<<< 250 <George@Tax-ME.GOV> recipient ok
+>>> DATA
+<<< 354 okay, send message
+>>> (message goes here)
+>>> .
+<<< 250 message accepted
+>>> QUIT
+<<< 221 goodbye
+
+10.2 Relay to Big-Bucks.COM
+
+ The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM.
+ (For the purpose of this example, mail.Big-Bucks.COM is the primary
+ mail exchanger for Big-Bucks.COM).
+
+<<< 220 mail.Big-Bucks.COM says hello
+>>> EHLO Pure-Heart.ORG
+<<< 250-mail.Big-Bucks.COM
+<<< 250 DSN
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 sender okay
+>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
+ ORCPT=rfc822;Bob@Big-Bucks.COM
+<<< 250 recipient okay
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message received
+>>> QUIT
+<<< 221 bcnu
+
+10.3 Relay to Ivory.EDU
+
+ The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as
+ it happens) is a gateway to a LAN-based mail system that accepts SMTP
+ mail and supports the DSN extension.
+
+<<< 220 Ivory.EDU gateway to FooMail(tm) here
+>>> EHLO Pure-Heart.ORG
+<<< 250-Ivory.EDU
+
+
+
+Moore Standards Track [Page 24]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+<<< 250 DSN
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 ok
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
+ ORCPT=rfc822;Carol@Ivory.EDU
+<<< 550 error - no such recipient
+>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
+ ORCPT=rfc822;Dana@Ivory.EDU
+<<< 250 recipient ok
+>>> DATA
+<<< 354 send message, end with '.'
+>>> (message goes here)
+>>> .
+<<< 250 message received
+>>> QUIT
+<<< 221 bye
+
+ Note that since the Ivory.EDU refused to accept mail for
+ Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the
+ sender-SMTP (in this case Pure-Heart.ORG) must generate a DSN.
+
+10.4 Relay to Bombs.AF.MIL
+
+ The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which
+ does not support the SMTP extension. Because the sender specified
+ NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure-
+ Heart.ORG chooses to send the message for that recipient in a
+ separate transaction with a reverse-path of <>.
+
+<<< 220-Bombs.AF.MIL reporting for duty.
+<<< 220 Electronic mail is to be used for official business only.
+>>> EHLO Pure-Heart.ORG
+<<< 502 command not implemented
+>>> RSET
+<<< 250 reset
+>>> HELO Pure-Heart.ORG
+<<< 250 Bombs.AF.MIL
+>>> MAIL FROM:<Alice@Pure-Heart.ORG>
+<<< 250 ok
+>>> RCPT TO:<Eric@Bombs.AF.MIL>
+<<< 250 ok
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message accepted
+>>> MAIL FROM:<>
+<<< 250 ok
+
+
+
+Moore Standards Track [Page 25]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+>>> RCPT TO:<Fred@Bombs.AF.MIL>
+<<< 250 ok
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message accepted
+>>> QUIT
+<<< 221 Bombs.AF.MIL closing connection
+
+10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV
+
+ The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV. (this
+ step is not shown). MTA Tax-ME.GOV then forwards the message to
+ Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Pure-Heart.ORG
+ support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all
+ retain their original values.
+
+<<< 220 BoonDoggle.GOV says hello
+>>> EHLO Pure-Heart.ORG
+<<< 250-mail.Big-Bucks.COM
+<<< 250 DSN
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 sender okay
+>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
+ ORCPT=rfc822;George@Tax-ME.GOV
+<<< 250 recipient okay
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message received
+>>> QUIT
+<<< 221 bcnu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore Standards Track [Page 26]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+10.6 "Delivered" DSN for Bob@Big-Bucks.COM
+
+ MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big-
+ Bucks.COM. Because the sender specified NOTIFY=SUCCESS, mail.Big-
+ Bucks.COM issues the following DSN, and sends it to Alice@Pure-
+ Heart.ORG.
+
+To: Alice@Pure-Heart.ORG
+From: postmaster@mail.Big-Bucks.COM
+Subject: Delivery Notification (success) for Bob@Big-Bucks.COM
+Content-Type: multipart/report; report-type=delivery-status;
+ boundary=abcde
+MIME-Version: 1.0
+
+--abcde
+Content-type: text/plain; charset=us-ascii
+
+Your message (id QQ314159) was successfully delivered to
+Bob@Big-Bucks.COM.
+
+--abcde
+Content-type: message/delivery-status
+
+Reporting-MTA: dns; mail.Big-Bucks.COM
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;Bob@Big-Bucks.COM
+Final-Recipient: rfc822;Bob@Big-Bucks.COM
+Action: delivered
+Status: 2.0.0
+
+--abcde
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--abcde--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore Standards Track [Page 27]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+10.7 Failed DSN for Carol@Ivory.EDU
+
+ Because delivery to Carol failed and the sender specified
+ NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP
+ client to which the failure was reported via SMTP) issues the
+ following DSN.
+
+To: Alice@Pure-Heart.ORG
+From: postmaster@Pure-Heart.ORG
+Subject: Delivery Notification (failure) for Carol@Ivory.EDU
+Content-Type: multipart/report; report-type=delivery-status;
+ boundary=bcdef
+MIME-Version: 1.0
+
+--bcdef
+Content-type: text/plain; charset=us-ascii
+
+Your message (id QQ314159) could not be delivered to
+Carol@Ivory.EDU.
+
+A transcript of the session follows:
+
+(while talking to Ivory.EDU)
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE
+<<< 550 error - no such recipient
+
+--bcdef
+Content-type: message/delivery-status
+
+Reporting-MTA: dns; Pure-Heart.ORG
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;Carol@Ivory.EDU
+Final-Recipient: rfc822;Carol@Ivory.EDU
+SMTP-Remote-Recipient: Carol@Ivory.EDU
+Diagnostic-Code: smtp; 550 error - no such recipient
+Action: failed
+Status: 5.0.0
+
+--bcdef
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--bcdef--
+
+
+
+
+
+
+Moore Standards Track [Page 28]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+10.8 Relayed DSN For Dana@Ivory.EDU
+
+ Although the mail gateway Ivory.EDU supports the DSN SMTP extension,
+ the LAN mail system attached to its other side does not generate
+ positive delivery confirmations. So Ivory.EDU issues a "relayed"
+ DSN:
+
+To: Alice@Pure-Heart.ORG
+From: postmaster@Ivory.EDU
+Subject: mail relayed for Dana@Ivory.EDU
+Content-Type: multipart/report; report-type=delivery-status;
+ boundary=cdefg
+MIME-Version: 1.0
+
+--cdefg
+Content-type: text/plain; charset=us-ascii
+
+Your message (addressed to Dana@Ivory.EDU) was successfully
+relayed to:
+
+ymail!Dana
+
+by the FooMail gateway at Ivory.EDU.
+
+Unfortunately, the remote mail system does not support
+confirmation of actual delivery. Unless delivery to ymail!Dana
+fails, this will be the only delivery status notification sent.
+
+--cdefg
+Content-type: message/delivery-status
+
+Reporting-MTA: dns; Ivory.EDU
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;Dana@Ivory.EDU
+Final-Recipient: rfc822;Dana@Ivory.EDU
+Action: relayed
+Status: 2.0.0
+
+--cdefg
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--cdefg--
+
+
+
+
+
+
+Moore Standards Track [Page 29]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+10.9 Failure notification for Sam@Boondoggle.GOV
+
+ The message originally addressed to George@Tax-ME.GOV was forwarded
+ to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to
+ deliver the message due to a lack of disk space in Sam's mailbox.
+ After trying for several days, Boondoggle.GOV returned the following
+ DSN:
+
+To: Alice@BigHeart.ORG
+From: Postmaster@Boondoggle.GOV
+Subject: Delivery failure for Sam@Boondoggle.GOV
+Content-Type: multipart/report; report-type=delivery-status;
+ boundary=defgh
+MIME-Version: 1.0
+
+--defgh
+Your message, originally addressed to George@Tax-ME.GOV, and forwarded
+from there to Sam@Boondoggle.GOV could not be delivered, for the
+following reason:
+
+write error to mailbox, disk quota exceeded
+
+--defgh
+Content-type: message/delivery-status
+
+Reporting-MTA: Boondoggle.GOV
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;George@Tax-ME.GOV
+Final-Recipient: rfc822;Sam@Boondoggle.GOV
+Action: failed
+Status: 4.2.2 (disk quota exceeded)
+
+--defgh
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--defgh--
+
+
+
+
+
+
+
+
+
+
+
+
+Moore Standards Track [Page 30]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+11. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [3] Westine, A., and J. Postel, "Problems with the Maintenance of
+ Large Mailing Lists.", RFC 1211, USC/Information Sciences
+ Institute, March 1991.
+
+ [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
+ "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
+ Consulting, Inc., Network Management Associates, Inc., Silicon
+ Graphics, Inc., July 1994.
+
+ [5] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+ Delivery Status Notifications", RFC 1894, University of Tennessee,
+ Octel Network Services, January 1996.
+
+ [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
+ 1730, University of Washington, 20 December 1994.
+
+ [7] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
+ 1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
+
+ [8] Vaudreuil, G., "The Multipart/Report Content Type for the
+ Reporting of Mail System Administrative Messages", RFC 1892, Octel
+ Network Services, January 1996.
+
+ [9] Braden, R., Editor, "Requirements for Internet Hosts - Application
+ and Support", STD 3, RFC 1123, IETF, October 1989.
+
+ [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+ Octel Network Services, January 1996.
+
+12. Author's Address
+
+ Keith Moore
+ University of Tennessee
+ 107 Ayres Hall
+ Knoxville, TN 37996-1301
+ USA
+
+ EMail: moore@cs.utk.edu
+
+
+
+
+
+Moore Standards Track [Page 31]
+
diff --git a/Documentation/en/rfc/rfc1893.txt b/Documentation/en/rfc/rfc1893.txt
new file mode 100644
index 00000000..9ca4efb5
--- /dev/null
+++ b/Documentation/en/rfc/rfc1893.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group G. Vaudreuil
+Request for Comments: 1893 Octel Network Services
+Category: Standards Track January 1996
+
+
+ Enhanced Mail System Status Codes
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Overview
+
+ There currently is not a standard mechanism for the reporting of mail
+ system errors except for the limited set offered by SMTP and the
+ system specific text descriptions sent in mail messages. There is a
+ pressing need for a rich machine readable status code for use in
+ delivery status notifications [DSN]. This document proposes a new
+ set of status codes for this purpose.
+
+ SMTP [SMTP] error codes have historically been used for reporting
+ mail system errors. Because of limitations in the SMTP code design,
+ these are not suitable for use in delivery status notifications.
+ SMTP provides about 12 useful codes for delivery reports. The
+ majority of the codes are protocol specific response codes such as
+ the 354 response to the SMTP data command. Each of the 12 useful
+ codes are each overloaded to indicate several error conditions each.
+ SMTP suffers some scars from history, most notably the unfortunate
+ damage to the reply code extension mechanism by uncontrolled use.
+ This proposal facilitates future extensibility by requiring the
+ client to interpret unknown error codes according to the theory of
+ codes while requiring servers to register new response codes.
+
+ The SMTP theory of reply codes partitioned in the number space such a
+ manner that the remaining available codes will not provide the space
+ needed. The most critical example is the existence of only 5
+ remaining codes for mail system errors. The mail system
+ classification includes both host and mailbox error conditions. The
+ remaining third digit space would be completely consumed as needed to
+ indicate MIME and media conversion errors and security system errors.
+
+ A revision to the SMTP theory of reply codes to better distribute the
+ error conditions in the number space will necessarily be incompatible
+ with SMTP. Further, consumption of the remaining reply-code number
+
+
+
+Vaudreuil Standards Track [Page 1]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ space for delivery notification reporting will reduce the available
+ codes for new ESMTP extensions.
+
+ The following proposal is based on the SMTP theory of reply codes.
+ It adopts the success, permanent error, and transient error semantics
+ of the first value, with a further description and classification in
+ the second. This proposal re-distributes the classifications to
+ better distribute the error conditions, such as separating mailbox
+ from host errors.
+
+2. Status Codes
+
+ This document defines a new set of status codes to report mail system
+ conditions. These status codes are intended to be used for media and
+ language independent status reporting. They are not intended for
+ system specific diagnostics.
+
+ The syntax of the new status codes is defined as:
+
+ status-code = class "." subject "." detail
+ class = "2"/"4"/"5"
+ subject = 1*3digit
+ detail = 1*3digit
+
+ White-space characters and comments are NOT allowed within a status-
+ code. Each numeric sub-code within the status-code MUST be expressed
+ without leading zero digits.
+
+ Status codes consist of three numerical fields separated by ".". The
+ first sub-code indicates whether the delivery attempt was successful.
+ The second sub-code indicates the probable source of any delivery
+ anomalies, and the third sub-code indicates a precise error
+ condition.
+
+ The codes space defined is intended to be extensible only by
+ standards track documents. Mail system specific status codes should
+ be mapped as close as possible to the standard status codes. Servers
+ should send only defined, registered status codes. System specific
+ errors and diagnostics should be carried by means other than status
+ codes.
+
+ New subject and detail codes will be added over time. Because the
+ number space is large, it is not intended that published status codes
+ will ever be redefined or eliminated. Clients should preserve the
+ extensibility of the code space by reporting the general error
+ described in the subject sub-code when the specific detail is
+ unrecognized.
+
+
+
+
+Vaudreuil Standards Track [Page 2]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ The class sub-code provides a broad classification of the status.
+ The enumerated values the class are defined as:
+
+ 2.X.X Success
+
+ Success specifies that the DSN is reporting a positive delivery
+ action. Detail sub-codes may provide notification of
+ transformations required for delivery.
+
+ 4.X.X Persistent Transient Failure
+
+ A persistent transient failure is one in which the message as
+ sent is valid, but some temporary event prevents the successful
+ sending of the message. Sending in the future may be successful.
+
+ 5.X.X Permanent Failure
+
+ A permanent failure is one which is not likely to be resolved by
+ resending the message in the current form. Some change to the
+ message or the destination must be made for successful delivery.
+
+ A client must recognize and report class sub-code even where
+ subsequent subject sub-codes are unrecognized.
+
+ The subject sub-code classifies the status. This value applies to
+ each of the three classifications. The subject sub-code, if
+ recognized, must be reported even if the additional detail provided
+ by the detail sub-code is not recognized. The enumerated values for
+ the subject sub-code are:
+
+ X.0.X Other or Undefined Status
+
+ There is no additional subject information available.
+
+ X.1.X Addressing Status
+
+ The address status reports on the originator or destination
+ address. It may include address syntax or validity. These
+ errors can generally be corrected by the sender and retried.
+
+ X.2.X Mailbox Status
+
+ Mailbox status indicates that something having to do with the
+ mailbox has cause this DSN. Mailbox issues are assumed to be
+ under the general control of the recipient.
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 3]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.3.X Mail System Status
+
+ Mail system status indicates that something having to do
+ with the destination system has caused this DSN. System
+ issues are assumed to be under the general control of the
+ destination system administrator.
+
+ X.4.X Network and Routing Status
+
+ The networking or routing codes report status about the
+ delivery system itself. These system components include any
+ necessary infrastructure such as directory and routing
+ services. Network issues are assumed to be under the
+ control of the destination or intermediate system
+ administrator.
+
+ X.5.X Mail Delivery Protocol Status
+
+ The mail delivery protocol status codes report failures
+ involving the message delivery protocol. These failures
+ include the full range of problems resulting from
+ implementation errors or an unreliable connection. Mail
+ delivery protocol issues may be controlled by many parties
+ including the originating system, destination system, or
+ intermediate system administrators.
+
+ X.6.X Message Content or Media Status
+
+ The message content or media status codes report failures
+ involving the content of the message. These codes report
+ failures due to translation, transcoding, or otherwise
+ unsupported message media. Message content or media issues
+ are under the control of both the sender and the receiver,
+ both of whom must support a common set of supported
+ content-types.
+
+ X.7.X Security or Policy Status
+
+ The security or policy status codes report failures
+ involving policies such as per-recipient or per-host
+ filtering and cryptographic operations. Security and policy
+ status issues are assumed to be under the control of either
+ or both the sender and recipient. Both the sender and
+ recipient must permit the exchange of messages and arrange
+ the exchange of necessary keys and certificates for
+ cryptographic operations.
+
+
+
+
+
+Vaudreuil Standards Track [Page 4]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+3. Enumerated Status Codes
+
+ The following section defines and describes the detail sub-code. The
+ detail value provides more information about the status and is
+ defined relative to the subject of the status.
+
+ 3.1 Other or Undefined Status
+
+ X.0.0 Other undefined Status
+
+ Other undefined status is the only undefined error code. It
+ should be used for all errors for which only the class of the
+ error is known.
+
+ 3.2 Address Status
+
+ X.1.0 Other address status
+
+ Something about the address specified in the message caused
+ this DSN.
+
+ X.1.1 Bad destination mailbox address
+
+ The mailbox specified in the address does not exist. For
+ Internet mail names, this means the address portion to the
+ left of the "@" sign is invalid. This code is only useful
+ for permanent failures.
+
+ X.1.2 Bad destination system address
+
+ The destination system specified in the address does not
+ exist or is incapable of accepting mail. For Internet mail
+ names, this means the address portion to the right of the
+ "@" is invalid for mail. This codes is only useful for
+ permanent failures.
+
+ X.1.3 Bad destination mailbox address syntax
+
+ The destination address was syntactically invalid. This can
+ apply to any field in the address. This code is only useful
+ for permanent failures.
+
+ X.1.4 Destination mailbox address ambiguous
+
+ The mailbox address as specified matches one or more
+ recipients on the destination system. This may result if a
+ heuristic address mapping algorithm is used to map the
+ specified address to a local mailbox name.
+
+
+
+Vaudreuil Standards Track [Page 5]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.1.5 Destination address valid
+
+ This mailbox address as specified was valid. This status
+ code should be used for positive delivery reports.
+
+ X.1.6 Destination mailbox has moved, No forwarding address
+
+ The mailbox address provided was at one time valid, but mail
+ is no longer being accepted for that address. This code is
+ only useful for permanent failures.
+
+ X.1.7 Bad sender's mailbox address syntax
+
+ The sender's address was syntactically invalid. This can
+ apply to any field in the address.
+
+ X.1.8 Bad sender's system address
+
+ The sender's system specified in the address does not exist
+ or is incapable of accepting return mail. For domain names,
+ this means the address portion to the right of the "@" is
+ invalid for mail.
+
+ 3.3 Mailbox Status
+
+ X.2.0 Other or undefined mailbox status
+
+ The mailbox exists, but something about the destination
+ mailbox has caused the sending of this DSN.
+
+ X.2.1 Mailbox disabled, not accepting messages
+
+ The mailbox exists, but is not accepting messages. This may
+ be a permanent error if the mailbox will never be re-enabled
+ or a transient error if the mailbox is only temporarily
+ disabled.
+
+ X.2.2 Mailbox full
+
+ The mailbox is full because the user has exceeded a
+ per-mailbox administrative quota or physical capacity. The
+ general semantics implies that the recipient can delete
+ messages to make more space available. This code should be
+ used as a persistent transient failure.
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 6]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.2.3 Message length exceeds administrative limit
+
+ A per-mailbox administrative message length limit has been
+ exceeded. This status code should be used when the
+ per-mailbox message length limit is less than the general
+ system limit. This code should be used as a permanent
+ failure.
+
+ X.2.4 Mailing list expansion problem
+
+ The mailbox is a mailing list address and the mailing list
+ was unable to be expanded. This code may represent a
+ permanent failure or a persistent transient failure.
+
+ 3.4 Mail system status
+
+ X.3.0 Other or undefined mail system status
+
+ The destination system exists and normally accepts mail, but
+ something about the system has caused the generation of this
+ DSN.
+
+ X.3.1 Mail system full
+
+ Mail system storage has been exceeded. The general
+ semantics imply that the individual recipient may not be
+ able to delete material to make room for additional
+ messages. This is useful only as a persistent transient
+ error.
+
+ X.3.2 System not accepting network messages
+
+ The host on which the mailbox is resident is not accepting
+ messages. Examples of such conditions include an immanent
+ shutdown, excessive load, or system maintenance. This is
+ useful for both permanent and permanent transient errors.
+
+ X.3.3 System not capable of selected features
+
+ Selected features specified for the message are not
+ supported by the destination system. This can occur in
+ gateways when features from one domain cannot be mapped onto
+ the supported feature in another.
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 7]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.3.4 Message too big for system
+
+ The message is larger than per-message size limit. This
+ limit may either be for physical or administrative reasons.
+ This is useful only as a permanent error.
+
+ X.3.5 System incorrectly configured
+
+ The system is not configured in a manner which will permit
+ it to accept this message.
+
+ 3.5 Network and Routing Status
+
+ X.4.0 Other or undefined network or routing status
+
+ Something went wrong with the networking, but it is not
+ clear what the problem is, or the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.4.1 No answer from host
+
+ The outbound connection attempt was not answered, either
+ because the remote system was busy, or otherwise unable to
+ take a call. This is useful only as a persistent transient
+ error.
+
+ X.4.2 Bad connection
+
+ The outbound connection was established, but was otherwise
+ unable to complete the message transaction, either because
+ of time-out, or inadequate connection quality. This is
+ useful only as a persistent transient error.
+
+ X.4.3 Directory server failure
+
+ The network system was unable to forward the message,
+ because a directory server was unavailable. This is useful
+ only as a persistent transient error.
+
+ The inability to connect to an Internet DNS server is one
+ example of the directory server failure error.
+
+ X.4.4 Unable to route
+
+ The mail system was unable to determine the next hop for the
+ message because the necessary routing information was
+ unavailable from the directory server. This is useful for
+ both permanent and persistent transient errors.
+
+
+
+Vaudreuil Standards Track [Page 8]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ A DNS lookup returning only an SOA (Start of Administration)
+ record for a domain name is one example of the unable to
+ route error.
+
+ X.4.5 Mail system congestion
+
+ The mail system was unable to deliver the message because
+ the mail system was congested. This is useful only as a
+ persistent transient error.
+
+ X.4.6 Routing loop detected
+
+ A routing loop caused the message to be forwarded too many
+ times, either because of incorrect routing tables or a user
+ forwarding loop. This is useful only as a persistent
+ transient error.
+
+ X.4.7 Delivery time expired
+
+ The message was considered too old by the rejecting system,
+ either because it remained on that host too long or because
+ the time-to-live value specified by the sender of the
+ message was exceeded. If possible, the code for the actual
+ problem found when delivery was attempted should be returned
+ rather than this code. This is useful only as a persistent
+ transient error.
+
+ 3.6 Mail Delivery Protocol Status
+
+ X.5.0 Other or undefined protocol status
+
+ Something was wrong with the protocol necessary to deliver
+ the message to the next hop and the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.5.1 Invalid command
+
+ A mail transaction protocol command was issued which was
+ either out of sequence or unsupported. This is useful only
+ as a permanent error.
+
+ X.5.2 Syntax error
+
+ A mail transaction protocol command was issued which could
+ not be interpreted, either because the syntax was wrong or
+ the command is unrecognized. This is useful only as a
+ permanent error.
+
+
+
+
+Vaudreuil Standards Track [Page 9]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.5.3 Too many recipients
+
+ More recipients were specified for the message than could
+ have been delivered by the protocol. This error should
+ normally result in the segmentation of the message into two,
+ the remainder of the recipients to be delivered on a
+ subsequent delivery attempt. It is included in this list in
+ the event that such segmentation is not possible.
+
+ X.5.4 Invalid command arguments
+
+ A valid mail transaction protocol command was issued with
+ invalid arguments, either because the arguments were out of
+ range or represented unrecognized features. This is useful
+ only as a permanent error.
+
+ X.5.5 Wrong protocol version
+
+ A protocol version mis-match existed which could not be
+ automatically resolved by the communicating parties.
+
+ 3.7 Message Content or Message Media Status
+
+ X.6.0 Other or undefined media error
+
+ Something about the content of a message caused it to be
+ considered undeliverable and the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.6.1 Media not supported
+
+ The media of the message is not supported by either the
+ delivery protocol or the next system in the forwarding path.
+ This is useful only as a permanent error.
+
+ X.6.2 Conversion required and prohibited
+
+ The content of the message must be converted before it can
+ be delivered and such conversion is not permitted. Such
+ prohibitions may be the expression of the sender in the
+ message itself or the policy of the sending host.
+
+ X.6.3 Conversion required but not supported
+
+ The message content must be converted to be forwarded but
+ such conversion is not possible or is not practical by a
+ host in the forwarding path. This condition may result when
+ an ESMTP gateway supports 8bit transport but is not able to
+
+
+
+Vaudreuil Standards Track [Page 10]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ downgrade the message to 7 bit as required for the next hop.
+
+ X.6.4 Conversion with loss performed
+
+ This is a warning sent to the sender when message delivery
+ was successfully but when the delivery required a conversion
+ in which some data was lost. This may also be a permanant
+ error if the sender has indicated that conversion with loss
+ is prohibited for the message.
+
+ X.6.5 Conversion Failed
+
+ A conversion was required but was unsuccessful. This may be
+ useful as a permanent or persistent temporary notification.
+
+ 3.8 Security or Policy Status
+
+ X.7.0 Other or undefined security status
+
+ Something related to security caused the message to be
+ returned, and the problem cannot be well expressed with any
+ of the other provided detail codes. This status code may
+ also be used when the condition cannot be further described
+ because of security policies in force.
+
+ X.7.1 Delivery not authorized, message refused
+
+ The sender is not authorized to send to the destination.
+ This can be the result of per-host or per-recipient
+ filtering. This memo does not discuss the merits of any
+ such filtering, but provides a mechanism to report such.
+ This is useful only as a permanent error.
+
+ X.7.2 Mailing list expansion prohibited
+
+ The sender is not authorized to send a message to the
+ intended mailing list. This is useful only as a permanent
+ error.
+
+ X.7.3 Security conversion required but not possible
+
+ A conversion from one secure messaging protocol to another
+ was required for delivery and such conversion was not
+ possible. This is useful only as a permanent error.
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 11]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.7.4 Security features not supported
+
+ A message contained security features such as secure
+ authentication which could not be supported on the delivery
+ protocol. This is useful only as a permanent error.
+
+ X.7.5 Cryptographic failure
+
+ A transport system otherwise authorized to validate or
+ decrypt a message in transport was unable to do so because
+ necessary information such as key was not available or such
+ information was invalid.
+
+ X.7.6 Cryptographic algorithm not supported
+
+ A transport system otherwise authorized to validate or
+ decrypt a message was unable to do so because the necessary
+ algorithm was not supported.
+
+ X.7.7 Message integrity failure
+
+ A transport system otherwise authorized to validate a
+ message was unable to do so because the message was
+ corrupted or altered. This may be useful as a permanent,
+ transient persistent, or successful delivery code.
+
+4. References
+
+ [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+ Delivery Status Notifications", RFC 1894, University of
+ Tennessee, Octel Network Services, January 1996.
+
+5. Security Considerations
+
+ This document describes a status code system with increased
+ precision. Use of these status codes may disclose additional
+ information about how an internal mail system is implemented beyond
+ that currently available.
+
+6. Acknowledgments
+
+ The author wishes to offer special thanks to Harald Alvestrand, Marko
+ Kaittola, and Keith Moore for their extensive review and constructive
+ suggestions.
+
+
+
+
+Vaudreuil Standards Track [Page 12]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+7. Author's Address
+
+ Gregory M. Vaudreuil
+ Octel Network Services
+ 17060 Dallas Parkway
+ Suite 214
+ Dallas, TX 75248-1905
+
+ Voice/Fax: +1-214-733-2722
+ EMail: Greg.Vaudreuil@Octel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 13]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+8. Appendix - Collected Status Codes
+
+ X.1.0 Other address status
+ X.1.1 Bad destination mailbox address
+ X.1.2 Bad destination system address
+ X.1.3 Bad destination mailbox address syntax
+ X.1.4 Destination mailbox address ambiguous
+ X.1.5 Destination mailbox address valid
+ X.1.6 Mailbox has moved
+ X.1.7 Bad sender's mailbox address syntax
+ X.1.8 Bad sender's system address
+
+ X.2.0 Other or undefined mailbox status
+ X.2.1 Mailbox disabled, not accepting messages
+ X.2.2 Mailbox full
+ X.2.3 Message length exceeds administrative limit.
+ X.2.4 Mailing list expansion problem
+
+ X.3.0 Other or undefined mail system status
+ X.3.1 Mail system full
+ X.3.2 System not accepting network messages
+ X.3.3 System not capable of selected features
+ X.3.4 Message too big for system
+
+ X.4.0 Other or undefined network or routing status
+ X.4.1 No answer from host
+ X.4.2 Bad connection
+ X.4.3 Routing server failure
+ X.4.4 Unable to route
+ X.4.5 Network congestion
+ X.4.6 Routing loop detected
+ X.4.7 Delivery time expired
+
+ X.5.0 Other or undefined protocol status
+ X.5.1 Invalid command
+ X.5.2 Syntax error
+ X.5.3 Too many recipients
+ X.5.4 Invalid command arguments
+ X.5.5 Wrong protocol version
+
+ X.6.0 Other or undefined media error
+ X.6.1 Media not supported
+ X.6.2 Conversion required and prohibited
+ X.6.3 Conversion required but not supported
+ X.6.4 Conversion with loss performed
+ X.6.5 Conversion failed
+
+
+
+
+
+Vaudreuil Standards Track [Page 14]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.7.0 Other or undefined security status
+ X.7.1 Delivery not authorized, message refused
+ X.7.2 Mailing list expansion prohibited
+ X.7.3 Security conversion required but not possible
+ X.7.4 Security features not supported
+ X.7.5 Cryptographic failure
+ X.7.6 Cryptographic algorithm not supported
+ X.7.7 Message integrity failure
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 15]
+
diff --git a/Documentation/en/rfc/rfc1985.txt b/Documentation/en/rfc/rfc1985.txt
new file mode 100644
index 00000000..f49afd75
--- /dev/null
+++ b/Documentation/en/rfc/rfc1985.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group J. De Winter
+Request for Comments: 1985 Wildbear Consulting, Inc.
+Category: Standards Track August 1996
+
+
+ SMTP Service Extension
+ for Remote Message Queue Starting
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This memo defines an extension to the SMTP service whereby an SMTP
+ client and server may interact to give the server an opportunity to
+ start the processing of its queues for messages to go to a given
+ host. This extension is meant to be used in startup conditions as
+ well as for mail nodes that have transient connections to their
+ service providers.
+
+1. Introduction
+
+ The TURN command was a valid attempt to address the problem of having
+ to start the processing for the mail queue on a remote machine.
+ However, the TURN command presents a large security loophole. As
+ there is no verification of the remote host name, the TURN command
+ could be used by a rogue system to download the mail for a site other
+ than itself.
+
+ Therefore, this memo introduces the ETRN command. This command uses
+ the mechanism defined in [4] to define extensions to the SMTP service
+ whereby a client ("sender-SMTP") may request that the server
+ ("receiver-SMTP") start the processing of its mail queues for
+ messages that are waiting at the server for the client machine. If
+ any messages are at the server for the client, then the server should
+ create a new SMTP session and send the messages at that time.
+
+
+
+
+
+
+
+
+
+
+De Winter Standards Track [Page 1]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+2. Framework for the ETRN Extension
+
+ The following service extension is therefore defined:
+
+ (1) the name of the SMTP service extension is "Remote Queue
+ Processing Declaration";
+
+ (2) the EHLO keyword value associated with this extension is "ETRN",
+ with no associated parameters;
+
+ (3) one additional verb, ETRN, with a single parameter that
+ specifies the name of the client(s) to start processing for;
+
+ (4) no additional SMTP verbs are defined by this extension.
+
+ The remainder of this memo specifies how support for the extension
+ affects the behavior of an SMTP client and server.
+
+3. The Remote Queue Processing Declaration service extension
+
+ To save money, many small companies want to only maintain transient
+ connections to their service providers. In addition, there are some
+ situations where the client sites depend on their mail arriving
+ quickly, so forcing the queues on the server belonging to their
+ service provider may be more desirable than waiting for the retry
+ timeout to occur.
+
+ Both of these situations could currently be fixed using the TURN
+ command defined in [1], if it were not for a large security loophole
+ in the TURN command. As it stands, the TURN command will reverse the
+ direction of the SMTP connection and assume that the remote host is
+ being honest about what its name is. The security loophole is that
+ there is no documented stipulation for checking the authenticity of
+ the remote host name, as given in the HELO or EHLO command. As such,
+ most SMTP and ESMTP implementations do not implement the TURN command
+ to avoid this security loophole.
+
+ This has been addressed in the design of the ETRN command. This
+ extended turn command was written with the points in the first
+ paragraph in mind, yet paying attention to the problems that
+ currently exist with the TURN command. The security loophole is
+ avoided by asking the server to start a new connection aimed at the
+ specified client.
+
+ In this manner, the server has a lot more certainty that it is
+ talking to the correct SMTP client. This mechanism can just be seen
+ as a more immediate version of the retry queues that appear in most
+ SMTP implementations. In addition, as this command will take a
+
+
+
+De Winter Standards Track [Page 2]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+ single parameter, the name of the remote host(s) to start the queues
+ for, the server can decide whether it wishes to respect the request
+ or deny it for any local administrative reasons.
+
+4. Definitions
+
+ Remote queue processing means that using an SMTP or ESMTP connection,
+ the client may request that the server start to process parts of its
+ messaging queue. This processing is performed using the existing
+ SMTP infrastructure and will occur at some point after the processing
+ is initiated.
+
+ The server host is the node that is responding to the ETRN
+ command.
+
+ The client host is the node that is initiating the ETRN command.
+
+ The remote host name is defined to be a plain-text field that
+ specifies a name for the remote host(s). This remote host name may
+ also include an alias for the specified remote host or special
+ commands to identify other types of queues.
+
+5. The extended ETRN command
+
+ The extended ETRN command is issued by the client host when it wishes
+ to start the SMTP queue processing of a given server host. The
+ syntax of this command is as follows:
+
+ ETRN [<option character>]<node name><CR><LF>
+
+ This command may be issued at any time once a session is established,
+ as long as there is not a transaction occuring. Thus, this command
+ is illegal between a MAIL FROM: command and the end of the DATA
+ commands and responses.
+
+ The specified node name must be a fully qualified domain name for the
+ node, which may refer to a CNAME or MX pointer in the DNS. If an
+ alias is used for the node, multiple ETRN commands may be needed to
+ start the processing for the node as it may be listed at the remote
+ site under multiple names. This can also be addressed using the
+ options discussed in section 5.3.
+
+ The option character under normal circumstances is not used.
+
+
+
+
+
+
+
+
+De Winter Standards Track [Page 3]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+5.1 Server action on receipt of the extended ETRN command
+
+ When the server host receives the ETRN command, it should have a look
+ at the node name that is specified in the command and make a local
+ decision if it should honour the request. If not, the appropriate
+ error codes should be returned to the client.
+
+ Otherwise, the server host should force its retry queues to start
+ sending messages to that remote site, using another SMTP connection.
+ At the moment, there is no requirement that a connection must occur,
+ or that the connection must occur within a given time frame. This
+ should be noted in the case where there are no messages for the
+ client host at the server host and only the 250 response is used.
+
+ Since the processing of the queues may take an indeterminate amount
+ of time, this command should return immediately with a response to
+ the client host. The valid return codes for this command are:
+
+ 250 OK, queuing for node <x> started
+ 251 OK, no messages waiting for node <x>
+ 252 OK, pending messages for node <x> started
+ 253 OK, <n> pending messages for node <x> started
+ 458 Unable to queue messages for node <x>
+ 459 Node <x> not allowed: <reason>
+ 500 Syntax Error
+ 501 Syntax Error in Parameters
+
+ The 250 response code does not indicate that messages will be sent to
+ the system in question, just that the queue has been started and some
+ action will occur. If the server is capable of supporting it, the
+ 251, 252 or 253 response codes should be used to give more
+ information to the client side. In this case, if there are messages
+ waiting for the client side node, a check can be performed using
+ these responses codes as an indication of when there are no more
+ pending messages in the queue for that node.
+
+ The 458 and 459 result codes should be used to give more information
+ back to the client host as to why the action was not performed. If
+ the syntax of the request is not correct, then the 500 and 501 result
+ codes should be used.
+
+5.2 Client action on receiving response to extended ETRN command
+
+ If one of the 500 level error codes (550 or 551) are sent, the client
+ should assume that the protocol is not supported in the remote host
+ or that the protocol has not been implemented correctly on either the
+ client or server host. In this case, multiple ETRN commands (dealing
+ with the aliases for the system) should not be sent.
+
+
+
+De Winter Standards Track [Page 4]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+ If the 250 response is received, then the client host can assume that
+ the server host found its request to be satisfactory and it will send
+ any queued messages. This process may involve going through a very
+ large retry queue, and may take some time.
+
+ If the 400 level response is received, then the client can assume
+ that the server supports the command, but for some local reason does
+ not want to accept the ETRN command as is. In most cases, it will
+ mean that there is a list of nodes that it will accept the command
+ from and the current client is not on that list. The 459 response
+ code is presented to allow for a more in-depth reason as to why the
+ remote queuing cannot be started.
+
+5.3 Use Of ETRN to release mail for a subdomain or queue
+
+ If the requesting server wishes to release all of the mail for a
+ given subdomain, a variation on the ETRN command can be used. To
+ perform this request, the option character '@' should be used in
+ front of the node name. In this manner, any domain names that are
+ formed with a suffix of the specified node name are released.
+
+ For example, if the command ETRN @foo.com was issued, then any
+ accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com
+ may be released. It should be noted that the receiving side of the
+ ETRN command should make a decision based on the client in question
+ and only allow certain combinations for each of the nodes. This is
+ more of a security issue than anything else.
+
+ In a similar vein, it might be necessary under some circumstances to
+ release a certain queue, where that queue does not correspond to a
+ given domain name. To this end, the option character '#' can be used
+ to force the processing of a given queue. In this case, the node
+ name would be used as a queue name instead, and its syntactical
+ structure would be dependant on the receiving server. An example of
+ this would be using the command ETRN #uucp to force the flush of a
+ UUCP queue. Note that the use of this option is entirely a local
+ matter and there is no way for a client to find a list of any such
+ queues that exist.
+
+6. Minimal usage
+
+ A "minimal" client may use this extension with its host name to start
+ the queues on the server host. This minimal usage will not handle
+ cases where mail for 'x.y' is sent to 's.x.y'.
+
+ A minimal server may use this extensions to start the processing of
+ the queues for all remote sites. In this case, the 458 error
+ response will not be seen, and it should always return the 250
+
+
+
+De Winter Standards Track [Page 5]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+ response as it will always try and start the processing for any
+ request.
+
+7. Example
+
+ The following example illustrates the use of remote queue processing
+ with some permanent and temporary failures.
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
+ C: EHLO ymir.claremont.edu
+ S: 250-sigurd.innosoft.com
+ S: 250-EXPN
+ S: 250-HELP
+ S: 250 ETRN
+ C: ETRN
+ S: 500 Syntax Error
+ C: ETRN localname
+ S: 501 Syntax Error in Parameters
+ C: ETRN uu.net
+ S: 458 Unable to queue messages for node uu.net
+ ...
+
+ C: ETRN sigurd.innosoft.com
+ S: 250 OK, queuing for node sigurd.innosoft.com started
+ C: ETRN innosoft.com
+ S: 250 OK, queuing for node innosoft.com started
+
+ OR
+
+ C: ETRN sigurd.innosoft.com
+ S: 251 OK, no messages waiting for node sigurd.innosoft.com
+ C: ETRN innosoft.com
+ S: 252 OK, pending messages for node innosoft.com started
+ C: ETRN mysoft.com
+ S: 253 OK, 14 pending messages for node mysoft.com started
+
+ ...
+ C: ETRN foo.bar
+ S: 459 Node foo.bar not allowed: Unable to resolve name.
+ ...
+ C: QUIT
+ S: 250 Goodbye
+
+
+
+
+
+
+
+De Winter Standards Track [Page 6]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+8. Security Considerations
+
+ This command does not compromise any security considerations of any
+ existing SMTP or ESMTP protocols as it merely shortens the time that
+ a client needs to wait before their messages are retried.
+
+ Precautions should be taken to make sure that any client server can
+ only use the @ and # option characters for systems that make sense.
+ Failure to implement some kind of sanity checking on the parameters
+ could lead to congestion. This would be evident if a person asking
+ to release @com, which would release mail for any address that ended
+ with com.
+
+9. Acknowledgements
+
+ This document was created with lots of support from the users of our
+ products, who have given some input to the functionality that they
+ would like to see in the software that they bought.
+
+10. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+ [2] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+ E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
+ Nations University, Innosoft International, Inc., Dover Beach
+ Consulting, Inc., Network Management Associates, Inc., The Branch
+ Office, February 1993.
+
+11. Author's Address
+
+ Jack De Winter
+ Wildbear Consulting, Inc.
+ 17 Brock Street
+ Kitchener, Ontario, Canada
+ N2M 1X2
+
+ Phone: +1 519 576 3873
+ EMail: jack@wildbear.on.ca
+
+
+
+
+
+
+
+
+
+
+
+De Winter Standards Track [Page 7]
+
diff --git a/Documentation/en/rfc/rfc2034.txt b/Documentation/en/rfc/rfc2034.txt
new file mode 100644
index 00000000..14f0ab3e
--- /dev/null
+++ b/Documentation/en/rfc/rfc2034.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group N. Freed
+Request for Comments: RFC 2034 Innosoft
+Category: Standards Track October 1996
+
+
+ SMTP Service Extension for
+ Returning Enhanced Error Codes
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Abstract
+
+ This memo defines an extension to the SMTP service [RFC-821, RFC-
+ 1869] whereby an SMTP server augments its responses with the enhanced
+ mail system status codes defined in RFC 1893. These codes can then
+ be used to provide more informative explanations of error conditions,
+ especially in the context of the delivery status notifications format
+ defined in RFC 1894.
+
+2. Introduction
+
+ Although SMTP is widely and robustly deployed, various extensions
+ have been requested by parts of the Internet community. In
+ particular, in the modern, international, and multilingual Internet a
+ need exists to assign codes to specific error conditions that can be
+ translated into different languages. RFC 1893 defines such a set of
+ status codes and RFC 1894 defines a mechanism to send such coded
+ material to users. However, in many cases the agent creating the RFC
+ 1894 delivery status notification is doing so in response to errors
+ it received from a remote SMTP server.
+
+ As such, remote servers need a mechanism for embedding enhanced
+ status codes in their responses as well as a way to indicate to a
+ client when they are in fact doing this. This memo uses the SMTP
+ extension mechanism described in RFC 1869 to define such a mechanism.
+
+
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 1]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+3. Framework for the Enhanced Error Statuses Extension
+
+ The enhanced error statuses transport extension is laid out as
+ follows:
+
+ (1) the name of the SMTP service extension defined here is
+ Enhanced-Status-Codes;
+
+ (2) the EHLO keyword value associated with the extension is
+ ENHANCEDSTATUSCODES;
+
+ (3) no parameter is used with the ENHANCEDSTATUSCODES EHLO
+ keyword;
+
+ (4) the text part of all 2xx, 4xx, and 5xx SMTP responses
+ other than the initial greeting and any response to
+ HELO or EHLO are prefaced with a status code as defined
+ in RFC 1893. This status code is always followed by one
+ or more spaces.
+
+ (5) no additional SMTP verbs are defined by this extension;
+ and,
+
+ (6) the next section specifies how support for the
+ extension affects the behavior of a server and client
+ SMTP.
+
+4. The Enhanced-Status-Codes service extension
+
+ Servers supporting the Enhanced-Status-Codes extension must preface
+ the text part of almost all response lines with a status code. As in
+ RFC 1893, the syntax of these status codes is given by the ABNF:
+
+ status-code ::= class "." subject "." detail
+ class ::= "2" / "4" / "5"
+ subject ::= 1*3digit
+ detail ::= 1*3digit
+
+ These codes must appear in all 2xx, 4xx, and 5xx response lines other
+ than initial greeting and any response to HELO or EHLO. Note that 3xx
+ responses are NOT included in this list.
+
+ All status codes returned by the server must agree with the primary
+ response code, that is, a 2xx response must incorporate a 2.X.X code,
+ a 4xx response must incorporate a 4.X.X code, and a 5xx response must
+ incorporate a 5.X.X code.
+
+
+
+
+
+Freed Standards Track [Page 2]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+ When responses are continued across multiple lines the same status
+ code must appear at the beginning of the text in each line of the
+ response.
+
+ Servers supporting this extension must attach enhanced status codes
+ to their responses regardless of whether or not EHLO is employed by
+ the client.
+
+5. Status Codes and Negotiation
+
+ This specification does not provide a means for clients to request
+ that status codes be returned or that they not be returned; a
+ compliant server includes these codes in the responses it sends
+ regardless of whether or not the client expects them. This is
+ somewhat different from most other SMTP extensions, where generally
+ speaking a client must specifically make a request before the
+ extended server behaves any differently than an unextended server.
+ The omission of client negotiation in this case is entirely
+ intentional: Given the generally poor state of SMTP server error code
+ implementation it is felt that any step taken towards more
+ comprehensible error codes is something that all clients, extended or
+ not, should benefit from.
+
+ IMPORTANT NOTE: The use of this approach in this extension should be
+ seen as a very special case. It MUST NOT be taken as a license for
+ future SMTP extensions to dramatically change the nature of SMTP
+ client-server interaction without proper announcement from the server
+ and a corresponding enabling command from the client.
+
+6. Usage Example
+
+ The following dialogue illustrates the use of enhanced status codes
+ by a server:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250-dbc.mtview.ca.us says hello
+ S: 250 ENHANCEDSTATUSCODES
+ C: MAIL FROM:<ned@ymir.claremont.edu>
+ S: 250 2.1.0 Originator <ned@ymir.claremont.edu> ok
+ C: RCPT TO:<mrose@dbc.mtview.ca.us>
+ S: 250 2.1.5 Recipient <mrose@dbc.mtview.ca.us> ok
+ C: RCPT TO:<nosuchuser@dbc.mtview.ca.us>
+ S: 550 5.1.1 Mailbox "nosuchuser" does not exist
+ C: RCPT TO:<remoteuser@isi.edu>
+ S: 551-5.7.1 Forwarding to remote hosts disabled
+
+
+
+Freed Standards Track [Page 3]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+ S: 551 5.7.1 Select another host to act as your forwarder
+ C: DATA
+ S: 354 Send message, ending in CRLF.CRLF.
+ ...
+ C: .
+ S: 250 2.6.0 Message accepted
+ C: QUIT
+ S: 221 2.0.0 Goodbye
+
+ The client that receives these responses might then send a
+ nondelivery notification of the general form:
+
+ Date: Mon, 11 Mar 1996 09:21:47 -0400
+ From: Mail Delivery Subsystem <mailer-daemon@ymir.claremont.edu>
+ Subject: Returned mail
+ To: <ned@ymir.claremont.edu>
+ MIME-Version: 1.0
+ Content-Type: multipart/report; report-type=delivery-status;
+ boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU"
+
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU
+ content-type: text/plain; charset=us-ascii
+
+ ----- Mail was successfully relayed to
+ the following addresses -----
+
+ <mrose@dbc.mtview.ca.us>
+
+ ----- The following addresses had delivery problems -----
+ <nosuchuser@dbc.mtview.ca.us>
+ (Mailbox "nosuchuser" does not exist)
+ <remoteuser@isi.edu>
+ (Forwarding to remote hosts disabled)
+
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU
+ content-type: message/delivery-status
+
+ Reporting-MTA: dns; ymir.claremont.edu
+
+ Original-Recipient: rfc822;mrose@dbc.mtview.ca.us
+ Final-Recipient: rfc822;mrose@dbc.mtview.ca.us
+ Action: relayed
+ Status: 2.1.5 (Destination address valid)
+ Diagnostic-Code: smtp;
+ 250 Recipient <mrose@dbc.mtview.ca.us> ok
+ Remote-MTA: dns; dbc.mtview.ca.us
+
+
+
+
+
+Freed Standards Track [Page 4]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+ Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
+ Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
+ Action: failed
+ Status: 5.1.1 (Bad destination mailbox address)
+ Diagnostic-Code: smtp;
+ 550 Mailbox "nosuchuser" does not exist
+ Remote-MTA: dns; dbc.mtview.ca.us
+
+ Original-Recipient: rfc822;remoteuser@isi.edu
+ Final-Recipient: rfc822;remoteuser@isi.edu
+ Action: failed
+ Status: 5.7.1 (Delivery not authorized, message refused)
+ Diagnostic-Code: smtp;
+ 551 Forwarding to remote hosts disabled
+ Select another host to act as your forwarder
+ Remote-MTA: dns; dbc.mtview.ca.us
+
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU
+ content-type: message/rfc822
+
+ [original message goes here]
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU--
+
+ Note that in order to reduce clutter the reporting MTA has omitted
+ enhanced status code information from the diagnostic-code fields it
+ has generated.
+
+7. Security Considerations
+
+ Additional detail in server responses axiomatically provides
+ additional information about the server. It is conceivable that
+ additional information of this sort may be of assistance in
+ circumventing server security. The advantages of provides additional
+ information must always be weighed against the security implications
+ of doing so.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 5]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+8. References
+
+ [RFC-821]
+ Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+ August, 1982. (August, 1982).
+
+ [RFC-1869]
+ Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed,
+ N., "SMTP Service Extensions", RFC 1869, November, 1995.
+
+ [RFC-1893]
+ Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
+ 1893, January, 1996.
+
+ [RFC-1894]
+ Moore, K., Vaudreuil, G., "An Extensible Message Format
+ for Delivery Status Notifications", RFC 1894, January,
+ 1996.
+
+9. Author Address
+
+ Ned Freed
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+ tel: +1 818 919 3600 fax: +1 818 919 3614
+ email: ned@innosoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 6]
+
diff --git a/Documentation/en/rfc/rfc2045.txt b/Documentation/en/rfc/rfc2045.txt
new file mode 100644
index 00000000..9f286b1a
--- /dev/null
+++ b/Documentation/en/rfc/rfc2045.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group N. Freed
+Request for Comments: 2045 Innosoft
+Obsoletes: 1521, 1522, 1590 N. Borenstein
+Category: Standards Track First Virtual
+ November 1996
+
+
+ Multipurpose Internet Mail Extensions
+ (MIME) Part One:
+ Format of Internet Message Bodies
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ STD 11, RFC 822, defines a message representation protocol specifying
+ considerable detail about US-ASCII message headers, and leaves the
+ message content, or message body, as flat US-ASCII text. This set of
+ documents, collectively called the Multipurpose Internet Mail
+ Extensions, or MIME, redefines the format of messages to allow for
+
+ (1) textual message bodies in character sets other than
+ US-ASCII,
+
+ (2) an extensible set of different formats for non-textual
+ message bodies,
+
+ (3) multi-part message bodies, and
+
+ (4) textual header information in character sets other than
+ US-ASCII.
+
+ These documents are based on earlier work documented in RFC 934, STD
+ 11, and RFC 1049, but extends and revises them. Because RFC 822 said
+ so little about message bodies, these documents are largely
+ orthogonal to (rather than a revision of) RFC 822.
+
+ This initial document specifies the various headers used to describe
+ the structure of MIME messages. The second document, RFC 2046,
+ defines the general structure of the MIME media typing system and
+ defines an initial set of media types. The third document, RFC 2047,
+ describes extensions to RFC 822 to allow non-US-ASCII text data in
+
+
+
+Freed & Borenstein Standards Track [Page 1]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ Internet mail header fields. The fourth document, RFC 2048, specifies
+ various IANA registration procedures for MIME-related facilities. The
+ fifth and final document, RFC 2049, describes MIME conformance
+ criteria as well as providing some illustrative examples of MIME
+ message formats, acknowledgements, and the bibliography.
+
+ These documents are revisions of RFCs 1521, 1522, and 1590, which
+ themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
+ 2049 describes differences and changes from previous versions.
+
+Table of Contents
+
+ 1. Introduction ......................................... 3
+ 2. Definitions, Conventions, and Generic BNF Grammar .... 5
+ 2.1 CRLF ................................................ 5
+ 2.2 Character Set ....................................... 6
+ 2.3 Message ............................................. 6
+ 2.4 Entity .............................................. 6
+ 2.5 Body Part ........................................... 7
+ 2.6 Body ................................................ 7
+ 2.7 7bit Data ........................................... 7
+ 2.8 8bit Data ........................................... 7
+ 2.9 Binary Data ......................................... 7
+ 2.10 Lines .............................................. 7
+ 3. MIME Header Fields ................................... 8
+ 4. MIME-Version Header Field ............................ 8
+ 5. Content-Type Header Field ............................ 10
+ 5.1 Syntax of the Content-Type Header Field ............. 12
+ 5.2 Content-Type Defaults ............................... 14
+ 6. Content-Transfer-Encoding Header Field ............... 14
+ 6.1 Content-Transfer-Encoding Syntax .................... 14
+ 6.2 Content-Transfer-Encodings Semantics ................ 15
+ 6.3 New Content-Transfer-Encodings ...................... 16
+ 6.4 Interpretation and Use .............................. 16
+ 6.5 Translating Encodings ............................... 18
+ 6.6 Canonical Encoding Model ............................ 19
+ 6.7 Quoted-Printable Content-Transfer-Encoding .......... 19
+ 6.8 Base64 Content-Transfer-Encoding .................... 24
+ 7. Content-ID Header Field .............................. 26
+ 8. Content-Description Header Field ..................... 27
+ 9. Additional MIME Header Fields ........................ 27
+ 10. Summary ............................................. 27
+ 11. Security Considerations ............................. 27
+ 12. Authors' Addresses .................................. 28
+ A. Collected Grammar .................................... 29
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 2]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+1. Introduction
+
+ Since its publication in 1982, RFC 822 has defined the standard
+ format of textual mail messages on the Internet. Its success has
+ been such that the RFC 822 format has been adopted, wholly or
+ partially, well beyond the confines of the Internet and the Internet
+ SMTP transport defined by RFC 821. As the format has seen wider use,
+ a number of limitations have proven increasingly restrictive for the
+ user community.
+
+ RFC 822 was intended to specify a format for text messages. As such,
+ non-text messages, such as multimedia messages that might include
+ audio or images, are simply not mentioned. Even in the case of text,
+ however, RFC 822 is inadequate for the needs of mail users whose
+ languages require the use of character sets richer than US-ASCII.
+ Since RFC 822 does not specify mechanisms for mail containing audio,
+ video, Asian language text, or even text in most European languages,
+ additional specifications are needed.
+
+ One of the notable limitations of RFC 821/822 based mail systems is
+ the fact that they limit the contents of electronic mail messages to
+ relatively short lines (e.g. 1000 characters or less [RFC-821]) of
+ 7bit US-ASCII. This forces users to convert any non-textual data
+ that they may wish to send into seven-bit bytes representable as
+ printable US-ASCII characters before invoking a local mail UA (User
+ Agent, a program with which human users send and receive mail).
+ Examples of such encodings currently used in the Internet include
+ pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in
+ RFC 1421, the Andrew Toolkit Representation [ATK], and many others.
+
+ The limitations of RFC 822 mail become even more apparent as gateways
+ are designed to allow for the exchange of mail messages between RFC
+ 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
+ inclusion of non-textual material within electronic mail messages.
+ The current standards for the mapping of X.400 messages to RFC 822
+ messages specify either that X.400 non-textual material must be
+ converted to (not encoded in) IA5Text format, or that they must be
+ discarded, notifying the RFC 822 user that discarding has occurred.
+ This is clearly undesirable, as information that a user may wish to
+ receive is lost. Even though a user agent may not have the
+ capability of dealing with the non-textual material, the user might
+ have some mechanism external to the UA that can extract useful
+ information from the material. Moreover, it does not allow for the
+ fact that the message may eventually be gatewayed back into an X.400
+ message handling system (i.e., the X.400 message is "tunneled"
+ through Internet mail), where the non-textual information would
+ definitely become useful again.
+
+
+
+
+Freed & Borenstein Standards Track [Page 3]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ This document describes several mechanisms that combine to solve most
+ of these problems without introducing any serious incompatibilities
+ with the existing world of RFC 822 mail. In particular, it
+ describes:
+
+ (1) A MIME-Version header field, which uses a version
+ number to declare a message to be conformant with MIME
+ and allows mail processing agents to distinguish
+ between such messages and those generated by older or
+ non-conformant software, which are presumed to lack
+ such a field.
+
+ (2) A Content-Type header field, generalized from RFC 1049,
+ which can be used to specify the media type and subtype
+ of data in the body of a message and to fully specify
+ the native representation (canonical form) of such
+ data.
+
+ (3) A Content-Transfer-Encoding header field, which can be
+ used to specify both the encoding transformation that
+ was applied to the body and the domain of the result.
+ Encoding transformations other than the identity
+ transformation are usually applied to data in order to
+ allow it to pass through mail transport mechanisms
+ which may have data or character set limitations.
+
+ (4) Two additional header fields that can be used to
+ further describe the data in a body, the Content-ID and
+ Content-Description header fields.
+
+ All of the header fields defined in this document are subject to the
+ general syntactic rules for header fields specified in RFC 822. In
+ particular, all of these header fields except for Content-Disposition
+ can include RFC 822 comments, which have no semantic content and
+ should be ignored during MIME processing.
+
+ Finally, to specify and promote interoperability, RFC 2049 provides a
+ basic applicability statement for a subset of the above mechanisms
+ that defines a minimal level of "conformance" with this document.
+
+ HISTORICAL NOTE: Several of the mechanisms described in this set of
+ documents may seem somewhat strange or even baroque at first reading.
+ It is important to note that compatibility with existing standards
+ AND robustness across existing practice were two of the highest
+ priorities of the working group that developed this set of documents.
+ In particular, compatibility was always favored over elegance.
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 4]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ Please refer to the current edition of the "Internet Official
+ Protocol Standards" for the standardization state and status of this
+ protocol. RFC 822 and STD 3, RFC 1123 also provide essential
+ background for MIME since no conforming implementation of MIME can
+ violate them. In addition, several other informational RFC documents
+ will be of interest to the MIME implementor, in particular RFC 1344,
+ RFC 1345, and RFC 1524.
+
+2. Definitions, Conventions, and Generic BNF Grammar
+
+ Although the mechanisms specified in this set of documents are all
+ described in prose, most are also described formally in the augmented
+ BNF notation of RFC 822. Implementors will need to be familiar with
+ this notation in order to understand this set of documents, and are
+ referred to RFC 822 for a complete explanation of the augmented BNF
+ notation.
+
+ Some of the augmented BNF in this set of documents makes named
+ references to syntax rules defined in RFC 822. A complete formal
+ grammar, then, is obtained by combining the collected grammar
+ appendices in each document in this set with the BNF of RFC 822 plus
+ the modifications to RFC 822 defined in RFC 1123 (which specifically
+ changes the syntax for `return', `date' and `mailbox').
+
+ All numeric and octet values are given in decimal notation in this
+ set of documents. All media type values, subtype values, and
+ parameter names as defined are case-insensitive. However, parameter
+ values are case-sensitive unless otherwise specified for the specific
+ parameter.
+
+ FORMATTING NOTE: Notes, such at this one, provide additional
+ nonessential information which may be skipped by the reader without
+ missing anything essential. The primary purpose of these non-
+ essential notes is to convey information about the rationale of this
+ set of documents, or to place these documents in the proper
+ historical or evolutionary context. Such information may in
+ particular be skipped by those who are focused entirely on building a
+ conformant implementation, but may be of use to those who wish to
+ understand why certain design choices were made.
+
+2.1. CRLF
+
+ The term CRLF, in this set of documents, refers to the sequence of
+ octets corresponding to the two US-ASCII characters CR (decimal value
+ 13) and LF (decimal value 10) which, taken together, in this order,
+ denote a line break in RFC 822 mail.
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 5]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+2.2. Character Set
+
+ The term "character set" is used in MIME to refer to a method of
+ converting a sequence of octets into a sequence of characters. Note
+ that unconditional and unambiguous conversion in the other direction
+ is not required, in that not all characters may be representable by a
+ given character set and a character set may provide more than one
+ sequence of octets to represent a particular sequence of characters.
+
+ This definition is intended to allow various kinds of character
+ encodings, from simple single-table mappings such as US-ASCII to
+ complex table switching methods such as those that use ISO 2022's
+ techniques, to be used as character sets. However, the definition
+ associated with a MIME character set name must fully specify the
+ mapping to be performed. In particular, use of external profiling
+ information to determine the exact mapping is not permitted.
+
+ NOTE: The term "character set" was originally to describe such
+ straightforward schemes as US-ASCII and ISO-8859-1 which have a
+ simple one-to-one mapping from single octets to single characters.
+ Multi-octet coded character sets and switching techniques make the
+ situation more complex. For example, some communities use the term
+ "character encoding" for what MIME calls a "character set", while
+ using the phrase "coded character set" to denote an abstract mapping
+ from integers (not octets) to characters.
+
+2.3. Message
+
+ The term "message", when not further qualified, means either a
+ (complete or "top-level") RFC 822 message being transferred on a
+ network, or a message encapsulated in a body of type "message/rfc822"
+ or "message/partial".
+
+2.4. Entity
+
+ The term "entity", refers specifically to the MIME-defined header
+ fields and contents of either a message or one of the parts in the
+ body of a multipart entity. The specification of such entities is
+ the essence of MIME. Since the contents of an entity are often
+ called the "body", it makes sense to speak about the body of an
+ entity. Any sort of field may be present in the header of an entity,
+ but only those fields whose names begin with "content-" actually have
+ any MIME-related meaning. Note that this does NOT imply thay they
+ have no meaning at all -- an entity that is also a message has non-
+ MIME header fields whose meanings are defined by RFC 822.
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 6]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+2.5. Body Part
+
+ The term "body part" refers to an entity inside of a multipart
+ entity.
+
+2.6. Body
+
+ The term "body", when not further qualified, means the body of an
+ entity, that is, the body of either a message or of a body part.
+
+ NOTE: The previous four definitions are clearly circular. This is
+ unavoidable, since the overall structure of a MIME message is indeed
+ recursive.
+
+2.7. 7bit Data
+
+ "7bit data" refers to data that is all represented as relatively
+ short lines with 998 octets or less between CRLF line separation
+ sequences [RFC-821]. No octets with decimal values greater than 127
+ are allowed and neither are NULs (octets with decimal value 0). CR
+ (decimal value 13) and LF (decimal value 10) octets only occur as
+ part of CRLF line separation sequences.
+
+2.8. 8bit Data
+
+ "8bit data" refers to data that is all represented as relatively
+ short lines with 998 octets or less between CRLF line separation
+ sequences [RFC-821]), but octets with decimal values greater than 127
+ may be used. As with "7bit data" CR and LF octets only occur as part
+ of CRLF line separation sequences and no NULs are allowed.
+
+2.9. Binary Data
+
+ "Binary data" refers to data where any sequence of octets whatsoever
+ is allowed.
+
+2.10. Lines
+
+ "Lines" are defined as sequences of octets separated by a CRLF
+ sequences. This is consistent with both RFC 821 and RFC 822.
+ "Lines" only refers to a unit of data in a message, which may or may
+ not correspond to something that is actually displayed by a user
+ agent.
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 7]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+3. MIME Header Fields
+
+ MIME defines a number of new RFC 822 header fields that are used to
+ describe the content of a MIME entity. These header fields occur in
+ at least two contexts:
+
+ (1) As part of a regular RFC 822 message header.
+
+ (2) In a MIME body part header within a multipart
+ construct.
+
+ The formal definition of these header fields is as follows:
+
+ entity-headers := [ content CRLF ]
+ [ encoding CRLF ]
+ [ id CRLF ]
+ [ description CRLF ]
+ *( MIME-extension-field CRLF )
+
+ MIME-message-headers := entity-headers
+ fields
+ version CRLF
+ ; The ordering of the header
+ ; fields implied by this BNF
+ ; definition should be ignored.
+
+ MIME-part-headers := entity-headers
+ [ fields ]
+ ; Any field not beginning with
+ ; "content-" can have no defined
+ ; meaning and may be ignored.
+ ; The ordering of the header
+ ; fields implied by this BNF
+ ; definition should be ignored.
+
+ The syntax of the various specific MIME header fields will be
+ described in the following sections.
+
+4. MIME-Version Header Field
+
+ Since RFC 822 was published in 1982, there has really been only one
+ format standard for Internet messages, and there has been little
+ perceived need to declare the format standard in use. This document
+ is an independent specification that complements RFC 822. Although
+ the extensions in this document have been defined in such a way as to
+ be compatible with RFC 822, there are still circumstances in which it
+ might be desirable for a mail-processing agent to know whether a
+ message was composed with the new standard in mind.
+
+
+
+Freed & Borenstein Standards Track [Page 8]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ Therefore, this document defines a new header field, "MIME-Version",
+ which is to be used to declare the version of the Internet message
+ body format standard in use.
+
+ Messages composed in accordance with this document MUST include such
+ a header field, with the following verbatim text:
+
+ MIME-Version: 1.0
+
+ The presence of this header field is an assertion that the message
+ has been composed in compliance with this document.
+
+ Since it is possible that a future document might extend the message
+ format standard again, a formal BNF is given for the content of the
+ MIME-Version field:
+
+ version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+ Thus, future format specifiers, which might replace or extend "1.0",
+ are constrained to be two integer fields, separated by a period. If
+ a message is received with a MIME-version value other than "1.0", it
+ cannot be assumed to conform with this document.
+
+ Note that the MIME-Version header field is required at the top level
+ of a message. It is not required for each body part of a multipart
+ entity. It is required for the embedded headers of a body of type
+ "message/rfc822" or "message/partial" if and only if the embedded
+ message is itself claimed to be MIME-conformant.
+
+ It is not possible to fully specify how a mail reader that conforms
+ with MIME as defined in this document should treat a message that
+ might arrive in the future with some value of MIME-Version other than
+ "1.0".
+
+ It is also worth noting that version control for specific media types
+ is not accomplished using the MIME-Version mechanism. In particular,
+ some formats (such as application/postscript) have version numbering
+ conventions that are internal to the media format. Where such
+ conventions exist, MIME does nothing to supersede them. Where no
+ such conventions exist, a MIME media type might use a "version"
+ parameter in the content-type field if necessary.
+
+
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 9]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ NOTE TO IMPLEMENTORS: When checking MIME-Version values any RFC 822
+ comment strings that are present must be ignored. In particular, the
+ following four MIME-Version fields are equivalent:
+
+ MIME-Version: 1.0
+
+ MIME-Version: 1.0 (produced by MetaSend Vx.x)
+
+ MIME-Version: (produced by MetaSend Vx.x) 1.0
+
+ MIME-Version: 1.(produced by MetaSend Vx.x)0
+
+ In the absence of a MIME-Version field, a receiving mail user agent
+ (whether conforming to MIME requirements or not) may optionally
+ choose to interpret the body of the message according to local
+ conventions. Many such conventions are currently in use and it
+ should be noted that in practice non-MIME messages can contain just
+ about anything.
+
+ It is impossible to be certain that a non-MIME mail message is
+ actually plain text in the US-ASCII character set since it might well
+ be a message that, using some set of nonstandard local conventions
+ that predate MIME, includes text in another character set or non-
+ textual data presented in a manner that cannot be automatically
+ recognized (e.g., a uuencoded compressed UNIX tar file).
+
+5. Content-Type Header Field
+
+ The purpose of the Content-Type field is to describe the data
+ contained in the body fully enough that the receiving user agent can
+ pick an appropriate agent or mechanism to present the data to the
+ user, or otherwise deal with the data in an appropriate manner. The
+ value in this field is called a media type.
+
+ HISTORICAL NOTE: The Content-Type header field was first defined in
+ RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one
+ that is largely compatible with the mechanism given here.
+
+ The Content-Type header field specifies the nature of the data in the
+ body of an entity by giving media type and subtype identifiers, and
+ by providing auxiliary information that may be required for certain
+ media types. After the media type and subtype names, the remainder
+ of the header field is simply a set of parameters, specified in an
+ attribute=value notation. The ordering of parameters is not
+ significant.
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 10]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ In general, the top-level media type is used to declare the general
+ type of data, while the subtype specifies a specific format for that
+ type of data. Thus, a media type of "image/xyz" is enough to tell a
+ user agent that the data is an image, even if the user agent has no
+ knowledge of the specific image format "xyz". Such information can
+ be used, for example, to decide whether or not to show a user the raw
+ data from an unrecognized subtype -- such an action might be
+ reasonable for unrecognized subtypes of text, but not for
+ unrecognized subtypes of image or audio. For this reason, registered
+ subtypes of text, image, audio, and video should not contain embedded
+ information that is really of a different type. Such compound
+ formats should be represented using the "multipart" or "application"
+ types.
+
+ Parameters are modifiers of the media subtype, and as such do not
+ fundamentally affect the nature of the content. The set of
+ meaningful parameters depends on the media type and subtype. Most
+ parameters are associated with a single specific subtype. However, a
+ given top-level media type may define parameters which are applicable
+ to any subtype of that type. Parameters may be required by their
+ defining content type or subtype or they may be optional. MIME
+ implementations must ignore any parameters whose names they do not
+ recognize.
+
+ For example, the "charset" parameter is applicable to any subtype of
+ "text", while the "boundary" parameter is required for any subtype of
+ the "multipart" media type.
+
+ There are NO globally-meaningful parameters that apply to all media
+ types. Truly global mechanisms are best addressed, in the MIME
+ model, by the definition of additional Content-* header fields.
+
+ An initial set of seven top-level media types is defined in RFC 2046.
+ Five of these are discrete types whose content is essentially opaque
+ as far as MIME processing is concerned. The remaining two are
+ composite types whose contents require additional handling by MIME
+ processors.
+
+ This set of top-level media types is intended to be substantially
+ complete. It is expected that additions to the larger set of
+ supported types can generally be accomplished by the creation of new
+ subtypes of these initial types. In the future, more top-level types
+ may be defined only by a standards-track extension to this standard.
+ If another top-level type is to be used for any reason, it must be
+ given a name starting with "X-" to indicate its non-standard status
+ and to avoid a potential conflict with a future official name.
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 11]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+5.1. Syntax of the Content-Type Header Field
+
+ In the Augmented BNF notation of RFC 822, a Content-Type header field
+ value is defined as follows:
+
+ content := "Content-Type" ":" type "/" subtype
+ *(";" parameter)
+ ; Matching of media type and subtype
+ ; is ALWAYS case-insensitive.
+
+ type := discrete-type / composite-type
+
+ discrete-type := "text" / "image" / "audio" / "video" /
+ "application" / extension-token
+
+ composite-type := "message" / "multipart" / extension-token
+
+ extension-token := ietf-token / x-token
+
+ ietf-token := <An extension token defined by a
+ standards-track RFC and registered
+ with IANA.>
+
+ x-token := <The two characters "X-" or "x-" followed, with
+ no intervening white space, by any token>
+
+ subtype := extension-token / iana-token
+
+ iana-token := <A publicly-defined extension token. Tokens
+ of this form must be registered with IANA
+ as specified in RFC 2048.>
+
+ parameter := attribute "=" value
+
+ attribute := token
+ ; Matching of attributes
+ ; is ALWAYS case-insensitive.
+
+ value := token / quoted-string
+
+ token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
+ or tspecials>
+
+ tspecials := "(" / ")" / "<" / ">" / "@" /
+ "," / ";" / ":" / "\" / <">
+ "/" / "[" / "]" / "?" / "="
+ ; Must be in quoted-string,
+ ; to use within parameter values
+
+
+
+Freed & Borenstein Standards Track [Page 12]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ Note that the definition of "tspecials" is the same as the RFC 822
+ definition of "specials" with the addition of the three characters
+ "/", "?", and "=", and the removal of ".".
+
+ Note also that a subtype specification is MANDATORY -- it may not be
+ omitted from a Content-Type header field. As such, there are no
+ default subtypes.
+
+ The type, subtype, and parameter names are not case sensitive. For
+ example, TEXT, Text, and TeXt are all equivalent top-level media
+ types. Parameter values are normally case sensitive, but sometimes
+ are interpreted in a case-insensitive fashion, depending on the
+ intended use. (For example, multipart boundaries are case-sensitive,
+ but the "access-type" parameter for message/External-body is not
+ case-sensitive.)
+
+ Note that the value of a quoted string parameter does not include the
+ quotes. That is, the quotation marks in a quoted-string are not a
+ part of the value of the parameter, but are merely used to delimit
+ that parameter value. In addition, comments are allowed in
+ accordance with RFC 822 rules for structured header fields. Thus the
+ following two forms
+
+ Content-type: text/plain; charset=us-ascii (Plain text)
+
+ Content-type: text/plain; charset="us-ascii"
+
+ are completely equivalent.
+
+ Beyond this syntax, the only syntactic constraint on the definition
+ of subtype names is the desire that their uses must not conflict.
+ That is, it would be undesirable to have two different communities
+ using "Content-Type: application/foobar" to mean two different
+ things. The process of defining new media subtypes, then, is not
+ intended to be a mechanism for imposing restrictions, but simply a
+ mechanism for publicizing their definition and usage. There are,
+ therefore, two acceptable mechanisms for defining new media subtypes:
+
+ (1) Private values (starting with "X-") may be defined
+ bilaterally between two cooperating agents without
+ outside registration or standardization. Such values
+ cannot be registered or standardized.
+
+ (2) New standard values should be registered with IANA as
+ described in RFC 2048.
+
+ The second document in this set, RFC 2046, defines the initial set of
+ media types for MIME.
+
+
+
+Freed & Borenstein Standards Track [Page 13]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+5.2. Content-Type Defaults
+
+ Default RFC 822 messages without a MIME Content-Type header are taken
+ by this protocol to be plain text in the US-ASCII character set,
+ which can be explicitly specified as:
+
+ Content-type: text/plain; charset=us-ascii
+
+ This default is assumed if no Content-Type header field is specified.
+ It is also recommend that this default be assumed when a
+ syntactically invalid Content-Type header field is encountered. In
+ the presence of a MIME-Version header field and the absence of any
+ Content-Type header field, a receiving User Agent can also assume
+ that plain US-ASCII text was the sender's intent. Plain US-ASCII
+ text may still be assumed in the absence of a MIME-Version or the
+ presence of an syntactically invalid Content-Type header field, but
+ the sender's intent might have been otherwise.
+
+6. Content-Transfer-Encoding Header Field
+
+ Many media types which could be usefully transported via email are
+ represented, in their "natural" format, as 8bit character or binary
+ data. Such data cannot be transmitted over some transfer protocols.
+ For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
+ data with lines no longer than 1000 characters including any trailing
+ CRLF line separator.
+
+ It is necessary, therefore, to define a standard mechanism for
+ encoding such data into a 7bit short line format. Proper labelling
+ of unencoded material in less restrictive formats for direct use over
+ less restrictive transports is also desireable. This document
+ specifies that such encodings will be indicated by a new "Content-
+ Transfer-Encoding" header field. This field has not been defined by
+ any previous standard.
+
+6.1. Content-Transfer-Encoding Syntax
+
+ The Content-Transfer-Encoding field's value is a single token
+ specifying the type of encoding, as enumerated below. Formally:
+
+ encoding := "Content-Transfer-Encoding" ":" mechanism
+
+ mechanism := "7bit" / "8bit" / "binary" /
+ "quoted-printable" / "base64" /
+ ietf-token / x-token
+
+ These values are not case sensitive -- Base64 and BASE64 and bAsE64
+ are all equivalent. An encoding type of 7BIT requires that the body
+
+
+
+Freed & Borenstein Standards Track [Page 14]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ is already in a 7bit mail-ready representation. This is the default
+ value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the
+ Content-Transfer-Encoding header field is not present.
+
+6.2. Content-Transfer-Encodings Semantics
+
+ This single Content-Transfer-Encoding token actually provides two
+ pieces of information. It specifies what sort of encoding
+ transformation the body was subjected to and hence what decoding
+ operation must be used to restore it to its original form, and it
+ specifies what the domain of the result is.
+
+ The transformation part of any Content-Transfer-Encodings specifies,
+ either explicitly or implicitly, a single, well-defined decoding
+ algorithm, which for any sequence of encoded octets either transforms
+ it to the original sequence of octets which was encoded, or shows
+ that it is illegal as an encoded sequence. Content-Transfer-
+ Encodings transformations never depend on any additional external
+ profile information for proper operation. Note that while decoders
+ must produce a single, well-defined output for a valid encoding no
+ such restrictions exist for encoders: Encoding a given sequence of
+ octets to different, equivalent encoded sequences is perfectly legal.
+
+ Three transformations are currently defined: identity, the "quoted-
+ printable" encoding, and the "base64" encoding. The domains are
+ "binary", "8bit" and "7bit".
+
+ The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
+ mean that the identity (i.e. NO) encoding transformation has been
+ performed. As such, they serve simply as indicators of the domain of
+ the body data, and provide useful information about the sort of
+ encoding that might be needed for transmission in a given transport
+ system. The terms "7bit data", "8bit data", and "binary data" are
+ all defined in Section 2.
+
+ The quoted-printable and base64 encodings transform their input from
+ an arbitrary domain into material in the "7bit" range, thus making it
+ safe to carry over restricted transports. The specific definition of
+ the transformations are given below.
+
+ The proper Content-Transfer-Encoding label must always be used.
+ Labelling unencoded data containing 8bit characters as "7bit" is not
+ allowed, nor is labelling unencoded non-line-oriented data as
+ anything other than "binary" allowed.
+
+ Unlike media subtypes, a proliferation of Content-Transfer-Encoding
+ values is both undesirable and unnecessary. However, establishing
+ only a single transformation into the "7bit" domain does not seem
+
+
+
+Freed & Borenstein Standards Track [Page 15]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ possible. There is a tradeoff between the desire for a compact and
+ efficient encoding of largely- binary data and the desire for a
+ somewhat readable encoding of data that is mostly, but not entirely,
+ 7bit. For this reason, at least two encoding mechanisms are
+ necessary: a more or less readable encoding (quoted-printable) and a
+ "dense" or "uniform" encoding (base64).
+
+ Mail transport for unencoded 8bit data is defined in RFC 1652. As of
+ the initial publication of this document, there are no standardized
+ Internet mail transports for which it is legitimate to include
+ unencoded binary data in mail bodies. Thus there are no
+ circumstances in which the "binary" Content-Transfer-Encoding is
+ actually valid in Internet mail. However, in the event that binary
+ mail transport becomes a reality in Internet mail, or when MIME is
+ used in conjunction with any other binary-capable mail transport
+ mechanism, binary bodies must be labelled as such using this
+ mechanism.
+
+ NOTE: The five values defined for the Content-Transfer-Encoding field
+ imply nothing about the media type other than the algorithm by which
+ it was encoded or the transport system requirements if unencoded.
+
+6.3. New Content-Transfer-Encodings
+
+ Implementors may, if necessary, define private Content-Transfer-
+ Encoding values, but must use an x-token, which is a name prefixed by
+ "X-", to indicate its non-standard status, e.g., "Content-Transfer-
+ Encoding: x-my-new-encoding". Additional standardized Content-
+ Transfer-Encoding values must be specified by a standards-track RFC.
+ The requirements such specifications must meet are given in RFC 2048.
+ As such, all content-transfer-encoding namespace except that
+ beginning with "X-" is explicitly reserved to the IETF for future
+ use.
+
+ Unlike media types and subtypes, the creation of new Content-
+ Transfer-Encoding values is STRONGLY discouraged, as it seems likely
+ to hinder interoperability with little potential benefit
+
+6.4. Interpretation and Use
+
+ If a Content-Transfer-Encoding header field appears as part of a
+ message header, it applies to the entire body of that message. If a
+ Content-Transfer-Encoding header field appears as part of an entity's
+ headers, it applies only to the body of that entity. If an entity is
+ of type "multipart" the Content-Transfer-Encoding is not permitted to
+ have any value other than "7bit", "8bit" or "binary". Even more
+ severe restrictions apply to some subtypes of the "message" type.
+
+
+
+
+Freed & Borenstein Standards Track [Page 16]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ It should be noted that most media types are defined in terms of
+ octets rather than bits, so that the mechanisms described here are
+ mechanisms for encoding arbitrary octet streams, not bit streams. If
+ a bit stream is to be encoded via one of these mechanisms, it must
+ first be converted to an 8bit byte stream using the network standard
+ bit order ("big-endian"), in which the earlier bits in a stream
+ become the higher-order bits in a 8bit byte. A bit stream not ending
+ at an 8bit boundary must be padded with zeroes. RFC 2046 provides a
+ mechanism for noting the addition of such padding in the case of the
+ application/octet-stream media type, which has a "padding" parameter.
+
+ The encoding mechanisms defined here explicitly encode all data in
+ US-ASCII. Thus, for example, suppose an entity has header fields
+ such as:
+
+ Content-Type: text/plain; charset=ISO-8859-1
+ Content-transfer-encoding: base64
+
+ This must be interpreted to mean that the body is a base64 US-ASCII
+ encoding of data that was originally in ISO-8859-1, and will be in
+ that character set again after decoding.
+
+ Certain Content-Transfer-Encoding values may only be used on certain
+ media types. In particular, it is EXPRESSLY FORBIDDEN to use any
+ encodings other than "7bit", "8bit", or "binary" with any composite
+ media type, i.e. one that recursively includes other Content-Type
+ fields. Currently the only composite media types are "multipart" and
+ "message". All encodings that are desired for bodies of type
+ multipart or message must be done at the innermost level, by encoding
+ the actual body that needs to be encoded.
+
+ It should also be noted that, by definition, if a composite entity
+ has a transfer-encoding value such as "7bit", but one of the enclosed
+ entities has a less restrictive value such as "8bit", then either the
+ outer "7bit" labelling is in error, because 8bit data are included,
+ or the inner "8bit" labelling placed an unnecessarily high demand on
+ the transport system because the actual included data were actually
+ 7bit-safe.
+
+ NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using
+ content-transfer-encodings on composite body data may seem overly
+ restrictive, it is necessary to prevent nested encodings, in which
+ data are passed through an encoding algorithm multiple times, and
+ must be decoded multiple times in order to be properly viewed.
+ Nested encodings add considerable complexity to user agents: Aside
+ from the obvious efficiency problems with such multiple encodings,
+ they can obscure the basic structure of a message. In particular,
+ they can imply that several decoding operations are necessary simply
+
+
+
+Freed & Borenstein Standards Track [Page 17]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ to find out what types of bodies a message contains. Banning nested
+ encodings may complicate the job of certain mail gateways, but this
+ seems less of a problem than the effect of nested encodings on user
+ agents.
+
+ Any entity with an unrecognized Content-Transfer-Encoding must be
+ treated as if it has a Content-Type of "application/octet-stream",
+ regardless of what the Content-Type header field actually says.
+
+ NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-TRANSFER-
+ ENCODING: It may seem that the Content-Transfer-Encoding could be
+ inferred from the characteristics of the media that is to be encoded,
+ or, at the very least, that certain Content-Transfer-Encodings could
+ be mandated for use with specific media types. There are several
+ reasons why this is not the case. First, given the varying types of
+ transports used for mail, some encodings may be appropriate for some
+ combinations of media types and transports but not for others. (For
+ example, in an 8bit transport, no encoding would be required for text
+ in certain character sets, while such encodings are clearly required
+ for 7bit SMTP.)
+
+ Second, certain media types may require different types of transfer
+ encoding under different circumstances. For example, many PostScript
+ bodies might consist entirely of short lines of 7bit data and hence
+ require no encoding at all. Other PostScript bodies (especially
+ those using Level 2 PostScript's binary encoding mechanism) may only
+ be reasonably represented using a binary transport encoding.
+ Finally, since the Content-Type field is intended to be an open-ended
+ specification mechanism, strict specification of an association
+ between media types and encodings effectively couples the
+ specification of an application protocol with a specific lower-level
+ transport. This is not desirable since the developers of a media
+ type should not have to be aware of all the transports in use and
+ what their limitations are.
+
+6.5. Translating Encodings
+
+ The quoted-printable and base64 encodings are designed so that
+ conversion between them is possible. The only issue that arises in
+ such a conversion is the handling of hard line breaks in quoted-
+ printable encoding output. When converting from quoted-printable to
+ base64 a hard line break in the quoted-printable form represents a
+ CRLF sequence in the canonical form of the data. It must therefore be
+ converted to a corresponding encoded CRLF in the base64 form of the
+ data. Similarly, a CRLF sequence in the canonical form of the data
+ obtained after base64 decoding must be converted to a quoted-
+ printable hard line break, but ONLY when converting text data.
+
+
+
+
+Freed & Borenstein Standards Track [Page 18]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+6.6. Canonical Encoding Model
+
+ There was some confusion, in the previous versions of this RFC,
+ regarding the model for when email data was to be converted to
+ canonical form and encoded, and in particular how this process would
+ affect the treatment of CRLFs, given that the representation of
+ newlines varies greatly from system to system, and the relationship
+ between content-transfer-encodings and character sets. A canonical
+ model for encoding is presented in RFC 2049 for this reason.
+
+6.7. Quoted-Printable Content-Transfer-Encoding
+
+ The Quoted-Printable encoding is intended to represent data that
+ largely consists of octets that correspond to printable characters in
+ the US-ASCII character set. It encodes the data in such a way that
+ the resulting octets are unlikely to be modified by mail transport.
+ If the data being encoded are mostly US-ASCII text, the encoded form
+ of the data remains largely recognizable by humans. A body which is
+ entirely US-ASCII may also be encoded in Quoted-Printable to ensure
+ the integrity of the data should the message pass through a
+ character-translating, and/or line-wrapping gateway.
+
+ In this encoding, octets are to be represented as determined by the
+ following rules:
+
+ (1) (General 8bit representation) Any octet, except a CR or
+ LF that is part of a CRLF line break of the canonical
+ (standard) form of the data being encoded, may be
+ represented by an "=" followed by a two digit
+ hexadecimal representation of the octet's value. The
+ digits of the hexadecimal alphabet, for this purpose,
+ are "0123456789ABCDEF". Uppercase letters must be
+ used; lowercase letters are not allowed. Thus, for
+ example, the decimal value 12 (US-ASCII form feed) can
+ be represented by "=0C", and the decimal value 61 (US-
+ ASCII EQUAL SIGN) can be represented by "=3D". This
+ rule must be followed except when the following rules
+ allow an alternative encoding.
+
+ (2) (Literal representation) Octets with decimal values of
+ 33 through 60 inclusive, and 62 through 126, inclusive,
+ MAY be represented as the US-ASCII characters which
+ correspond to those octets (EXCLAMATION POINT through
+ LESS THAN, and GREATER THAN through TILDE,
+ respectively).
+
+ (3) (White Space) Octets with values of 9 and 32 MAY be
+ represented as US-ASCII TAB (HT) and SPACE characters,
+
+
+
+Freed & Borenstein Standards Track [Page 19]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ respectively, but MUST NOT be so represented at the end
+ of an encoded line. Any TAB (HT) or SPACE characters
+ on an encoded line MUST thus be followed on that line
+ by a printable character. In particular, an "=" at the
+ end of an encoded line, indicating a soft line break
+ (see rule #5) may follow one or more TAB (HT) or SPACE
+ characters. It follows that an octet with decimal
+ value 9 or 32 appearing at the end of an encoded line
+ must be represented according to Rule #1. This rule is
+ necessary because some MTAs (Message Transport Agents,
+ programs which transport messages from one user to
+ another, or perform a portion of such transfers) are
+ known to pad lines of text with SPACEs, and others are
+ known to remove "white space" characters from the end
+ of a line. Therefore, when decoding a Quoted-Printable
+ body, any trailing white space on a line must be
+ deleted, as it will necessarily have been added by
+ intermediate transport agents.
+
+ (4) (Line Breaks) A line break in a text body, represented
+ as a CRLF sequence in the text canonical form, must be
+ represented by a (RFC 822) line break, which is also a
+ CRLF sequence, in the Quoted-Printable encoding. Since
+ the canonical representation of media types other than
+ text do not generally include the representation of
+ line breaks as CRLF sequences, no hard line breaks
+ (i.e. line breaks that are intended to be meaningful
+ and to be displayed to the user) can occur in the
+ quoted-printable encoding of such types. Sequences
+ like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely
+ appear in non-text data represented in quoted-
+ printable, of course.
+
+ Note that many implementations may elect to encode the
+ local representation of various content types directly
+ rather than converting to canonical form first,
+ encoding, and then converting back to local
+ representation. In particular, this may apply to plain
+ text material on systems that use newline conventions
+ other than a CRLF terminator sequence. Such an
+ implementation optimization is permissible, but only
+ when the combined canonicalization-encoding step is
+ equivalent to performing the three steps separately.
+
+ (5) (Soft Line Breaks) The Quoted-Printable encoding
+ REQUIRES that encoded lines be no more than 76
+ characters long. If longer lines are to be encoded
+ with the Quoted-Printable encoding, "soft" line breaks
+
+
+
+Freed & Borenstein Standards Track [Page 20]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ must be used. An equal sign as the last character on a
+ encoded line indicates such a non-significant ("soft")
+ line break in the encoded text.
+
+ Thus if the "raw" form of the line is a single unencoded line that
+ says:
+
+ Now's the time for all folk to come to the aid of their country.
+
+ This can be represented, in the Quoted-Printable encoding, as:
+
+ Now's the time =
+ for all folk to come=
+ to the aid of their country.
+
+ This provides a mechanism with which long lines are encoded in such a
+ way as to be restored by the user agent. The 76 character limit does
+ not count the trailing CRLF, but counts all other characters,
+ including any equal signs.
+
+ Since the hyphen character ("-") may be represented as itself in the
+ Quoted-Printable encoding, care must be taken, when encapsulating a
+ quoted-printable encoded body inside one or more multipart entities,
+ to ensure that the boundary delimiter does not appear anywhere in the
+ encoded body. (A good strategy is to choose a boundary that includes
+ a character sequence such as "=_" which can never appear in a
+ quoted-printable body. See the definition of multipart messages in
+ RFC 2046.)
+
+ NOTE: The quoted-printable encoding represents something of a
+ compromise between readability and reliability in transport. Bodies
+ encoded with the quoted-printable encoding will work reliably over
+ most mail gateways, but may not work perfectly over a few gateways,
+ notably those involving translation into EBCDIC. A higher level of
+ confidence is offered by the base64 Content-Transfer-Encoding. A way
+ to get reasonably reliable transport through EBCDIC gateways is to
+ also quote the US-ASCII characters
+
+ !"#$@[\]^`{|}~
+
+ according to rule #1.
+
+ Because quoted-printable data is generally assumed to be line-
+ oriented, it is to be expected that the representation of the breaks
+ between the lines of quoted-printable data may be altered in
+ transport, in the same manner that plain text mail has always been
+ altered in Internet mail when passing between systems with differing
+ newline conventions. If such alterations are likely to constitute a
+
+
+
+Freed & Borenstein Standards Track [Page 21]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ corruption of the data, it is probably more sensible to use the
+ base64 encoding rather than the quoted-printable encoding.
+
+ NOTE: Several kinds of substrings cannot be generated according to
+ the encoding rules for the quoted-printable content-transfer-
+ encoding, and hence are formally illegal if they appear in the output
+ of a quoted-printable encoder. This note enumerates these cases and
+ suggests ways to handle such illegal substrings if any are
+ encountered in quoted-printable data that is to be decoded.
+
+ (1) An "=" followed by two hexadecimal digits, one or both
+ of which are lowercase letters in "abcdef", is formally
+ illegal. A robust implementation might choose to
+ recognize them as the corresponding uppercase letters.
+
+ (2) An "=" followed by a character that is neither a
+ hexadecimal digit (including "abcdef") nor the CR
+ character of a CRLF pair is illegal. This case can be
+ the result of US-ASCII text having been included in a
+ quoted-printable part of a message without itself
+ having been subjected to quoted-printable encoding. A
+ reasonable approach by a robust implementation might be
+ to include the "=" character and the following
+ character in the decoded data without any
+ transformation and, if possible, indicate to the user
+ that proper decoding was not possible at this point in
+ the data.
+
+ (3) An "=" cannot be the ultimate or penultimate character
+ in an encoded object. This could be handled as in case
+ (2) above.
+
+ (4) Control characters other than TAB, or CR and LF as
+ parts of CRLF pairs, must not appear. The same is true
+ for octets with decimal values greater than 126. If
+ found in incoming quoted-printable data by a decoder, a
+ robust implementation might exclude them from the
+ decoded data and warn the user that illegal characters
+ were discovered.
+
+ (5) Encoded lines must not be longer than 76 characters,
+ not counting the trailing CRLF. If longer lines are
+ found in incoming, encoded data, a robust
+ implementation might nevertheless decode the lines, and
+ might report the erroneous encoding to the user.
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 22]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ WARNING TO IMPLEMENTORS: If binary data is encoded in quoted-
+ printable, care must be taken to encode CR and LF characters as "=0D"
+ and "=0A", respectively. In particular, a CRLF sequence in binary
+ data should be encoded as "=0D=0A". Otherwise, if CRLF were
+ represented as a hard line break, it might be incorrectly decoded on
+ platforms with different line break conventions.
+
+ For formalists, the syntax of quoted-printable data is described by
+ the following grammar:
+
+ quoted-printable := qp-line *(CRLF qp-line)
+
+ qp-line := *(qp-segment transport-padding CRLF)
+ qp-part transport-padding
+
+ qp-part := qp-section
+ ; Maximum length of 76 characters
+
+ qp-segment := qp-section *(SPACE / TAB) "="
+ ; Maximum length of 76 characters
+
+ qp-section := [*(ptext / SPACE / TAB) ptext]
+
+ ptext := hex-octet / safe-char
+
+ safe-char := <any octet with decimal value of 33 through
+ 60 inclusive, and 62 through 126>
+ ; Characters not listed as "mail-safe" in
+ ; RFC 2049 are also not recommended.
+
+ hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
+ ; Octet must be used for characters > 127, =,
+ ; SPACEs or TABs at the ends of lines, and is
+ ; recommended for any character not listed in
+ ; RFC 2049 as "mail-safe".
+
+ transport-padding := *LWSP-char
+ ; Composers MUST NOT generate
+ ; non-zero length transport
+ ; padding, but receivers MUST
+ ; be able to handle padding
+ ; added by message transports.
+
+ IMPORTANT: The addition of LWSP between the elements shown in this
+ BNF is NOT allowed since this BNF does not specify a structured
+ header field.
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 23]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+6.8. Base64 Content-Transfer-Encoding
+
+ The Base64 Content-Transfer-Encoding is designed to represent
+ arbitrary sequences of octets in a form that need not be humanly
+ readable. The encoding and decoding algorithms are simple, but the
+ encoded data are consistently only about 33 percent larger than the
+ unencoded data. This encoding is virtually identical to the one used
+ in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
+
+ A 65-character subset of US-ASCII is used, enabling 6 bits to be
+ represented per printable character. (The extra 65th character, "=",
+ is used to signify a special processing function.)
+
+ NOTE: This subset has the important property that it is represented
+ identically in all versions of ISO 646, including US-ASCII, and all
+ characters in the subset are also represented identically in all
+ versions of EBCDIC. Other popular encodings, such as the encoding
+ used by the uuencode utility, Macintosh binhex 4.0 [RFC-1741], and
+ the base85 encoding specified as part of Level 2 PostScript, do not
+ share these properties, and thus do not fulfill the portability
+ requirements a binary transport encoding for mail must meet.
+
+ The encoding process represents 24-bit groups of input bits as output
+ strings of 4 encoded characters. Proceeding from left to right, a
+ 24-bit input group is formed by concatenating 3 8bit input groups.
+ These 24 bits are then treated as 4 concatenated 6-bit groups, each
+ of which is translated into a single digit in the base64 alphabet.
+ When encoding a bit stream via the base64 encoding, the bit stream
+ must be presumed to be ordered with the most-significant-bit first.
+ That is, the first bit in the stream will be the high-order bit in
+ the first 8bit byte, and the eighth bit will be the low-order bit in
+ the first 8bit byte, and so on.
+
+ Each 6-bit group is used as an index into an array of 64 printable
+ characters. The character referenced by the index is placed in the
+ output string. These characters, identified in Table 1, below, are
+ selected so as to be universally representable, and the set excludes
+ characters with particular significance to SMTP (e.g., ".", CR, LF)
+ and to the multipart boundary delimiters defined in RFC 2046 (e.g.,
+ "-").
+
+
+
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 24]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ Table 1: The Base64 Alphabet
+
+ Value Encoding Value Encoding Value Encoding Value Encoding
+ 0 A 17 R 34 i 51 z
+ 1 B 18 S 35 j 52 0
+ 2 C 19 T 36 k 53 1
+ 3 D 20 U 37 l 54 2
+ 4 E 21 V 38 m 55 3
+ 5 F 22 W 39 n 56 4
+ 6 G 23 X 40 o 57 5
+ 7 H 24 Y 41 p 58 6
+ 8 I 25 Z 42 q 59 7
+ 9 J 26 a 43 r 60 8
+ 10 K 27 b 44 s 61 9
+ 11 L 28 c 45 t 62 +
+ 12 M 29 d 46 u 63 /
+ 13 N 30 e 47 v
+ 14 O 31 f 48 w (pad) =
+ 15 P 32 g 49 x
+ 16 Q 33 h 50 y
+
+ The encoded output stream must be represented in lines of no more
+ than 76 characters each. All line breaks or other characters not
+ found in Table 1 must be ignored by decoding software. In base64
+ data, characters other than those in Table 1, line breaks, and other
+ white space probably indicate a transmission error, about which a
+ warning message or even a message rejection might be appropriate
+ under some circumstances.
+
+ Special processing is performed if fewer than 24 bits are available
+ at the end of the data being encoded. A full encoding quantum is
+ always completed at the end of a body. When fewer than 24 input bits
+ are available in an input group, zero bits are added (on the right)
+ to form an integral number of 6-bit groups. Padding at the end of
+ the data is performed using the "=" character. Since all base64
+ input is an integral number of octets, only the following cases can
+ arise: (1) the final quantum of encoding input is an integral
+ multiple of 24 bits; here, the final unit of encoded output will be
+ an integral multiple of 4 characters with no "=" padding, (2) the
+ final quantum of encoding input is exactly 8 bits; here, the final
+ unit of encoded output will be two characters followed by two "="
+ padding characters, or (3) the final quantum of encoding input is
+ exactly 16 bits; here, the final unit of encoded output will be three
+ characters followed by one "=" padding character.
+
+ Because it is used only for padding at the end of the data, the
+ occurrence of any "=" characters may be taken as evidence that the
+ end of the data has been reached (without truncation in transit). No
+
+
+
+Freed & Borenstein Standards Track [Page 25]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ such assurance is possible, however, when the number of octets
+ transmitted was a multiple of three and no "=" characters are
+ present.
+
+ Any characters outside of the base64 alphabet are to be ignored in
+ base64-encoded data.
+
+ Care must be taken to use the proper octets for line breaks if base64
+ encoding is applied directly to text material that has not been
+ converted to canonical form. In particular, text line breaks must be
+ converted into CRLF sequences prior to base64 encoding. The
+ important thing to note is that this may be done directly by the
+ encoder rather than in a prior canonicalization step in some
+ implementations.
+
+ NOTE: There is no need to worry about quoting potential boundary
+ delimiters within base64-encoded bodies within multipart entities
+ because no hyphen characters are used in the base64 encoding.
+
+7. Content-ID Header Field
+
+ In constructing a high-level user agent, it may be desirable to allow
+ one body to make reference to another. Accordingly, bodies may be
+ labelled using the "Content-ID" header field, which is syntactically
+ identical to the "Message-ID" header field:
+
+ id := "Content-ID" ":" msg-id
+
+ Like the Message-ID values, Content-ID values must be generated to be
+ world-unique.
+
+ The Content-ID value may be used for uniquely identifying MIME
+ entities in several contexts, particularly for caching data
+ referenced by the message/external-body mechanism. Although the
+ Content-ID header is generally optional, its use is MANDATORY in
+ implementations which generate data of the optional MIME media type
+ "message/external-body". That is, each message/external-body entity
+ must have a Content-ID field to permit caching of such data.
+
+ It is also worth noting that the Content-ID value has special
+ semantics in the case of the multipart/alternative media type. This
+ is explained in the section of RFC 2046 dealing with
+ multipart/alternative.
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 26]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+8. Content-Description Header Field
+
+ The ability to associate some descriptive information with a given
+ body is often desirable. For example, it may be useful to mark an
+ "image" body as "a picture of the Space Shuttle Endeavor." Such text
+ may be placed in the Content-Description header field. This header
+ field is always optional.
+
+ description := "Content-Description" ":" *text
+
+ The description is presumed to be given in the US-ASCII character
+ set, although the mechanism specified in RFC 2047 may be used for
+ non-US-ASCII Content-Description values.
+
+9. Additional MIME Header Fields
+
+ Future documents may elect to define additional MIME header fields
+ for various purposes. Any new header field that further describes
+ the content of a message should begin with the string "Content-" to
+ allow such fields which appear in a message header to be
+ distinguished from ordinary RFC 822 message header fields.
+
+ MIME-extension-field := <Any RFC 822 header field which
+ begins with the string
+ "Content-">
+
+10. Summary
+
+ Using the MIME-Version, Content-Type, and Content-Transfer-Encoding
+ header fields, it is possible to include, in a standardized way,
+ arbitrary types of data with RFC 822 conformant mail messages. No
+ restrictions imposed by either RFC 821 or RFC 822 are violated, and
+ care has been taken to avoid problems caused by additional
+ restrictions imposed by the characteristics of some Internet mail
+ transport mechanisms (see RFC 2049).
+
+ The next document in this set, RFC 2046, specifies the initial set of
+ media types that can be labelled and transported using these headers.
+
+11. Security Considerations
+
+ Security issues are discussed in the second document in this set, RFC
+ 2046.
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 27]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+12. Authors' Addresses
+
+ For more information, the authors of this document are best contacted
+ via Internet mail:
+
+ Ned Freed
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+ Nathaniel S. Borenstein
+ First Virtual Holdings
+ 25 Washington Avenue
+ Morristown, NJ 07960
+ USA
+
+ Phone: +1 201 540 8967
+ Fax: +1 201 993 3032
+ EMail: nsb@nsb.fv.com
+
+
+ MIME is a result of the work of the Internet Engineering Task Force
+ Working Group on RFC 822 Extensions. The chairman of that group,
+ Greg Vaudreuil, may be reached at:
+
+ Gregory M. Vaudreuil
+ Octel Network Services
+ 17080 Dallas Parkway
+ Dallas, TX 75248-1905
+ USA
+
+ EMail: Greg.Vaudreuil@Octel.Com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 28]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+Appendix A -- Collected Grammar
+
+ This appendix contains the complete BNF grammar for all the syntax
+ specified by this document.
+
+ By itself, however, this grammar is incomplete. It refers by name to
+ several syntax rules that are defined by RFC 822. Rather than
+ reproduce those definitions here, and risk unintentional differences
+ between the two, this document simply refers the reader to RFC 822
+ for the remaining definitions. Wherever a term is undefined, it
+ refers to the RFC 822 definition.
+
+ attribute := token
+ ; Matching of attributes
+ ; is ALWAYS case-insensitive.
+
+ composite-type := "message" / "multipart" / extension-token
+
+ content := "Content-Type" ":" type "/" subtype
+ *(";" parameter)
+ ; Matching of media type and subtype
+ ; is ALWAYS case-insensitive.
+
+ description := "Content-Description" ":" *text
+
+ discrete-type := "text" / "image" / "audio" / "video" /
+ "application" / extension-token
+
+ encoding := "Content-Transfer-Encoding" ":" mechanism
+
+ entity-headers := [ content CRLF ]
+ [ encoding CRLF ]
+ [ id CRLF ]
+ [ description CRLF ]
+ *( MIME-extension-field CRLF )
+
+ extension-token := ietf-token / x-token
+
+ hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
+ ; Octet must be used for characters > 127, =,
+ ; SPACEs or TABs at the ends of lines, and is
+ ; recommended for any character not listed in
+ ; RFC 2049 as "mail-safe".
+
+ iana-token := <A publicly-defined extension token. Tokens
+ of this form must be registered with IANA
+ as specified in RFC 2048.>
+
+
+
+
+Freed & Borenstein Standards Track [Page 29]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ ietf-token := <An extension token defined by a
+ standards-track RFC and registered
+ with IANA.>
+
+ id := "Content-ID" ":" msg-id
+
+ mechanism := "7bit" / "8bit" / "binary" /
+ "quoted-printable" / "base64" /
+ ietf-token / x-token
+
+ MIME-extension-field := <Any RFC 822 header field which
+ begins with the string
+ "Content-">
+
+ MIME-message-headers := entity-headers
+ fields
+ version CRLF
+ ; The ordering of the header
+ ; fields implied by this BNF
+ ; definition should be ignored.
+
+ MIME-part-headers := entity-headers
+ [fields]
+ ; Any field not beginning with
+ ; "content-" can have no defined
+ ; meaning and may be ignored.
+ ; The ordering of the header
+ ; fields implied by this BNF
+ ; definition should be ignored.
+
+ parameter := attribute "=" value
+
+ ptext := hex-octet / safe-char
+
+ qp-line := *(qp-segment transport-padding CRLF)
+ qp-part transport-padding
+
+ qp-part := qp-section
+ ; Maximum length of 76 characters
+
+ qp-section := [*(ptext / SPACE / TAB) ptext]
+
+ qp-segment := qp-section *(SPACE / TAB) "="
+ ; Maximum length of 76 characters
+
+ quoted-printable := qp-line *(CRLF qp-line)
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 30]
+
+RFC 2045 Internet Message Bodies November 1996
+
+
+ safe-char := <any octet with decimal value of 33 through
+ 60 inclusive, and 62 through 126>
+ ; Characters not listed as "mail-safe" in
+ ; RFC 2049 are also not recommended.
+
+ subtype := extension-token / iana-token
+
+ token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
+ or tspecials>
+
+ transport-padding := *LWSP-char
+ ; Composers MUST NOT generate
+ ; non-zero length transport
+ ; padding, but receivers MUST
+ ; be able to handle padding
+ ; added by message transports.
+
+ tspecials := "(" / ")" / "<" / ">" / "@" /
+ "," / ";" / ":" / "\" / <">
+ "/" / "[" / "]" / "?" / "="
+ ; Must be in quoted-string,
+ ; to use within parameter values
+
+ type := discrete-type / composite-type
+
+ value := token / quoted-string
+
+ version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+ x-token := <The two characters "X-" or "x-" followed, with
+ no intervening white space, by any token>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 31]
+
diff --git a/Documentation/en/rfc/rfc2046.txt b/Documentation/en/rfc/rfc2046.txt
new file mode 100644
index 00000000..84d90c10
--- /dev/null
+++ b/Documentation/en/rfc/rfc2046.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+Network Working Group N. Freed
+Request for Comments: 2046 Innosoft
+Obsoletes: 1521, 1522, 1590 N. Borenstein
+Category: Standards Track First Virtual
+ November 1996
+
+
+ Multipurpose Internet Mail Extensions
+ (MIME) Part Two:
+ Media Types
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ STD 11, RFC 822 defines a message representation protocol specifying
+ considerable detail about US-ASCII message headers, but which leaves
+ the message content, or message body, as flat US-ASCII text. This
+ set of documents, collectively called the Multipurpose Internet Mail
+ Extensions, or MIME, redefines the format of messages to allow for
+
+ (1) textual message bodies in character sets other than
+ US-ASCII,
+
+ (2) an extensible set of different formats for non-textual
+ message bodies,
+
+ (3) multi-part message bodies, and
+
+ (4) textual header information in character sets other than
+ US-ASCII.
+
+ These documents are based on earlier work documented in RFC 934, STD
+ 11, and RFC 1049, but extends and revises them. Because RFC 822 said
+ so little about message bodies, these documents are largely
+ orthogonal to (rather than a revision of) RFC 822.
+
+ The initial document in this set, RFC 2045, specifies the various
+ headers used to describe the structure of MIME messages. This second
+ document defines the general structure of the MIME media typing
+ system and defines an initial set of media types. The third document,
+ RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text
+
+
+
+Freed & Borenstein Standards Track [Page 1]
+
+RFC 2046 Media Types November 1996
+
+
+ data in Internet mail header fields. The fourth document, RFC 2048,
+ specifies various IANA registration procedures for MIME-related
+ facilities. The fifth and final document, RFC 2049, describes MIME
+ conformance criteria as well as providing some illustrative examples
+ of MIME message formats, acknowledgements, and the bibliography.
+
+ These documents are revisions of RFCs 1521 and 1522, which themselves
+ were revisions of RFCs 1341 and 1342. An appendix in RFC 2049
+ describes differences and changes from previous versions.
+
+Table of Contents
+
+ 1. Introduction ......................................... 3
+ 2. Definition of a Top-Level Media Type ................. 4
+ 3. Overview Of The Initial Top-Level Media Types ........ 4
+ 4. Discrete Media Type Values ........................... 6
+ 4.1 Text Media Type ..................................... 6
+ 4.1.1 Representation of Line Breaks ..................... 7
+ 4.1.2 Charset Parameter ................................. 7
+ 4.1.3 Plain Subtype ..................................... 11
+ 4.1.4 Unrecognized Subtypes ............................. 11
+ 4.2 Image Media Type .................................... 11
+ 4.3 Audio Media Type .................................... 11
+ 4.4 Video Media Type .................................... 12
+ 4.5 Application Media Type .............................. 12
+ 4.5.1 Octet-Stream Subtype .............................. 13
+ 4.5.2 PostScript Subtype ................................ 14
+ 4.5.3 Other Application Subtypes ........................ 17
+ 5. Composite Media Type Values .......................... 17
+ 5.1 Multipart Media Type ................................ 17
+ 5.1.1 Common Syntax ..................................... 19
+ 5.1.2 Handling Nested Messages and Multiparts ........... 24
+ 5.1.3 Mixed Subtype ..................................... 24
+ 5.1.4 Alternative Subtype ............................... 24
+ 5.1.5 Digest Subtype .................................... 26
+ 5.1.6 Parallel Subtype .................................. 27
+ 5.1.7 Other Multipart Subtypes .......................... 28
+ 5.2 Message Media Type .................................. 28
+ 5.2.1 RFC822 Subtype .................................... 28
+ 5.2.2 Partial Subtype ................................... 29
+ 5.2.2.1 Message Fragmentation and Reassembly ............ 30
+ 5.2.2.2 Fragmentation and Reassembly Example ............ 31
+ 5.2.3 External-Body Subtype ............................. 33
+ 5.2.4 Other Message Subtypes ............................ 40
+ 6. Experimental Media Type Values ....................... 40
+ 7. Summary .............................................. 41
+ 8. Security Considerations .............................. 41
+ 9. Authors' Addresses ................................... 42
+
+
+
+Freed & Borenstein Standards Track [Page 2]
+
+RFC 2046 Media Types November 1996
+
+
+ A. Collected Grammar .................................... 43
+
+1. Introduction
+
+ The first document in this set, RFC 2045, defines a number of header
+ fields, including Content-Type. The Content-Type field is used to
+ specify the nature of the data in the body of a MIME entity, by
+ giving media type and subtype identifiers, and by providing auxiliary
+ information that may be required for certain media types. After the
+ type and subtype names, the remainder of the header field is simply a
+ set of parameters, specified in an attribute/value notation. The
+ ordering of parameters is not significant.
+
+ In general, the top-level media type is used to declare the general
+ type of data, while the subtype specifies a specific format for that
+ type of data. Thus, a media type of "image/xyz" is enough to tell a
+ user agent that the data is an image, even if the user agent has no
+ knowledge of the specific image format "xyz". Such information can
+ be used, for example, to decide whether or not to show a user the raw
+ data from an unrecognized subtype -- such an action might be
+ reasonable for unrecognized subtypes of "text", but not for
+ unrecognized subtypes of "image" or "audio". For this reason,
+ registered subtypes of "text", "image", "audio", and "video" should
+ not contain embedded information that is really of a different type.
+ Such compound formats should be represented using the "multipart" or
+ "application" types.
+
+ Parameters are modifiers of the media subtype, and as such do not
+ fundamentally affect the nature of the content. The set of
+ meaningful parameters depends on the media type and subtype. Most
+ parameters are associated with a single specific subtype. However, a
+ given top-level media type may define parameters which are applicable
+ to any subtype of that type. Parameters may be required by their
+ defining media type or subtype or they may be optional. MIME
+ implementations must also ignore any parameters whose names they do
+ not recognize.
+
+ MIME's Content-Type header field and media type mechanism has been
+ carefully designed to be extensible, and it is expected that the set
+ of media type/subtype pairs and their associated parameters will grow
+ significantly over time. Several other MIME facilities, such as
+ transfer encodings and "message/external-body" access types, are
+ likely to have new values defined over time. In order to ensure that
+ the set of such values is developed in an orderly, well-specified,
+ and public manner, MIME sets up a registration process which uses the
+ Internet Assigned Numbers Authority (IANA) as a central registry for
+ MIME's various areas of extensibility. The registration process for
+ these areas is described in a companion document, RFC 2048.
+
+
+
+Freed & Borenstein Standards Track [Page 3]
+
+RFC 2046 Media Types November 1996
+
+
+ The initial seven standard top-level media type are defined and
+ described in the remainder of this document.
+
+2. Definition of a Top-Level Media Type
+
+ The definition of a top-level media type consists of:
+
+ (1) a name and a description of the type, including
+ criteria for whether a particular type would qualify
+ under that type,
+
+ (2) the names and definitions of parameters, if any, which
+ are defined for all subtypes of that type (including
+ whether such parameters are required or optional),
+
+ (3) how a user agent and/or gateway should handle unknown
+ subtypes of this type,
+
+ (4) general considerations on gatewaying entities of this
+ top-level type, if any, and
+
+ (5) any restrictions on content-transfer-encodings for
+ entities of this top-level type.
+
+3. Overview Of The Initial Top-Level Media Types
+
+ The five discrete top-level media types are:
+
+ (1) text -- textual information. The subtype "plain" in
+ particular indicates plain text containing no
+ formatting commands or directives of any sort. Plain
+ text is intended to be displayed "as-is". No special
+ software is required to get the full meaning of the
+ text, aside from support for the indicated character
+ set. Other subtypes are to be used for enriched text in
+ forms where application software may enhance the
+ appearance of the text, but such software must not be
+ required in order to get the general idea of the
+ content. Possible subtypes of "text" thus include any
+ word processor format that can be read without
+ resorting to software that understands the format. In
+ particular, formats that employ embeddded binary
+ formatting information are not considered directly
+ readable. A very simple and portable subtype,
+ "richtext", was defined in RFC 1341, with a further
+ revision in RFC 1896 under the name "enriched".
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 4]
+
+RFC 2046 Media Types November 1996
+
+
+ (2) image -- image data. "Image" requires a display device
+ (such as a graphical display, a graphics printer, or a
+ FAX machine) to view the information. An initial
+ subtype is defined for the widely-used image format
+ JPEG. . subtypes are defined for two widely-used image
+ formats, jpeg and gif.
+
+ (3) audio -- audio data. "Audio" requires an audio output
+ device (such as a speaker or a telephone) to "display"
+ the contents. An initial subtype "basic" is defined in
+ this document.
+
+ (4) video -- video data. "Video" requires the capability
+ to display moving images, typically including
+ specialized hardware and software. An initial subtype
+ "mpeg" is defined in this document.
+
+ (5) application -- some other kind of data, typically
+ either uninterpreted binary data or information to be
+ processed by an application. The subtype "octet-
+ stream" is to be used in the case of uninterpreted
+ binary data, in which case the simplest recommended
+ action is to offer to write the information into a file
+ for the user. The "PostScript" subtype is also defined
+ for the transport of PostScript material. Other
+ expected uses for "application" include spreadsheets,
+ data for mail-based scheduling systems, and languages
+ for "active" (computational) messaging, and word
+ processing formats that are not directly readable.
+ Note that security considerations may exist for some
+ types of application data, most notably
+ "application/PostScript" and any form of active
+ messaging. These issues are discussed later in this
+ document.
+
+ The two composite top-level media types are:
+
+ (1) multipart -- data consisting of multiple entities of
+ independent data types. Four subtypes are initially
+ defined, including the basic "mixed" subtype specifying
+ a generic mixed set of parts, "alternative" for
+ representing the same data in multiple formats,
+ "parallel" for parts intended to be viewed
+ simultaneously, and "digest" for multipart entities in
+ which each part has a default type of "message/rfc822".
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 5]
+
+RFC 2046 Media Types November 1996
+
+
+ (2) message -- an encapsulated message. A body of media
+ type "message" is itself all or a portion of some kind
+ of message object. Such objects may or may not in turn
+ contain other entities. The "rfc822" subtype is used
+ when the encapsulated content is itself an RFC 822
+ message. The "partial" subtype is defined for partial
+ RFC 822 messages, to permit the fragmented transmission
+ of bodies that are thought to be too large to be passed
+ through transport facilities in one piece. Another
+ subtype, "external-body", is defined for specifying
+ large bodies by reference to an external data source.
+
+ It should be noted that the list of media type values given here may
+ be augmented in time, via the mechanisms described above, and that
+ the set of subtypes is expected to grow substantially.
+
+4. Discrete Media Type Values
+
+ Five of the seven initial media type values refer to discrete bodies.
+ The content of these types must be handled by non-MIME mechanisms;
+ they are opaque to MIME processors.
+
+4.1. Text Media Type
+
+ The "text" media type is intended for sending material which is
+ principally textual in form. A "charset" parameter may be used to
+ indicate the character set of the body text for "text" subtypes,
+ notably including the subtype "text/plain", which is a generic
+ subtype for plain text. Plain text does not provide for or allow
+ formatting commands, font attribute specifications, processing
+ instructions, interpretation directives, or content markup. Plain
+ text is seen simply as a linear sequence of characters, possibly
+ interrupted by line breaks or page breaks. Plain text may allow the
+ stacking of several characters in the same position in the text.
+ Plain text in scripts like Arabic and Hebrew may also include
+ facilitites that allow the arbitrary mixing of text segments with
+ opposite writing directions.
+
+ Beyond plain text, there are many formats for representing what might
+ be known as "rich text". An interesting characteristic of many such
+ representations is that they are to some extent readable even without
+ the software that interprets them. It is useful, then, to
+ distinguish them, at the highest level, from such unreadable data as
+ images, audio, or text represented in an unreadable form. In the
+ absence of appropriate interpretation software, it is reasonable to
+ show subtypes of "text" to the user, while it is not reasonable to do
+ so with most nontextual data. Such formatted textual data should be
+ represented using subtypes of "text".
+
+
+
+Freed & Borenstein Standards Track [Page 6]
+
+RFC 2046 Media Types November 1996
+
+
+4.1.1. Representation of Line Breaks
+
+ The canonical form of any MIME "text" subtype MUST always represent a
+ line break as a CRLF sequence. Similarly, any occurrence of CRLF in
+ MIME "text" MUST represent a line break. Use of CR and LF outside of
+ line break sequences is also forbidden.
+
+ This rule applies regardless of format or character set or sets
+ involved.
+
+ NOTE: The proper interpretation of line breaks when a body is
+ displayed depends on the media type. In particular, while it is
+ appropriate to treat a line break as a transition to a new line when
+ displaying a "text/plain" body, this treatment is actually incorrect
+ for other subtypes of "text" like "text/enriched" [RFC-1896].
+ Similarly, whether or not line breaks should be added during display
+ operations is also a function of the media type. It should not be
+ necessary to add any line breaks to display "text/plain" correctly,
+ whereas proper display of "text/enriched" requires the appropriate
+ addition of line breaks.
+
+ NOTE: Some protocols defines a maximum line length. E.g. SMTP [RFC-
+ 821] allows a maximum of 998 octets before the next CRLF sequence.
+ To be transported by such protocols, data which includes too long
+ segments without CRLF sequences must be encoded with a suitable
+ content-transfer-encoding.
+
+4.1.2. Charset Parameter
+
+ A critical parameter that may be specified in the Content-Type field
+ for "text/plain" data is the character set. This is specified with a
+ "charset" parameter, as in:
+
+ Content-type: text/plain; charset=iso-8859-1
+
+ Unlike some other parameter values, the values of the charset
+ parameter are NOT case sensitive. The default character set, which
+ must be assumed in the absence of a charset parameter, is US-ASCII.
+
+ The specification for any future subtypes of "text" must specify
+ whether or not they will also utilize a "charset" parameter, and may
+ possibly restrict its values as well. For other subtypes of "text"
+ than "text/plain", the semantics of the "charset" parameter should be
+ defined to be identical to those specified here for "text/plain",
+ i.e., the body consists entirely of characters in the given charset.
+ In particular, definers of future "text" subtypes should pay close
+ attention to the implications of multioctet character sets for their
+ subtype definitions.
+
+
+
+Freed & Borenstein Standards Track [Page 7]
+
+RFC 2046 Media Types November 1996
+
+
+ The charset parameter for subtypes of "text" gives a name of a
+ character set, as "character set" is defined in RFC 2045. The rules
+ regarding line breaks detailed in the previous section must also be
+ observed -- a character set whose definition does not conform to
+ these rules cannot be used in a MIME "text" subtype.
+
+ An initial list of predefined character set names can be found at the
+ end of this section. Additional character sets may be registered
+ with IANA.
+
+ Other media types than subtypes of "text" might choose to employ the
+ charset parameter as defined here, but with the CRLF/line break
+ restriction removed. Therefore, all character sets that conform to
+ the general definition of "character set" in RFC 2045 can be
+ registered for MIME use.
+
+ Note that if the specified character set includes 8-bit characters
+ and such characters are used in the body, a Content-Transfer-Encoding
+ header field and a corresponding encoding on the data are required in
+ order to transmit the body via some mail transfer protocols, such as
+ SMTP [RFC-821].
+
+ The default character set, US-ASCII, has been the subject of some
+ confusion and ambiguity in the past. Not only were there some
+ ambiguities in the definition, there have been wide variations in
+ practice. In order to eliminate such ambiguity and variations in the
+ future, it is strongly recommended that new user agents explicitly
+ specify a character set as a media type parameter in the Content-Type
+ header field. "US-ASCII" does not indicate an arbitrary 7-bit
+ character set, but specifies that all octets in the body must be
+ interpreted as characters according to the US-ASCII character set.
+ National and application-oriented versions of ISO 646 [ISO-646] are
+ usually NOT identical to US-ASCII, and in that case their use in
+ Internet mail is explicitly discouraged. The omission of the ISO 646
+ character set from this document is deliberate in this regard. The
+ character set name of "US-ASCII" explicitly refers to the character
+ set defined in ANSI X3.4-1986 [US- ASCII]. The new international
+ reference version (IRV) of the 1991 edition of ISO 646 is identical
+ to US-ASCII. The character set name "ASCII" is reserved and must not
+ be used for any purpose.
+
+ NOTE: RFC 821 explicitly specifies "ASCII", and references an earlier
+ version of the American Standard. Insofar as one of the purposes of
+ specifying a media type and character set is to permit the receiver
+ to unambiguously determine how the sender intended the coded message
+ to be interpreted, assuming anything other than "strict ASCII" as the
+ default would risk unintentional and incompatible changes to the
+ semantics of messages now being transmitted. This also implies that
+
+
+
+Freed & Borenstein Standards Track [Page 8]
+
+RFC 2046 Media Types November 1996
+
+
+ messages containing characters coded according to other versions of
+ ISO 646 than US-ASCII and the 1991 IRV, or using code-switching
+ procedures (e.g., those of ISO 2022), as well as 8bit or multiple
+ octet character encodings MUST use an appropriate character set
+ specification to be consistent with MIME.
+
+ The complete US-ASCII character set is listed in ANSI X3.4- 1986.
+ Note that the control characters including DEL (0-31, 127) have no
+ defined meaning in apart from the combination CRLF (US-ASCII values
+ 13 and 10) indicating a new line. Two of the characters have de
+ facto meanings in wide use: FF (12) often means "start subsequent
+ text on the beginning of a new page"; and TAB or HT (9) often (though
+ not always) means "move the cursor to the next available column after
+ the current position where the column number is a multiple of 8
+ (counting the first column as column 0)." Aside from these
+ conventions, any use of the control characters or DEL in a body must
+ either occur
+
+ (1) because a subtype of text other than "plain"
+ specifically assigns some additional meaning, or
+
+ (2) within the context of a private agreement between the
+ sender and recipient. Such private agreements are
+ discouraged and should be replaced by the other
+ capabilities of this document.
+
+ NOTE: An enormous proliferation of character sets exist beyond US-
+ ASCII. A large number of partially or totally overlapping character
+ sets is NOT a good thing. A SINGLE character set that can be used
+ universally for representing all of the world's languages in Internet
+ mail would be preferrable. Unfortunately, existing practice in
+ several communities seems to point to the continued use of multiple
+ character sets in the near future. A small number of standard
+ character sets are, therefore, defined for Internet use in this
+ document.
+
+ The defined charset values are:
+
+ (1) US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
+
+ (2) ISO-8859-X -- where "X" is to be replaced, as
+ necessary, for the parts of ISO-8859 [ISO-8859]. Note
+ that the ISO 646 character sets have deliberately been
+ omitted in favor of their 8859 replacements, which are
+ the designated character sets for Internet mail. As of
+ the publication of this document, the legitimate values
+ for "X" are the digits 1 through 10.
+
+
+
+
+Freed & Borenstein Standards Track [Page 9]
+
+RFC 2046 Media Types November 1996
+
+
+ Characters in the range 128-159 has no assigned meaning in ISO-8859-
+ X. Characters with values below 128 in ISO-8859-X have the same
+ assigned meaning as they do in US-ASCII.
+
+ Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/Hebrew
+ alphabet) includes both characters for which the normal writing
+ direction is right to left and characters for which it is left to
+ right, but do not define a canonical ordering method for representing
+ bi-directional text. The charset values "ISO-8859-6" and "ISO-8859-
+ 8", however, specify that the visual method is used [RFC-1556].
+
+ All of these character sets are used as pure 7bit or 8bit sets
+ without any shift or escape functions. The meaning of shift and
+ escape sequences in these character sets is not defined.
+
+ The character sets specified above are the ones that were relatively
+ uncontroversial during the drafting of MIME. This document does not
+ endorse the use of any particular character set other than US-ASCII,
+ and recognizes that the future evolution of world character sets
+ remains unclear.
+
+ Note that the character set used, if anything other than US- ASCII,
+ must always be explicitly specified in the Content-Type field.
+
+ No character set name other than those defined above may be used in
+ Internet mail without the publication of a formal specification and
+ its registration with IANA, or by private agreement, in which case
+ the character set name must begin with "X-".
+
+ Implementors are discouraged from defining new character sets unless
+ absolutely necessary.
+
+ The "charset" parameter has been defined primarily for the purpose of
+ textual data, and is described in this section for that reason.
+ However, it is conceivable that non-textual data might also wish to
+ specify a charset value for some purpose, in which case the same
+ syntax and values should be used.
+
+ In general, composition software should always use the "lowest common
+ denominator" character set possible. For example, if a body contains
+ only US-ASCII characters, it SHOULD be marked as being in the US-
+ ASCII character set, not ISO-8859-1, which, like all the ISO-8859
+ family of character sets, is a superset of US-ASCII. More generally,
+ if a widely-used character set is a subset of another character set,
+ and a body contains only characters in the widely-used subset, it
+ should be labelled as being in that subset. This will increase the
+ chances that the recipient will be able to view the resulting entity
+ correctly.
+
+
+
+Freed & Borenstein Standards Track [Page 10]
+
+RFC 2046 Media Types November 1996
+
+
+4.1.3. Plain Subtype
+
+ The simplest and most important subtype of "text" is "plain". This
+ indicates plain text that does not contain any formatting commands or
+ directives. Plain text is intended to be displayed "as-is", that is,
+ no interpretation of embedded formatting commands, font attribute
+ specifications, processing instructions, interpretation directives,
+ or content markup should be necessary for proper display. The
+ default media type of "text/plain; charset=us-ascii" for Internet
+ mail describes existing Internet practice. That is, it is the type
+ of body defined by RFC 822.
+
+ No other "text" subtype is defined by this document.
+
+4.1.4. Unrecognized Subtypes
+
+ Unrecognized subtypes of "text" should be treated as subtype "plain"
+ as long as the MIME implementation knows how to handle the charset.
+ Unrecognized subtypes which also specify an unrecognized charset
+ should be treated as "application/octet- stream".
+
+4.2. Image Media Type
+
+ A media type of "image" indicates that the body contains an image.
+ The subtype names the specific image format. These names are not
+ case sensitive. An initial subtype is "jpeg" for the JPEG format
+ using JFIF encoding [JPEG].
+
+ The list of "image" subtypes given here is neither exclusive nor
+ exhaustive, and is expected to grow as more types are registered with
+ IANA, as described in RFC 2048.
+
+ Unrecognized subtypes of "image" should at a miniumum be treated as
+ "application/octet-stream". Implementations may optionally elect to
+ pass subtypes of "image" that they do not specifically recognize to a
+ secure and robust general-purpose image viewing application, if such
+ an application is available.
+
+ NOTE: Using of a generic-purpose image viewing application this way
+ inherits the security problems of the most dangerous type supported
+ by the application.
+
+4.3. Audio Media Type
+
+ A media type of "audio" indicates that the body contains audio data.
+ Although there is not yet a consensus on an "ideal" audio format for
+ use with computers, there is a pressing need for a format capable of
+ providing interoperable behavior.
+
+
+
+Freed & Borenstein Standards Track [Page 11]
+
+RFC 2046 Media Types November 1996
+
+
+ The initial subtype of "basic" is specified to meet this requirement
+ by providing an absolutely minimal lowest common denominator audio
+ format. It is expected that richer formats for higher quality and/or
+ lower bandwidth audio will be defined by a later document.
+
+ The content of the "audio/basic" subtype is single channel audio
+ encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz.
+
+ Unrecognized subtypes of "audio" should at a miniumum be treated as
+ "application/octet-stream". Implementations may optionally elect to
+ pass subtypes of "audio" that they do not specifically recognize to a
+ robust general-purpose audio playing application, if such an
+ application is available.
+
+4.4. Video Media Type
+
+ A media type of "video" indicates that the body contains a time-
+ varying-picture image, possibly with color and coordinated sound.
+ The term 'video' is used in its most generic sense, rather than with
+ reference to any particular technology or format, and is not meant to
+ preclude subtypes such as animated drawings encoded compactly. The
+ subtype "mpeg" refers to video coded according to the MPEG standard
+ [MPEG].
+
+ Note that although in general this document strongly discourages the
+ mixing of multiple media in a single body, it is recognized that many
+ so-called video formats include a representation for synchronized
+ audio, and this is explicitly permitted for subtypes of "video".
+
+ Unrecognized subtypes of "video" should at a minumum be treated as
+ "application/octet-stream". Implementations may optionally elect to
+ pass subtypes of "video" that they do not specifically recognize to a
+ robust general-purpose video display application, if such an
+ application is available.
+
+4.5. Application Media Type
+
+ The "application" media type is to be used for discrete data which do
+ not fit in any of the other categories, and particularly for data to
+ be processed by some type of application program. This is
+ information which must be processed by an application before it is
+ viewable or usable by a user. Expected uses for the "application"
+ media type include file transfer, spreadsheets, data for mail-based
+ scheduling systems, and languages for "active" (computational)
+ material. (The latter, in particular, can pose security problems
+ which must be understood by implementors, and are considered in
+ detail in the discussion of the "application/PostScript" media type.)
+
+
+
+
+Freed & Borenstein Standards Track [Page 12]
+
+RFC 2046 Media Types November 1996
+
+
+ For example, a meeting scheduler might define a standard
+ representation for information about proposed meeting dates. An
+ intelligent user agent would use this information to conduct a dialog
+ with the user, and might then send additional material based on that
+ dialog. More generally, there have been several "active" messaging
+ languages developed in which programs in a suitably specialized
+ language are transported to a remote location and automatically run
+ in the recipient's environment.
+
+ Such applications may be defined as subtypes of the "application"
+ media type. This document defines two subtypes:
+
+ octet-stream, and PostScript.
+
+ The subtype of "application" will often be either the name or include
+ part of the name of the application for which the data are intended.
+ This does not mean, however, that any application program name may be
+ used freely as a subtype of "application".
+
+4.5.1. Octet-Stream Subtype
+
+ The "octet-stream" subtype is used to indicate that a body contains
+ arbitrary binary data. The set of currently defined parameters is:
+
+ (1) TYPE -- the general type or category of binary data.
+ This is intended as information for the human recipient
+ rather than for any automatic processing.
+
+ (2) PADDING -- the number of bits of padding that were
+ appended to the bit-stream comprising the actual
+ contents to produce the enclosed 8bit byte-oriented
+ data. This is useful for enclosing a bit-stream in a
+ body when the total number of bits is not a multiple of
+ 8.
+
+ Both of these parameters are optional.
+
+ An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
+ has since been removed. RFC 1341 also defined the use of a "NAME"
+ parameter which gave a suggested file name to be used if the data
+ were to be written to a file. This has been deprecated in
+ anticipation of a separate Content-Disposition header field, to be
+ defined in a subsequent RFC.
+
+ The recommended action for an implementation that receives an
+ "application/octet-stream" entity is to simply offer to put the data
+ in a file, with any Content-Transfer-Encoding undone, or perhaps to
+ use it as input to a user-specified process.
+
+
+
+Freed & Borenstein Standards Track [Page 13]
+
+RFC 2046 Media Types November 1996
+
+
+ To reduce the danger of transmitting rogue programs, it is strongly
+ recommended that implementations NOT implement a path-search
+ mechanism whereby an arbitrary program named in the Content-Type
+ parameter (e.g., an "interpreter=" parameter) is found and executed
+ using the message body as input.
+
+4.5.2. PostScript Subtype
+
+ A media type of "application/postscript" indicates a PostScript
+ program. Currently two variants of the PostScript language are
+ allowed; the original level 1 variant is described in [POSTSCRIPT]
+ and the more recent level 2 variant is described in [POSTSCRIPT2].
+
+ PostScript is a registered trademark of Adobe Systems, Inc. Use of
+ the MIME media type "application/postscript" implies recognition of
+ that trademark and all the rights it entails.
+
+ The PostScript language definition provides facilities for internal
+ labelling of the specific language features a given program uses.
+ This labelling, called the PostScript document structuring
+ conventions, or DSC, is very general and provides substantially more
+ information than just the language level. The use of document
+ structuring conventions, while not required, is strongly recommended
+ as an aid to interoperability. Documents which lack proper
+ structuring conventions cannot be tested to see whether or not they
+ will work in a given environment. As such, some systems may assume
+ the worst and refuse to process unstructured documents.
+
+ The execution of general-purpose PostScript interpreters entails
+ serious security risks, and implementors are discouraged from simply
+ sending PostScript bodies to "off- the-shelf" interpreters. While it
+ is usually safe to send PostScript to a printer, where the potential
+ for harm is greatly constrained by typical printer environments,
+ implementors should consider all of the following before they add
+ interactive display of PostScript bodies to their MIME readers.
+
+ The remainder of this section outlines some, though probably not all,
+ of the possible problems with the transport of PostScript entities.
+
+ (1) Dangerous operations in the PostScript language
+ include, but may not be limited to, the PostScript
+ operators "deletefile", "renamefile", "filenameforall",
+ and "file". "File" is only dangerous when applied to
+ something other than standard input or output.
+ Implementations may also define additional nonstandard
+ file operators; these may also pose a threat to
+ security. "Filenameforall", the wildcard file search
+ operator, may appear at first glance to be harmless.
+
+
+
+Freed & Borenstein Standards Track [Page 14]
+
+RFC 2046 Media Types November 1996
+
+
+ Note, however, that this operator has the potential to
+ reveal information about what files the recipient has
+ access to, and this information may itself be
+ sensitive. Message senders should avoid the use of
+ potentially dangerous file operators, since these
+ operators are quite likely to be unavailable in secure
+ PostScript implementations. Message receiving and
+ displaying software should either completely disable
+ all potentially dangerous file operators or take
+ special care not to delegate any special authority to
+ their operation. These operators should be viewed as
+ being done by an outside agency when interpreting
+ PostScript documents. Such disabling and/or checking
+ should be done completely outside of the reach of the
+ PostScript language itself; care should be taken to
+ insure that no method exists for re-enabling full-
+ function versions of these operators.
+
+ (2) The PostScript language provides facilities for exiting
+ the normal interpreter, or server, loop. Changes made
+ in this "outer" environment are customarily retained
+ across documents, and may in some cases be retained
+ semipermanently in nonvolatile memory. The operators
+ associated with exiting the interpreter loop have the
+ potential to interfere with subsequent document
+ processing. As such, their unrestrained use
+ constitutes a threat of service denial. PostScript
+ operators that exit the interpreter loop include, but
+ may not be limited to, the exitserver and startjob
+ operators. Message sending software should not
+ generate PostScript that depends on exiting the
+ interpreter loop to operate, since the ability to exit
+ will probably be unavailable in secure PostScript
+ implementations. Message receiving and displaying
+ software should completely disable the ability to make
+ retained changes to the PostScript environment by
+ eliminating or disabling the "startjob" and
+ "exitserver" operations. If these operations cannot be
+ eliminated or completely disabled the password
+ associated with them should at least be set to a hard-
+ to-guess value.
+
+ (3) PostScript provides operators for setting system-wide
+ and device-specific parameters. These parameter
+ settings may be retained across jobs and may
+ potentially pose a threat to the correct operation of
+ the interpreter. The PostScript operators that set
+ system and device parameters include, but may not be
+
+
+
+Freed & Borenstein Standards Track [Page 15]
+
+RFC 2046 Media Types November 1996
+
+
+ limited to, the "setsystemparams" and "setdevparams"
+ operators. Message sending software should not
+ generate PostScript that depends on the setting of
+ system or device parameters to operate correctly. The
+ ability to set these parameters will probably be
+ unavailable in secure PostScript implementations.
+ Message receiving and displaying software should
+ disable the ability to change system and device
+ parameters. If these operators cannot be completely
+ disabled the password associated with them should at
+ least be set to a hard-to-guess value.
+
+ (4) Some PostScript implementations provide nonstandard
+ facilities for the direct loading and execution of
+ machine code. Such facilities are quite obviously open
+ to substantial abuse. Message sending software should
+ not make use of such features. Besides being totally
+ hardware-specific, they are also likely to be
+ unavailable in secure implementations of PostScript.
+ Message receiving and displaying software should not
+ allow such operators to be used if they exist.
+
+ (5) PostScript is an extensible language, and many, if not
+ most, implementations of it provide a number of their
+ own extensions. This document does not deal with such
+ extensions explicitly since they constitute an unknown
+ factor. Message sending software should not make use
+ of nonstandard extensions; they are likely to be
+ missing from some implementations. Message receiving
+ and displaying software should make sure that any
+ nonstandard PostScript operators are secure and don't
+ present any kind of threat.
+
+ (6) It is possible to write PostScript that consumes huge
+ amounts of various system resources. It is also
+ possible to write PostScript programs that loop
+ indefinitely. Both types of programs have the
+ potential to cause damage if sent to unsuspecting
+ recipients. Message-sending software should avoid the
+ construction and dissemination of such programs, which
+ is antisocial. Message receiving and displaying
+ software should provide appropriate mechanisms to abort
+ processing after a reasonable amount of time has
+ elapsed. In addition, PostScript interpreters should be
+ limited to the consumption of only a reasonable amount
+ of any given system resource.
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 16]
+
+RFC 2046 Media Types November 1996
+
+
+ (7) It is possible to include raw binary information inside
+ PostScript in various forms. This is not recommended
+ for use in Internet mail, both because it is not
+ supported by all PostScript interpreters and because it
+ significantly complicates the use of a MIME Content-
+ Transfer-Encoding. (Without such binary, PostScript
+ may typically be viewed as line-oriented data. The
+ treatment of CRLF sequences becomes extremely
+ problematic if binary and line-oriented data are mixed
+ in a single Postscript data stream.)
+
+ (8) Finally, bugs may exist in some PostScript interpreters
+ which could possibly be exploited to gain unauthorized
+ access to a recipient's system. Apart from noting this
+ possibility, there is no specific action to take to
+ prevent this, apart from the timely correction of such
+ bugs if any are found.
+
+4.5.3. Other Application Subtypes
+
+ It is expected that many other subtypes of "application" will be
+ defined in the future. MIME implementations must at a minimum treat
+ any unrecognized subtypes as being equivalent to "application/octet-
+ stream".
+
+5. Composite Media Type Values
+
+ The remaining two of the seven initial Content-Type values refer to
+ composite entities. Composite entities are handled using MIME
+ mechanisms -- a MIME processor typically handles the body directly.
+
+5.1. Multipart Media Type
+
+ In the case of multipart entities, in which one or more different
+ sets of data are combined in a single body, a "multipart" media type
+ field must appear in the entity's header. The body must then contain
+ one or more body parts, each preceded by a boundary delimiter line,
+ and the last one followed by a closing boundary delimiter line.
+ After its boundary delimiter line, each body part then consists of a
+ header area, a blank line, and a body area. Thus a body part is
+ similar to an RFC 822 message in syntax, but different in meaning.
+
+ A body part is an entity and hence is NOT to be interpreted as
+ actually being an RFC 822 message. To begin with, NO header fields
+ are actually required in body parts. A body part that starts with a
+ blank line, therefore, is allowed and is a body part for which all
+ default values are to be assumed. In such a case, the absence of a
+ Content-Type header usually indicates that the corresponding body has
+
+
+
+Freed & Borenstein Standards Track [Page 17]
+
+RFC 2046 Media Types November 1996
+
+
+ a content-type of "text/plain; charset=US-ASCII".
+
+ The only header fields that have defined meaning for body parts are
+ those the names of which begin with "Content-". All other header
+ fields may be ignored in body parts. Although they should generally
+ be retained if at all possible, they may be discarded by gateways if
+ necessary. Such other fields are permitted to appear in body parts
+ but must not be depended on. "X-" fields may be created for
+ experimental or private purposes, with the recognition that the
+ information they contain may be lost at some gateways.
+
+ NOTE: The distinction between an RFC 822 message and a body part is
+ subtle, but important. A gateway between Internet and X.400 mail,
+ for example, must be able to tell the difference between a body part
+ that contains an image and a body part that contains an encapsulated
+ message, the body of which is a JPEG image. In order to represent
+ the latter, the body part must have "Content-Type: message/rfc822",
+ and its body (after the blank line) must be the encapsulated message,
+ with its own "Content-Type: image/jpeg" header field. The use of
+ similar syntax facilitates the conversion of messages to body parts,
+ and vice versa, but the distinction between the two must be
+ understood by implementors. (For the special case in which parts
+ actually are messages, a "digest" subtype is also defined.)
+
+ As stated previously, each body part is preceded by a boundary
+ delimiter line that contains the boundary delimiter. The boundary
+ delimiter MUST NOT appear inside any of the encapsulated parts, on a
+ line by itself or as the prefix of any line. This implies that it is
+ crucial that the composing agent be able to choose and specify a
+ unique boundary parameter value that does not contain the boundary
+ parameter value of an enclosing multipart as a prefix.
+
+ All present and future subtypes of the "multipart" type must use an
+ identical syntax. Subtypes may differ in their semantics, and may
+ impose additional restrictions on syntax, but must conform to the
+ required syntax for the "multipart" type. This requirement ensures
+ that all conformant user agents will at least be able to recognize
+ and separate the parts of any multipart entity, even those of an
+ unrecognized subtype.
+
+ As stated in the definition of the Content-Transfer-Encoding field
+ [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is
+ permitted for entities of type "multipart". The "multipart" boundary
+ delimiters and header fields are always represented as 7bit US-ASCII
+ in any case (though the header fields may encode non-US-ASCII header
+ text as per RFC 2047) and data within the body parts can be encoded
+ on a part-by-part basis, with Content-Transfer-Encoding fields for
+ each appropriate body part.
+
+
+
+Freed & Borenstein Standards Track [Page 18]
+
+RFC 2046 Media Types November 1996
+
+
+5.1.1. Common Syntax
+
+ This section defines a common syntax for subtypes of "multipart".
+ All subtypes of "multipart" must use this syntax. A simple example
+ of a multipart message also appears in this section. An example of a
+ more complex multipart message is given in RFC 2049.
+
+ The Content-Type field for multipart entities requires one parameter,
+ "boundary". The boundary delimiter line is then defined as a line
+ consisting entirely of two hyphen characters ("-", decimal value 45)
+ followed by the boundary parameter value from the Content-Type header
+ field, optional linear whitespace, and a terminating CRLF.
+
+ NOTE: The hyphens are for rough compatibility with the earlier RFC
+ 934 method of message encapsulation, and for ease of searching for
+ the boundaries in some implementations. However, it should be noted
+ that multipart messages are NOT completely compatible with RFC 934
+ encapsulations; in particular, they do not obey RFC 934 quoting
+ conventions for embedded lines that begin with hyphens. This
+ mechanism was chosen over the RFC 934 mechanism because the latter
+ causes lines to grow with each level of quoting. The combination of
+ this growth with the fact that SMTP implementations sometimes wrap
+ long lines made the RFC 934 mechanism unsuitable for use in the event
+ that deeply-nested multipart structuring is ever desired.
+
+ WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-
+ type field is such that it is often necessary to enclose the boundary
+ parameter values in quotes on the Content-type line. This is not
+ always necessary, but never hurts. Implementors should be sure to
+ study the grammar carefully in order to avoid producing invalid
+ Content-type fields. Thus, a typical "multipart" Content-Type header
+ field might look like this:
+
+ Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
+
+ But the following is not valid:
+
+ Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
+
+ (because of the colon) and must instead be represented as
+
+ Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
+
+ This Content-Type value indicates that the content consists of one or
+ more parts, each with a structure that is syntactically identical to
+ an RFC 822 message, except that the header area is allowed to be
+ completely empty, and that the parts are each preceded by the line
+
+
+
+
+Freed & Borenstein Standards Track [Page 19]
+
+RFC 2046 Media Types November 1996
+
+
+ --gc0pJq0M:08jU534c0p
+
+ The boundary delimiter MUST occur at the beginning of a line, i.e.,
+ following a CRLF, and the initial CRLF is considered to be attached
+ to the boundary delimiter line rather than part of the preceding
+ part. The boundary may be followed by zero or more characters of
+ linear whitespace. It is then terminated by either another CRLF and
+ the header fields for the next part, or by two CRLFs, in which case
+ there are no header fields for the next part. If no Content-Type
+ field is present it is assumed to be "message/rfc822" in a
+ "multipart/digest" and "text/plain" otherwise.
+
+ NOTE: The CRLF preceding the boundary delimiter line is conceptually
+ attached to the boundary so that it is possible to have a part that
+ does not end with a CRLF (line break). Body parts that must be
+ considered to end with line breaks, therefore, must have two CRLFs
+ preceding the boundary delimiter line, the first of which is part of
+ the preceding body part, and the second of which is part of the
+ encapsulation boundary.
+
+ Boundary delimiters must not appear within the encapsulated material,
+ and must be no longer than 70 characters, not counting the two
+ leading hyphens.
+
+ The boundary delimiter line following the last body part is a
+ distinguished delimiter that indicates that no further body parts
+ will follow. Such a delimiter line is identical to the previous
+ delimiter lines, with the addition of two more hyphens after the
+ boundary parameter value.
+
+ --gc0pJq0M:08jU534c0p--
+
+ NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the
+ boundary value with the beginning of each candidate line. An exact
+ match of the entire candidate line is not required; it is sufficient
+ that the boundary appear in its entirety following the CRLF.
+
+ There appears to be room for additional information prior to the
+ first boundary delimiter line and following the final boundary
+ delimiter line. These areas should generally be left blank, and
+ implementations must ignore anything that appears before the first
+ boundary delimiter line or after the last one.
+
+ NOTE: These "preamble" and "epilogue" areas are generally not used
+ because of the lack of proper typing of these parts and the lack of
+ clear semantics for handling these areas at gateways, particularly
+ X.400 gateways. However, rather than leaving the preamble area
+ blank, many MIME implementations have found this to be a convenient
+
+
+
+Freed & Borenstein Standards Track [Page 20]
+
+RFC 2046 Media Types November 1996
+
+
+ place to insert an explanatory note for recipients who read the
+ message with pre-MIME software, since such notes will be ignored by
+ MIME-compliant software.
+
+ NOTE: Because boundary delimiters must not appear in the body parts
+ being encapsulated, a user agent must exercise care to choose a
+ unique boundary parameter value. The boundary parameter value in the
+ example above could have been the result of an algorithm designed to
+ produce boundary delimiters with a very low probability of already
+ existing in the data to be encapsulated without having to prescan the
+ data. Alternate algorithms might result in more "readable" boundary
+ delimiters for a recipient with an old user agent, but would require
+ more attention to the possibility that the boundary delimiter might
+ appear at the beginning of some line in the encapsulated part. The
+ simplest boundary delimiter line possible is something like "---",
+ with a closing boundary delimiter line of "-----".
+
+ As a very simple example, the following multipart message has two
+ parts, both of them plain text, one of them explicitly typed and one
+ of them implicitly typed:
+
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
+ Subject: Sample message
+ MIME-Version: 1.0
+ Content-type: multipart/mixed; boundary="simple boundary"
+
+ This is the preamble. It is to be ignored, though it
+ is a handy place for composition agents to include an
+ explanatory note to non-MIME conformant readers.
+
+ --simple boundary
+
+ This is implicitly typed plain US-ASCII text.
+ It does NOT end with a linebreak.
+ --simple boundary
+ Content-type: text/plain; charset=us-ascii
+
+ This is explicitly typed plain US-ASCII text.
+ It DOES end with a linebreak.
+
+ --simple boundary--
+
+ This is the epilogue. It is also to be ignored.
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 21]
+
+RFC 2046 Media Types November 1996
+
+
+ The use of a media type of "multipart" in a body part within another
+ "multipart" entity is explicitly allowed. In such cases, for obvious
+ reasons, care must be taken to ensure that each nested "multipart"
+ entity uses a different boundary delimiter. See RFC 2049 for an
+ example of nested "multipart" entities.
+
+ The use of the "multipart" media type with only a single body part
+ may be useful in certain contexts, and is explicitly permitted.
+
+ NOTE: Experience has shown that a "multipart" media type with a
+ single body part is useful for sending non-text media types. It has
+ the advantage of providing the preamble as a place to include
+ decoding instructions. In addition, a number of SMTP gateways move
+ or remove the MIME headers, and a clever MIME decoder can take a good
+ guess at multipart boundaries even in the absence of the Content-Type
+ header and thereby successfully decode the message.
+
+ The only mandatory global parameter for the "multipart" media type is
+ the boundary parameter, which consists of 1 to 70 characters from a
+ set of characters known to be very robust through mail gateways, and
+ NOT ending with white space. (If a boundary delimiter line appears to
+ end with white space, the white space must be presumed to have been
+ added by a gateway, and must be deleted.) It is formally specified
+ by the following BNF:
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
+ "+" / "_" / "," / "-" / "." /
+ "/" / ":" / "=" / "?"
+
+ Overall, the body of a "multipart" entity may be specified as
+ follows:
+
+ dash-boundary := "--" boundary
+ ; boundary taken from the value of
+ ; boundary parameter of the
+ ; Content-Type field.
+
+ multipart-body := [preamble CRLF]
+ dash-boundary transport-padding CRLF
+ body-part *encapsulation
+ close-delimiter transport-padding
+ [CRLF epilogue]
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 22]
+
+RFC 2046 Media Types November 1996
+
+
+ transport-padding := *LWSP-char
+ ; Composers MUST NOT generate
+ ; non-zero length transport
+ ; padding, but receivers MUST
+ ; be able to handle padding
+ ; added by message transports.
+
+ encapsulation := delimiter transport-padding
+ CRLF body-part
+
+ delimiter := CRLF dash-boundary
+
+ close-delimiter := delimiter "--"
+
+ preamble := discard-text
+
+ epilogue := discard-text
+
+ discard-text := *(*text CRLF) *text
+ ; May be ignored or discarded.
+
+ body-part := MIME-part-headers [CRLF *OCTET]
+ ; Lines in a body-part must not start
+ ; with the specified dash-boundary and
+ ; the delimiter must not appear anywhere
+ ; in the body part. Note that the
+ ; semantics of a body-part differ from
+ ; the semantics of a message, as
+ ; described in the text.
+
+ OCTET := <any 0-255 octet value>
+
+ IMPORTANT: The free insertion of linear-white-space and RFC 822
+ comments between the elements shown in this BNF is NOT allowed since
+ this BNF does not specify a structured header field.
+
+ NOTE: In certain transport enclaves, RFC 822 restrictions such as
+ the one that limits bodies to printable US-ASCII characters may not
+ be in force. (That is, the transport domains may exist that resemble
+ standard Internet mail transport as specified in RFC 821 and assumed
+ by RFC 822, but without certain restrictions.) The relaxation of
+ these restrictions should be construed as locally extending the
+ definition of bodies, for example to include octets outside of the
+ US-ASCII range, as long as these extensions are supported by the
+ transport and adequately documented in the Content- Transfer-Encoding
+ header field. However, in no event are headers (either message
+ headers or body part headers) allowed to contain anything other than
+ US-ASCII characters.
+
+
+
+Freed & Borenstein Standards Track [Page 23]
+
+RFC 2046 Media Types November 1996
+
+
+ NOTE: Conspicuously missing from the "multipart" type is a notion of
+ structured, related body parts. It is recommended that those wishing
+ to provide more structured or integrated multipart messaging
+ facilities should define subtypes of multipart that are syntactically
+ identical but define relationships between the various parts. For
+ example, subtypes of multipart could be defined that include a
+ distinguished part which in turn is used to specify the relationships
+ between the other parts, probably referring to them by their
+ Content-ID field. Old implementations will not recognize the new
+ subtype if this approach is used, but will treat it as
+ multipart/mixed and will thus be able to show the user the parts that
+ are recognized.
+
+5.1.2. Handling Nested Messages and Multiparts
+
+ The "message/rfc822" subtype defined in a subsequent section of this
+ document has no terminating condition other than running out of data.
+ Similarly, an improperly truncated "multipart" entity may not have
+ any terminating boundary marker, and can turn up operationally due to
+ mail system malfunctions.
+
+ It is essential that such entities be handled correctly when they are
+ themselves imbedded inside of another "multipart" structure. MIME
+ implementations are therefore required to recognize outer level
+ boundary markers at ANY level of inner nesting. It is not sufficient
+ to only check for the next expected marker or other terminating
+ condition.
+
+5.1.3. Mixed Subtype
+
+ The "mixed" subtype of "multipart" is intended for use when the body
+ parts are independent and need to be bundled in a particular order.
+ Any "multipart" subtypes that an implementation does not recognize
+ must be treated as being of subtype "mixed".
+
+5.1.4. Alternative Subtype
+
+ The "multipart/alternative" type is syntactically identical to
+ "multipart/mixed", but the semantics are different. In particular,
+ each of the body parts is an "alternative" version of the same
+ information.
+
+ Systems should recognize that the content of the various parts are
+ interchangeable. Systems should choose the "best" type based on the
+ local environment and references, in some cases even through user
+ interaction. As with "multipart/mixed", the order of body parts is
+ significant. In this case, the alternatives appear in an order of
+ increasing faithfulness to the original content. In general, the
+
+
+
+Freed & Borenstein Standards Track [Page 24]
+
+RFC 2046 Media Types November 1996
+
+
+ best choice is the LAST part of a type supported by the recipient
+ system's local environment.
+
+ "Multipart/alternative" may be used, for example, to send a message
+ in a fancy text format in such a way that it can easily be displayed
+ anywhere:
+
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
+ Subject: Formatted text mail
+ MIME-Version: 1.0
+ Content-Type: multipart/alternative; boundary=boundary42
+
+ --boundary42
+ Content-Type: text/plain; charset=us-ascii
+
+ ... plain text version of message goes here ...
+
+ --boundary42
+ Content-Type: text/enriched
+
+ ... RFC 1896 text/enriched version of same message
+ goes here ...
+
+ --boundary42
+ Content-Type: application/x-whatever
+
+ ... fanciest version of same message goes here ...
+
+ --boundary42--
+
+ In this example, users whose mail systems understood the
+ "application/x-whatever" format would see only the fancy version,
+ while other users would see only the enriched or plain text version,
+ depending on the capabilities of their system.
+
+ In general, user agents that compose "multipart/alternative" entities
+ must place the body parts in increasing order of preference, that is,
+ with the preferred format last. For fancy text, the sending user
+ agent should put the plainest format first and the richest format
+ last. Receiving user agents should pick and display the last format
+ they are capable of displaying. In the case where one of the
+ alternatives is itself of type "multipart" and contains unrecognized
+ sub-parts, the user agent may choose either to show that alternative,
+ an earlier alternative, or both.
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 25]
+
+RFC 2046 Media Types November 1996
+
+
+ NOTE: From an implementor's perspective, it might seem more sensible
+ to reverse this ordering, and have the plainest alternative last.
+ However, placing the plainest alternative first is the friendliest
+ possible option when "multipart/alternative" entities are viewed
+ using a non-MIME-conformant viewer. While this approach does impose
+ some burden on conformant MIME viewers, interoperability with older
+ mail readers was deemed to be more important in this case.
+
+ It may be the case that some user agents, if they can recognize more
+ than one of the formats, will prefer to offer the user the choice of
+ which format to view. This makes sense, for example, if a message
+ includes both a nicely- formatted image version and an easily-edited
+ text version. What is most critical, however, is that the user not
+ automatically be shown multiple versions of the same data. Either
+ the user should be shown the last recognized version or should be
+ given the choice.
+
+ THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each part of a
+ "multipart/alternative" entity represents the same data, but the
+ mappings between the two are not necessarily without information
+ loss. For example, information is lost when translating ODA to
+ PostScript or plain text. It is recommended that each part should
+ have a different Content-ID value in the case where the information
+ content of the two parts is not identical. And when the information
+ content is identical -- for example, where several parts of type
+ "message/external-body" specify alternate ways to access the
+ identical data -- the same Content-ID field value should be used, to
+ optimize any caching mechanisms that might be present on the
+ recipient's end. However, the Content-ID values used by the parts
+ should NOT be the same Content-ID value that describes the
+ "multipart/alternative" as a whole, if there is any such Content-ID
+ field. That is, one Content-ID value will refer to the
+ "multipart/alternative" entity, while one or more other Content-ID
+ values will refer to the parts inside it.
+
+5.1.5. Digest Subtype
+
+ This document defines a "digest" subtype of the "multipart" Content-
+ Type. This type is syntactically identical to "multipart/mixed", but
+ the semantics are different. In particular, in a digest, the default
+ Content-Type value for a body part is changed from "text/plain" to
+ "message/rfc822". This is done to allow a more readable digest
+ format that is largely compatible (except for the quoting convention)
+ with RFC 934.
+
+ Note: Though it is possible to specify a Content-Type value for a
+ body part in a digest which is other than "message/rfc822", such as a
+ "text/plain" part containing a description of the material in the
+
+
+
+Freed & Borenstein Standards Track [Page 26]
+
+RFC 2046 Media Types November 1996
+
+
+ digest, actually doing so is undesireble. The "multipart/digest"
+ Content-Type is intended to be used to send collections of messages.
+ If a "text/plain" part is needed, it should be included as a seperate
+ part of a "multipart/mixed" message.
+
+ A digest in this format might, then, look something like this:
+
+ From: Moderator-Address
+ To: Recipient-List
+ Date: Mon, 22 Mar 1994 13:34:51 +0000
+ Subject: Internet Digest, volume 42
+ MIME-Version: 1.0
+ Content-Type: multipart/mixed;
+ boundary="---- main boundary ----"
+
+ ------ main boundary ----
+
+ ...Introductory text or table of contents...
+
+ ------ main boundary ----
+ Content-Type: multipart/digest;
+ boundary="---- next message ----"
+
+ ------ next message ----
+
+ From: someone-else
+ Date: Fri, 26 Mar 1993 11:13:32 +0200
+ Subject: my opinion
+
+ ...body goes here ...
+
+ ------ next message ----
+
+ From: someone-else-again
+ Date: Fri, 26 Mar 1993 10:07:13 -0500
+ Subject: my different opinion
+
+ ... another body goes here ...
+
+ ------ next message ------
+
+ ------ main boundary ------
+
+5.1.6. Parallel Subtype
+
+ This document defines a "parallel" subtype of the "multipart"
+ Content-Type. This type is syntactically identical to
+ "multipart/mixed", but the semantics are different. In particular,
+
+
+
+Freed & Borenstein Standards Track [Page 27]
+
+RFC 2046 Media Types November 1996
+
+
+ in a parallel entity, the order of body parts is not significant.
+
+ A common presentation of this type is to display all of the parts
+ simultaneously on hardware and software that are capable of doing so.
+ However, composing agents should be aware that many mail readers will
+ lack this capability and will show the parts serially in any event.
+
+5.1.7. Other Multipart Subtypes
+
+ Other "multipart" subtypes are expected in the future. MIME
+ implementations must in general treat unrecognized subtypes of
+ "multipart" as being equivalent to "multipart/mixed".
+
+5.2. Message Media Type
+
+ It is frequently desirable, in sending mail, to encapsulate another
+ mail message. A special media type, "message", is defined to
+ facilitate this. In particular, the "rfc822" subtype of "message" is
+ used to encapsulate RFC 822 messages.
+
+ NOTE: It has been suggested that subtypes of "message" might be
+ defined for forwarded or rejected messages. However, forwarded and
+ rejected messages can be handled as multipart messages in which the
+ first part contains any control or descriptive information, and a
+ second part, of type "message/rfc822", is the forwarded or rejected
+ message. Composing rejection and forwarding messages in this manner
+ will preserve the type information on the original message and allow
+ it to be correctly presented to the recipient, and hence is strongly
+ encouraged.
+
+ Subtypes of "message" often impose restrictions on what encodings are
+ allowed. These restrictions are described in conjunction with each
+ specific subtype.
+
+ Mail gateways, relays, and other mail handling agents are commonly
+ known to alter the top-level header of an RFC 822 message. In
+ particular, they frequently add, remove, or reorder header fields.
+ These operations are explicitly forbidden for the encapsulated
+ headers embedded in the bodies of messages of type "message."
+
+5.2.1. RFC822 Subtype
+
+ A media type of "message/rfc822" indicates that the body contains an
+ encapsulated message, with the syntax of an RFC 822 message.
+ However, unlike top-level RFC 822 messages, the restriction that each
+ "message/rfc822" body must include a "From", "Date", and at least one
+ destination header is removed and replaced with the requirement that
+ at least one of "From", "Subject", or "Date" must be present.
+
+
+
+Freed & Borenstein Standards Track [Page 28]
+
+RFC 2046 Media Types November 1996
+
+
+ It should be noted that, despite the use of the numbers "822", a
+ "message/rfc822" entity isn't restricted to material in strict
+ conformance to RFC822, nor are the semantics of "message/rfc822"
+ objects restricted to the semantics defined in RFC822. More
+ specifically, a "message/rfc822" message could well be a News article
+ or a MIME message.
+
+ No encoding other than "7bit", "8bit", or "binary" is permitted for
+ the body of a "message/rfc822" entity. The message header fields are
+ always US-ASCII in any case, and data within the body can still be
+ encoded, in which case the Content-Transfer-Encoding header field in
+ the encapsulated message will reflect this. Non-US-ASCII text in the
+ headers of an encapsulated message can be specified using the
+ mechanisms described in RFC 2047.
+
+5.2.2. Partial Subtype
+
+ The "partial" subtype is defined to allow large entities to be
+ delivered as several separate pieces of mail and automatically
+ reassembled by a receiving user agent. (The concept is similar to IP
+ fragmentation and reassembly in the basic Internet Protocols.) This
+ mechanism can be used when intermediate transport agents limit the
+ size of individual messages that can be sent. The media type
+ "message/partial" thus indicates that the body contains a fragment of
+ a larger entity.
+
+ Because data of type "message" may never be encoded in base64 or
+ quoted-printable, a problem might arise if "message/partial" entities
+ are constructed in an environment that supports binary or 8bit
+ transport. The problem is that the binary data would be split into
+ multiple "message/partial" messages, each of them requiring binary
+ transport. If such messages were encountered at a gateway into a
+ 7bit transport environment, there would be no way to properly encode
+ them for the 7bit world, aside from waiting for all of the fragments,
+ reassembling the inner message, and then encoding the reassembled
+ data in base64 or quoted-printable. Since it is possible that
+ different fragments might go through different gateways, even this is
+ not an acceptable solution. For this reason, it is specified that
+ entities of type "message/partial" must always have a content-
+ transfer-encoding of 7bit (the default). In particular, even in
+ environments that support binary or 8bit transport, the use of a
+ content- transfer-encoding of "8bit" or "binary" is explicitly
+ prohibited for MIME entities of type "message/partial". This in turn
+ implies that the inner message must not use "8bit" or "binary"
+ encoding.
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 29]
+
+RFC 2046 Media Types November 1996
+
+
+ Because some message transfer agents may choose to automatically
+ fragment large messages, and because such agents may use very
+ different fragmentation thresholds, it is possible that the pieces of
+ a partial message, upon reassembly, may prove themselves to comprise
+ a partial message. This is explicitly permitted.
+
+ Three parameters must be specified in the Content-Type field of type
+ "message/partial": The first, "id", is a unique identifier, as close
+ to a world-unique identifier as possible, to be used to match the
+ fragments together. (In general, the identifier is essentially a
+ message-id; if placed in double quotes, it can be ANY message-id, in
+ accordance with the BNF for "parameter" given in RFC 2045.) The
+ second, "number", an integer, is the fragment number, which indicates
+ where this fragment fits into the sequence of fragments. The third,
+ "total", another integer, is the total number of fragments. This
+ third subfield is required on the final fragment, and is optional
+ (though encouraged) on the earlier fragments. Note also that these
+ parameters may be given in any order.
+
+ Thus, the second piece of a 3-piece message may have either of the
+ following header fields:
+
+ Content-Type: Message/Partial; number=2; total=3;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
+
+ Content-Type: Message/Partial;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
+ number=2
+
+ But the third piece MUST specify the total number of fragments:
+
+ Content-Type: Message/Partial; number=3; total=3;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
+
+ Note that fragment numbering begins with 1, not 0.
+
+ When the fragments of an entity broken up in this manner are put
+ together, the result is always a complete MIME entity, which may have
+ its own Content-Type header field, and thus may contain any other
+ data type.
+
+5.2.2.1. Message Fragmentation and Reassembly
+
+ The semantics of a reassembled partial message must be those of the
+ "inner" message, rather than of a message containing the inner
+ message. This makes it possible, for example, to send a large audio
+ message as several partial messages, and still have it appear to the
+ recipient as a simple audio message rather than as an encapsulated
+
+
+
+Freed & Borenstein Standards Track [Page 30]
+
+RFC 2046 Media Types November 1996
+
+
+ message containing an audio message. That is, the encapsulation of
+ the message is considered to be "transparent".
+
+ When generating and reassembling the pieces of a "message/partial"
+ message, the headers of the encapsulated message must be merged with
+ the headers of the enclosing entities. In this process the following
+ rules must be observed:
+
+ (1) Fragmentation agents must split messages at line
+ boundaries only. This restriction is imposed because
+ splits at points other than the ends of lines in turn
+ depends on message transports being able to preserve
+ the semantics of messages that don't end with a CRLF
+ sequence. Many transports are incapable of preserving
+ such semantics.
+
+ (2) All of the header fields from the initial enclosing
+ message, except those that start with "Content-" and
+ the specific header fields "Subject", "Message-ID",
+ "Encrypted", and "MIME-Version", must be copied, in
+ order, to the new message.
+
+ (3) The header fields in the enclosed message which start
+ with "Content-", plus the "Subject", "Message-ID",
+ "Encrypted", and "MIME-Version" fields, must be
+ appended, in order, to the header fields of the new
+ message. Any header fields in the enclosed message
+ which do not start with "Content-" (except for the
+ "Subject", "Message-ID", "Encrypted", and "MIME-
+ Version" fields) will be ignored and dropped.
+
+ (4) All of the header fields from the second and any
+ subsequent enclosing messages are discarded by the
+ reassembly process.
+
+5.2.2.2. Fragmentation and Reassembly Example
+
+ If an audio message is broken into two pieces, the first piece might
+ look something like this:
+
+ X-Weird-Header-1: Foo
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
+ Subject: Audio mail (part 1 of 2)
+ Message-ID: <id1@host.com>
+ MIME-Version: 1.0
+ Content-type: message/partial; id="ABC@host.com";
+
+
+
+Freed & Borenstein Standards Track [Page 31]
+
+RFC 2046 Media Types November 1996
+
+
+ number=1; total=2
+
+ X-Weird-Header-1: Bar
+ X-Weird-Header-2: Hello
+ Message-ID: <anotherid@foo.com>
+ Subject: Audio mail
+ MIME-Version: 1.0
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here ...
+
+ and the second half might look something like this:
+
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
+ Subject: Audio mail (part 2 of 2)
+ MIME-Version: 1.0
+ Message-ID: <id2@host.com>
+ Content-type: message/partial;
+ id="ABC@host.com"; number=2; total=2
+
+ ... second half of encoded audio data goes here ...
+
+ Then, when the fragmented message is reassembled, the resulting
+ message to be displayed to the user should look something like this:
+
+ X-Weird-Header-1: Foo
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
+ Subject: Audio mail
+ Message-ID: <anotherid@foo.com>
+ MIME-Version: 1.0
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here ...
+ ... second half of encoded audio data goes here ...
+
+ The inclusion of a "References" field in the headers of the second
+ and subsequent pieces of a fragmented message that references the
+ Message-Id on the previous piece may be of benefit to mail readers
+ that understand and track references. However, the generation of
+ such "References" fields is entirely optional.
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 32]
+
+RFC 2046 Media Types November 1996
+
+
+ Finally, it should be noted that the "Encrypted" header field has
+ been made obsolete by Privacy Enhanced Messaging (PEM) [RFC-1421,
+ RFC-1422, RFC-1423, RFC-1424], but the rules above are nevertheless
+ believed to describe the correct way to treat it if it is encountered
+ in the context of conversion to and from "message/partial" fragments.
+
+5.2.3. External-Body Subtype
+
+ The external-body subtype indicates that the actual body data are not
+ included, but merely referenced. In this case, the parameters
+ describe a mechanism for accessing the external data.
+
+ When a MIME entity is of type "message/external-body", it consists of
+ a header, two consecutive CRLFs, and the message header for the
+ encapsulated message. If another pair of consecutive CRLFs appears,
+ this of course ends the message header for the encapsulated message.
+ However, since the encapsulated message's body is itself external, it
+ does NOT appear in the area that follows. For example, consider the
+ following message:
+
+ Content-type: message/external-body;
+ access-type=local-file;
+ name="/u/nsb/Me.jpeg"
+
+ Content-type: image/jpeg
+ Content-ID: <id42@guppylake.bellcore.com>
+ Content-Transfer-Encoding: binary
+
+ THIS IS NOT REALLY THE BODY!
+
+ The area at the end, which might be called the "phantom body", is
+ ignored for most external-body messages. However, it may be used to
+ contain auxiliary information for some such messages, as indeed it is
+ when the access-type is "mail- server". The only access-type defined
+ in this document that uses the phantom body is "mail-server", but
+ other access-types may be defined in the future in other
+ specifications that use this area.
+
+ The encapsulated headers in ALL "message/external-body" entities MUST
+ include a Content-ID header field to give a unique identifier by
+ which to reference the data. This identifier may be used for caching
+ mechanisms, and for recognizing the receipt of the data when the
+ access-type is "mail-server".
+
+ Note that, as specified here, the tokens that describe external-body
+ data, such as file names and mail server commands, are required to be
+ in the US-ASCII character set.
+
+
+
+
+Freed & Borenstein Standards Track [Page 33]
+
+RFC 2046 Media Types November 1996
+
+
+ If this proves problematic in practice, a new mechanism may be
+ required as a future extension to MIME, either as newly defined
+ access-types for "message/external-body" or by some other mechanism.
+
+ As with "message/partial", MIME entities of type "message/external-
+ body" MUST have a content-transfer-encoding of 7bit (the default).
+ In particular, even in environments that support binary or 8bit
+ transport, the use of a content- transfer-encoding of "8bit" or
+ "binary" is explicitly prohibited for entities of type
+ "message/external-body".
+
+5.2.3.1. General External-Body Parameters
+
+ The parameters that may be used with any "message/external- body"
+ are:
+
+ (1) ACCESS-TYPE -- A word indicating the supported access
+ mechanism by which the file or data may be obtained.
+ This word is not case sensitive. Values include, but
+ are not limited to, "FTP", "ANON-FTP", "TFTP", "LOCAL-
+ FILE", and "MAIL-SERVER". Future values, except for
+ experimental values beginning with "X-", must be
+ registered with IANA, as described in RFC 2048.
+ This parameter is unconditionally mandatory and MUST be
+ present on EVERY "message/external-body".
+
+ (2) EXPIRATION -- The date (in the RFC 822 "date-time"
+ syntax, as extended by RFC 1123 to permit 4 digits in
+ the year field) after which the existence of the
+ external data is not guaranteed. This parameter may be
+ used with ANY access-type and is ALWAYS optional.
+
+ (3) SIZE -- The size (in octets) of the data. The intent
+ of this parameter is to help the recipient decide
+ whether or not to expend the necessary resources to
+ retrieve the external data. Note that this describes
+ the size of the data in its canonical form, that is,
+ before any Content-Transfer-Encoding has been applied
+ or after the data have been decoded. This parameter
+ may be used with ANY access-type and is ALWAYS
+ optional.
+
+ (4) PERMISSION -- A case-insensitive field that indicates
+ whether or not it is expected that clients might also
+ attempt to overwrite the data. By default, or if
+ permission is "read", the assumption is that they are
+ not, and that if the data is retrieved once, it is
+ never needed again. If PERMISSION is "read-write",
+
+
+
+Freed & Borenstein Standards Track [Page 34]
+
+RFC 2046 Media Types November 1996
+
+
+ this assumption is invalid, and any local copy must be
+ considered no more than a cache. "Read" and "Read-
+ write" are the only defined values of permission. This
+ parameter may be used with ANY access-type and is
+ ALWAYS optional.
+
+ The precise semantics of the access-types defined here are described
+ in the sections that follow.
+
+5.2.3.2. The 'ftp' and 'tftp' Access-Types
+
+ An access-type of FTP or TFTP indicates that the message body is
+ accessible as a file using the FTP [RFC-959] or TFTP [RFC- 783]
+ protocols, respectively. For these access-types, the following
+ additional parameters are mandatory:
+
+ (1) NAME -- The name of the file that contains the actual
+ body data.
+
+ (2) SITE -- A machine from which the file may be obtained,
+ using the given protocol. This must be a fully
+ qualified domain name, not a nickname.
+
+ (3) Before any data are retrieved, using FTP, the user will
+ generally need to be asked to provide a login id and a
+ password for the machine named by the site parameter.
+ For security reasons, such an id and password are not
+ specified as content-type parameters, but must be
+ obtained from the user.
+
+ In addition, the following parameters are optional:
+
+ (1) DIRECTORY -- A directory from which the data named by
+ NAME should be retrieved.
+
+ (2) MODE -- A case-insensitive string indicating the mode
+ to be used when retrieving the information. The valid
+ values for access-type "TFTP" are "NETASCII", "OCTET",
+ and "MAIL", as specified by the TFTP protocol [RFC-
+ 783]. The valid values for access-type "FTP" are
+ "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
+ decimal integer, typically 8. These correspond to the
+ representation types "A" "E" "I" and "L n" as specified
+ by the FTP protocol [RFC-959]. Note that "BINARY" and
+ "TENEX" are not valid values for MODE and that "OCTET"
+ or "IMAGE" or "LOCAL8" should be used instead. IF MODE
+ is not specified, the default value is "NETASCII" for
+ TFTP and "ASCII" otherwise.
+
+
+
+Freed & Borenstein Standards Track [Page 35]
+
+RFC 2046 Media Types November 1996
+
+
+5.2.3.3. The 'anon-ftp' Access-Type
+
+ The "anon-ftp" access-type is identical to the "ftp" access type,
+ except that the user need not be asked to provide a name and password
+ for the specified site. Instead, the ftp protocol will be used with
+ login "anonymous" and a password that corresponds to the user's mail
+ address.
+
+5.2.3.4. The 'local-file' Access-Type
+
+ An access-type of "local-file" indicates that the actual body is
+ accessible as a file on the local machine. Two additional parameters
+ are defined for this access type:
+
+ (1) NAME -- The name of the file that contains the actual
+ body data. This parameter is mandatory for the
+ "local-file" access-type.
+
+ (2) SITE -- A domain specifier for a machine or set of
+ machines that are known to have access to the data
+ file. This optional parameter is used to describe the
+ locality of reference for the data, that is, the site
+ or sites at which the file is expected to be visible.
+ Asterisks may be used for wildcard matching to a part
+ of a domain name, such as "*.bellcore.com", to indicate
+ a set of machines on which the data should be directly
+ visible, while a single asterisk may be used to
+ indicate a file that is expected to be universally
+ available, e.g., via a global file system.
+
+5.2.3.5. The 'mail-server' Access-Type
+
+ The "mail-server" access-type indicates that the actual body is
+ available from a mail server. Two additional parameters are defined
+ for this access-type:
+
+ (1) SERVER -- The addr-spec of the mail server from which
+ the actual body data can be obtained. This parameter
+ is mandatory for the "mail-server" access-type.
+
+ (2) SUBJECT -- The subject that is to be used in the mail
+ that is sent to obtain the data. Note that keying mail
+ servers on Subject lines is NOT recommended, but such
+ mail servers are known to exist. This is an optional
+ parameter.
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 36]
+
+RFC 2046 Media Types November 1996
+
+
+ Because mail servers accept a variety of syntaxes, some of which is
+ multiline, the full command to be sent to a mail server is not
+ included as a parameter in the content-type header field. Instead,
+ it is provided as the "phantom body" when the media type is
+ "message/external-body" and the access-type is mail-server.
+
+ Note that MIME does not define a mail server syntax. Rather, it
+ allows the inclusion of arbitrary mail server commands in the phantom
+ body. Implementations must include the phantom body in the body of
+ the message it sends to the mail server address to retrieve the
+ relevant data.
+
+ Unlike other access-types, mail-server access is asynchronous and
+ will happen at an unpredictable time in the future. For this reason,
+ it is important that there be a mechanism by which the returned data
+ can be matched up with the original "message/external-body" entity.
+ MIME mail servers must use the same Content-ID field on the returned
+ message that was used in the original "message/external-body"
+ entities, to facilitate such matching.
+
+5.2.3.6. External-Body Security Issues
+
+ "Message/external-body" entities give rise to two important security
+ issues:
+
+ (1) Accessing data via a "message/external-body" reference
+ effectively results in the message recipient performing
+ an operation that was specified by the message
+ originator. It is therefore possible for the message
+ originator to trick a recipient into doing something
+ they would not have done otherwise. For example, an
+ originator could specify a action that attempts
+ retrieval of material that the recipient is not
+ authorized to obtain, causing the recipient to
+ unwittingly violate some security policy. For this
+ reason, user agents capable of resolving external
+ references must always take steps to describe the
+ action they are to take to the recipient and ask for
+ explicit permisssion prior to performing it.
+
+ The 'mail-server' access-type is particularly
+ vulnerable, in that it causes the recipient to send a
+ new message whose contents are specified by the
+ original message's originator. Given the potential for
+ abuse, any such request messages that are constructed
+ should contain a clear indication that they were
+ generated automatically (e.g. in a Comments: header
+ field) in an attempt to resolve a MIME
+
+
+
+Freed & Borenstein Standards Track [Page 37]
+
+RFC 2046 Media Types November 1996
+
+
+ "message/external-body" reference.
+
+ (2) MIME will sometimes be used in environments that
+ provide some guarantee of message integrity and
+ authenticity. If present, such guarantees may apply
+ only to the actual direct content of messages -- they
+ may or may not apply to data accessed through MIME's
+ "message/external-body" mechanism. In particular, it
+ may be possible to subvert certain access mechanisms
+ even when the messaging system itself is secure.
+
+ It should be noted that this problem exists either with
+ or without the availabilty of MIME mechanisms. A
+ casual reference to an FTP site containing a document
+ in the text of a secure message brings up similar
+ issues -- the only difference is that MIME provides for
+ automatic retrieval of such material, and users may
+ place unwarranted trust is such automatic retrieval
+ mechanisms.
+
+5.2.3.7. Examples and Further Explanations
+
+ When the external-body mechanism is used in conjunction with the
+ "multipart/alternative" media type it extends the functionality of
+ "multipart/alternative" to include the case where the same entity is
+ provided in the same format but via different accces mechanisms.
+ When this is done the originator of the message must order the parts
+ first in terms of preferred formats and then by preferred access
+ mechanisms. The recipient's viewer should then evaluate the list
+ both in terms of format and access mechanisms.
+
+ With the emerging possibility of very wide-area file systems, it
+ becomes very hard to know in advance the set of machines where a file
+ will and will not be accessible directly from the file system.
+ Therefore it may make sense to provide both a file name, to be tried
+ directly, and the name of one or more sites from which the file is
+ known to be accessible. An implementation can try to retrieve remote
+ files using FTP or any other protocol, using anonymous file retrieval
+ or prompting the user for the necessary name and password. If an
+ external body is accessible via multiple mechanisms, the sender may
+ include multiple entities of type "message/external-body" within the
+ body parts of an enclosing "multipart/alternative" entity.
+
+ However, the external-body mechanism is not intended to be limited to
+ file retrieval, as shown by the mail-server access-type. Beyond
+ this, one can imagine, for example, using a video server for external
+ references to video clips.
+
+
+
+
+Freed & Borenstein Standards Track [Page 38]
+
+RFC 2046 Media Types November 1996
+
+
+ The embedded message header fields which appear in the body of the
+ "message/external-body" data must be used to declare the media type
+ of the external body if it is anything other than plain US-ASCII
+ text, since the external body does not have a header section to
+ declare its type. Similarly, any Content-transfer-encoding other
+ than "7bit" must also be declared here. Thus a complete
+ "message/external-body" message, referring to an object in PostScript
+ format, might look like this:
+
+ From: Whomever
+ To: Someone
+ Date: Whenever
+ Subject: whatever
+ MIME-Version: 1.0
+ Message-ID: <id1@host.com>
+ Content-Type: multipart/alternative; boundary=42
+ Content-ID: <id001@guppylake.bellcore.com>
+
+ --42
+ Content-Type: message/external-body; name="BodyFormats.ps";
+ site="thumper.bellcore.com"; mode="image";
+ access-type=ANON-FTP; directory="pub";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+ Content-ID: <id42@guppylake.bellcore.com>
+
+ --42
+ Content-Type: message/external-body; access-type=local-file;
+ name="/u/nsb/writing/rfcs/RFC-MIME.ps";
+ site="thumper.bellcore.com";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+ Content-ID: <id42@guppylake.bellcore.com>
+
+ --42
+ Content-Type: message/external-body;
+ access-type=mail-server
+ server="listserv@bogus.bitnet";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+ Content-ID: <id42@guppylake.bellcore.com>
+
+ get RFC-MIME.DOC
+
+ --42--
+
+
+
+Freed & Borenstein Standards Track [Page 39]
+
+RFC 2046 Media Types November 1996
+
+
+ Note that in the above examples, the default Content-transfer-
+ encoding of "7bit" is assumed for the external postscript data.
+
+ Like the "message/partial" type, the "message/external-body" media
+ type is intended to be transparent, that is, to convey the data type
+ in the external body rather than to convey a message with a body of
+ that type. Thus the headers on the outer and inner parts must be
+ merged using the same rules as for "message/partial". In particular,
+ this means that the Content-type and Subject fields are overridden,
+ but the From field is preserved.
+
+ Note that since the external bodies are not transported along with
+ the external body reference, they need not conform to transport
+ limitations that apply to the reference itself. In particular,
+ Internet mail transports may impose 7bit and line length limits, but
+ these do not automatically apply to binary external body references.
+ Thus a Content-Transfer-Encoding is not generally necessary, though
+ it is permitted.
+
+ Note that the body of a message of type "message/external-body" is
+ governed by the basic syntax for an RFC 822 message. In particular,
+ anything before the first consecutive pair of CRLFs is header
+ information, while anything after it is body information, which is
+ ignored for most access-types.
+
+5.2.4. Other Message Subtypes
+
+ MIME implementations must in general treat unrecognized subtypes of
+ "message" as being equivalent to "application/octet-stream".
+
+ Future subtypes of "message" intended for use with email should be
+ restricted to "7bit" encoding. A type other than "message" should be
+ used if restriction to "7bit" is not possible.
+
+6. Experimental Media Type Values
+
+ A media type value beginning with the characters "X-" is a private
+ value, to be used by consenting systems by mutual agreement. Any
+ format without a rigorous and public definition must be named with an
+ "X-" prefix, and publicly specified values shall never begin with
+ "X-". (Older versions of the widely used Andrew system use the "X-
+ BE2" name, so new systems should probably choose a different name.)
+
+ In general, the use of "X-" top-level types is strongly discouraged.
+ Implementors should invent subtypes of the existing types whenever
+ possible. In many cases, a subtype of "application" will be more
+ appropriate than a new top-level type.
+
+
+
+
+Freed & Borenstein Standards Track [Page 40]
+
+RFC 2046 Media Types November 1996
+
+
+7. Summary
+
+ The five discrete media types provide provide a standardized
+ mechanism for tagging entities as "audio", "image", or several other
+ kinds of data. The composite "multipart" and "message" media types
+ allow mixing and hierarchical structuring of entities of different
+ types in a single message. A distinguished parameter syntax allows
+ further specification of data format details, particularly the
+ specification of alternate character sets. Additional optional
+ header fields provide mechanisms for certain extensions deemed
+ desirable by many implementors. Finally, a number of useful media
+ types are defined for general use by consenting user agents, notably
+ "message/partial" and "message/external-body".
+
+9. Security Considerations
+
+ Security issues are discussed in the context of the
+ "application/postscript" type, the "message/external-body" type, and
+ in RFC 2048. Implementors should pay special attention to the
+ security implications of any media types that can cause the remote
+ execution of any actions in the recipient's environment. In such
+ cases, the discussion of the "application/postscript" type may serve
+ as a model for considering other media types with remote execution
+ capabilities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 41]
+
+RFC 2046 Media Types November 1996
+
+
+9. Authors' Addresses
+
+ For more information, the authors of this document are best contacted
+ via Internet mail:
+
+ Ned Freed
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+ Nathaniel S. Borenstein
+ First Virtual Holdings
+ 25 Washington Avenue
+ Morristown, NJ 07960
+ USA
+
+ Phone: +1 201 540 8967
+ Fax: +1 201 993 3032
+ EMail: nsb@nsb.fv.com
+
+
+ MIME is a result of the work of the Internet Engineering Task Force
+ Working Group on RFC 822 Extensions. The chairman of that group,
+ Greg Vaudreuil, may be reached at:
+
+ Gregory M. Vaudreuil
+ Octel Network Services
+ 17080 Dallas Parkway
+ Dallas, TX 75248-1905
+ USA
+
+ EMail: Greg.Vaudreuil@Octel.Com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 42]
+
+RFC 2046 Media Types November 1996
+
+
+Appendix A -- Collected Grammar
+
+ This appendix contains the complete BNF grammar for all the syntax
+ specified by this document.
+
+ By itself, however, this grammar is incomplete. It refers by name to
+ several syntax rules that are defined by RFC 822. Rather than
+ reproduce those definitions here, and risk unintentional differences
+ between the two, this document simply refers the reader to RFC 822
+ for the remaining definitions. Wherever a term is undefined, it
+ refers to the RFC 822 definition.
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
+ "+" / "_" / "," / "-" / "." /
+ "/" / ":" / "=" / "?"
+
+ body-part := <"message" as defined in RFC 822, with all
+ header fields optional, not starting with the
+ specified dash-boundary, and with the
+ delimiter not occurring anywhere in the
+ body part. Note that the semantics of a
+ part differ from the semantics of a message,
+ as described in the text.>
+
+ close-delimiter := delimiter "--"
+
+ dash-boundary := "--" boundary
+ ; boundary taken from the value of
+ ; boundary parameter of the
+ ; Content-Type field.
+
+ delimiter := CRLF dash-boundary
+
+ discard-text := *(*text CRLF)
+ ; May be ignored or discarded.
+
+ encapsulation := delimiter transport-padding
+ CRLF body-part
+
+ epilogue := discard-text
+
+ multipart-body := [preamble CRLF]
+ dash-boundary transport-padding CRLF
+ body-part *encapsulation
+
+
+
+Freed & Borenstein Standards Track [Page 43]
+
+RFC 2046 Media Types November 1996
+
+
+ close-delimiter transport-padding
+ [CRLF epilogue]
+
+ preamble := discard-text
+
+ transport-padding := *LWSP-char
+ ; Composers MUST NOT generate
+ ; non-zero length transport
+ ; padding, but receivers MUST
+ ; be able to handle padding
+ ; added by message transports.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Borenstein Standards Track [Page 44]
+
diff --git a/Documentation/en/rfc/rfc2254.txt b/Documentation/en/rfc/rfc2254.txt
new file mode 100644
index 00000000..323fdb00
--- /dev/null
+++ b/Documentation/en/rfc/rfc2254.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group T. Howes
+Request for Comments: 2254 Netscape Communications Corp.
+Category: Standards Track December 1997
+
+
+ The String Representation of LDAP Search Filters
+
+1. Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+IESG Note
+
+ This document describes a directory access protocol that provides
+ both read and update access. Update access requires secure
+ authentication, but this document does not mandate implementation of
+ any satisfactory authentication mechanisms.
+
+ In accordance with RFC 2026, section 4.4.1, this specification is
+ being approved by IESG as a Proposed Standard despite this
+ limitation, for the following reasons:
+
+ a. to encourage implementation and interoperability testing of
+ these protocols (with or without update access) before they
+ are deployed, and
+
+ b. to encourage deployment and use of these protocols in read-only
+ applications. (e.g. applications where LDAPv3 is used as
+ a query language for directories which are updated by some
+ secure mechanism other than LDAP), and
+
+ c. to avoid delaying the advancement and deployment of other Internet
+ standards-track protocols which require the ability to query, but
+ not update, LDAPv3 directory servers.
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 1]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+ Readers are hereby warned that until mandatory authentication
+ mechanisms are standardized, clients and servers written according to
+ this specification which make use of update functionality are
+ UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+ IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+ Implementors are hereby discouraged from deploying LDAPv3 clients or
+ servers which implement the update functionality, until a Proposed
+ Standard for mandatory authentication in LDAPv3 has been approved and
+ published as an RFC.
+
+2. Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) [1] defines a
+ network representation of a search filter transmitted to an LDAP
+ server. Some applications may find it useful to have a common way of
+ representing these search filters in a human-readable form. This
+ document defines a human-readable string format for representing LDAP
+ search filters.
+
+ This document replaces RFC 1960, extending the string LDAP filter
+ definition to include support for LDAP version 3 extended match
+ filters, and including support for representing the full range of
+ possible LDAP search filters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 2]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+3. LDAP Search Filter Definition
+
+ An LDAPv3 search filter is defined in Section 4.5.1 of [1] as
+ follows:
+
+ Filter ::= CHOICE {
+ and [0] SET OF Filter,
+ or [1] SET OF Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion
+ }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ SEQUENCE OF CHOICE {
+ initial [0] LDAPString,
+ any [1] LDAPString,
+ final [2] LDAPString
+ }
+ }
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ attributeValue AttributeValue
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleID OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE
+ }
+
+ AttributeDescription ::= LDAPString
+
+ AttributeValue ::= OCTET STRING
+
+ MatchingRuleID ::= LDAPString
+
+ AssertionValue ::= OCTET STRING
+
+ LDAPString ::= OCTET STRING
+
+
+
+Howes Standards Track [Page 3]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+ where the LDAPString above is limited to the UTF-8 encoding of the
+ ISO 10646 character set [4]. The AttributeDescription is a string
+ representation of the attribute description and is defined in [1].
+ The AttributeValue and AssertionValue OCTET STRING have the form
+ defined in [2]. The Filter is encoded for transmission over a
+ network using the Basic Encoding Rules defined in [3], with
+ simplifications described in [1].
+
+4. String Search Filter Definition
+
+ The string representation of an LDAP search filter is defined by the
+ following grammar, following the ABNF notation defined in [5]. The
+ filter format uses a prefix notation.
+
+ filter = "(" filtercomp ")"
+ filtercomp = and / or / not / item
+ and = "&" filterlist
+ or = "|" filterlist
+ not = "!" filter
+ filterlist = 1*filter
+ item = simple / present / substring / extensible
+ simple = attr filtertype value
+ filtertype = equal / approx / greater / less
+ equal = "="
+ approx = "~="
+ greater = ">="
+ less = "<="
+ extensible = attr [":dn"] [":" matchingrule] ":=" value
+ / [":dn"] ":" matchingrule ":=" value
+ present = attr "=*"
+ substring = attr "=" [initial] any [final]
+ initial = value
+ any = "*" *(value "*")
+ final = value
+ attr = AttributeDescription from Section 4.1.5 of [1]
+ matchingrule = MatchingRuleId from Section 4.1.9 of [1]
+ value = AttributeValue from Section 4.1.6 of [1]
+
+ The attr, matchingrule, and value constructs are as described in the
+ corresponding section of [1] given above.
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 4]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+ If a value should contain any of the following characters
+
+ Character ASCII value
+ ---------------------------
+ * 0x2a
+ ( 0x28
+ ) 0x29
+ \ 0x5c
+ NUL 0x00
+
+ the character must be encoded as the backslash '\' character (ASCII
+ 0x5c) followed by the two hexadecimal digits representing the ASCII
+ value of the encoded character. The case of the two hexadecimal
+ digits is not significant.
+
+ This simple escaping mechanism eliminates filter-parsing ambiguities
+ and allows any filter that can be represented in LDAP to be
+ represented as a NUL-terminated string. Other characters besides the
+ ones listed above may be escaped using this mechanism, for example,
+ non-printing characters.
+
+ For example, the filter checking whether the "cn" attribute contained
+ a value with the character "*" anywhere in it would be represented as
+ "(cn=*\2a*)".
+
+ Note that although both the substring and present productions in the
+ grammar above can produce the "attr=*" construct, this construct is
+ used only to denote a presence filter.
+
+5. Examples
+
+ This section gives a few examples of search filters written using
+ this notation.
+
+ (cn=Babs Jensen)
+ (!(cn=Tim Howes))
+ (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
+ (o=univ*of*mich*)
+
+ The following examples illustrate the use of extensible matching.
+
+ (cn:1.2.3.4.5:=Fred Flintstone)
+ (sn:dn:2.4.6.8.10:=Barney Rubble)
+ (o:dn:=Ace Industry)
+ (:dn:2.4.6.8.10:=Dino)
+
+
+
+
+
+
+Howes Standards Track [Page 5]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+ The second example illustrates the use of the ":dn" notation to
+ indicate that matching rule "2.4.6.8.10" should be used when making
+ comparisons, and that the attributes of an entry's distinguished name
+ should be considered part of the entry when evaluating the match.
+
+ The third example denotes an equality match, except that DN
+ components should be considered part of the entry when doing the
+ match.
+
+ The fourth example is a filter that should be applied to any
+ attribute supporting the matching rule given (since the attr has been
+ left off). Attributes supporting the matching rule contained in the
+ DN should also be considered.
+
+ The following examples illustrate the use of the escaping mechanism.
+
+ (o=Parens R Us \28for all your parenthetical needs\29)
+ (cn=*\2A*)
+ (filename=C:\5cMyFile)
+ (bin=\00\00\00\04)
+ (sn=Lu\c4\8di\c4\87)
+
+ The first example shows the use of the escaping mechanism to
+ represent parenthesis characters. The second shows how to represent a
+ "*" in a value, preventing it from being interpreted as a substring
+ indicator. The third illustrates the escaping of the backslash
+ character.
+
+ The fourth example shows a filter searching for the four-byte value
+ 0x00000004, illustrating the use of the escaping mechanism to
+ represent arbitrary data, including NUL characters.
+
+ The final example illustrates the use of the escaping mechanism to
+ represent various non-ASCII UTF-8 characters.
+
+6. Security Considerations
+
+ This memo describes a string representation of LDAP search filters.
+ While the representation itself has no known security implications,
+ LDAP search filters do. They are interpreted by LDAP servers to
+ select entries from which data is retrieved. LDAP servers should
+ take care to protect the data they maintain from unauthorized access.
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 6]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+7. References
+
+ [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
+ 2252, December 1997.
+
+ [3] Specification of ASN.1 encoding rules: Basic, Canonical, and
+ Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
+
+ [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+ 10646", RFC 2044, October 1996.
+
+ [5] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+8. Author's Address
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Road
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 415 937-3419
+ EMail: howes@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 7]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 8]
+
diff --git a/Documentation/en/rfc/rfc2476.txt b/Documentation/en/rfc/rfc2476.txt
new file mode 100644
index 00000000..0c5c17dc
--- /dev/null
+++ b/Documentation/en/rfc/rfc2476.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group R. Gellens
+Request for Comments: 2476 QUALCOMM
+Category: Standards Track J. Klensin
+ MCI
+ December 1998
+
+
+ Message Submission
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Table of Contents
+
+ 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Document Information . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Definitions of Terms Used in this Memo . . . . . . . . . 3
+ 2.2. Conventions Used in this Document . . . . . . . . . . . 4
+ 3. Message Submission . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Submission Identification . . . . . . . . . . . . . . . 4
+ 3.2. Message Rejection and Bouncing . . . . . . . . . . . . . 4
+ 3.3. Authorized Submission . . . . . . . . . . . . . . . . . 5
+ 3.4. Enhanced Status Codes . . . . . . . . . . . . . . . . . 6
+ 4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . 6
+ 4.1. General Submission Rejection Code . . . . . . . . . . . 6
+ 4.2. Ensure All Domains are Fully-Qualified . . . . . . . . 6
+ 5. Recommended Actions . . . . . . . . . . . . . . . . . . . . 7
+ 5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . 7
+ 5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. Optional Actions . . . . . . . . . . . . . . . . . . . . . 7
+ 6.1. Enforce Submission Rights . . . . . . . . . . . . . . . 7
+ 6.2. Require Authentication . . . . . . . . . . . . . . . . 8
+ 6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . 8
+ 6.4. Check Message Data . . . . . . . . . . . . . . . . . . 8
+ 7. Interaction with SMTP Extensions . . . . . . . . . . . . . . 8
+ 8. Message Modifications . . . . . . . . . . . . . . . . . . . 9
+ 8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 9
+ 8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . 10
+ 8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10
+
+
+
+Gellens & Klensin Standards Track [Page 1]
+
+RFC 2476 Message Submission December 1998
+
+
+ 8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . 10
+ 8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . 10
+ 8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . 10
+ 8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . 10
+ 8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . 10
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . 11
+ 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
+ 13. Full Copyright Statement . . . . . . . . . . . . . . . . . 15
+
+1. Abstract
+
+ SMTP was defined as a message *transfer* protocol, that is, a means
+ to route (if needed) and deliver finished (complete) messages.
+ Message Transfer Agents (MTAs) are not supposed to alter the message
+ text, except to add 'Received', 'Return-Path', and other header
+ fields as required by [SMTP-MTA].
+
+ However, SMTP is now also widely used as a message *submission*
+ protocol, that is, a means for message user agents (MUAs) to
+ introduce new messages into the MTA routing network. The process
+ which accepts message submissions from MUAs is termed a Message
+ Submission Agent (MSA).
+
+ Messages being submitted are in some cases finished (complete)
+ messages, and in other cases are unfinished (incomplete) in some
+ aspect or other. Unfinished messages need to be completed to ensure
+ they conform to [MESSAGE-FORMAT], and later requirements. For
+ example, the message may lack a proper 'Date' header field, and
+ domains might not be fully qualified. In some cases, the MUA may be
+ unable to generate finished messages (for example, it might not know
+ its time zone). Even when submitted messages are complete, local
+ site policy may dictate that the message text be examined or modified
+ in some way. Such completions or modifications have been shown to
+ cause harm when performed by downstream MTAs -- that is, MTAs after
+ the first-hop submission MTA -- and are in general considered to be
+ outside the province of standardized MTA functionality.
+
+ Separating messages into submissions and transfers allows developers
+ and network administrators to more easily:
+
+ * Implement security policies and guard against unauthorized mail
+ relaying or injection of unsolicited bulk mail
+
+ * Implement authenticated submission, including off-site submission
+ by authorized users such as travelers
+
+
+
+
+Gellens & Klensin Standards Track [Page 2]
+
+RFC 2476 Message Submission December 1998
+
+
+ * Separate the relevant software code differences, thereby making
+ each code base more straightforward and allowing for different
+ programs for relay and submission
+
+ * Detect configuration problems with a site's mail clients
+
+ * Provide a basis for adding enhanced submission services in the
+ future
+
+ This memo describes a low cost, deterministic means for messages to
+ be identified as submissions, and specifies what actions are to be
+ taken by a submission server.
+
+ Public comments should be sent to the IETF Submit mailing list,
+ <ietf-submit@imc.org>. To subscribe, send a message containing
+ SUBSCRIBE to <ietf-submit-request@imc.org>. Private comments may be
+ sent to the authors.
+
+2. Document Information
+
+2.1. Definitions of Terms Used in this Memo
+
+ Fully-Qualified
+
+ Containing or consisting of a domain which can be globally resolved
+ using the global Domain Name Service; that is, not a local alias or
+ partial specification.
+
+ Message Submission Agent (MSA)
+
+ A process which conforms to this specification, which acts as a
+ submission server to accept messages from MUAs, and either delivers
+ them or acts as an SMTP client to relay them to an MTA.
+
+ Message Transfer Agent (MTA)
+
+ A process which conforms to [SMTP-MTA], which acts as an SMTP server
+ to accept messages from an MSA or another MTA, and either delivers
+ them or acts as an SMTP client to relay them to another MTA.
+
+ Message User Agent (MUA)
+
+ A process which acts (usually on behalf of a user) to compose and
+ submit new messages, and process delivered messages. In the split-
+ MUA model, POP or IMAP is used to access delivered messages.
+
+
+
+
+
+
+Gellens & Klensin Standards Track [Page 3]
+
+RFC 2476 Message Submission December 1998
+
+
+2.2. Conventions Used in this Document
+
+ In examples, "C:" is used to indicate lines sent by the client, and
+ "S:" indicates those sent by the server. Line breaks within a
+ command example are for editorial purposes only.
+
+ Examples use the 'example.net' domain.
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ in this document are to be interpreted as defined in [KEYWORDS].
+
+3. Message Submission
+
+3.1. Submission Identification
+
+ Port 587 is reserved for email message submission as specified in
+ this document. Messages received on this port are defined to be
+ submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with
+ additional restrictions as specified here.
+
+ While most email clients and servers can be configured to use port
+ 587 instead of 25, there are cases where this is not possible or
+ convenient. A site MAY choose to use port 25 for message submission,
+ by designating some hosts to be MSAs and others to be MTAs.
+
+3.2. Message Rejection and Bouncing
+
+ MTAs and MSAs MAY implement message rejection rules that rely in part
+ on whether the message is a submission or a relay.
+
+ For example, some sites might configure their MTA to reject all RCPT
+ TOs for messages that do not reference local users, and configure
+ their MSA to reject all message submissions that do not come from
+ authorized users, based on IP address, or authenticated identity.
+
+ NOTE: It is better to reject a message than to risk sending one that
+ is damaged. This is especially true for problems that are
+ correctable by the MUA, for example, an invalid 'From' field.
+
+ If an MSA is not able to determine a return path to the submitting
+ user, from a valid MAIL FROM, a valid source IP address, or based on
+ authenticated identity, then the MSA SHOULD immediately reject the
+ message. A message can be immediately rejected by returning a 550
+ code to the MAIL FROM command.
+
+
+
+
+
+
+
+Gellens & Klensin Standards Track [Page 4]
+
+RFC 2476 Message Submission December 1998
+
+
+ Note that a null return path, that is, MAIL FROM:<>, is permitted
+ and MUST be accepted. (MUAs need to generate null return-path
+ messages for a variety of reasons, including disposition
+ notifications.)
+
+ Except in the case where the MSA is unable to determine a valid
+ return path for the message being submitted, text in this
+ specification which instructs an MSA to issue a rejection code MAY be
+ complied with by accepting the message and subsequently generating a
+ bounce message. (That is, if the MSA is going to reject a message for
+ any reason except being unable to determine a return path, it can
+ optionally do an immediate rejection or accept the message and then
+ mail a bounce.)
+
+ NOTE: In the normal case of message submission, immediately
+ rejecting the message is preferred, as it gives the user and MUA
+ direct feedback. To properly handle delayed bounces the client MUA
+ must maintain a queue of messages it has submitted, and match bounces
+ to them.
+
+3.3. Authorized Submission
+
+ Numerous methods have been used to ensure that only authorized users
+ are able to submit messages. These methods include authenticated
+ SMTP, IP address restrictions, secure IP, and prior POP
+ authentication.
+
+ Authenticated SMTP [SMTP-AUTH] has been proposed. It allows the MSA
+ to determine an authorization identity for the message submission,
+ which is not tied to other protocols.
+
+ IP address restrictions are very widely implemented, but do not allow
+ for travellers and similar situations, and can be spoofed.
+
+ Secure IP [IPSEC] can also be used, and provides additional benefits
+ of protection against eavesdropping and traffic analysis.
+
+ Requiring a POP [POP3] authentication (from the same IP address)
+ within some amount of time (for example, 20 minutes) prior to the
+ start of a message submission session has also been used, but this
+ does impose restrictions on clients as well as servers which may
+ cause difficulties. Specifically, the client must do a POP
+ authentication before an SMTP submission session, and not all clients
+ are capable and configured for this. Also, the MSA must coordinate
+ with the POP server, which may be difficult. There is also a window
+ during which an unauthorized user can submit messages and appear to
+ be a prior authorized user.
+
+
+
+
+Gellens & Klensin Standards Track [Page 5]
+
+RFC 2476 Message Submission December 1998
+
+
+3.4. Enhanced Status Codes
+
+ This memo suggests several enhanced status codes [SMTP-CODES] for
+ submission-specific rejections. The specific codes used are:
+
+ 5.6.0 Bad content. The content of the header or text is
+ improper.
+
+ 5.6.2 Bad domain or address. Invalid or improper domain or address
+ in MAIL FROM, RCPT TO, or DATA.
+
+ 5.7.1 Not allowed. The address in MAIL FROM appears to have
+ insufficient submission rights, or is invalid, or is not
+ authorized with the authentication used; the address in a
+ RCPT TO command is inconsistent with the permissions given to
+ the user; the message data is rejected based on the
+ submitting user.
+
+ 5.7.0 Site policy. The message appears to violate site policy in
+ some way.
+
+4. Mandatory Actions
+
+ An MSA MUST do all of the following:
+
+4.1. General Submission Rejection Code
+
+ Unless covered by a more precise response code, response code 554 is
+ to be used to reject a MAIL FROM, RCPT TO, or DATA command that
+ contains something improper. Enhanced status code 5.6.0 is to be
+ used if no other code is more specific.
+
+4.2. Ensure All Domains are Fully-Qualified
+
+ The MSA MUST ensure that all domains in the envelope are fully-
+ qualified.
+
+ If the MSA examines or alters the message text in way, except to add
+ trace header fields [SMTP-MTA], it MUST ensure that all domains in
+ address header fields are fully-qualified.
+
+ Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA
+ command which contains improper domain references.
+
+ NOTE: A frequent local convention is to accept single-level domains
+ (for example, 'sales') and then to expand the reference by adding the
+ remaining portion of the domain name (for example, to
+
+
+
+
+Gellens & Klensin Standards Track [Page 6]
+
+RFC 2476 Message Submission December 1998
+
+
+ 'sales.example.net'). Local conventions that permit single-level
+ domains SHOULD reject, rather than expand, incomplete multi-level
+ domains, since such expansion is particularly risky.
+
+5. Recommended Actions
+
+ The MSA SHOULD do all of the following:
+
+5.1. Enforce Address Syntax
+
+ An MSA SHOULD reject messages with illegal syntax in a sender or
+ recipient envelope address.
+
+ If the MSA examines or alters the message text in way, except to add
+ trace header fields, it SHOULD reject messages with illegal address
+ syntax in address header fields.
+
+ Reply code 501 is to be used to reject a MAIL FROM or RCPT TO command
+ that contains a detectably improper address.
+
+ When addresses are resolved after submission of the message body,
+ reply code 554 with enhanced status code 5.6.2 is to be used after
+ end-of-data, if the message contains invalid addresses in the header.
+
+5.2. Log Errors
+
+ The MSA SHOULD log message errors, especially apparent
+ misconfigurations of client software.
+
+ Note: It can be very helpful to notify the administrator when
+ problems are detected with local mail clients. This is another
+ advantage of distinguishing submission from relay: system
+ administrators might be interested in local configuration problems,
+ but not in client problems at other sites.
+
+6. Optional Actions
+
+ The MSA MAY do any of the following:
+
+6.1. Enforce Submission Rights
+
+ The MSA MAY issue an error response to the MAIL FROM command if the
+ address in MAIL FROM appears to have insufficient submission rights,
+ or is not authorized with the authentication used (if the session has
+ been authenticated).
+
+ Reply code 550 with enhanced status code 5.7.1 is used for this
+ purpose.
+
+
+
+Gellens & Klensin Standards Track [Page 7]
+
+RFC 2476 Message Submission December 1998
+
+
+6.2. Require Authentication
+
+ The MSA MAY issue an error response to the MAIL FROM command if the
+ session has not been authenticated.
+
+ Section 3.3 discusses authentication mechanisms.
+
+ Reply code 530 [SMTP-AUTH] is used for this purpose.
+
+6.3. Enforce Permissions
+
+ The MSA MAY issue an error response to the RCPT TO command if
+ inconsistent with the permissions given to the user (if the session
+ has been authenticated).
+
+ Reply code 550 with enhanced status code 5.7.1 is used for this
+ purpose.
+
+6.4. Check Message Data
+
+ The MSA MAY issue an error response to the DATA command or send a
+ failure result after end-of-data if the submitted message is
+ syntactically invalid, or seems inconsistent with permissions given
+ to the user (if known), or violates site policy in some way.
+
+ Reply code 554 is used for syntactic problems in the data. Reply
+ code 501 is used if the command itself is not syntactically valid.
+ Reply code 550 with enhanced status code 5.7.1 is used to reject
+ based on the submitting user. Reply code 550 with enhanced status
+ code 5.7.0 is used if the message violates site policy.
+
+7. Interaction with SMTP Extensions
+
+ The following table lists the current standards-track and
+ Experimental SMTP extensions. Listed are the RFC, name, an
+ indication as to the use of the extension on the submit port, and a
+ reference:
+
+ RFC Name Submission Reference
+ ---- --------------- ---------- ------------------
+ 2197 Pipelining SHOULD [PIPELINING]
+ 2034 Error Codes SHOULD [CODES-EXTENSION]
+ 1985 ETRN MUST NOT [ETRN]
+ 1893 Extended Codes SHOULD [SMTP-CODES]
+ 1891 DSN SHOULD [DSN]
+ 1870 Size MAY [SIZE]
+ 1846 521 MUST NOT [521REPLY]
+ 1845 Checkpoint MAY [Checkpoint]
+
+
+
+Gellens & Klensin Standards Track [Page 8]
+
+RFC 2476 Message Submission December 1998
+
+
+ 1830 Binary MAY [CHUNKING]
+ 1652 8-bit MIME SHOULD [8BITMIME]
+ ---- Authentication ------ [SMTP-AUTH]
+
+ Future SMTP extensions should explicitly specify if they are valid on
+ the Submission port.
+
+ Some SMTP extensions are especially useful for message submission:
+
+ Extended Status Codes [SMTP-CODES], SHOULD be supported and used
+ according to [CODES-EXTENSION]. This permits the MSA to notify the
+ client of specific configuration or other problems in more detail
+ than the response codes listed in this memo. Because some rejections
+ are related to a site's security policy, care should be used not to
+ expose more detail than is needed to correct the problem.
+
+ [PIPELINING] SHOULD be supported by the MSA.
+
+ [SMTP-AUTH] allows the MSA to validate the authority and determine
+ the identity of the submitting user.
+
+ Any references to the DATA command in this memo also refer to any
+ substitutes for DATA, such as the BDAT command used with [CHUNKING].
+
+8. Message Modifications
+
+ Sites MAY modify submissions to ensure compliance with standards and
+ site policy. This section describes a number of such modifications
+ that are often considered useful.
+
+ NOTE: As a matter of guidance for local decisions to implement
+ message modification, a paramount rule is to limit such actions to
+ remedies for specific problems that have clear solutions. This is
+ especially true with address elements. For example, indiscriminately
+ appending a domain to an address or element which lacks one typically
+ results in more broken addresses. An unqualified address must be
+ verified to be a valid local part in the domain before the domain can
+ be safely added.
+
+8.1. Add 'Sender'
+
+ The MSA MAY add or replace the 'Sender' field, if the identity of the
+ sender is known and this is not given in the 'From' field.
+
+ The MSA MUST ensure that any address it places in a 'Sender' field is
+ in fact a valid mail address.
+
+
+
+
+
+Gellens & Klensin Standards Track [Page 9]
+
+RFC 2476 Message Submission December 1998
+
+
+8.2. Add 'Date'
+
+ The MSA MAY add a 'Date' field to the submitted message, if it lacks
+ it, or correct the 'Date' field if it does not conform to [MESSAGE-
+ FORMAT] syntax.
+
+8.3. Add 'Message-ID'
+
+ The MSA MAY add or replace the 'Message-ID' field, if it lacks it, or
+ it is not valid syntax (as defined by [MESSAGE-FORMAT]).
+
+8.4. Transfer Encode
+
+ The MSA MAY apply transfer encoding to the message according to MIME
+ conventions, if needed and not harmful to the MIME type.
+
+8.5. Sign the Message
+
+ The MSA MAY (digitally) sign or otherwise add authentication
+ information to the message.
+
+8.6. Encrypt the Message
+
+ The MSA MAY encrypt the message for transport to reflect
+ organizational policies.
+
+ NOTE: To be useful, the addition of a signature and/or encryption by
+ the MSA generally implies that the connection between the MUA and MSA
+ must itself be secured in some other way, e.g., by operating inside
+ of a secure environment, by securing the submission connection at the
+ transport layer, or by using an [SMTP-AUTH] mechanism that provides
+ for session integrity.
+
+8.7. Resolve Aliases
+
+ The MSA MAY resolve aliases (CNAME records) for domain names, in the
+ envelope and optionally in address fields of the header, subject to
+ local policy.
+
+ NOTE: Unconditionally resolving aliases could be harmful. For
+ example, if www.example.net and ftp.example.net are both aliases for
+ mail.example.net, rewriting them could lose useful information.
+
+8.8. Header Rewriting
+
+ The MSA MAY rewrite local parts and/or domains, in the envelope and
+ optionally in address fields of the header, according to local
+ policy. For example, a site may prefer to rewrite 'JRU' as '
+
+
+
+Gellens & Klensin Standards Track [Page 10]
+
+RFC 2476 Message Submission December 1998
+
+
+ J.Random.User' in order to hide logon names, and/or to rewrite '
+ squeeky.sales.example.net' as 'zyx.example.net' to hide machine names
+ and make it easier to move users.
+
+ However, only addresses, local-parts, or domains which match specific
+ local MSA configuration settings should be altered. It would be very
+ dangerous for the MSA to apply data-independent rewriting rules, such
+ as always deleting the first element of a domain name. So, for
+ example, a rule which strips the left-most element of the domain if
+ the complete domain matches '*.foo.example.net' would be acceptable.
+
+9. Security Considerations
+
+ Separation of submission and relay of messages can allow a site to
+ implement different policies for the two types of services, including
+ requiring use of additional security mechanisms for one or both. It
+ can do this in a way which is simpler, both technically and
+ administratively. This increases the likelihood that policies will
+ be applied correctly.
+
+ Separation also can aid in tracking and preventing unsolicited bulk
+ email.
+
+ For example, a site could configure its MSA to require authentication
+ before accepting a message, and could configure its MTA to reject all
+ RCPT TOs for non-local users. This can be an important element in a
+ site's total email security policy.
+
+ If a site fails to require any form of authorization for message
+ submissions (see section 3.3 for discussion), it is allowing open use
+ of its resources and name; unsolicited bulk email can be injected
+ using its facilities.
+
+10. Acknowledgments
+
+ This updated memo has been revised in part based on comments and
+ discussions which took place on and off the IETF-Submit mailing list.
+ The help of those who took the time to review the draft and make
+ suggestions is appreciated, especially that of Dave Crocker, Ned
+ Freed, Keith Moore, John Myers, and Chris Newman.
+
+ Special thanks to Harald Alvestrand, who got this effort started.
+
+
+
+
+
+
+
+
+
+Gellens & Klensin Standards Track [Page 11]
+
+RFC 2476 Message Submission December 1998
+
+
+11. References
+
+ [521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code",
+ RFC 1846, September 1995.
+
+ [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E. and
+ D. Crocker, "SMTP Service Extension for 8bit-
+ MIMEtransport", RFC 1652, July 1994.
+
+ [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", RFC 2234, November
+ 1997.
+
+ [CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, "SMTP
+ Service Extension for Checkpoint/Restart", RFC
+ 1845, September 1995.
+
+ [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for
+ Transmission of Large and Binary MIME Messages",
+ RFC 1830, August 1995.
+
+ [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
+ Enhanced Error Codes", RFC 2034, October 1996.
+
+ [DSN] Moore, K., "SMTP Service Extension for Delivery
+ Status Notifications", RFC 1891, January 1996.
+
+ [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and
+ D. Crocker, "SMTP Service Extensions", STD 10, RFC
+ 1869, November 1995.
+
+ [ETRN] De Winter, J., "SMTP Service Extension for Remote
+ Message Queue Starting", RFC 1985, August 1996.
+
+ [HEADERS] Palme, J., "Common Internet Message Headers", RFC
+ 2076, February 1997.
+
+ [IPSEC] Atkinson, R., "Security Architecture for the
+ Internet Protocol", RFC 1825, August 1995.
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+Gellens & Klensin Standards Track [Page 12]
+
+RFC 2476 Message Submission December 1998
+
+
+ [MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA
+ Internet text messages", STD 11, RFC 822, August
+ 1982;
+
+ Braden, R., Editor, "Requirements for Internet
+ Hosts -- Application and Support", STD 3, RFC 1123,
+ October 1989.
+
+ [PIPELINING] Freed, N., "SMTP Service Extension for Command
+ Pipelining", RFC 2197, September 1997.
+
+ [POP3] Myers, J. and M. Rose, "Post Office Protocol --
+ Version 3", STD 53, RFC 1939, May 1996.
+
+ [SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service
+ Extension for Message Size Declaration", STD 10,
+ RFC 1870, November 1995.
+
+ [SMTP-AUTH] Myers, J., "SMTP Service Extension for
+ Authentication", Work in Progress.
+
+ [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes",
+ RFC 1893, January 1996.
+
+ [SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD
+ 10, RFC 821, August 1982.
+
+ Partridge, C., "Mail Routing and the Domain
+ System", STD 14, RFC 974, January 1986.
+
+ Braden, R., Editor, "Requirements for Internet
+ Hosts -- Application and Support", STD 3, RFC 1123,
+ October 1989.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin Standards Track [Page 13]
+
+RFC 2476 Message Submission December 1998
+
+
+12. Authors' Addresses
+
+ Randall Gellens
+ QUALCOMM Incorporated
+ 6455 Lusk Blvd.
+ San Diego, CA 92121-2779
+ U.S.A.
+
+ Phone: +1 619 651 5115
+ Fax: +1 619 651 5334
+ EMail: Randy@Qualcomm.Com
+
+
+ John C. Klensin
+ MCI Telecommunications
+ 800 Boylston St, 7th floor
+ Boston, MA 02199
+ USA
+
+ Phone: +1 617 960 1011
+ EMail: klensin@mci.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin Standards Track [Page 14]
+
+RFC 2476 Message Submission December 1998
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin Standards Track [Page 15]
+
diff --git a/Documentation/en/rfc/rfc2487.txt b/Documentation/en/rfc/rfc2487.txt
new file mode 100644
index 00000000..fb1305f0
--- /dev/null
+++ b/Documentation/en/rfc/rfc2487.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group P. Hoffman
+Request for Comments: 2487 Internet Mail Consortium
+Category: Standards Track January 1999
+
+
+ SMTP Service Extension for Secure SMTP over TLS
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+1. Abstract
+
+ This document describes an extension to the SMTP service that allows
+ an SMTP server and client to use transport-layer security to provide
+ private, authenticated communication over the Internet. This gives
+ SMTP agents the ability to protect some or all of their
+ communications from eavesdroppers and attackers.
+
+2. Introduction
+
+ SMTP [RFC-821] servers and clients normally communicate in the clear
+ over the Internet. In many cases, this communication goes through one
+ or more router that is not controlled or trusted by either entity.
+ Such an untrusted router might allow a third party to monitor or
+ alter the communications between the server and client.
+
+ Further, there is often a desire for two SMTP agents to be able to
+ authenticate each others' identities. For example, a secure SMTP
+ server might only allow communications from other SMTP agents it
+ knows, or it might act differently for messages received from an
+ agent it knows than from one it doesn't know.
+
+ TLS [TLS], more commonly known as SSL, is a popular mechanism for
+ enhancing TCP communications with privacy and authentication. TLS is
+ in wide use with the HTTP protocol, and is also being used for adding
+ security to many other common protocols that run over TCP.
+
+
+
+
+
+
+Hoffman Standards Track [Page 1]
+
+RFC 2487 SMTP Service Extension January 1999
+
+
+2.1 Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC-2119].
+
+3. STARTTLS Extension
+
+ The STARTTLS extension to SMTP is laid out as follows:
+
+ (1) the name of the SMTP service defined here is STARTTLS;
+
+ (2) the EHLO keyword value associated with the extension is STARTTLS;
+
+ (3) the STARTTLS keyword has no parameters;
+
+ (4) a new SMTP verb, "STARTTLS", is defined;
+
+ (5) no additional parameters are added to any SMTP command.
+
+4. The STARTTLS Keyword
+
+ The STARTTLS keyword is used to tell the SMTP client that the SMTP
+ server allows use of TLS. It takes no parameters.
+
+5. The STARTTLS Command
+
+ The format for the STARTTLS command is:
+
+ STARTTLS
+
+ with no parameters.
+
+ After the client gives the STARTTLS command, the server responds with
+ one of the following reply codes:
+
+ 220 Ready to start TLS
+ 501 Syntax error (no parameters allowed)
+ 454 TLS not available due to temporary reason
+
+ A publicly-referenced SMTP server MUST NOT require use of the
+ STARTTLS extension in order to deliver mail locally. This rule
+ prevents the STARTTLS extension from damaging the interoperability of
+ the Internet's SMTP infrastructure. A publicly-referenced SMTP server
+ is an SMTP server which runs on port 25 of an Internet host listed in
+ the MX record (or A record if an MX record is not present) for the
+ domain name on the right hand side of an Internet mail address.
+
+
+
+
+Hoffman Standards Track [Page 2]
+
+RFC 2487 SMTP Service Extension January 1999
+
+
+ Any SMTP server may refuse to accept messages for relay based on
+ authentication supplied during the TLS negotiation. An SMTP server
+ that is not publicly referenced may refuse to accept any messages for
+ relay or local delivery based on authentication supplied during the
+ TLS negotiation.
+
+ A SMTP server that is not publicly referenced may choose to require
+ that the client perform a TLS negotiation before accepting any
+ commands. In this case, the server SHOULD return the reply code:
+
+ 530 Must issue a STARTTLS command first
+
+ to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
+ client and server are using the ENHANCEDSTATUSCODES ESMTP extension
+ [RFC-2034], the status code to be returned SHOULD be 5.7.0.
+
+ After receiving a 220 response to a STARTTLS command, the client
+ SHOULD start the TLS negotiation before giving any other SMTP
+ commands.
+
+ If the SMTP client is using pipelining as defined in RFC 1854, the
+ STARTTLS command must be the last command in a group.
+
+5.1 Processing After the STARTTLS Command
+
+ After the TLS handshake has been completed, both parties MUST
+ immediately decide whether or not to continue based on the
+ authentication and privacy achieved. The SMTP client and server may
+ decide to move ahead even if the TLS negotiation ended with no
+ authentication and/or no privacy because most SMTP services are
+ performed with no authentication and no privacy, but some SMTP
+ clients or servers may want to continue only if a particular level of
+ authentication and/or privacy was achieved.
+
+ If the SMTP client decides that the level of authentication or
+ privacy is not high enough for it to continue, it SHOULD issue an
+ SMTP QUIT command immediately after the TLS negotiation is complete.
+ If the SMTP server decides that the level of authentication or
+ privacy is not high enough for it to continue, it SHOULD reply to
+ every SMTP command from the client (other than a QUIT command) with
+ the 554 reply code (with a possible text string such as "Command
+ refused due to lack of security").
+
+ The decision of whether or not to believe the authenticity of the
+ other party in a TLS negotiation is a local matter. However, some
+ general rules for the decisions are:
+
+
+
+
+
+Hoffman Standards Track [Page 3]
+
+RFC 2487 SMTP Service Extension January 1999
+
+
+ - A SMTP client would probably only want to authenticate an SMTP
+ server whose server certificate has a domain name that is the
+ domain name that the client thought it was connecting to.
+ - A publicly-referenced SMTP server would probably want to accept
+ any certificate from an SMTP client, and would possibly want to
+ put distinguishing information about the certificate in the
+ Received header of messages that were relayed or submitted from
+ the client.
+
+5.2 Result of the STARTTLS Command
+
+ Upon completion of the TLS handshake, the SMTP protocol is reset to
+ the initial state (the state in SMTP after a server issues a 220
+ service ready greeting). The server MUST discard any knowledge
+ obtained from the client, such as the argument to the EHLO command,
+ which was not obtained from the TLS negotiation itself. The client
+ MUST discard any knowledge obtained from the server, such as the list
+ of SMTP service extensions, which was not obtained from the TLS
+ negotiation itself. The client SHOULD send an EHLO command as the
+ first command after a successful TLS negotiation.
+
+ The list of SMTP service extensions returned in response to an EHLO
+ command received after the TLS handshake MAY be different than the
+ list returned before the TLS handshake. For example, an SMTP server
+ might not want to advertise support for a particular SASL mechanism
+ [SASL] unless a client has sent an appropriate client certificate
+ during a TLS handshake.
+
+ Both the client and the server MUST know if there is a TLS session
+ active. A client MUST NOT attempt to start a TLS session if a TLS
+ session is already active. A server MUST NOT return the TLS extension
+ in response to an EHLO command received after a TLS handshake has
+ completed.
+
+6. Usage Example
+
+ The following dialog illustrates how a client and server can start a
+ TLS session:
+
+ S: <waits for connection on TCP port 25>
+ C: <opens connection>
+ S: 220 mail.imc.org SMTP service ready
+ C: EHLO mail.ietf.org
+ S: 250-mail.imc.org offers a warm hug of welcome
+ S: 250 STARTTLS
+ C: STARTTLS
+ S: 220 Go ahead
+ C: <starts TLS negotiation>
+
+
+
+Hoffman Standards Track [Page 4]
+
+RFC 2487 SMTP Service Extension January 1999
+
+
+ C & S: <negotiate a TLS session>
+ C & S: <check result of negotiation>
+ C: <continues by sending an SMTP command>
+ . . .
+
+7. Security Considerations
+
+ It should be noted that SMTP is not an end-to-end mechanism. Thus, if
+ an SMTP client/server pair decide to add TLS privacy, they are not
+ securing the transport from the originating mail user agent to the
+ recipient. Further, because delivery of a single piece of mail may
+ go between more than two SMTP servers, adding TLS privacy to one pair
+ of servers does not mean that the entire SMTP chain has been made
+ private. Further, just because an SMTP server can authenticate an
+ SMTP client, it does not mean that the mail from the SMTP client was
+ authenticated by the SMTP client when the client received it.
+
+ Both the STMP client and server must check the result of the TLS
+ negotiation to see whether acceptable authentication or privacy was
+ achieved. Ignoring this step completely invalidates using TLS for
+ security. The decision about whether acceptable authentication or
+ privacy was achieved is made locally, is implementation-dependant,
+ and is beyond the scope of this document.
+
+ The SMTP client and server should note carefully the result of the
+ TLS negotiation. If the negotiation results in no privacy, or if it
+ results in privacy using algorithms or key lengths that are deemed
+ not strong enough, or if the authentication is not good enough for
+ either party, the client may choose to end the SMTP session with an
+ immediate QUIT command, or the server may choose to not accept any
+ more SMTP commands.
+
+ A server announcing in an EHLO response that it uses a particular TLS
+ protocol should not pose any security issues, since any use of TLS
+ will be at least as secure as no use of TLS.
+
+ A man-in-the-middle attack can be launched by deleting the "250
+ STARTTLS" response from the server. This would cause the client not
+ to try to start a TLS session. An SMTP client can protect against
+ this attack by recording the fact that a particular SMTP server
+ offers TLS during one session and generating an alarm if it does not
+ appear in the EHLO response for a later session. The lack of TLS
+ during a session SHOULD NOT result in the bouncing of email, although
+ it could result in delayed processing.
+
+
+
+
+
+
+
+Hoffman Standards Track [Page 5]
+
+RFC 2487 SMTP Service Extension January 1999
+
+
+ Before the TLS handshake has begun, any protocol interactions are
+ performed in the clear and may be modified by an active attacker. For
+ this reason, clients and servers MUST discard any knowledge obtained
+ prior to the start of the TLS handshake upon completion of the TLS
+ handshake.
+
+ The STARTTLS extension is not suitable for authenticating the author
+ of an email message unless every hop in the delivery chain, including
+ the submission to the first SMTP server, is authenticated. Another
+ proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
+ security multiparts [MIME-SEC] can be used to authenticate the author
+ of an email message. In addition, the [SMTP-AUTH] proposal offers
+ simpler and more flexible options to authenticate an SMTP client and
+ the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with
+ the STARTTLS command to provide an authorization identity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman Standards Track [Page 6]
+
+RFC 2487 SMTP Service Extension January 1999
+
+
+A. References
+
+ [RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+ August 1982.
+
+ [RFC-1869] Klensin, J., Freed, N, Rose, M, Stefferud, E. and D.
+ Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
+ November 1995.
+
+ [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced
+ Error Codes", RFC 2034, October 1996.
+
+ [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [SMTP-AUTH] "SMTP Service Extension for Authentication", Work in
+ Progress.
+
+ [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+B. Author's Address
+
+ Paul Hoffman
+ Internet Mail Consortium
+ 127 Segre Place
+ Santa Cruz, CA 95060
+
+ Phone: (831) 426-9827
+ EMail: phoffman@imc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman Standards Track [Page 7]
+
+RFC 2487 SMTP Service Extension January 1999
+
+
+C. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman Standards Track [Page 8]
+
diff --git a/Documentation/en/rfc/rfc2554.txt b/Documentation/en/rfc/rfc2554.txt
new file mode 100644
index 00000000..2922deae
--- /dev/null
+++ b/Documentation/en/rfc/rfc2554.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group J. Myers
+Request for Comments: 2554 Netscape Communications
+Category: Standards Track March 1999
+
+
+ SMTP Service Extension
+ for Authentication
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+
+1. Introduction
+
+ This document defines an SMTP service extension [ESMTP] whereby an
+ SMTP client may indicate an authentication mechanism to the server,
+ perform an authentication protocol exchange, and optionally negotiate
+ a security layer for subsequent protocol interactions. This
+ extension is a profile of the Simple Authentication and Security
+ Layer [SASL].
+
+
+2. Conventions Used in this Document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ in this document are to be interpreted as defined in "Key words for
+ use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+
+3. The Authentication service extension
+
+
+ (1) the name of the SMTP service extension is "Authentication"
+
+ (2) the EHLO keyword value associated with this extension is "AUTH"
+
+
+
+
+Myers Standards Track [Page 1]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ (3) The AUTH EHLO keyword contains as a parameter a space separated
+ list of the names of supported SASL mechanisms.
+
+ (4) a new SMTP verb "AUTH" is defined
+
+ (5) an optional parameter using the keyword "AUTH" is added to the
+ MAIL FROM command, and extends the maximum line length of the
+ MAIL FROM command by 500 characters.
+
+ (6) this extension is appropriate for the submission protocol
+ [SUBMIT].
+
+
+4. The AUTH command
+
+ AUTH mechanism [initial-response]
+
+ Arguments:
+ a string identifying a SASL authentication mechanism.
+ an optional base64-encoded response
+
+ Restrictions:
+ After an AUTH command has successfully completed, no more AUTH
+ commands may be issued in the same session. After a successful
+ AUTH command completes, a server MUST reject any further AUTH
+ commands with a 503 reply.
+
+ The AUTH command is not permitted during a mail transaction.
+
+ Discussion:
+ The AUTH command indicates an authentication mechanism to the
+ server. If the server supports the requested authentication
+ mechanism, it performs an authentication protocol exchange to
+ authenticate and identify the user. Optionally, it also
+ negotiates a security layer for subsequent protocol
+ interactions. If the requested authentication mechanism is not
+ supported, the server rejects the AUTH command with a 504
+ reply.
+
+ The authentication protocol exchange consists of a series of
+ server challenges and client answers that are specific to the
+ authentication mechanism. A server challenge, otherwise known
+ as a ready response, is a 334 reply with the text part
+ containing a BASE64 encoded string. The client answer consists
+ of a line containing a BASE64 encoded string. If the client
+ wishes to cancel an authentication exchange, it issues a line
+ with a single "*". If the server receives such an answer, it
+ MUST reject the AUTH command by sending a 501 reply.
+
+
+
+Myers Standards Track [Page 2]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ The optional initial-response argument to the AUTH command is
+ used to save a round trip when using authentication mechanisms
+ that are defined to send no data in the initial challenge.
+ When the initial-response argument is used with such a
+ mechanism, the initial empty challenge is not sent to the
+ client and the server uses the data in the initial-response
+ argument as if it were sent in response to the empty challenge.
+ Unlike a zero-length client answer to a 334 reply, a zero-
+ length initial response is sent as a single equals sign ("=").
+ If the client uses an initial-response argument to the AUTH
+ command with a mechanism that sends data in the initial
+ challenge, the server rejects the AUTH command with a 535
+ reply.
+
+ If the server cannot BASE64 decode the argument, it rejects the
+ AUTH command with a 501 reply. If the server rejects the
+ authentication data, it SHOULD reject the AUTH command with a
+ 535 reply unless a more specific error code, such as one listed
+ in section 6, is appropriate. Should the client successfully
+ complete the authentication exchange, the SMTP server issues a
+ 235 reply.
+
+ The service name specified by this protocol's profile of SASL
+ is "smtp".
+
+ If a security layer is negotiated through the SASL
+ authentication exchange, it takes effect immediately following
+ the CRLF that concludes the authentication exchange for the
+ client, and the CRLF of the success reply for the server. Upon
+ a security layer's taking effect, the SMTP protocol is reset to
+ the initial state (the state in SMTP after a server issues a
+ 220 service ready greeting). The server MUST discard any
+ knowledge obtained from the client, such as the argument to the
+ EHLO command, which was not obtained from the SASL negotiation
+ itself. The client MUST discard any knowledge obtained from
+ the server, such as the list of SMTP service extensions, which
+ was not obtained from the SASL negotiation itself (with the
+ exception that a client MAY compare the list of advertised SASL
+ mechanisms before and after authentication in order to detect
+ an active down-negotiation attack). The client SHOULD send an
+ EHLO command as the first command after a successful SASL
+ negotiation which results in the enabling of a security layer.
+
+ The server is not required to support any particular
+ authentication mechanism, nor are authentication mechanisms
+ required to support any security layers. If an AUTH command
+ fails, the client may try another authentication mechanism by
+ issuing another AUTH command.
+
+
+
+Myers Standards Track [Page 3]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ If an AUTH command fails, the server MUST behave the same as if
+ the client had not issued the AUTH command.
+
+ The BASE64 string may in general be arbitrarily long. Clients
+ and servers MUST be able to support challenges and responses
+ that are as long as are generated by the authentication
+ mechanisms they support, independent of any line length
+ limitations the client or server may have in other parts of its
+ protocol implementation.
+
+ Examples:
+ S: 220 smtp.example.com ESMTP server ready
+ C: EHLO jgm.example.com
+ S: 250-smtp.example.com
+ S: 250 AUTH CRAM-MD5 DIGEST-MD5
+ C: AUTH FOOBAR
+ S: 504 Unrecognized authentication type.
+ C: AUTH CRAM-MD5
+ S: 334
+ PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
+ C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
+ S: 235 Authentication successful.
+
+
+
+5. The AUTH parameter to the MAIL FROM command
+
+ AUTH=addr-spec
+
+ Arguments:
+ An addr-spec containing the identity which submitted the message
+ to the delivery system, or the two character sequence "<>"
+ indicating such an identity is unknown or insufficiently
+ authenticated. To comply with the restrictions imposed on ESMTP
+ parameters, the addr-spec is encoded inside an xtext. The syntax
+ of an xtext is described in section 5 of [ESMTP-DSN].
+
+ Discussion:
+ The optional AUTH parameter to the MAIL FROM command allows
+ cooperating agents in a trusted environment to communicate the
+ authentication of individual messages.
+
+ If the server trusts the authenticated identity of the client to
+ assert that the message was originally submitted by the supplied
+ addr-spec, then the server SHOULD supply the same addr-spec in an
+ AUTH parameter when relaying the message to any server which
+ supports the AUTH extension.
+
+
+
+
+Myers Standards Track [Page 4]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ A MAIL FROM parameter of AUTH=<> indicates that the original
+ submitter of the message is not known. The server MUST NOT treat
+ the message as having been originally submitted by the client.
+
+ If the AUTH parameter to the MAIL FROM is not supplied, the
+ client has authenticated, and the server believes the message is
+ an original submission by the client, the server MAY supply the
+ client's identity in the addr-spec in an AUTH parameter when
+ relaying the message to any server which supports the AUTH
+ extension.
+
+ If the server does not sufficiently trust the authenticated
+ identity of the client, or if the client is not authenticated,
+ then the server MUST behave as if the AUTH=<> parameter was
+ supplied. The server MAY, however, write the value of the AUTH
+ parameter to a log file.
+
+ If an AUTH=<> parameter was supplied, either explicitly or due to
+ the requirement in the previous paragraph, then the server MUST
+ supply the AUTH=<> parameter when relaying the message to any
+ server which it has authenticated to using the AUTH extension.
+
+ A server MAY treat expansion of a mailing list as a new
+ submission, setting the AUTH parameter to the mailing list
+ address or mailing list administration address when relaying the
+ message to list subscribers.
+
+ It is conforming for an implementation to be hard-coded to treat
+ all clients as being insufficiently trusted. In that case, the
+ implementation does nothing more than parse and discard
+ syntactically valid AUTH parameters to the MAIL FROM command and
+ supply AUTH=<> parameters to any servers to which it
+ authenticates using the AUTH extension.
+
+ Examples:
+ C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
+ S: 250 OK
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 5]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+6. Error Codes
+
+ The following error codes may be used to indicate various conditions
+ as described.
+
+ 432 A password transition is needed
+
+ This response to the AUTH command indicates that the user needs to
+ transition to the selected authentication mechanism. This typically
+ done by authenticating once using the PLAIN authentication mechanism.
+
+ 534 Authentication mechanism is too weak
+
+ This response to the AUTH command indicates that the selected
+ authentication mechanism is weaker than server policy permits for
+ that user.
+
+ 538 Encryption required for requested authentication mechanism
+
+ This response to the AUTH command indicates that the selected
+ authentication mechanism may only be used when the underlying SMTP
+ connection is encrypted.
+
+ 454 Temporary authentication failure
+
+ This response to the AUTH command indicates that the authentication
+ failed due to a temporary server failure.
+
+ 530 Authentication required
+
+ This response may be returned by any command other than AUTH, EHLO,
+ HELO, NOOP, RSET, or QUIT. It indicates that server policy requires
+ authentication in order to perform the requested action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 6]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+7. Formal Syntax
+
+ The following syntax specification uses the augmented Backus-Naur
+ Form (BNF) notation as specified in [ABNF].
+
+ Except as noted otherwise, all alphabetic characters are case-
+ insensitive. The use of upper or lower case characters to define
+ token strings is for editorial clarity only. Implementations MUST
+ accept these strings in a case-insensitive fashion.
+
+ UPALPHA = %x41-5A ;; Uppercase: A-Z
+
+ LOALPHA = %x61-7A ;; Lowercase: a-z
+
+ ALPHA = UPALPHA / LOALPHA ;; case insensitive
+
+ DIGIT = %x30-39 ;; Digits 0-9
+
+ HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)
+
+ hexchar = "+" HEXDIGIT HEXDIGIT
+
+ xchar = %x21-2A / %x2C-3C / %x3E-7E
+ ;; US-ASCII except for "+", "=", SPACE and CTL
+
+ xtext = *(xchar / hexchar)
+
+ AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
+
+ auth_type = 1*20AUTH_CHAR
+
+ auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
+ *(CRLF [base64]) CRLF
+
+ auth_param = "AUTH=" xtext
+ ;; The decoded form of the xtext MUST be either
+ ;; an addr-spec or the two characters "<>"
+
+ base64 = base64_terminal /
+ ( 1*(4base64_CHAR) [base64_terminal] )
+
+ base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
+ ;; Case-sensitive
+
+ base64_terminal = (2base64_char "==") / (3base64_char "=")
+
+ continue_req = "334" SPACE [base64] CRLF
+
+
+
+
+Myers Standards Track [Page 7]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ CR = %x0C ;; ASCII CR, carriage return
+
+ CRLF = CR LF
+
+ CTL = %x00-1F / %x7F ;; any ASCII control character and DEL
+
+ LF = %x0A ;; ASCII LF, line feed
+
+ SPACE = %x20 ;; ASCII SP, space
+
+
+
+
+8. References
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+ AUTHorize Extension for Simple Challenge/Response", RFC
+ 2195, September 1997.
+
+ [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+ Crocker, "SMTP Service Extensions", RFC 1869, November
+ 1995.
+
+ [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
+ Notifications", RFC 1891, January 1996.
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC
+ 2476, December 1998.
+
+ [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", STD 11, RFC 822, August 1982.
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 8]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+9. Security Considerations
+
+ Security issues are discussed throughout this memo.
+
+ If a client uses this extension to get an encrypted tunnel through an
+ insecure network to a cooperating server, it needs to be configured
+ to never send mail to that server when the connection is not mutually
+ authenticated and encrypted. Otherwise, an attacker could steal the
+ client's mail by hijacking the SMTP connection and either pretending
+ the server does not support the Authentication extension or causing
+ all AUTH commands to fail.
+
+ Before the SASL negotiation has begun, any protocol interactions are
+ performed in the clear and may be modified by an active attacker.
+ For this reason, clients and servers MUST discard any knowledge
+ obtained prior to the start of the SASL negotiation upon completion
+ of a SASL negotiation which results in a security layer.
+
+ This mechanism does not protect the TCP port, so an active attacker
+ may redirect a relay connection attempt to the submission port
+ [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing
+ an relayed message without an envelope authentication to pick up the
+ authentication of the relay client.
+
+ A message submission client may require the user to authenticate
+ whenever a suitable SASL mechanism is advertised. Therefore, it may
+ not be desirable for a submission server [SUBMIT] to advertise a SASL
+ mechanism when use of that mechanism grants the client no benefits
+ over anonymous submission.
+
+ This extension is not intended to replace or be used instead of end-
+ to-end message signature and encryption systems such as S/MIME or
+ PGP. This extension addresses a different problem than end-to-end
+ systems; it has the following key differences:
+
+ (1) it is generally useful only within a trusted enclave
+
+ (2) it protects the entire envelope of a message, not just the
+ message's body.
+
+ (3) it authenticates the message submission, not authorship of the
+ message content
+
+ (4) it can give the sender some assurance the message was
+ delivered to the next hop in the case where the sender
+ mutually authenticates with the next hop and negotiates an
+ appropriate security layer.
+
+
+
+
+Myers Standards Track [Page 9]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ Additional security considerations are mentioned in the SASL
+ specification [SASL].
+
+
+
+10. Author's Address
+
+ John Gardiner Myers
+ Netscape Communications
+ 501 East Middlefield Road
+ Mail Stop MV-029
+ Mountain View, CA 94043
+
+ EMail: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 10]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 11]
+
diff --git a/Documentation/en/rfc/rfc2821.txt b/Documentation/en/rfc/rfc2821.txt
new file mode 100644
index 00000000..0eac9118
--- /dev/null
+++ b/Documentation/en/rfc/rfc2821.txt
@@ -0,0 +1,4427 @@
+
+
+
+
+
+
+Network Working Group J. Klensin, Editor
+Request for Comments: 2821 AT&T Laboratories
+Obsoletes: 821, 974, 1869 April 2001
+Updates: 1123
+Category: Standards Track
+
+
+ Simple Mail Transfer Protocol
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document is a self-contained specification of the basic protocol
+ for the Internet electronic mail transport. It consolidates, updates
+ and clarifies, but doesn't add new or change existing functionality
+ of the following:
+
+ - the original SMTP (Simple Mail Transfer Protocol) specification of
+ RFC 821 [30],
+
+ - domain name system requirements and implications for mail
+ transport from RFC 1035 [22] and RFC 974 [27],
+
+ - the clarifications and applicability statements in RFC 1123 [2],
+ and
+
+ - material drawn from the SMTP Extension mechanisms [19].
+
+ It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the
+ mail transport materials of RFC 1123). However, RFC 821 specifies
+ some features that were not in significant use in the Internet by the
+ mid-1990s and (in appendices) some additional transport models.
+ Those sections are omitted here in the interest of clarity and
+ brevity; readers needing them should refer to RFC 821.
+
+
+
+
+
+
+Klensin Standards Track [Page 1]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ It also includes some additional material from RFC 1123 that required
+ amplification. This material has been identified in multiple ways,
+ mostly by tracking flaming on various lists and newsgroups and
+ problems of unusual readings or interpretations that have appeared as
+ the SMTP extensions have been deployed. Where this specification
+ moves beyond consolidation and actually differs from earlier
+ documents, it supersedes them technically as well as textually.
+
+ Although SMTP was designed as a mail transport and delivery protocol,
+ this specification also contains information that is important to its
+ use as a 'mail submission' protocol, as recommended for POP [3, 26]
+ and IMAP [6]. Additional submission issues are discussed in RFC 2476
+ [15].
+
+ Section 2.3 provides definitions of terms specific to this document.
+ Except when the historical terminology is necessary for clarity, this
+ document uses the current 'client' and 'server' terminology to
+ identify the sending and receiving SMTP processes, respectively.
+
+ A companion document [32] discusses message headers, message bodies
+ and formats and structures for them, and their relationship.
+
+Table of Contents
+
+ 1. Introduction .................................................. 4
+ 2. The SMTP Model ................................................ 5
+ 2.1 Basic Structure .............................................. 5
+ 2.2 The Extension Model .......................................... 7
+ 2.2.1 Background ................................................. 7
+ 2.2.2 Definition and Registration of Extensions .................. 8
+ 2.3 Terminology .................................................. 9
+ 2.3.1 Mail Objects ............................................... 10
+ 2.3.2 Senders and Receivers ...................................... 10
+ 2.3.3 Mail Agents and Message Stores ............................. 10
+ 2.3.4 Host ....................................................... 11
+ 2.3.5 Domain ..................................................... 11
+ 2.3.6 Buffer and State Table ..................................... 11
+ 2.3.7 Lines ...................................................... 12
+ 2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
+ 2.3.9 Message Content and Mail Data .............................. 13
+ 2.3.10 Mailbox and Address ....................................... 13
+ 2.3.11 Reply ..................................................... 13
+ 2.4 General Syntax Principles and Transaction Model .............. 13
+ 3. The SMTP Procedures: An Overview .............................. 15
+ 3.1 Session Initiation ........................................... 15
+ 3.2 Client Initiation ............................................ 16
+ 3.3 Mail Transactions ............................................ 16
+ 3.4 Forwarding for Address Correction or Updating ................ 19
+
+
+
+Klensin Standards Track [Page 2]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ 3.5 Commands for Debugging Addresses ............................. 20
+ 3.5.1 Overview ................................................... 20
+ 3.5.2 VRFY Normal Response ....................................... 22
+ 3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
+ 3.5.4 Semantics and Applications of EXPN ......................... 23
+ 3.6 Domains ...................................................... 23
+ 3.7 Relaying ..................................................... 24
+ 3.8 Mail Gatewaying .............................................. 25
+ 3.8.1 Header Fields in Gatewaying ................................ 26
+ 3.8.2 Received Lines in Gatewaying ............................... 26
+ 3.8.3 Addresses in Gatewaying .................................... 26
+ 3.8.4 Other Header Fields in Gatewaying .......................... 27
+ 3.8.5 Envelopes in Gatewaying .................................... 27
+ 3.9 Terminating Sessions and Connections ......................... 27
+ 3.10 Mailing Lists and Aliases ................................... 28
+ 3.10.1 Alias ..................................................... 28
+ 3.10.2 List ...................................................... 28
+ 4. The SMTP Specifications ....................................... 29
+ 4.1 SMTP Commands ................................................ 29
+ 4.1.1 Command Semantics and Syntax ............................... 29
+ 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29
+ 4.1.1.2 MAIL (MAIL) .............................................. 31
+ 4.1.1.3 RECIPIENT (RCPT) ......................................... 31
+ 4.1.1.4 DATA (DATA) .............................................. 33
+ 4.1.1.5 RESET (RSET) ............................................. 34
+ 4.1.1.6 VERIFY (VRFY) ............................................ 35
+ 4.1.1.7 EXPAND (EXPN) ............................................ 35
+ 4.1.1.8 HELP (HELP) .............................................. 35
+ 4.1.1.9 NOOP (NOOP) .............................................. 35
+ 4.1.1.10 QUIT (QUIT) ............................................. 36
+ 4.1.2 Command Argument Syntax .................................... 36
+ 4.1.3 Address Literals ........................................... 38
+ 4.1.4 Order of Commands .......................................... 39
+ 4.1.5 Private-use Commands ....................................... 40
+ 4.2 SMTP Replies ................................................ 40
+ 4.2.1 Reply Code Severities and Theory ........................... 42
+ 4.2.2 Reply Codes by Function Groups ............................. 44
+ 4.2.3 Reply Codes in Numeric Order .............................. 45
+ 4.2.4 Reply Code 502 ............................................. 46
+ 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
+ 4.3 Sequencing of Commands and Replies ........................... 47
+ 4.3.1 Sequencing Overview ........................................ 47
+ 4.3.2 Command-Reply Sequences .................................... 48
+ 4.4 Trace Information ............................................ 49
+ 4.5 Additional Implementation Issues ............................. 53
+ 4.5.1 Minimum Implementation ..................................... 53
+ 4.5.2 Transparency ............................................... 53
+ 4.5.3 Sizes and Timeouts ......................................... 54
+
+
+
+Klensin Standards Track [Page 3]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ 4.5.3.1 Size limits and minimums ................................. 54
+ 4.5.3.2 Timeouts ................................................. 56
+ 4.5.4 Retry Strategies ........................................... 57
+ 4.5.4.1 Sending Strategy ......................................... 58
+ 4.5.4.2 Receiving Strategy ....................................... 59
+ 4.5.5 Messages with a null reverse-path .......................... 59
+ 5. Address Resolution and Mail Handling .......................... 60
+ 6. Problem Detection and Handling ................................ 62
+ 6.1 Reliable Delivery and Replies by Email ....................... 62
+ 6.2 Loop Detection ............................................... 63
+ 6.3 Compensating for Irregularities .............................. 63
+ 7. Security Considerations ....................................... 64
+ 7.1 Mail Security and Spoofing ................................... 64
+ 7.2 "Blind" Copies ............................................... 65
+ 7.3 VRFY, EXPN, and Security ..................................... 65
+ 7.4 Information Disclosure in Announcements ...................... 66
+ 7.5 Information Disclosure in Trace Fields ....................... 66
+ 7.6 Information Disclosure in Message Forwarding ................. 67
+ 7.7 Scope of Operation of SMTP Servers ........................... 67
+ 8. IANA Considerations ........................................... 67
+ 9. References .................................................... 68
+ 10. Editor's Address ............................................. 70
+ 11. Acknowledgments .............................................. 70
+ Appendices ....................................................... 71
+ A. TCP Transport Service ......................................... 71
+ B. Generating SMTP Commands from RFC 822 Headers ................. 71
+ C. Source Routes ................................................. 72
+ D. Scenarios ..................................................... 73
+ E. Other Gateway Issues .......................................... 76
+ F. Deprecated Features of RFC 821 ................................ 76
+ Full Copyright Statement ......................................... 79
+
+1. Introduction
+
+ The objective of the Simple Mail Transfer Protocol (SMTP) is to
+ transfer mail reliably and efficiently.
+
+ SMTP is independent of the particular transmission subsystem and
+ requires only a reliable ordered data stream channel. While this
+ document specifically discusses transport over TCP, other transports
+ are possible. Appendices to RFC 821 describe some of them.
+
+ An important feature of SMTP is its capability to transport mail
+ across networks, usually referred to as "SMTP mail relaying" (see
+ section 3.8). A network consists of the mutually-TCP-accessible
+ hosts on the public Internet, the mutually-TCP-accessible hosts on a
+ firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
+ environment utilizing a non-TCP transport-level protocol. Using
+
+
+
+Klensin Standards Track [Page 4]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ SMTP, a process can transfer mail to another process on the same
+ network or to some other network via a relay or gateway process
+ accessible to both networks.
+
+ In this way, a mail message may pass through a number of intermediate
+ relay or gateway hosts on its path from sender to ultimate recipient.
+ The Mail eXchanger mechanisms of the domain name system [22, 27] (and
+ section 5 of this document) are used to identify the appropriate
+ next-hop destination for a message being transported.
+
+2. The SMTP Model
+
+2.1 Basic Structure
+
+ The SMTP design can be pictured as:
+
+ +----------+ +----------+
+ +------+ | | | |
+ | User |<-->| | SMTP | |
+ +------+ | Client- |Commands/Replies| Server- |
+ +------+ | SMTP |<-------------->| SMTP | +------+
+ | File |<-->| | and Mail | |<-->| File |
+ |System| | | | | |System|
+ +------+ +----------+ +----------+ +------+
+ SMTP client SMTP server
+
+ When an SMTP client has a message to transmit, it establishes a two-
+ way transmission channel to an SMTP server. The responsibility of an
+ SMTP client is to transfer mail messages to one or more SMTP servers,
+ or report its failure to do so.
+
+ The means by which a mail message is presented to an SMTP client, and
+ how that client determines the domain name(s) to which mail messages
+ are to be transferred is a local matter, and is not addressed by this
+ document. In some cases, the domain name(s) transferred to, or
+ determined by, an SMTP client will identify the final destination(s)
+ of the mail message. In other cases, common with SMTP clients
+ associated with implementations of the POP [3, 26] or IMAP [6]
+ protocols, or when the SMTP client is inside an isolated transport
+ service environment, the domain name determined will identify an
+ intermediate destination through which all mail messages are to be
+ relayed. SMTP clients that transfer all traffic, regardless of the
+ target domain names associated with the individual messages, or that
+ do not maintain queues for retrying message transmissions that
+ initially cannot be completed, may otherwise conform to this
+ specification but are not considered fully-capable. Fully-capable
+ SMTP implementations, including the relays used by these less capable
+
+
+
+
+Klensin Standards Track [Page 5]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ ones, and their destinations, are expected to support all of the
+ queuing, retrying, and alternate address functions discussed in this
+ specification.
+
+ The means by which an SMTP client, once it has determined a target
+ domain name, determines the identity of an SMTP server to which a
+ copy of a message is to be transferred, and then performs that
+ transfer, is covered by this document. To effect a mail transfer to
+ an SMTP server, an SMTP client establishes a two-way transmission
+ channel to that SMTP server. An SMTP client determines the address
+ of an appropriate host running an SMTP server by resolving a
+ destination domain name to either an intermediate Mail eXchanger host
+ or a final target host.
+
+ An SMTP server may be either the ultimate destination or an
+ intermediate "relay" (that is, it may assume the role of an SMTP
+ client after receiving the message) or "gateway" (that is, it may
+ transport the message further using some protocol other than SMTP).
+ SMTP commands are generated by the SMTP client and sent to the SMTP
+ server. SMTP replies are sent from the SMTP server to the SMTP
+ client in response to the commands.
+
+ In other words, message transfer can occur in a single connection
+ between the original SMTP-sender and the final SMTP-recipient, or can
+ occur in a series of hops through intermediary systems. In either
+ case, a formal handoff of responsibility for the message occurs: the
+ protocol requires that a server accept responsibility for either
+ delivering a message or properly reporting the failure to do so.
+
+ Once the transmission channel is established and initial handshaking
+ completed, the SMTP client normally initiates a mail transaction.
+ Such a transaction consists of a series of commands to specify the
+ originator and destination of the mail and transmission of the
+ message content (including any headers or other structure) itself.
+ When the same message is sent to multiple recipients, this protocol
+ encourages the transmission of only one copy of the data for all
+ recipients at the same destination (or intermediate relay) host.
+
+ The server responds to each command with a reply; replies may
+ indicate that the command was accepted, that additional commands are
+ expected, or that a temporary or permanent error condition exists.
+ Commands specifying the sender or recipients may include server-
+ permitted SMTP service extension requests as discussed in section
+ 2.2. The dialog is purposely lock-step, one-at-a-time, although this
+ can be modified by mutually-agreed extension requests such as command
+ pipelining [13].
+
+
+
+
+
+Klensin Standards Track [Page 6]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ Once a given mail message has been transmitted, the client may either
+ request that the connection be shut down or may initiate other mail
+ transactions. In addition, an SMTP client may use a connection to an
+ SMTP server for ancillary services such as verification of email
+ addresses or retrieval of mailing list subscriber addresses.
+
+ As suggested above, this protocol provides mechanisms for the
+ transmission of mail. This transmission normally occurs directly
+ from the sending user's host to the receiving user's host when the
+ two hosts are connected to the same transport service. When they are
+ not connected to the same transport service, transmission occurs via
+ one or more relay SMTP servers. An intermediate host that acts as
+ either an SMTP relay or as a gateway into some other transmission
+ environment is usually selected through the use of the domain name
+ service (DNS) Mail eXchanger mechanism.
+
+ Usually, intermediate hosts are determined via the DNS MX record, not
+ by explicit "source" routing (see section 5 and appendices C and
+ F.2).
+
+2.2 The Extension Model
+
+2.2.1 Background
+
+ In an effort that started in 1990, approximately a decade after RFC
+ 821 was completed, the protocol was modified with a "service
+ extensions" model that permits the client and server to agree to
+ utilize shared functionality beyond the original SMTP requirements.
+ The SMTP extension mechanism defines a means whereby an extended SMTP
+ client and server may recognize each other, and the server can inform
+ the client as to the service extensions that it supports.
+
+ Contemporary SMTP implementations MUST support the basic extension
+ mechanisms. For instance, servers MUST support the EHLO command even
+ if they do not implement any specific extensions and clients SHOULD
+ preferentially utilize EHLO rather than HELO. (However, for
+ compatibility with older conforming implementations, SMTP clients and
+ servers MUST support the original HELO mechanisms as a fallback.)
+ Unless the different characteristics of HELO must be identified for
+ interoperability purposes, this document discusses only EHLO.
+
+ SMTP is widely deployed and high-quality implementations have proven
+ to be very robust. However, the Internet community now considers
+ some services to be important that were not anticipated when the
+ protocol was first designed. If support for those services is to be
+ added, it must be done in a way that permits older implementations to
+ continue working acceptably. The extension framework consists of:
+
+
+
+
+Klensin Standards Track [Page 7]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ - The SMTP command EHLO, superseding the earlier HELO,
+
+ - a registry of SMTP service extensions,
+
+ - additional parameters to the SMTP MAIL and RCPT commands, and
+
+ - optional replacements for commands defined in this protocol, such
+ as for DATA in non-ASCII transmissions [33].
+
+ SMTP's strength comes primarily from its simplicity. Experience with
+ many protocols has shown that protocols with few options tend towards
+ ubiquity, whereas protocols with many options tend towards obscurity.
+
+ Each and every extension, regardless of its benefits, must be
+ carefully scrutinized with respect to its implementation, deployment,
+ and interoperability costs. In many cases, the cost of extending the
+ SMTP service will likely outweigh the benefit.
+
+2.2.2 Definition and Registration of Extensions
+
+ The IANA maintains a registry of SMTP service extensions. A
+ corresponding EHLO keyword value is associated with each extension.
+ Each service extension registered with the IANA must be defined in a
+ formal standards-track or IESG-approved experimental protocol
+ document. The definition must include:
+
+ - the textual name of the SMTP service extension;
+
+ - the EHLO keyword value associated with the extension;
+
+ - the syntax and possible values of parameters associated with the
+ EHLO keyword value;
+
+ - any additional SMTP verbs associated with the extension
+ (additional verbs will usually be, but are not required to be, the
+ same as the EHLO keyword value);
+
+ - any new parameters the extension associates with the MAIL or RCPT
+ verbs;
+
+ - a description of how support for the extension affects the
+ behavior of a server and client SMTP; and,
+
+ - the increment by which the extension is increasing the maximum
+ length of the commands MAIL and/or RCPT, over that specified in
+ this standard.
+
+
+
+
+
+Klensin Standards Track [Page 8]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ In addition, any EHLO keyword value starting with an upper or lower
+ case "X" refers to a local SMTP service extension used exclusively
+ through bilateral agreement. Keywords beginning with "X" MUST NOT be
+ used in a registered service extension. Conversely, keyword values
+ presented in the EHLO response that do not begin with "X" MUST
+ correspond to a standard, standards-track, or IESG-approved
+ experimental SMTP service extension registered with IANA. A
+ conforming server MUST NOT offer non-"X"-prefixed keyword values that
+ are not described in a registered extension.
+
+ Additional verbs and parameter names are bound by the same rules as
+ EHLO keywords; specifically, verbs beginning with "X" are local
+ extensions that may not be registered or standardized. Conversely,
+ verbs not beginning with "X" must always be registered.
+
+2.3 Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described below.
+
+ 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
+ the definition is an absolute requirement of the specification.
+
+ 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
+ definition is an absolute prohibition of the specification.
+
+ 3. SHOULD This word, or the adjective "RECOMMENDED", mean that
+ there may exist valid reasons in particular circumstances to
+ ignore a particular item, but the full implications must be
+ understood and carefully weighed before choosing a different
+ course.
+
+ 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
+ that there may exist valid reasons in particular circumstances
+ when the particular behavior is acceptable or even useful, but the
+ full implications should be understood and the case carefully
+ weighed before implementing any behavior described with this
+ label.
+
+ 5. MAY This word, or the adjective "OPTIONAL", mean that an item is
+ truly optional. One vendor may choose to include the item because
+ a particular marketplace requires it or because the vendor feels
+ that it enhances the product while another vendor may omit the
+ same item. An implementation which does not include a particular
+ option MUST be prepared to interoperate with another
+ implementation which does include the option, though perhaps with
+ reduced functionality. In the same vein an implementation which
+
+
+
+Klensin Standards Track [Page 9]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ does include a particular option MUST be prepared to interoperate
+ with another implementation which does not include the option
+ (except, of course, for the feature the option provides.)
+
+2.3.1 Mail Objects
+
+ SMTP transports a mail object. A mail object contains an envelope
+ and content.
+
+ The SMTP envelope is sent as a series of SMTP protocol units
+ (described in section 3). It consists of an originator address (to
+ which error reports should be directed); one or more recipient
+ addresses; and optional protocol extension material. Historically,
+ variations on the recipient address specification command (RCPT TO)
+ could be used to specify alternate delivery modes, such as immediate
+ display; those variations have now been deprecated (see appendix F,
+ section F.6).
+
+ The SMTP content is sent in the SMTP DATA protocol unit and has two
+ parts: the headers and the body. If the content conforms to other
+ contemporary standards, the headers form a collection of field/value
+ pairs structured as in the message format specification [32]; the
+ body, if structured, is defined according to MIME [12]. The content
+ is textual in nature, expressed using the US-ASCII repertoire [1].
+ Although SMTP extensions (such as "8BITMIME" [20]) may relax this
+ restriction for the content body, the content headers are always
+ encoded using the US-ASCII repertoire. A MIME extension [23] defines
+ an algorithm for representing header values outside the US-ASCII
+ repertoire, while still encoding them using the US-ASCII repertoire.
+
+2.3.2 Senders and Receivers
+
+ In RFC 821, the two hosts participating in an SMTP transaction were
+ described as the "SMTP-sender" and "SMTP-receiver". This document
+ has been changed to reflect current industry terminology and hence
+ refers to them as the "SMTP client" (or sometimes just "the client")
+ and "SMTP server" (or just "the server"), respectively. Since a
+ given host may act both as server and client in a relay situation,
+ "receiver" and "sender" terminology is still used where needed for
+ clarity.
+
+2.3.3 Mail Agents and Message Stores
+
+ Additional mail system terminology became common after RFC 821 was
+ published and, where convenient, is used in this specification. In
+ particular, SMTP servers and clients provide a mail transport service
+ and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
+ Agents" (MUAs or UAs) are normally thought of as the sources and
+
+
+
+Klensin Standards Track [Page 10]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ targets of mail. At the source, an MUA might collect mail to be
+ transmitted from a user and hand it off to an MTA; the final
+ ("delivery") MTA would be thought of as handing the mail off to an
+ MUA (or at least transferring responsibility to it, e.g., by
+ depositing the message in a "message store"). However, while these
+ terms are used with at least the appearance of great precision in
+ other environments, the implied boundaries between MUAs and MTAs
+ often do not accurately match common, and conforming, practices with
+ Internet mail. Hence, the reader should be cautious about inferring
+ the strong relationships and responsibilities that might be implied
+ if these terms were used elsewhere.
+
+2.3.4 Host
+
+ For the purposes of this specification, a host is a computer system
+ attached to the Internet (or, in some cases, to a private TCP/IP
+ network) and supporting the SMTP protocol. Hosts are known by names
+ (see "domain"); identifying them by numerical address is discouraged.
+
+2.3.5 Domain
+
+ A domain (or domain name) consists of one or more dot-separated
+ components. These components ("labels" in DNS terminology [22]) are
+ restricted for SMTP purposes to consist of a sequence of letters,
+ digits, and hyphens drawn from the ASCII character set [1]. Domain
+ names are used as names of hosts and of other entities in the domain
+ name hierarchy. For example, a domain may refer to an alias (label
+ of a CNAME RR) or the label of Mail eXchanger records to be used to
+ deliver mail instead of representing a host name. See [22] and
+ section 5 of this specification.
+
+ The domain name, as described in this document and in [22], is the
+ entire, fully-qualified name (often referred to as an "FQDN"). A
+ domain name that is not in FQDN form is no more than a local alias.
+ Local aliases MUST NOT appear in any SMTP transaction.
+
+2.3.6 Buffer and State Table
+
+ SMTP sessions are stateful, with both parties carefully maintaining a
+ common view of the current state. In this document we model this
+ state by a virtual "buffer" and a "state table" on the server which
+ may be used by the client to, for example, "clear the buffer" or
+ "reset the state table," causing the information in the buffer to be
+ discarded and the state to be returned to some previous state.
+
+
+
+
+
+
+
+Klensin Standards Track [Page 11]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+2.3.7 Lines
+
+ SMTP commands and, unless altered by a service extension, message
+ data, are transmitted in "lines". Lines consist of zero or more data
+ characters terminated by the sequence ASCII character "CR" (hex value
+ 0D) followed immediately by ASCII character "LF" (hex value 0A).
+ This termination sequence is denoted as <CRLF> in this document.
+ Conforming implementations MUST NOT recognize or generate any other
+ character or character sequence as a line terminator. Limits MAY be
+ imposed on line lengths by servers (see section 4.5.3).
+
+ In addition, the appearance of "bare" "CR" or "LF" characters in text
+ (i.e., either without the other) has a long history of causing
+ problems in mail implementations and applications that use the mail
+ system as a tool. SMTP client implementations MUST NOT transmit
+ these characters except when they are intended as line terminators
+ and then MUST, as indicated above, transmit them only as a <CRLF>
+ sequence.
+
+2.3.8 Originator, Delivery, Relay, and Gateway Systems
+
+ This specification makes a distinction among four types of SMTP
+ systems, based on the role those systems play in transmitting
+ electronic mail. An "originating" system (sometimes called an SMTP
+ originator) introduces mail into the Internet or, more generally,
+ into a transport service environment. A "delivery" SMTP system is
+ one that receives mail from a transport service environment and
+ passes it to a mail user agent or deposits it in a message store
+ which a mail user agent is expected to subsequently access. A
+ "relay" SMTP system (usually referred to just as a "relay") receives
+ mail from an SMTP client and transmits it, without modification to
+ the message data other than adding trace information, to another SMTP
+ server for further relaying or for delivery.
+
+ A "gateway" SMTP system (usually referred to just as a "gateway")
+ receives mail from a client system in one transport environment and
+ transmits it to a server system in another transport environment.
+ Differences in protocols or message semantics between the transport
+ environments on either side of a gateway may require that the gateway
+ system perform transformations to the message that are not permitted
+ to SMTP relay systems. For the purposes of this specification,
+ firewalls that rewrite addresses should be considered as gateways,
+ even if SMTP is used on both sides of them (see [11]).
+
+
+
+
+
+
+
+
+Klensin Standards Track [Page 12]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+2.3.9 Message Content and Mail Data
+
+ The terms "message content" and "mail data" are used interchangeably
+ in this document to describe the material transmitted after the DATA
+ command is accepted and before the end of data indication is
+ transmitted. Message content includes message headers and the
+ possibly-structured message body. The MIME specification [12]
+ provides the standard mechanisms for structured message bodies.
+
+2.3.10 Mailbox and Address
+
+ As used in this specification, an "address" is a character string
+ that identifies a user to whom mail will be sent or a location into
+ which mail will be deposited. The term "mailbox" refers to that
+ depository. The two terms are typically used interchangeably unless
+ the distinction between the location in which mail is placed (the
+ mailbox) and a reference to it (the address) is important. An
+ address normally consists of user and domain specifications. The
+ standard mailbox naming convention is defined to be "local-
+ part@domain": contemporary usage permits a much broader set of
+ applications than simple "user names". Consequently, and due to a
+ long history of problems when intermediate hosts have attempted to
+ optimize transport by modifying them, the local-part MUST be
+ interpreted and assigned semantics only by the host specified in the
+ domain part of the address.
+
+2.3.11 Reply
+
+ An SMTP reply is an acknowledgment (positive or negative) sent from
+ receiver to sender via the transmission channel in response to a
+ command. The general form of a reply is a numeric completion code
+ (indicating failure or success) usually followed by a text string.
+ The codes are for use by programs and the text is usually intended
+ for human users. Recent work [34] has specified further structuring
+ of the reply strings, including the use of supplemental and more
+ specific completion codes.
+
+2.4 General Syntax Principles and Transaction Model
+
+ SMTP commands and replies have a rigid syntax. All commands begin
+ with a command verb. All Replies begin with a three digit numeric
+ code. In some commands and replies, arguments MUST follow the verb
+ or reply code. Some commands do not accept arguments (after the
+ verb), and some reply codes are followed, sometimes optionally, by
+ free form text. In both cases, where text appears, it is separated
+ from the verb or reply code by a space character. Complete
+ definitions of commands and replies appear in section 4.
+
+
+
+
+Klensin Standards Track [Page 13]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
+ and extension name keywords) are not case sensitive, with the sole
+ exception in this specification of a mailbox local-part (SMTP
+ Extensions may explicitly specify case-sensitive elements). That is,
+ a command verb, an argument value other than a mailbox local-part,
+ and free form text MAY be encoded in upper case, lower case, or any
+ mixture of upper and lower case with no impact on its meaning. This
+ is NOT true of a mailbox local-part. The local-part of a mailbox
+ MUST BE treated as case sensitive. Therefore, SMTP implementations
+ MUST take care to preserve the case of mailbox local-parts. Mailbox
+ domains are not case sensitive. In particular, for some hosts the
+ user "smith" is different from the user "Smith". However, exploiting
+ the case sensitivity of mailbox local-parts impedes interoperability
+ and is discouraged.
+
+ A few SMTP servers, in violation of this specification (and RFC 821)
+ require that command verbs be encoded by clients in upper case.
+ Implementations MAY wish to employ this encoding to accommodate those
+ servers.
+
+ The argument field consists of a variable length character string
+ ending with the end of the line, i.e., with the character sequence
+ <CRLF>. The receiver will take no action until this sequence is
+ received.
+
+ The syntax for each command is shown with the discussion of that
+ command. Common elements and parameters are shown in section 4.1.2.
+
+ Commands and replies are composed of characters from the ASCII
+ character set [1]. When the transport service provides an 8-bit byte
+ (octet) transmission channel, each 7-bit character is transmitted
+ right justified in an octet with the high order bit cleared to zero.
+ More specifically, the unextended SMTP service provides seven bit
+ transport only. An originating SMTP client which has not
+ successfully negotiated an appropriate extension with a particular
+ server MUST NOT transmit messages with information in the high-order
+ bit of octets. If such messages are transmitted in violation of this
+ rule, receiving SMTP servers MAY clear the high-order bit or reject
+ the message as invalid. In general, a relay SMTP SHOULD assume that
+ the message content it has received is valid and, assuming that the
+ envelope permits doing so, relay it without inspecting that content.
+ Of course, if the content is mislabeled and the data path cannot
+ accept the actual content, this may result in ultimate delivery of a
+ severely garbled message to the recipient. Delivery SMTP systems MAY
+ reject ("bounce") such messages rather than deliver them. No sending
+ SMTP system is permitted to send envelope commands in any character
+
+
+
+
+
+Klensin Standards Track [Page 14]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ set other than US-ASCII; receiving systems SHOULD reject such
+ commands, normally using "500 syntax error - invalid character"
+ replies.
+
+ Eight-bit message content transmission MAY be requested of the server
+ by a client using extended SMTP facilities, notably the "8BITMIME"
+ extension [20]. 8BITMIME SHOULD be supported by SMTP servers.
+ However, it MUST not be construed as authorization to transmit
+ unrestricted eight bit material. 8BITMIME MUST NOT be requested by
+ senders for material with the high bit on that is not in MIME format
+ with an appropriate content-transfer encoding; servers MAY reject
+ such messages.
+
+ The metalinguistic notation used in this document corresponds to the
+ "Augmented BNF" used in other Internet mail system documents. The
+ reader who is not familiar with that syntax should consult the ABNF
+ specification [8]. Metalanguage terms used in running text are
+ surrounded by pointed brackets (e.g., <CRLF>) for clarity.
+
+3. The SMTP Procedures: An Overview
+
+ This section contains descriptions of the procedures used in SMTP:
+ session initiation, the mail transaction, forwarding mail, verifying
+ mailbox names and expanding mailing lists, and the opening and
+ closing exchanges. Comments on relaying, a note on mail domains, and
+ a discussion of changing roles are included at the end of this
+ section. Several complete scenarios are presented in appendix D.
+
+3.1 Session Initiation
+
+ An SMTP session is initiated when a client opens a connection to a
+ server and the server responds with an opening message.
+
+ SMTP server implementations MAY include identification of their
+ software and version information in the connection greeting reply
+ after the 220 code, a practice that permits more efficient isolation
+ and repair of any problems. Implementations MAY make provision for
+ SMTP servers to disable the software and version announcement where
+ it causes security concerns. While some systems also identify their
+ contact point for mail problems, this is not a substitute for
+ maintaining the required "postmaster" address (see section 4.5.1).
+
+ The SMTP protocol allows a server to formally reject a transaction
+ while still allowing the initial connection as follows: a 554
+ response MAY be given in the initial connection opening message
+ instead of the 220. A server taking this approach MUST still wait
+ for the client to send a QUIT (see section 4.1.1.10) before closing
+ the connection and SHOULD respond to any intervening commands with
+
+
+
+Klensin Standards Track [Page 15]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ "503 bad sequence of commands". Since an attempt to make an SMTP
+ connection to such a system is probably in error, a server returning
+ a 554 response on connection opening SHOULD provide enough
+ information in the reply text to facilitate debugging of the sending
+ system.
+
+3.2 Client Initiation
+
+ Once the server has sent the welcoming message and the client has
+ received it, the client normally sends the EHLO command to the
+ server, indicating the client's identity. In addition to opening the
+ session, use of EHLO indicates that the client is able to process
+ service extensions and requests that the server provide a list of the
+ extensions it supports. Older SMTP systems which are unable to
+ support service extensions and contemporary clients which do not
+ require service extensions in the mail session being initiated, MAY
+ use HELO instead of EHLO. Servers MUST NOT return the extended
+ EHLO-style response to a HELO command. For a particular connection
+ attempt, if the server returns a "command not recognized" response to
+ EHLO, the client SHOULD be able to fall back and send HELO.
+
+ In the EHLO command the host sending the command identifies itself;
+ the command may be interpreted as saying "Hello, I am <domain>" (and,
+ in the case of EHLO, "and I support service extension requests").
+
+3.3 Mail Transactions
+
+ There are three steps to SMTP mail transactions. The transaction
+ starts with a MAIL command which gives the sender identification.
+ (In general, the MAIL command may be sent only when no mail
+ transaction is in progress; see section 4.1.4.) A series of one or
+ more RCPT commands follows giving the receiver information. Then a
+ DATA command initiates transfer of the mail data and is terminated by
+ the "end of mail" data indicator, which also confirms the
+ transaction.
+
+ The first step in the procedure is the MAIL command.
+
+ MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
+
+ This command tells the SMTP-receiver that a new mail transaction is
+ starting and to reset all its state tables and buffers, including any
+ recipients or mail data. The <reverse-path> portion of the first or
+ only argument contains the source mailbox (between "<" and ">"
+ brackets), which can be used to report errors (see section 4.2 for a
+ discussion of error reporting). If accepted, the SMTP server returns
+ a 250 OK reply. If the mailbox specification is not acceptable for
+ some reason, the server MUST return a reply indicating whether the
+
+
+
+Klensin Standards Track [Page 16]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ failure is permanent (i.e., will occur again if the client tries to
+ send the same address again) or temporary (i.e., the address might be
+ accepted if the client tries again later). Despite the apparent
+ scope of this requirement, there are circumstances in which the
+ acceptability of the reverse-path may not be determined until one or
+ more forward-paths (in RCPT commands) can be examined. In those
+ cases, the server MAY reasonably accept the reverse-path (with a 250
+ reply) and then report problems after the forward-paths are received
+ and examined. Normally, failures produce 550 or 553 replies.
+
+ Historically, the <reverse-path> can contain more than just a
+ mailbox, however, contemporary systems SHOULD NOT use source routing
+ (see appendix C).
+
+ The optional <mail-parameters> are associated with negotiated SMTP
+ service extensions (see section 2.2).
+
+ The second step in the procedure is the RCPT command.
+
+ RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
+
+ The first or only argument to this command includes a forward-path
+ (normally a mailbox and domain, always surrounded by "<" and ">"
+ brackets) identifying one recipient. If accepted, the SMTP server
+ returns a 250 OK reply and stores the forward-path. If the recipient
+ is known not to be a deliverable address, the SMTP server returns a
+ 550 reply, typically with a string such as "no such user - " and the
+ mailbox name (other circumstances and reply codes are possible).
+ This step of the procedure can be repeated any number of times.
+
+ The <forward-path> can contain more than just a mailbox.
+ Historically, the <forward-path> can be a source routing list of
+ hosts and the destination mailbox, however, contemporary SMTP clients
+ SHOULD NOT utilize source routes (see appendix C). Servers MUST be
+ prepared to encounter a list of source routes in the forward path,
+ but SHOULD ignore the routes or MAY decline to support the relaying
+ they imply. Similarly, servers MAY decline to accept mail that is
+ destined for other hosts or systems. These restrictions make a
+ server useless as a relay for clients that do not support full SMTP
+ functionality. Consequently, restricted-capability clients MUST NOT
+ assume that any SMTP server on the Internet can be used as their mail
+ processing (relaying) site. If a RCPT command appears without a
+ previous MAIL command, the server MUST return a 503 "Bad sequence of
+ commands" response. The optional <rcpt-parameters> are associated
+ with negotiated SMTP service extensions (see section 2.2).
+
+ The third step in the procedure is the DATA command (or some
+ alternative specified in a service extension).
+
+
+
+Klensin Standards Track [Page 17]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ DATA <CRLF>
+
+ If accepted, the SMTP server returns a 354 Intermediate reply and
+ considers all succeeding lines up to but not including the end of
+ mail data indicator to be the message text. When the end of text is
+ successfully received and stored the SMTP-receiver sends a 250 OK
+ reply.
+
+ Since the mail data is sent on the transmission channel, the end of
+ mail data must be indicated so that the command and reply dialog can
+ be resumed. SMTP indicates the end of the mail data by sending a
+ line containing only a "." (period or full stop). A transparency
+ procedure is used to prevent this from interfering with the user's
+ text (see section 4.5.2).
+
+ The end of mail data indicator also confirms the mail transaction and
+ tells the SMTP server to now process the stored recipients and mail
+ data. If accepted, the SMTP server returns a 250 OK reply. The DATA
+ command can fail at only two points in the protocol exchange:
+
+ - If there was no MAIL, or no RCPT, command, or all such commands
+ were rejected, the server MAY return a "command out of sequence"
+ (503) or "no valid recipients" (554) reply in response to the DATA
+ command. If one of those replies (or any other 5yz reply) is
+ received, the client MUST NOT send the message data; more
+ generally, message data MUST NOT be sent unless a 354 reply is
+ received.
+
+ - If the verb is initially accepted and the 354 reply issued, the
+ DATA command should fail only if the mail transaction was
+ incomplete (for example, no recipients), or if resources were
+ unavailable (including, of course, the server unexpectedly
+ becoming unavailable), or if the server determines that the
+ message should be rejected for policy or other reasons.
+
+ However, in practice, some servers do not perform recipient
+ verification until after the message text is received. These servers
+ SHOULD treat a failure for one or more recipients as a "subsequent
+ failure" and return a mail message as discussed in section 6. Using
+ a "550 mailbox not found" (or equivalent) reply code after the data
+ are accepted makes it difficult or impossible for the client to
+ determine which recipients failed.
+
+ When RFC 822 format [7, 32] is being used, the mail data include the
+ memo header items such as Date, Subject, To, Cc, From. Server SMTP
+ systems SHOULD NOT reject messages based on perceived defects in the
+ RFC 822 or MIME [12] message header or message body. In particular,
+
+
+
+
+Klensin Standards Track [Page 18]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ they MUST NOT reject messages in which the numbers of Resent-fields
+ do not match or Resent-to appears without Resent-from and/or Resent-
+ date.
+
+ Mail transaction commands MUST be used in the order discussed above.
+
+3.4 Forwarding for Address Correction or Updating
+
+ Forwarding support is most often required to consolidate and simplify
+ addresses within, or relative to, some enterprise and less frequently
+ to establish addresses to link a person's prior address with current
+ one. Silent forwarding of messages (without server notification to
+ the sender), for security or non-disclosure purposes, is common in
+ the contemporary Internet.
+
+ In both the enterprise and the "new address" cases, information
+ hiding (and sometimes security) considerations argue against exposure
+ of the "final" address through the SMTP protocol as a side-effect of
+ the forwarding activity. This may be especially important when the
+ final address may not even be reachable by the sender. Consequently,
+ the "forwarding" mechanisms described in section 3.2 of RFC 821, and
+ especially the 251 (corrected destination) and 551 reply codes from
+ RCPT must be evaluated carefully by implementers and, when they are
+ available, by those configuring systems.
+
+ In particular:
+
+ * Servers MAY forward messages when they are aware of an address
+ change. When they do so, they MAY either provide address-updating
+ information with a 251 code, or may forward "silently" and return
+ a 250 code. But, if a 251 code is used, they MUST NOT assume that
+ the client will actually update address information or even return
+ that information to the user.
+
+ Alternately,
+
+ * Servers MAY reject or bounce messages when they are not
+ deliverable when addressed. When they do so, they MAY either
+ provide address-updating information with a 551 code, or may
+ reject the message as undeliverable with a 550 code and no
+ address-specific information. But, if a 551 code is used, they
+ MUST NOT assume that the client will actually update address
+ information or even return that information to the user.
+
+ SMTP server implementations that support the 251 and/or 551 reply
+ codes are strongly encouraged to provide configuration mechanisms so
+ that sites which conclude that they would undesirably disclose
+ information can disable or restrict their use.
+
+
+
+Klensin Standards Track [Page 19]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+3.5 Commands for Debugging Addresses
+
+3.5.1 Overview
+
+ SMTP provides commands to verify a user name or obtain the content of
+ a mailing list. This is done with the VRFY and EXPN commands, which
+ have character string arguments. Implementations SHOULD support VRFY
+ and EXPN (however, see section 3.5.2 and 7.3).
+
+ For the VRFY command, the string is a user name or a user name and
+ domain (see below). If a normal (i.e., 250) response is returned,
+ the response MAY include the full name of the user and MUST include
+ the mailbox of the user. It MUST be in either of the following
+ forms:
+
+ User Name <local-part@domain>
+ local-part@domain
+
+ When a name that is the argument to VRFY could identify more than one
+ mailbox, the server MAY either note the ambiguity or identify the
+ alternatives. In other words, any of the following are legitimate
+ response to VRFY:
+
+ 553 User ambiguous
+
+ or
+
+ 553- Ambiguous; Possibilities are
+ 553-Joe Smith <jsmith@foo.com>
+ 553-Harry Smith <hsmith@foo.com>
+ 553 Melvin Smith <dweep@foo.com>
+
+ or
+
+ 553-Ambiguous; Possibilities
+ 553- <jsmith@foo.com>
+ 553- <hsmith@foo.com>
+ 553 <dweep@foo.com>
+
+ Under normal circumstances, a client receiving a 553 reply would be
+ expected to expose the result to the user. Use of exactly the forms
+ given, and the "user ambiguous" or "ambiguous" keywords, possibly
+ supplemented by extended reply codes such as those described in [34],
+ will facilitate automated translation into other languages as needed.
+ Of course, a client that was highly automated or that was operating
+ in another language than English, might choose to try to translate
+ the response, to return some other indication to the user than the
+
+
+
+
+Klensin Standards Track [Page 20]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ literal text of the reply, or to take some automated action such as
+ consulting a directory service for additional information before
+ reporting to the user.
+
+ For the EXPN command, the string identifies a mailing list, and the
+ successful (i.e., 250) multiline response MAY include the full name
+ of the users and MUST give the mailboxes on the mailing list.
+
+ In some hosts the distinction between a mailing list and an alias for
+ a single mailbox is a bit fuzzy, since a common data structure may
+ hold both types of entries, and it is possible to have mailing lists
+ containing only one mailbox. If a request is made to apply VRFY to a
+ mailing list, a positive response MAY be given if a message so
+ addressed would be delivered to everyone on the list, otherwise an
+ error SHOULD be reported (e.g., "550 That is a mailing list, not a
+ user" or "252 Unable to verify members of mailing list"). If a
+ request is made to expand a user name, the server MAY return a
+ positive response consisting of a list containing one name, or an
+ error MAY be reported (e.g., "550 That is a user name, not a mailing
+ list").
+
+ In the case of a successful multiline reply (normal for EXPN) exactly
+ one mailbox is to be specified on each line of the reply. The case
+ of an ambiguous request is discussed above.
+
+ "User name" is a fuzzy term and has been used deliberately. An
+ implementation of the VRFY or EXPN commands MUST include at least
+ recognition of local mailboxes as "user names". However, since
+ current Internet practice often results in a single host handling
+ mail for multiple domains, hosts, especially hosts that provide this
+ functionality, SHOULD accept the "local-part@domain" form as a "user
+ name"; hosts MAY also choose to recognize other strings as "user
+ names".
+
+ The case of expanding a mailbox list requires a multiline reply, such
+ as:
+
+ C: EXPN Example-People
+ S: 250-Jon Postel <Postel@isi.edu>
+ S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
+ S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
+
+ or
+
+ C: EXPN Executive-Washroom-List
+ S: 550 Access Denied to You.
+
+
+
+
+
+Klensin Standards Track [Page 21]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ The character string arguments of the VRFY and EXPN commands cannot
+ be further restricted due to the variety of implementations of the
+ user name and mailbox list concepts. On some systems it may be
+ appropriate for the argument of the EXPN command to be a file name
+ for a file containing a mailing list, but again there are a variety
+ of file naming conventions in the Internet. Similarly, historical
+ variations in what is returned by these commands are such that the
+ response SHOULD be interpreted very carefully, if at all, and SHOULD
+ generally only be used for diagnostic purposes.
+
+3.5.2 VRFY Normal Response
+
+ When normal (2yz or 551) responses are returned from a VRFY or EXPN
+ request, the reply normally includes the mailbox name, i.e.,
+ "<local-part@domain>", where "domain" is a fully qualified domain
+ name, MUST appear in the syntax. In circumstances exceptional enough
+ to justify violating the intent of this specification, free-form text
+ MAY be returned. In order to facilitate parsing by both computers
+ and people, addresses SHOULD appear in pointed brackets. When
+ addresses, rather than free-form debugging information, are returned,
+ EXPN and VRFY MUST return only valid domain addresses that are usable
+ in SMTP RCPT commands. Consequently, if an address implies delivery
+ to a program or other system, the mailbox name used to reach that
+ target MUST be given. Paths (explicit source routes) MUST NOT be
+ returned by VRFY or EXPN.
+
+ Server implementations SHOULD support both VRFY and EXPN. For
+ security reasons, implementations MAY provide local installations a
+ way to disable either or both of these commands through configuration
+ options or the equivalent. When these commands are supported, they
+ are not required to work across relays when relaying is supported.
+ Since they were both optional in RFC 821, they MUST be listed as
+ service extensions in an EHLO response, if they are supported.
+
+3.5.3 Meaning of VRFY or EXPN Success Response
+
+ A server MUST NOT return a 250 code in response to a VRFY or EXPN
+ command unless it has actually verified the address. In particular,
+ a server MUST NOT return 250 if all it has done is to verify that the
+ syntax given is valid. In that case, 502 (Command not implemented)
+ or 500 (Syntax error, command unrecognized) SHOULD be returned. As
+ stated elsewhere, implementation (in the sense of actually validating
+ addresses and returning information) of VRFY and EXPN are strongly
+ recommended. Hence, implementations that return 500 or 502 for VRFY
+ are not in full compliance with this specification.
+
+
+
+
+
+
+Klensin Standards Track [Page 22]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ There may be circumstances where an address appears to be valid but
+ cannot reasonably be verified in real time, particularly when a
+ server is acting as a mail exchanger for another server or domain.
+ "Apparent validity" in this case would normally involve at least
+ syntax checking and might involve verification that any domains
+ specified were ones to which the host expected to be able to relay
+ mail. In these situations, reply code 252 SHOULD be returned. These
+ cases parallel the discussion of RCPT verification discussed in
+ section 2.1. Similarly, the discussion in section 3.4 applies to the
+ use of reply codes 251 and 551 with VRFY (and EXPN) to indicate
+ addresses that are recognized but that would be forwarded or bounced
+ were mail received for them. Implementations generally SHOULD be
+ more aggressive about address verification in the case of VRFY than
+ in the case of RCPT, even if it takes a little longer to do so.
+
+3.5.4 Semantics and Applications of EXPN
+
+ EXPN is often very useful in debugging and understanding problems
+ with mailing lists and multiple-target-address aliases. Some systems
+ have attempted to use source expansion of mailing lists as a means of
+ eliminating duplicates. The propagation of aliasing systems with
+ mail on the Internet, for hosts (typically with MX and CNAME DNS
+ records), for mailboxes (various types of local host aliases), and in
+ various proxying arrangements, has made it nearly impossible for
+ these strategies to work consistently, and mail systems SHOULD NOT
+ attempt them.
+
+3.6 Domains
+
+ Only resolvable, fully-qualified, domain names (FQDNs) are permitted
+ when domain names are used in SMTP. In other words, names that can
+ be resolved to MX RRs or A RRs (as discussed in section 5) are
+ permitted, as are CNAME RRs whose targets can be resolved, in turn,
+ to MX or A RRs. Local nicknames or unqualified names MUST NOT be
+ used. There are two exceptions to the rule requiring FQDNs:
+
+ - The domain name given in the EHLO command MUST BE either a primary
+ host name (a domain name that resolves to an A RR) or, if the host
+ has no name, an address literal as described in section 4.1.1.1.
+
+ - The reserved mailbox name "postmaster" may be used in a RCPT
+ command without domain qualification (see section 4.1.1.3) and
+ MUST be accepted if so used.
+
+
+
+
+
+
+
+
+Klensin Standards Track [Page 23]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+3.7 Relaying
+
+ In general, the availability of Mail eXchanger records in the domain
+ name system [22, 27] makes the use of explicit source routes in the
+ Internet mail system unnecessary. Many historical problems with
+ their interpretation have made their use undesirable. SMTP clients
+ SHOULD NOT generate explicit source routes except under unusual
+ circumstances. SMTP servers MAY decline to act as mail relays or to
+ accept addresses that specify source routes. When route information
+ is encountered, SMTP servers are also permitted to ignore the route
+ information and simply send to the final destination specified as the
+ last element in the route and SHOULD do so. There has been an
+ invalid practice of using names that do not appear in the DNS as
+ destination names, with the senders counting on the intermediate
+ hosts specified in source routing to resolve any problems. If source
+ routes are stripped, this practice will cause failures. This is one
+ of several reasons why SMTP clients MUST NOT generate invalid source
+ routes or depend on serial resolution of names.
+
+ When source routes are not used, the process described in RFC 821 for
+ constructing a reverse-path from the forward-path is not applicable
+ and the reverse-path at the time of delivery will simply be the
+ address that appeared in the MAIL command.
+
+ A relay SMTP server is usually the target of a DNS MX record that
+ designates it, rather than the final delivery system. The relay
+ server may accept or reject the task of relaying the mail in the same
+ way it accepts or rejects mail for a local user. If it accepts the
+ task, it then becomes an SMTP client, establishes a transmission
+ channel to the next SMTP server specified in the DNS (according to
+ the rules in section 5), and sends it the mail. If it declines to
+ relay mail to a particular address for policy reasons, a 550 response
+ SHOULD be returned.
+
+ Many mail-sending clients exist, especially in conjunction with
+ facilities that receive mail via POP3 or IMAP, that have limited
+ capability to support some of the requirements of this specification,
+ such as the ability to queue messages for subsequent delivery
+ attempts. For these clients, it is common practice to make private
+ arrangements to send all messages to a single server for processing
+ and subsequent distribution. SMTP, as specified here, is not ideally
+ suited for this role, and work is underway on standardized mail
+ submission protocols that might eventually supercede the current
+ practices. In any event, because these arrangements are private and
+ fall outside the scope of this specification, they are not described
+ here.
+
+
+
+
+
+Klensin Standards Track [Page 24]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ It is important to note that MX records can point to SMTP servers
+ which act as gateways into other environments, not just SMTP relays
+ and final delivery systems; see sections 3.8 and 5.
+
+ If an SMTP server has accepted the task of relaying the mail and
+ later finds that the destination is incorrect or that the mail cannot
+ be delivered for some other reason, then it MUST construct an
+ "undeliverable mail" notification message and send it to the
+ originator of the undeliverable mail (as indicated by the reverse-
+ path). Formats specified for non-delivery reports by other standards
+ (see, for example, [24, 25]) SHOULD be used if possible.
+
+ This notification message must be from the SMTP server at the relay
+ host or the host that first determines that delivery cannot be
+ accomplished. Of course, SMTP servers MUST NOT send notification
+ messages about problems transporting notification messages. One way
+ to prevent loops in error reporting is to specify a null reverse-path
+ in the MAIL command of a notification message. When such a message
+ is transmitted the reverse-path MUST be set to null (see section
+ 4.5.5 for additional discussion). A MAIL command with a null
+ reverse-path appears as follows:
+
+ MAIL FROM:<>
+
+ As discussed in section 2.4.1, a relay SMTP has no need to inspect or
+ act upon the headers or body of the message data and MUST NOT do so
+ except to add its own "Received:" header (section 4.4) and,
+ optionally, to attempt to detect looping in the mail system (see
+ section 6.2).
+
+3.8 Mail Gatewaying
+
+ While the relay function discussed above operates within the Internet
+ SMTP transport service environment, MX records or various forms of
+ explicit routing may require that an intermediate SMTP server perform
+ a translation function between one transport service and another. As
+ discussed in section 2.3.8, when such a system is at the boundary
+ between two transport service environments, we refer to it as a
+ "gateway" or "gateway SMTP".
+
+ Gatewaying mail between different mail environments, such as
+ different mail formats and protocols, is complex and does not easily
+ yield to standardization. However, some general requirements may be
+ given for a gateway between the Internet and another mail
+ environment.
+
+
+
+
+
+
+Klensin Standards Track [Page 25]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+3.8.1 Header Fields in Gatewaying
+
+ Header fields MAY be rewritten when necessary as messages are
+ gatewayed across mail environment boundaries. This may involve
+ inspecting the message body or interpreting the local-part of the
+ destination address in spite of the prohibitions in section 2.4.1.
+
+ Other mail systems gatewayed to the Internet often use a subset of
+ RFC 822 headers or provide similar functionality with a different
+ syntax, but some of these mail systems do not have an equivalent to
+ the SMTP envelope. Therefore, when a message leaves the Internet
+ environment, it may be necessary to fold the SMTP envelope
+ information into the message header. A possible solution would be to
+ create new header fields to carry the envelope information (e.g.,
+ "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would require
+ changes in mail programs in foreign environments and might risk
+ disclosure of private information (see section 7.2).
+
+3.8.2 Received Lines in Gatewaying
+
+ 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.
+
+ "Received:" fields of messages originating from other environments
+ may not conform exactly to this specification. However, the most
+ important use of Received: lines is for debugging mail faults, and
+ this debugging can be severely hampered by well-meaning gateways that
+ try to "fix" a Received: line. As another consequence of trace
+ fields arising in non-SMTP environments, receiving systems MUST NOT
+ reject mail based on the format of a trace field and SHOULD be
+ extremely robust in the light of unexpected information or formats in
+ those fields.
+
+ The gateway SHOULD indicate the environment and protocol in the "via"
+ clauses of Received field(s) that it supplies.
+
+3.8.3 Addresses in Gatewaying
+
+ 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. Addresses and headers generated by gateways MUST
+ conform to applicable Internet standards (including this one and RFC
+ 822). Gateways are, of course, subject to the same rules for
+ handling source routes as those described for other SMTP systems in
+ section 3.3.
+
+
+
+
+
+Klensin Standards Track [Page 26]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+3.8.4 Other Header Fields in Gatewaying
+
+ The gateway MUST ensure that all header fields of a message that it
+ forwards into the Internet mail environment 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, MUST reference only fully-qualified domain names, and
+ MUST be effective and useful for sending replies. The translation
+ algorithm used to convert mail from the Internet protocols to another
+ environment's protocol SHOULD ensure that error messages from the
+ foreign mail environment are delivered to the return path from the
+ SMTP envelope, not to the sender listed in the "From:" field (or
+ other fields) of the RFC 822 message.
+
+3.8.5 Envelopes in Gatewaying
+
+ Similarly, when forwarding a message from another environment into
+ the Internet, the gateway SHOULD set the envelope return path in
+ accordance with an error message return address, if supplied by the
+ foreign environment. If the foreign environment has no equivalent
+ concept, the gateway must select and use a best approximation, with
+ the message originator's address as the default of last resort.
+
+3.9 Terminating Sessions and Connections
+
+ An SMTP connection is terminated when the client sends a QUIT
+ command. The server responds with a positive reply code, after which
+ it closes the connection.
+
+ An SMTP server MUST NOT intentionally close the connection except:
+
+ - After receiving a QUIT command and responding with a 221 reply.
+
+ - After detecting the need to shut down the SMTP service and
+ returning a 421 response code. This response code can be issued
+ after the server receives any command or, if necessary,
+ asynchronously from command receipt (on the assumption that the
+ client will receive it after the next command is issued).
+
+ In particular, a server that closes connections in response to
+ commands that are not understood is in violation of this
+ specification. Servers are expected to be tolerant of unknown
+ commands, issuing a 500 reply and awaiting further instructions from
+ the client.
+
+
+
+
+
+
+
+Klensin Standards Track [Page 27]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ An SMTP server which is forcibly shut down via external means SHOULD
+ attempt to send a line containing a 421 response code to the SMTP
+ client before exiting. The SMTP client will normally read the 421
+ response code after sending its next command.
+
+ SMTP clients that experience a connection close, reset, or other
+ communications failure due to circumstances not under their control
+ (in violation of the intent of this specification but sometimes
+ unavoidable) SHOULD, to maintain the robustness of the mail system,
+ treat the mail transaction as if a 451 response had been received and
+ act accordingly.
+
+3.10 Mailing Lists and Aliases
+
+ An SMTP-capable host SHOULD support both the alias and the list
+ models of address expansion for multiple delivery. When a message is
+ delivered or forwarded to each address of an expanded list form, the
+ return address in the envelope ("MAIL FROM:") MUST be changed to be
+ the address of a person or other entity who administers the list.
+ However, in this case, the message header [32] MUST be left
+ unchanged; in particular, the "From" field of the message header is
+ unaffected.
+
+ An important mail facility is a mechanism for multi-destination
+ delivery of a single message, by transforming (or "expanding" or
+ "exploding") a pseudo-mailbox address into a list of destination
+ mailbox addresses. When a message is sent to such a pseudo-mailbox
+ (sometimes called an "exploder"), copies are forwarded or
+ redistributed to each mailbox in the expanded list. Servers SHOULD
+ simply utilize the addresses on the list; application of heuristics
+ or other matching rules to eliminate some addresses, such as that of
+ the originator, is strongly discouraged. We classify such a pseudo-
+ mailbox as an "alias" or a "list", depending upon the expansion
+ rules.
+
+3.10.1 Alias
+
+ To expand an alias, the recipient mailer simply replaces the pseudo-
+ mailbox address in the envelope with each of the expanded addresses
+ in turn; the rest of the envelope and the message body are left
+ unchanged. The message is then delivered or forwarded to each
+ expanded address.
+
+3.10.2 List
+
+ A mailing list may be said to operate by "redistribution" rather than
+ by "forwarding". To expand a list, the recipient mailer replaces the
+ pseudo-mailbox address in the envelope with all of the expanded
+
+
+
+Klensin Standards Track [Page 28]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ addresses. The return address in the envelope is changed so that all
+ error messages generated by the final deliveries will be returned to
+ a list administrator, not to the message originator, who generally
+ has no control over the contents of the list and will typically find
+ error messages annoying.
+
+4. The SMTP Specifications
+
+4.1 SMTP Commands
+
+4.1.1 Command Semantics and Syntax
+
+ The SMTP commands define the mail transfer or the mail system
+ function requested by the user. SMTP commands are character strings
+ terminated by <CRLF>. The commands themselves are alphabetic
+ characters terminated by <SP> if parameters follow and <CRLF>
+ otherwise. (In the interest of improved interoperability, SMTP
+ receivers are encouraged to tolerate trailing white space before the
+ terminating <CRLF>.) The syntax of the local part of a mailbox must
+ conform to receiver site conventions and the syntax specified in
+ section 4.1.2. The SMTP commands are discussed below. The SMTP
+ replies are discussed in section 4.2.
+
+ A mail transaction involves several data objects which are
+ communicated as arguments to different commands. The reverse-path is
+ the argument of the MAIL command, the forward-path is the argument of
+ the RCPT command, and the mail data is the argument of the DATA
+ command. These arguments or data objects must be transmitted and
+ held pending the confirmation communicated by the end of mail data
+ indication which finalizes the transaction. The model for this is
+ that distinct buffers are provided to hold the types of data objects,
+ that is, there is a reverse-path buffer, a forward-path buffer, and a
+ mail data buffer. Specific commands cause information to be appended
+ to a specific buffer, or cause one or more buffers to be cleared.
+
+ Several commands (RSET, DATA, QUIT) are specified as not permitting
+ parameters. In the absence of specific extensions offered by the
+ server and accepted by the client, clients MUST NOT send such
+ parameters and servers SHOULD reject commands containing them as
+ having invalid syntax.
+
+4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
+
+ These commands are used to identify the SMTP client to the SMTP
+ server. The argument field contains the fully-qualified domain name
+ of the SMTP client if one is available. In situations in which the
+ SMTP client system does not have a meaningful domain name (e.g., when
+ its address is dynamically allocated and no reverse mapping record is
+
+
+
+Klensin Standards Track [Page 29]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ available), the client SHOULD send an address literal (see section
+ 4.1.3), optionally followed by information that will help to identify
+ the client system. y The SMTP server identifies itself to the SMTP
+ client in the connection greeting reply and in the response to this
+ command.
+
+ A client SMTP SHOULD start an SMTP session by issuing the EHLO
+ command. If the SMTP server supports the SMTP service extensions it
+ will give a successful response, a failure response, or an error
+ response. If the SMTP server, in violation of this specification,
+ does not support any SMTP service extensions it will generate an
+ error response. Older client SMTP systems MAY, as discussed above,
+ use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
+ support the HELO command and reply properly to it. In any event, a
+ client MUST issue HELO or EHLO before starting a mail transaction.
+
+ These commands, and a "250 OK" reply to one of them, confirm that
+ both the SMTP client and the SMTP server are in the initial state,
+ that is, there is no transaction in progress and all state tables and
+ buffers are cleared.
+
+ Syntax:
+
+ ehlo = "EHLO" SP Domain CRLF
+ helo = "HELO" SP Domain CRLF
+
+ Normally, the response to EHLO will be a multiline reply. Each line
+ of the response contains a keyword and, optionally, one or more
+ parameters. Following the normal syntax for multiline replies, these
+ keyworks follow the code (250) and a hyphen for all but the last
+ line, and the code and a space for the last line. The syntax for a
+ positive response, using the ABNF notation and terminal symbols of
+ [8], is:
+
+ ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
+ / ( "250-" domain [ SP ehlo-greet ] CRLF
+ *( "250-" ehlo-line CRLF )
+ "250" SP ehlo-line CRLF )
+
+ ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
+ ; string of any characters other than CR or LF
+
+ ehlo-line = ehlo-keyword *( SP ehlo-param )
+
+ ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+ ; additional syntax of ehlo-params depends on
+ ; ehlo-keyword
+
+
+
+
+Klensin Standards Track [Page 30]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ ehlo-param = 1*(%d33-127)
+ ; any CHAR excluding <SP> and all
+ ; control characters (US-ASCII 0-31 inclusive)
+
+ Although EHLO keywords may be specified in upper, lower, or mixed
+ case, they MUST always be recognized and processed in a case-
+ insensitive manner. This is simply an extension of practices
+ specified in RFC 821 and section 2.4.1.
+
+4.1.1.2 MAIL (MAIL)
+
+ This command is used to initiate a mail transaction in which the mail
+ data is delivered to an SMTP server which may, in turn, deliver it to
+ one or more mailboxes or pass it on to another system (possibly using
+ SMTP). The argument field contains a reverse-path and may contain
+ optional parameters. In general, the MAIL command may be sent only
+ when no mail transaction is in progress, see section 4.1.4.
+
+ The reverse-path consists of the sender mailbox. Historically, that
+ mailbox might optionally have been preceded by a list of hosts, but
+ that behavior is now deprecated (see appendix C). In some types of
+ reporting messages for which a reply is likely to cause a mail loop
+ (for example, mail delivery and nondelivery notifications), the
+ reverse-path may be null (see section 3.7).
+
+ This command clears the reverse-path buffer, the forward-path buffer,
+ and the mail data buffer; and inserts the reverse-path information
+ from this command into the reverse-path buffer.
+
+ If service extensions were negotiated, the MAIL command may also
+ carry parameters associated with a particular service extension.
+
+ Syntax:
+
+ "MAIL FROM:" ("<>" / Reverse-Path)
+ [SP Mail-parameters] CRLF
+
+4.1.1.3 RECIPIENT (RCPT)
+
+ This command is used to identify an individual recipient of the mail
+ data; multiple recipients are specified by multiple use of this
+ command. The argument field contains a forward-path and may contain
+ optional parameters.
+
+ The forward-path normally consists of the required destination
+ mailbox. Sending systems SHOULD not generate the optional list of
+ hosts known as a source route. Receiving systems MUST recognize
+
+
+
+
+Klensin Standards Track [Page 31]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ source route syntax but SHOULD strip off the source route
+ specification and utilize the domain name associated with the mailbox
+ as if the source route had not been provided.
+
+ Similarly, relay hosts SHOULD strip or ignore source routes, and
+ names MUST NOT be copied into the reverse-path. When mail reaches
+ its ultimate destination (the forward-path contains only a
+ destination mailbox), the SMTP server inserts it into the destination
+ mailbox in accordance with its host mail conventions.
+
+ For example, mail received at relay host xyz.com with envelope
+ commands
+
+ MAIL FROM:<userx@y.foo.org>
+ RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+ will normally be sent directly on to host d.bar.org with envelope
+ commands
+
+ MAIL FROM:<userx@y.foo.org>
+ RCPT TO:<userc@d.bar.org>
+
+ As provided in appendix C, xyz.com MAY also choose to relay the
+ message to hosta.int, using the envelope commands
+
+ MAIL FROM:<userx@y.foo.org>
+ RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+ or to jkl.org, using the envelope commands
+
+ MAIL FROM:<userx@y.foo.org>
+ RCPT TO:<@jkl.org:userc@d.bar.org>
+
+ Of course, since hosts are not required to relay mail at all, xyz.com
+ may also reject the message entirely when the RCPT command is
+ received, using a 550 code (since this is a "policy reason").
+
+ If service extensions were negotiated, the RCPT command may also
+ carry parameters associated with a particular service extension
+ offered by the server. The client MUST NOT transmit parameters other
+ than those associated with a service extension offered by the server
+ in its EHLO response.
+
+Syntax:
+ "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
+ [SP Rcpt-parameters] CRLF
+
+
+
+
+
+Klensin Standards Track [Page 32]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+4.1.1.4 DATA (DATA)
+
+ The receiver normally sends a 354 response to DATA, and then treats
+ the lines (strings ending in <CRLF> sequences, as described in
+ section 2.3.7) following the command as mail data from the sender.
+ This command causes the mail data to be appended to the mail data
+ buffer. The mail data may contain any of the 128 ASCII character
+ codes, although experience has indicated that use of control
+ characters other than SP, HT, CR, and LF may cause problems and
+ SHOULD be avoided when possible.
+
+ The mail data is terminated by a line containing only a period, that
+ is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This
+ is the end of mail data indication. Note that the first <CRLF> of
+ this terminating sequence is also the <CRLF> that ends the final line
+ of the data (message text) or, if there was no data, ends the DATA
+ command itself. An extra <CRLF> MUST NOT be added, as that would
+ cause an empty line to be added to the message. The only exception
+ to this rule would arise if the message body were passed to the
+ originating SMTP-sender with a final "line" that did not end in
+ <CRLF>; in that case, the originating SMTP system MUST either reject
+ the message as invalid or add <CRLF> in order to have the receiving
+ SMTP server recognize the "end of data" condition.
+
+ The custom of accepting lines ending only in <LF>, as a concession to
+ non-conforming behavior on the part of some UNIX systems, has proven
+ to cause more interoperability problems than it solves, and SMTP
+ server systems MUST NOT do this, even in the name of improved
+ robustness. In particular, the sequence "<LF>.<LF>" (bare line
+ feeds, without carriage returns) MUST NOT be treated as equivalent to
+ <CRLF>.<CRLF> as the end of mail data indication.
+
+ Receipt of the end of mail data indication requires the server to
+ process the stored mail transaction information. This processing
+ consumes the information in the reverse-path buffer, the forward-path
+ buffer, and the mail data buffer, and on the completion of this
+ command these buffers are cleared. If the processing is successful,
+ the receiver MUST send an OK reply. If the processing fails the
+ receiver MUST send a failure reply. The SMTP model does not allow
+ for partial failures at this point: either the message is accepted by
+ the server for delivery and a positive response is returned or it is
+ not accepted and a failure reply is returned. In sending a positive
+ completion reply to the end of data indication, the receiver takes
+ full responsibility for the message (see section 6.1). Errors that
+ are diagnosed subsequently MUST be reported in a mail message, as
+ discussed in section 4.4.
+
+
+
+
+
+Klensin Standards Track [Page 33]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ When the SMTP server accepts a message either for relaying or for
+ final delivery, it inserts a trace record (also referred to
+ interchangeably as a "time stamp line" or "Received" line) at the top
+ of the mail data. This trace record indicates the identity of the
+ host that sent the message, the identity of the host that received
+ the message (and is inserting this time stamp), and the date and time
+ the message was received. Relayed messages will have multiple time
+ stamp lines. Details for formation of these lines, including their
+ syntax, is specified in section 4.4.
+
+ Additional discussion about the operation of the DATA command appears
+ in section 3.3.
+
+ Syntax:
+ "DATA" CRLF
+
+4.1.1.5 RESET (RSET)
+
+ This command specifies that the current mail transaction will be
+ aborted. Any stored sender, recipients, and mail data MUST be
+ discarded, and all buffers and state tables cleared. The receiver
+ MUST send a "250 OK" reply to a RSET command with no arguments. A
+ reset command may be issued by the client at any time. It is
+ effectively equivalent to a NOOP (i.e., if has no effect) if issued
+ immediately after EHLO, before EHLO is issued in the session, after
+ an end-of-data indicator has been sent and acknowledged, or
+ immediately before a QUIT. An SMTP server MUST NOT close the
+ connection as the result of receiving a RSET; that action is reserved
+ for QUIT (see section 4.1.1.10).
+
+ Since EHLO implies some additional processing and response by the
+ server, RSET will normally be more efficient than reissuing that
+ command, even though the formal semantics are the same.
+
+ There are circumstances, contrary to the intent of this
+ specification, in which an SMTP server may receive an indication that
+ the underlying TCP connection has been closed or reset. To preserve
+ the robustness of the mail system, SMTP servers SHOULD be prepared
+ for this condition and SHOULD treat it as if a QUIT had been received
+ before the connection disappeared.
+
+ Syntax:
+ "RSET" CRLF
+
+
+
+
+
+
+
+
+Klensin Standards Track [Page 34]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+4.1.1.6 VERIFY (VRFY)
+
+ This command asks the receiver to confirm that the argument
+ identifies a user or mailbox. If it is a user name, information is
+ returned as specified in section 3.5.
+
+ This command has no effect on the reverse-path buffer, the forward-
+ path buffer, or the mail data buffer.
+
+ Syntax:
+ "VRFY" SP String CRLF
+
+4.1.1.7 EXPAND (EXPN)
+
+ This command asks the receiver to confirm that the argument
+ identifies a mailing list, and if so, to return the membership of
+ that list. If the command is successful, a reply is returned
+ containing information as described in section 3.5. This reply will
+ have multiple lines except in the trivial case of a one-member list.
+
+ This command has no effect on the reverse-path buffer, the forward-
+ path buffer, or the mail data buffer and may be issued at any time.
+
+ Syntax:
+ "EXPN" SP String CRLF
+
+4.1.1.8 HELP (HELP)
+
+ This command causes the server to send helpful information to the
+ client. The command MAY take an argument (e.g., any command name)
+ and return more specific information as a response.
+
+ This command has no effect on the reverse-path buffer, the forward-
+ path buffer, or the mail data buffer and may be issued at any time.
+
+ SMTP servers SHOULD support HELP without arguments and MAY support it
+ with arguments.
+
+ Syntax:
+ "HELP" [ SP String ] CRLF
+
+4.1.1.9 NOOP (NOOP)
+
+ This command does not affect any parameters or previously entered
+ commands. It specifies no action other than that the receiver send
+ an OK reply.
+
+
+
+
+
+Klensin Standards Track [Page 35]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ This command has no effect on the reverse-path buffer, the forward-
+ path buffer, or the mail data buffer and may be issued at any time.
+ If a parameter string is specified, servers SHOULD ignore it.
+
+ Syntax:
+ "NOOP" [ SP String ] CRLF
+
+4.1.1.10 QUIT (QUIT)
+
+ This command specifies that the receiver MUST send an OK reply, and
+ then close the transmission channel.
+
+ The receiver MUST NOT intentionally close the transmission channel
+ until it receives and replies to a QUIT command (even if there was an
+ error). The sender MUST NOT intentionally close the transmission
+ channel until it sends a QUIT command and SHOULD wait until it
+ receives the reply (even if there was an error response to a previous
+ command). If the connection is closed prematurely due to violations
+ of the above or system or network failure, the server MUST cancel any
+ pending transaction, but not undo any previously completed
+ transaction, and generally MUST act as if the command or transaction
+ in progress had received a temporary error (i.e., a 4yz response).
+
+ The QUIT command may be issued at any time.
+
+ Syntax:
+ "QUIT" CRLF
+
+4.1.2 Command Argument Syntax
+
+ The syntax of the argument fields of the above commands (using the
+ syntax specified in [8] where applicable) is given below. Some of
+ the productions given below are used only in conjunction with source
+ routes as described in appendix C. Terminals not defined in this
+ document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in
+ the "core" syntax [8 (section 6)] or in the message format syntax
+ [32].
+
+ Reverse-path = Path
+ Forward-path = Path
+ Path = "<" [ A-d-l ":" ] Mailbox ">"
+ A-d-l = At-domain *( "," A-d-l )
+ ; Note that this form, the so-called "source route",
+ ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
+ ; ignored.
+ At-domain = "@" domain
+ Mail-parameters = esmtp-param *(SP esmtp-param)
+ Rcpt-parameters = esmtp-param *(SP esmtp-param)
+
+
+
+Klensin Standards Track [Page 36]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ esmtp-param = esmtp-keyword ["=" esmtp-value]
+ esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+ esmtp-value = 1*(%d33-60 / %d62-127)
+ ; any CHAR excluding "=", SP, and control characters
+ Keyword = Ldh-str
+ Argument = Atom
+ Domain = (sub-domain 1*("." sub-domain)) / address-literal
+ sub-domain = Let-dig [Ldh-str]
+
+ address-literal = "[" IPv4-address-literal /
+ IPv6-address-literal /
+ General-address-literal "]"
+ ; See section 4.1.3
+
+ Mailbox = Local-part "@" Domain
+
+ Local-part = Dot-string / Quoted-string
+ ; MAY be case-sensitive
+
+ Dot-string = Atom *("." Atom)
+
+ Atom = 1*atext
+
+ Quoted-string = DQUOTE *qcontent DQUOTE
+
+ String = Atom / Quoted-string
+
+ While the above definition for Local-part is relatively permissive,
+ for maximum interoperability, a host that expects to receive mail
+ SHOULD avoid defining mailboxes where the Local-part requires (or
+ uses) the Quoted-string form or where the Local-part is case-
+ sensitive. For any purposes that require generating or comparing
+ Local-parts (e.g., to specific mailbox names), all quoted forms MUST
+ be treated as equivalent and the sending system SHOULD transmit the
+ form that uses the minimum quoting possible.
+
+ Systems MUST NOT define mailboxes in such a way as to require the use
+ in SMTP of non-ASCII characters (octets with the high order bit set
+ to one) or ASCII "control characters" (decimal value 0-31 and 127).
+ These characters MUST NOT be used in MAIL or RCPT commands or other
+ commands that require mailbox names.
+
+ Note that the backslash, "\", is a quote character, which is used to
+ indicate that the next character is to be used literally (instead of
+ its normal interpretation). For example, "Joe\,Smith" indicates a
+ single nine character user field with the comma being the fourth
+ character of the field.
+
+
+
+
+Klensin Standards Track [Page 37]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ To promote interoperability and consistent with long-standing
+ guidance about conservative use of the DNS in naming and applications
+ (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]),
+ characters outside the set of alphas, digits, and hyphen MUST NOT
+ appear in domain name labels for SMTP clients or servers. In
+ particular, the underscore character is not permitted. SMTP servers
+ that receive a command in which invalid character codes have been
+ employed, and for which there are no other reasons for rejection,
+ MUST reject that command with a 501 response.
+
+4.1.3 Address Literals
+
+ Sometimes a host is not known to the domain name system and
+ communication (and, in particular, communication to report and repair
+ the error) is blocked. To bypass this barrier a special literal form
+ of the address is allowed as an alternative to a domain name. For
+ IPv4 addresses, this form uses four small decimal integers separated
+ by dots and enclosed by brackets such as [123.255.37.2], which
+ indicates an (IPv4) Internet Address in sequence-of-octets form. For
+ IPv6 and other forms of addressing that might eventually be
+ standardized, the form consists of a standardized "tag" that
+ identifies the address syntax, a colon, and the address itself, in a
+ format specified as part of the IPv6 standards [17].
+
+ Specifically:
+
+ IPv4-address-literal = Snum 3("." Snum)
+ IPv6-address-literal = "IPv6:" IPv6-addr
+ General-address-literal = Standardized-tag ":" 1*dcontent
+ Standardized-tag = Ldh-str
+ ; MUST be specified in a standards-track RFC
+ ; and registered with IANA
+
+ Snum = 1*3DIGIT ; representing a decimal integer
+ ; value in the range 0 through 255
+ Let-dig = ALPHA / DIGIT
+ Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
+
+ IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
+ IPv6-hex = 1*4HEXDIG
+ IPv6-full = IPv6-hex 7(":" IPv6-hex)
+ IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
+ IPv6-hex)]
+ ; The "::" represents at least 2 16-bit groups of zeros
+ ; No more than 6 groups in addition to the "::" may be
+ ; present
+ IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
+ IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
+
+
+
+Klensin Standards Track [Page 38]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
+ ; The "::" represents at least 2 16-bit groups of zeros
+ ; No more than 4 groups in addition to the "::" and
+ ; IPv4-address-literal may be present
+
+4.1.4 Order of Commands
+
+ There are restrictions on the order in which these commands may be
+ used.
+
+ A session that will contain mail transactions MUST first be
+ initialized by the use of the EHLO command. An SMTP server SHOULD
+ accept commands for non-mail transactions (e.g., VRFY or EXPN)
+ without this initialization.
+
+ An EHLO command MAY be issued by a client later in the session. If
+ it is issued after the session begins, the SMTP server MUST clear all
+ buffers and reset the state exactly as if a RSET command had been
+ issued. In other words, the sequence of RSET followed immediately by
+ EHLO is redundant, but not harmful other than in the performance cost
+ of executing unnecessary commands.
+
+ If the EHLO command is not acceptable to the SMTP server, 501, 500,
+ or 502 failure replies MUST be returned as appropriate. The SMTP
+ server MUST stay in the same state after transmitting these replies
+ that it was in before the EHLO was received.
+
+ The SMTP client MUST, if possible, ensure that the domain parameter
+ to the EHLO command is a valid principal host name (not a CNAME or MX
+ name) for its host. If this is not possible (e.g., when the client's
+ address is dynamically assigned and the client does not have an
+ obvious name), an address literal SHOULD be substituted for the
+ domain name and supplemental information provided that will assist in
+ identifying the client.
+
+ An SMTP server MAY verify that the domain name parameter in the EHLO
+ command actually corresponds to the IP address of the client.
+ However, the server MUST NOT refuse to accept a message for this
+ reason if the verification fails: the information about verification
+ failure is for logging and tracing only.
+
+ The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
+ during a session, or without previously initializing a session. SMTP
+ servers SHOULD process these normally (that is, not return a 503
+ code) even if no EHLO command has yet been received; clients SHOULD
+ open a session with EHLO before sending these commands.
+
+
+
+
+
+Klensin Standards Track [Page 39]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ If these rules are followed, the example in RFC 821 that shows "550
+ access denied to you" in response to an EXPN command is incorrect
+ unless an EHLO command precedes the EXPN or the denial of access is
+ based on the client's IP address or other authentication or
+ authorization-determining mechanisms.
+
+ The MAIL command (or the obsolete SEND, SOML, or SAML commands)
+ begins a mail transaction. Once started, a mail transaction consists
+ of a transaction beginning command, one or more RCPT commands, and a
+ DATA command, in that order. A mail transaction may be aborted by
+ the RSET (or a new EHLO) command. There may be zero or more
+ transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be
+ sent if a mail transaction is already open, i.e., it should be sent
+ only if no mail transaction had been started in the session, or it
+ the previous one successfully concluded with a successful DATA
+ command, or if the previous one was aborted with a RSET.
+
+ If the transaction beginning command argument is not acceptable, a
+ 501 failure reply MUST be returned and the SMTP server MUST stay in
+ the same state. If the commands in a transaction are out of order to
+ the degree that they cannot be processed by the server, a 503 failure
+ reply MUST be returned and the SMTP server MUST stay in the same
+ state.
+
+ The last command in a session MUST be the QUIT command. The QUIT
+ command cannot be used at any other time in a session, but SHOULD be
+ used by the client SMTP to request connection closure, even when no
+ session opening command was sent and accepted.
+
+4.1.5 Private-use Commands
+
+ As specified in section 2.2.2, commands starting in "X" may be used
+ by bilateral agreement between the client (sending) and server
+ (receiving) SMTP agents. An SMTP server that does not recognize such
+ a command is expected to reply with "500 Command not recognized". An
+ extended SMTP server MAY list the feature names associated with these
+ private commands in the response to the EHLO command.
+
+ Commands sent or accepted by SMTP systems that do not start with "X"
+ MUST conform to the requirements of section 2.2.2.
+
+4.2 SMTP Replies
+
+ Replies to SMTP commands serve to ensure the synchronization of
+ requests and actions in the process of mail transfer and to guarantee
+ that the SMTP client always knows the state of the SMTP server.
+ Every command MUST generate exactly one reply.
+
+
+
+
+Klensin Standards Track [Page 40]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ The details of the command-reply sequence are described in section
+ 4.3.
+
+ An SMTP reply consists of a three digit number (transmitted as three
+ numeric characters) followed by some text unless specified otherwise
+ in this document. The number is for use by automata to determine
+ what state to enter next; the text is for the human user. The three
+ digits contain enough encoded information that the SMTP client need
+ not examine the text and may either discard it or pass it on to the
+ user, as appropriate. Exceptions are as noted elsewhere in this
+ document. In particular, the 220, 221, 251, 421, and 551 reply codes
+ are associated with message text that must be parsed and interpreted
+ by machines. In the general case, the text may be receiver dependent
+ and context dependent, so there are likely to be varying texts for
+ each reply code. A discussion of the theory of reply codes is given
+ in section 4.2.1. Formally, a reply is defined to be the sequence: a
+ three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
+ reply (as defined in section 4.2.1). Since, in violation of this
+ specification, the text is sometimes not sent, clients which do not
+ receive it SHOULD be prepared to process the code alone (with or
+ without a trailing space character). Only the EHLO, EXPN, and HELP
+ commands are expected to result in multiline replies in normal
+ circumstances, however, multiline replies are allowed for any
+ command.
+
+ In ABNF, server responses are:
+
+ Greeting = "220 " Domain [ SP text ] CRLF
+ Reply-line = Reply-code [ SP text ] CRLF
+
+ where "Greeting" appears only in the 220 response that announces that
+ the server is opening its part of the connection.
+
+ An SMTP server SHOULD send only the reply codes listed in this
+ document. An SMTP server SHOULD use the text shown in the examples
+ whenever appropriate.
+
+ An SMTP client MUST determine its actions only by the reply code, not
+ by the text (except for the "change of address" 251 and 551 and, if
+ necessary, 220, 221, and 421 replies); in the general case, any text,
+ including no text at all (although senders SHOULD NOT send bare
+ codes), MUST be acceptable. The space (blank) following the reply
+ code is considered part of the text. Whenever possible, a receiver-
+ SMTP SHOULD test the first digit (severity indication) of the reply
+ code.
+
+
+
+
+
+
+Klensin Standards Track [Page 41]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ The list of codes that appears below MUST NOT be construed as
+ permanent. While the addition of new codes should be a rare and
+ significant activity, with supplemental information in the textual
+ part of the response being preferred, new codes may be added as the
+ result of new Standards or Standards-track specifications.
+ Consequently, a sender-SMTP MUST be prepared to handle codes not
+ specified in this document and MUST do so by interpreting the first
+ digit only.
+
+4.2.1 Reply Code Severities and Theory
+
+ The three digits of the reply each have a special significance. The
+ first digit denotes whether the response is good, bad or incomplete.
+ An unsophisticated SMTP client, or one that receives an unexpected
+ code, will be able to determine its next action (proceed as planned,
+ redo, retrench, etc.) by examining this first digit. An SMTP client
+ that wants to know approximately what kind of error occurred (e.g.,
+ mail system error, command syntax error) may examine the second
+ digit. The third digit and any supplemental information that may be
+ present is reserved for the finest gradation of information.
+
+ There are five values for the first digit of the reply code:
+
+ 1yz Positive Preliminary reply
+ The command has been accepted, but the requested action is being
+ held in abeyance, pending confirmation of the information in this
+ reply. The SMTP client should send another command specifying
+ whether to continue or abort the action. Note: unextended SMTP
+ does not have any commands that allow this type of reply, and so
+ does not have continue or abort commands.
+
+ 2yz Positive Completion reply
+ The requested action has been successfully completed. A new
+ request may be initiated.
+
+ 3yz Positive Intermediate reply
+ The command has been accepted, but the requested action is being
+ held in abeyance, pending receipt of further information. The
+ SMTP client should send another command specifying this
+ information. This reply is used in command sequence groups (i.e.,
+ in DATA).
+
+ 4yz Transient Negative Completion reply
+ The command was not accepted, and the requested action did not
+ occur. However, the error condition is temporary and the action
+ may be requested again. The sender should return to the beginning
+ of the command sequence (if any). It is difficult to assign a
+ meaning to "transient" when two different sites (receiver- and
+
+
+
+Klensin Standards Track [Page 42]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ sender-SMTP agents) must agree on the interpretation. Each reply
+ in this category might have a different time value, but the SMTP
+ client is encouraged to try again. A rule of thumb to determine
+ whether a reply fits into the 4yz or the 5yz category (see below)
+ is that replies are 4yz if they can be successful if repeated
+ without any change in command form or in properties of the sender
+ or receiver (that is, the command is repeated identically and the
+ receiver does not put up a new implementation.)
+
+ 5yz Permanent Negative Completion reply
+ The command was not accepted and the requested action did not
+ occur. The SMTP client is discouraged from repeating the exact
+ request (in the same sequence). Even some "permanent" error
+ conditions can be corrected, so the human user may want to direct
+ the SMTP client to reinitiate the command sequence by direct
+ action at some point in the future (e.g., after the spelling has
+ been changed, or the user has altered the account status).
+
+ The second digit encodes responses in specific categories:
+
+ x0z Syntax: These replies refer to syntax errors, syntactically
+ correct commands that do not fit any functional category, and
+ unimplemented or superfluous commands.
+
+ x1z Information: These are replies to requests for information,
+ such as status or help.
+
+ x2z Connections: These are replies referring to the transmission
+ channel.
+
+ x3z Unspecified.
+
+ x4z Unspecified.
+
+ x5z Mail system: These replies indicate the status of the receiver
+ mail system vis-a-vis the requested transfer or other mail system
+ action.
+
+ The third digit gives a finer gradation of meaning in each category
+ specified by the second digit. The list of replies illustrates this.
+ Each reply text is recommended rather than mandatory, and may even
+ change according to the command with which it is associated. On the
+ other hand, the reply codes must strictly follow the specifications
+ in this section. Receiver implementations should not invent new
+ codes for slightly different situations from the ones described here,
+ but rather adapt codes already defined.
+
+
+
+
+
+Klensin Standards Track [Page 43]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ For example, a command such as NOOP, whose successful execution does
+ not offer the SMTP client any new information, will return a 250
+ reply. The reply is 502 when the command requests an unimplemented
+ non-site-specific action. A refinement of that is the 504 reply for
+ a command that is implemented, but that requests an unimplemented
+ parameter.
+
+ The reply text may be longer than a single line; in these cases the
+ complete text must be marked so the SMTP client knows when it can
+ stop reading the reply. This requires a special format to indicate a
+ multiple line reply.
+
+ The format for multiline replies requires that every line, except the
+ last, begin with the reply code, followed immediately by a hyphen,
+ "-" (also known as minus), followed by text. The last line will
+ begin with the reply code, followed immediately by <SP>, optionally
+ some text, and <CRLF>. As noted above, servers SHOULD send the <SP>
+ if subsequent text is not sent, but clients MUST be prepared for it
+ to be omitted.
+
+ For example:
+
+ 123-First line
+ 123-Second line
+ 123-234 text beginning with numbers
+ 123 The last line
+
+ In many cases the SMTP client then simply needs to search for a line
+ beginning with the reply code followed by <SP> or <CRLF> and ignore
+ all preceding lines. In a few cases, there is important data for the
+ client in the reply "text". The client will be able to identify
+ these cases from the current context.
+
+4.2.2 Reply Codes by Function Groups
+
+ 500 Syntax error, command unrecognized
+ (This may include errors such as command line too long)
+ 501 Syntax error in parameters or arguments
+ 502 Command not implemented (see section 4.2.4)
+ 503 Bad sequence of commands
+ 504 Command parameter not implemented
+
+ 211 System status, or system help reply
+ 214 Help message
+ (Information on how to use the receiver or the meaning of a
+ particular non-standard command; this reply is useful only
+ to the human user)
+
+
+
+
+Klensin Standards Track [Page 44]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ 220 <domain> Service ready
+ 221 <domain> Service closing transmission channel
+ 421 <domain> Service not available, closing transmission channel
+ (This may be a reply to any command if the service knows it
+ must shut down)
+
+ 250 Requested mail action okay, completed
+ 251 User not local; will forward to <forward-path>
+ (See section 3.4)
+ 252 Cannot VRFY user, but will accept message and attempt
+ delivery
+ (See section 3.5.3)
+ 450 Requested mail action not taken: mailbox unavailable
+ (e.g., mailbox busy)
+ 550 Requested action not taken: mailbox unavailable
+ (e.g., mailbox not found, no access, or command rejected
+ for policy reasons)
+ 451 Requested action aborted: error in processing
+ 551 User not local; please try <forward-path>
+ (See section 3.4)
+ 452 Requested action not taken: insufficient system storage
+ 552 Requested mail action aborted: exceeded storage allocation
+ 553 Requested action not taken: mailbox name not allowed
+ (e.g., mailbox syntax incorrect)
+ 354 Start mail input; end with <CRLF>.<CRLF>
+ 554 Transaction failed (Or, in the case of a connection-opening
+ response, "No SMTP service here")
+
+4.2.3 Reply Codes in Numeric Order
+
+ 211 System status, or system help reply
+ 214 Help message
+ (Information on how to use the receiver or the meaning of a
+ particular non-standard command; this reply is useful only
+ to the human user)
+ 220 <domain> Service ready
+ 221 <domain> Service closing transmission channel
+ 250 Requested mail action okay, completed
+ 251 User not local; will forward to <forward-path>
+ (See section 3.4)
+ 252 Cannot VRFY user, but will accept message and attempt
+ delivery
+ (See section 3.5.3)
+
+ 354 Start mail input; end with <CRLF>.<CRLF>
+
+
+
+
+
+
+Klensin Standards Track [Page 45]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ 421 <domain> Service not available, closing transmission channel
+ (This may be a reply to any command if the service knows it
+ must shut down)
+ 450 Requested mail action not taken: mailbox unavailable
+ (e.g., mailbox busy)
+ 451 Requested action aborted: local error in processing
+ 452 Requested action not taken: insufficient system storage
+ 500 Syntax error, command unrecognized
+ (This may include errors such as command line too long)
+ 501 Syntax error in parameters or arguments
+ 502 Command not implemented (see section 4.2.4)
+ 503 Bad sequence of commands
+ 504 Command parameter not implemented
+ 550 Requested action not taken: mailbox unavailable
+ (e.g., mailbox not found, no access, or command rejected
+ for policy reasons)
+ 551 User not local; please try <forward-path>
+ (See section 3.4)
+ 552 Requested mail action aborted: exceeded storage allocation
+ 553 Requested action not taken: mailbox name not allowed
+ (e.g., mailbox syntax incorrect)
+ 554 Transaction failed (Or, in the case of a connection-opening
+ response, "No SMTP service here")
+
+4.2.4 Reply Code 502
+
+ Questions have been raised as to when reply code 502 (Command not
+ implemented) SHOULD be returned in preference to other codes. 502
+ SHOULD be used when the command is actually recognized by the SMTP
+ server, but not implemented. If the command is not recognized, code
+ 500 SHOULD be returned. Extended SMTP systems MUST NOT list
+ capabilities in response to EHLO for which they will return 502 (or
+ 500) replies.
+
+4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
+
+ When an SMTP server returns a positive completion status (2yz code)
+ after the DATA command is completed with <CRLF>.<CRLF>, it accepts
+ responsibility for:
+
+ - delivering the message (if the recipient mailbox exists), or
+
+ - if attempts to deliver the message fail due to transient
+ conditions, retrying delivery some reasonable number of times at
+ intervals as specified in section 4.5.4.
+
+
+
+
+
+
+Klensin Standards Track [Page 46]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ - if attempts to deliver the message fail due to permanent
+ conditions, or if repeated attempts to deliver the message fail
+ due to transient conditions, returning appropriate notification to
+ the sender of the original message (using the address in the SMTP
+ MAIL command).
+
+ When an SMTP server returns a permanent error status (5yz) code after
+ the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
+ any subsequent attempt to deliver that message. The SMTP client
+ retains responsibility for delivery of that message and may either
+ return it to the user or requeue it for a subsequent attempt (see
+ section 4.5.4.1).
+
+ The user who originated the message SHOULD be able to interpret the
+ return of a transient failure status (by mail message or otherwise)
+ as a non-delivery indication, just as a permanent failure would be
+ interpreted. I.e., if the client SMTP successfully handles these
+ conditions, the user will not receive such a reply.
+
+ When an SMTP server returns a permanent error status (5yz) code after
+ the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
+ any subsequent attempt to deliver the message. As with temporary
+ error status codes, the SMTP client retains responsibility for the
+ message, but SHOULD not again attempt delivery to the same server
+ without user review and intervention of the message.
+
+4.3 Sequencing of Commands and Replies
+
+4.3.1 Sequencing Overview
+
+ The communication between the sender and receiver is an alternating
+ dialogue, controlled by the sender. As such, the sender issues a
+ command and the receiver responds with a reply. Unless other
+ arrangements are negotiated through service extensions, the sender
+ MUST wait for this response before sending further commands.
+
+ One important reply is the connection greeting. Normally, a receiver
+ will send a 220 "Service ready" reply when the connection is
+ completed. The sender SHOULD wait for this greeting message before
+ sending any commands.
+
+ Note: all the greeting-type replies have the official name (the
+ fully-qualified primary domain name) of the server host as the first
+ word following the reply code. Sometimes the host will have no
+ meaningful name. See 4.1.3 for a discussion of alternatives in these
+ situations.
+
+
+
+
+
+Klensin Standards Track [Page 47]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ For example,
+
+ 220 ISIF.USC.EDU Service ready
+ or
+ 220 mail.foo.com SuperSMTP v 6.1.2 Service ready
+ or
+ 220 [10.0.0.1] Clueless host service ready
+
+ The table below lists alternative success and failure replies for
+ each command. These SHOULD be strictly adhered to: a receiver may
+ substitute text in the replies, but the meaning and action implied by
+ the code numbers and by the specific command reply sequence cannot be
+ altered.
+
+4.3.2 Command-Reply Sequences
+
+ Each command is listed with its usual possible replies. The prefixes
+ used before the possible replies are "I" for intermediate, "S" for
+ success, and "E" for error. Since some servers may generate other
+ replies under special circumstances, and to allow for future
+ extension, SMTP clients SHOULD, when possible, interpret only the
+ first digit of the reply and MUST be prepared to deal with
+ unrecognized reply codes by interpreting the first digit only.
+ Unless extended using the mechanisms described in section 2.2, SMTP
+ servers MUST NOT transmit reply codes to an SMTP client that are
+ other than three digits or that do not start in a digit between 2 and
+ 5 inclusive.
+
+ These sequencing rules and, in principle, the codes themselves, can
+ be extended or modified by SMTP extensions offered by the server and
+ accepted (requested) by the client.
+
+ In addition to the codes listed below, any SMTP command can return
+ any of the following codes if the corresponding unusual circumstances
+ are encountered:
+
+ 500 For the "command line too long" case or if the command name was
+ not recognized. Note that producing a "command not recognized"
+ error in response to the required subset of these commands is a
+ violation of this specification.
+
+ 501 Syntax error in command or arguments. In order to provide for
+ future extensions, commands that are specified in this document as
+ not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
+ message if arguments are supplied in the absence of EHLO-
+ advertised extensions.
+
+ 421 Service shutting down and closing transmission channel
+
+
+
+Klensin Standards Track [Page 48]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ Specific sequences are:
+
+ CONNECTION ESTABLISHMENT
+ S: 220
+ E: 554
+ EHLO or HELO
+ S: 250
+ E: 504, 550
+ MAIL
+ S: 250
+ E: 552, 451, 452, 550, 553, 503
+ RCPT
+ S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
+ E: 550, 551, 552, 553, 450, 451, 452, 503, 550
+ DATA
+ I: 354 -> data -> S: 250
+ E: 552, 554, 451, 452
+ E: 451, 554, 503
+ RSET
+ S: 250
+ VRFY
+ S: 250, 251, 252
+ E: 550, 551, 553, 502, 504
+ EXPN
+ S: 250, 252
+ E: 550, 500, 502, 504
+ HELP
+ S: 211, 214
+ E: 502, 504
+ NOOP
+ S: 250
+ QUIT
+ S: 221
+
+4.4 Trace Information
+
+ When an SMTP server receives a message for delivery or further
+ processing, it MUST insert trace ("time stamp" or "Received")
+ information at the beginning of the message content, as discussed in
+ section 4.1.1.4.
+
+ This line MUST be structured as follows:
+
+ - The FROM field, which MUST be supplied in an SMTP environment,
+ SHOULD contain both (1) the name of the source host as presented
+ in the EHLO command and (2) an address literal containing the IP
+ address of the source, determined from the TCP connection.
+
+
+
+
+Klensin Standards Track [Page 49]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ - 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. This may raise some security
+ issues and is usually not desirable; see section 7.2.
+
+ An Internet mail program MUST NOT change a Received: line that was
+ previously added to the message header. SMTP servers MUST prepend
+ Received lines to messages; they MUST NOT change the order of
+ existing lines or insert Received lines in any other location.
+
+ As the Internet grows, comparability of Received fields is important
+ for detecting problems, especially slow relays. SMTP servers that
+ create Received fields SHOULD use explicit offsets in the dates
+ (e.g., -0800), rather than time zone names of any type. Local time
+ (with an offset) is preferred to UT when feasible. This formulation
+ allows slightly more information about local circumstances to be
+ specified. If UT is needed, the receiver need merely do some simple
+ arithmetic to convert the values. Use of UT loses information about
+ the time zone-location of the server. If it is desired to supply a
+ time zone name, it SHOULD be included in a comment.
+
+ When the delivery SMTP server makes the "final delivery" of a
+ message, it inserts a return-path line at the beginning of the mail
+ data. This use of return-path is required; mail systems MUST support
+ it. The return-path line preserves the information in the <reverse-
+ path> from the MAIL command. Here, final delivery means the message
+ has left the SMTP environment. Normally, this would mean it had been
+ delivered to the destination user or an associated mail drop, but in
+ some cases it may be further processed and transmitted by another
+ mail system.
+
+ It is possible for the mailbox in the return path to be different
+ from the actual sender's mailbox, for example, if error responses are
+ to be delivered to a special error handling mailbox rather than to
+ the message sender. When mailing lists are involved, this
+ arrangement is common and useful as a means of directing errors to
+ the list maintainer rather than the message originator.
+
+ The text above implies that the final mail data will begin with a
+ return path line, followed by one or more time stamp lines. These
+ lines will be followed by the mail data headers and body [32].
+
+ It is sometimes difficult for an SMTP server to determine whether or
+ not it is making final delivery since forwarding or other operations
+ may occur after the message is accepted for delivery. Consequently,
+
+
+
+
+Klensin Standards Track [Page 50]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ any further (forwarding, gateway, or relay) systems MAY remove the
+ return path and rebuild the MAIL command as needed to ensure that
+ exactly one such line appears in a delivered message.
+
+ A message-originating SMTP system SHOULD NOT send a message that
+ already contains a Return-path header. SMTP servers performing a
+ relay function MUST NOT inspect the message data, and especially not
+ to the extent needed to determine if Return-path headers are present.
+ SMTP servers making final delivery MAY remove Return-path headers
+ before adding their own.
+
+ The primary purpose of the Return-path is to designate the address to
+ which messages indicating non-delivery or other mail system failures
+ are to be sent. For this to be unambiguous, exactly one return path
+ SHOULD be present when the message is delivered. Systems using RFC
+ 822 syntax with non-SMTP transports SHOULD designate an unambiguous
+ address, associated with the transport envelope, to which error
+ reports (e.g., non-delivery messages) should be sent.
+
+ Historical note: Text in RFC 822 that appears to contradict the use
+ of the Return-path header (or the envelope reverse path address from
+ the MAIL command) as the destination for error messages is not
+ applicable on the Internet. The reverse path address (as copied into
+ the Return-path) MUST be used as the target of any mail containing
+ delivery error messages.
+
+ In particular:
+
+ - a gateway from SMTP->elsewhere SHOULD insert a return-path header,
+ unless it is known that the "elsewhere" transport also uses
+ Internet domain addresses and maintains the envelope sender
+ address separately.
+
+ - a gateway from elsewhere->SMTP SHOULD delete any return-path
+ header present in the message, and either copy that information to
+ the SMTP envelope or combine it with information present in the
+ envelope of the other transport system to construct the reverse
+ path argument to the MAIL command in the SMTP envelope.
+
+ The server must give special treatment to cases in which the
+ processing following the end of mail data indication is only
+ partially successful. This could happen if, after accepting several
+ recipients and the mail data, the SMTP server finds that the mail
+ data could be successfully delivered to some, but not all, of the
+ recipients. In such cases, the response to the DATA command MUST be
+ an OK reply. However, the SMTP server MUST compose and send an
+ "undeliverable mail" notification message to the originator of the
+ message.
+
+
+
+Klensin Standards Track [Page 51]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ A single notification listing all of the failed recipients or
+ separate notification messages MUST be sent for each failed
+ recipient. For economy of processing by the sender, the former is
+ preferred when possible. All undeliverable mail notification
+ messages are sent using the MAIL command (even if they result from
+ processing the obsolete SEND, SOML, or SAML commands) and use a null
+ return path as discussed in section 3.7.
+
+ The time stamp line and the return path line are formally defined as
+ follows:
+
+Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
+
+Time-stamp-line = "Received:" FWS Stamp <CRLF>
+
+Stamp = From-domain By-domain Opt-info ";" FWS date-time
+
+ ; where "date-time" is as defined in [32]
+ ; but the "obs-" forms, especially two-digit
+ ; years, are prohibited in SMTP and MUST NOT be used.
+
+From-domain = "FROM" FWS Extended-Domain CFWS
+
+By-domain = "BY" FWS Extended-Domain CFWS
+
+Extended-Domain = Domain /
+ ( Domain FWS "(" TCP-info ")" ) /
+ ( Address-literal FWS "(" TCP-info ")" )
+
+TCP-info = Address-literal / ( Domain FWS Address-literal )
+ ; Information derived by server from TCP connection
+ ; not client EHLO.
+
+Opt-info = [Via] [With] [ID] [For]
+
+Via = "VIA" FWS Link CFWS
+
+With = "WITH" FWS Protocol CFWS
+
+ID = "ID" FWS String / msg-id CFWS
+
+For = "FOR" FWS 1*( Path / Mailbox ) CFWS
+
+Link = "TCP" / Addtl-Link
+Addtl-Link = Atom
+ ; Additional standard names for links are registered with the
+ ; Internet Assigned Numbers Authority (IANA). "Via" is
+ ; primarily of value with non-Internet transports. SMTP
+
+
+
+Klensin Standards Track [Page 52]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ ; servers SHOULD NOT use unregistered names.
+Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+Attdl-Protocol = Atom
+ ; Additional standard names for protocols are registered with the
+ ; Internet Assigned Numbers Authority (IANA). SMTP servers
+ ; SHOULD NOT use unregistered names.
+
+4.5 Additional Implementation Issues
+
+4.5.1 Minimum Implementation
+
+ In order to make SMTP workable, the following minimum implementation
+ is required for all receivers. The following commands MUST be
+ supported to conform to this specification:
+
+ EHLO
+ HELO
+ MAIL
+ RCPT
+ DATA
+ RSET
+ NOOP
+ QUIT
+ VRFY
+
+ Any system that includes an SMTP server supporting mail relaying or
+ delivery MUST support the reserved mailbox "postmaster" as a case-
+ insensitive local name. This postmaster address is not strictly
+ necessary if the server always returns 554 on connection opening (as
+ described in section 3.1). The requirement to accept mail for
+ postmaster implies that RCPT commands which specify a mailbox for
+ postmaster at any of the domains for which the SMTP server provides
+ mail service, as well as the special case of "RCPT TO:<Postmaster>"
+ (with no domain specification), MUST be supported.
+
+ SMTP systems are expected to make every reasonable effort to accept
+ mail directed to Postmaster from any other system on the Internet.
+ In extreme cases --such as to contain a denial of service attack or
+ other breach of security-- an SMTP server may block mail directed to
+ Postmaster. However, such arrangements SHOULD be narrowly tailored
+ so as to avoid blocking messages which are not part of such attacks.
+
+4.5.2 Transparency
+
+ Without some provision for data transparency, the character sequence
+ "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
+ In general, users are not aware of such "forbidden" sequences. To
+
+
+
+
+Klensin Standards Track [Page 53]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ allow all user composed text to be transmitted transparently, the
+ following procedures are used:
+
+ - Before sending a line of mail text, the SMTP client checks the
+ first character of the line. If it is a period, one additional
+ period is inserted at the beginning of the line.
+
+ - When a line of mail text is received by the SMTP server, it checks
+ the line. If the line is composed of a single period, it is
+ treated as the end of mail indicator. If the first character is a
+ period and there are other characters on the line, the first
+ character is deleted.
+
+ The mail data may contain any of the 128 ASCII characters. All
+ characters are to be delivered to the recipient's mailbox, including
+ spaces, vertical and horizontal tabs, and other control characters.
+ If the transmission channel provides an 8-bit byte (octet) data
+ stream, the 7-bit ASCII codes are transmitted right justified in the
+ octets, with the high order bits cleared to zero. See 3.7 for
+ special treatment of these conditions in SMTP systems serving a relay
+ function.
+
+ In some systems it may be necessary to transform the data as it is
+ received and stored. This may be necessary for hosts that use a
+ different character set than ASCII as their local character set, that
+ store data in records rather than strings, or which use special
+ character sequences as delimiters inside mailboxes. If such
+ transformations are necessary, they MUST be reversible, especially if
+ they are applied to mail being relayed.
+
+4.5.3 Sizes and Timeouts
+
+4.5.3.1 Size limits and minimums
+
+ There are several objects that have required minimum/maximum sizes.
+ Every implementation MUST be able to receive objects of at least
+ these sizes. Objects larger than these sizes SHOULD be avoided when
+ possible. However, some Internet mail constructs such as encoded
+ X.400 addresses [16] will often require larger objects: clients MAY
+ attempt to transmit these, but MUST be prepared for a server to
+ reject them if they cannot be handled by it. To the maximum extent
+ possible, implementation techniques which impose no limits on the
+ length of these objects should be used.
+
+ local-part
+ The maximum total length of a user name or other local-part is 64
+ characters.
+
+
+
+
+Klensin Standards Track [Page 54]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ domain
+ The maximum total length of a domain name or number is 255
+ characters.
+
+ path
+ The maximum total length of a reverse-path or forward-path is 256
+ characters (including the punctuation and element separators).
+
+ command line
+ The maximum total length of a command line including the command
+ word and the <CRLF> is 512 characters. SMTP extensions may be
+ used to increase this limit.
+
+ reply line
+ The maximum total length of a reply line including the reply code
+ and the <CRLF> is 512 characters. More information may be
+ conveyed through multiple-line replies.
+
+ text line
+ The maximum total length of a text line including the <CRLF> is
+ 1000 characters (not counting the leading dot duplicated for
+ transparency). This number may be increased by the use of SMTP
+ Service Extensions.
+
+ message content
+ The maximum total length of a message content (including any
+ message headers as well as the message body) MUST BE at least 64K
+ octets. Since the introduction of Internet standards for
+ multimedia mail [12], message lengths on the Internet have grown
+ dramatically, and message size restrictions should be avoided if
+ at all possible. SMTP server systems that must impose
+ restrictions SHOULD implement the "SIZE" service extension [18],
+ and SMTP client systems that will send large messages SHOULD
+ utilize it when possible.
+
+ recipients buffer
+ The minimum total number of recipients that must be buffered is
+ 100 recipients. Rejection of messages (for excessive recipients)
+ with fewer than 100 RCPT commands is a violation of this
+ specification. The general principle that relaying SMTP servers
+ MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
+ tests on message headers suggests that rejecting a message based
+ on the total number of recipients shown in header fields is to be
+ discouraged. A server which imposes a limit on the number of
+ recipients MUST behave in an orderly fashion, such as to reject
+ additional addresses over its limit rather than silently
+ discarding addresses previously accepted. A client that needs to
+
+
+
+
+Klensin Standards Track [Page 55]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ deliver a message containing over 100 RCPT commands SHOULD be
+ prepared to transmit in 100-recipient "chunks" if the server
+ declines to accept more than 100 recipients in a single message.
+
+ Errors due to exceeding these limits may be reported by using the
+ reply codes. Some examples of reply codes are:
+
+ 500 Line too long.
+ or
+ 501 Path too long
+ or
+ 452 Too many recipients (see below)
+ or
+ 552 Too much mail data.
+
+ RFC 821 [30] incorrectly listed the error where an SMTP server
+ exhausts its implementation limit on the number of RCPT commands
+ ("too many recipients") as having reply code 552. The correct reply
+ code for this condition is 452. Clients SHOULD treat a 552 code in
+ this case as a temporary, rather than permanent, failure so the logic
+ below works.
+
+ When a conforming SMTP server encounters this condition, it has at
+ least 100 successful RCPT commands in its recipients buffer. If the
+ server is able to accept the message, then at least these 100
+ addresses will be removed from the SMTP client's queue. When the
+ client attempts retransmission of those addresses which received 452
+ responses, at least 100 of these will be able to fit in the SMTP
+ server's recipients buffer. Each retransmission attempt which is
+ able to deliver anything will be able to dispose of at least 100 of
+ these recipients.
+
+ If an SMTP server has an implementation limit on the number of RCPT
+ commands and this limit is exhausted, it MUST use a response code of
+ 452 (but the client SHOULD also be prepared for a 552, as noted
+ above). If the server has a configured site-policy limitation on the
+ number of RCPT commands, it MAY instead use a 5XX response code.
+ This would be most appropriate if the policy limitation was intended
+ to apply if the total recipient count for a particular message body
+ were enforced even if that message body was sent in multiple mail
+ transactions.
+
+4.5.3.2 Timeouts
+
+ An SMTP client MUST provide a timeout mechanism. It MUST use per-
+ command timeouts rather than somehow trying to time the entire mail
+ transaction. Timeouts SHOULD be easily reconfigurable, preferably
+ without recompiling the SMTP code. To implement this, a timer is set
+
+
+
+Klensin Standards Track [Page 56]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ for each SMTP command and for each buffer of the data transfer. The
+ latter means that the overall timeout is inherently proportional to
+ the size of the message.
+
+ Based on extensive experience with busy mail-relay hosts, the minimum
+ per-command timeout values SHOULD be as follows:
+
+ Initial 220 Message: 5 minutes
+ An SMTP client process needs to distinguish between a failed TCP
+ connection and a delay in receiving the initial 220 greeting
+ message. Many SMTP servers accept a TCP connection but delay
+ delivery of the 220 message until their system load permits more
+ mail to be processed.
+
+ MAIL Command: 5 minutes
+
+ RCPT Command: 5 minutes
+ A longer timeout is required if processing of mailing lists and
+ aliases is 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
+ performs processing to deliver the message to a user mailbox. A
+ spurious timeout at this point would be very wasteful and would
+ typically result in delivery of multiple copies of the message,
+ since it has been successfully sent and the server has accepted
+ responsibility for delivery. See section 6.1 for additional
+ discussion.
+
+ An SMTP server SHOULD have a timeout of at least 5 minutes while it
+ is awaiting the next command from the sender.
+
+4.5.4 Retry Strategies
+
+ The common structure of a host SMTP implementation includes user
+ mailboxes, one or more areas for queuing messages in transit, and one
+ or more daemon processes for sending and receiving mail. The exact
+ structure will vary depending on the needs of the users on the host
+
+
+
+
+Klensin Standards Track [Page 57]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ and the number and size of mailing lists supported by the host. We
+ describe several optimizations that have proved helpful, particularly
+ for mailers supporting high traffic levels.
+
+ Any queuing strategy MUST include timeouts on all activities on a
+ per-command basis. A queuing strategy MUST NOT send error messages
+ in response to error messages under any circumstances.
+
+4.5.4.1 Sending Strategy
+
+ The general model for an SMTP client is one or more processes that
+ periodically attempt to transmit outgoing mail. In a typical system,
+ the program that composes a message has some method for requesting
+ immediate attention for a new piece of outgoing mail, while mail that
+ cannot be transmitted immediately MUST be queued and periodically
+ retried by the sender. A mail queue entry will include not only the
+ message itself but also the envelope information.
+
+ The sender MUST delay retrying a particular destination after one
+ attempt has failed. In general, the retry interval SHOULD be at
+ least 30 minutes; however, more sophisticated and variable strategies
+ will be beneficial when the SMTP client can determine the reason for
+ non-delivery.
+
+ Retries continue until the message is transmitted or the sender gives
+ up; the give-up time generally needs to be at least 4-5 days. The
+ parameters to the retry algorithm MUST be configurable.
+
+ A client SHOULD keep a list of hosts it cannot reach and
+ corresponding connection timeouts, rather than just retrying queued
+ mail items.
+
+ Experience suggests that failures are typically transient (the target
+ system or its connection has crashed), favoring a policy of two
+ connection attempts in the first hour the message is in the queue,
+ and then backing off to one every two or three hours.
+
+ The SMTP client can shorten the queuing delay in cooperation with the
+ SMTP server. For example, if mail is received from a particular
+ address, it is likely that mail queued for that host can now be sent.
+ Application of this principle may, in many cases, eliminate the
+ requirement for an explicit "send queues now" function such as ETRN
+ [9].
+
+ The strategy may be further modified as a result of multiple
+ addresses per host (see below) to optimize delivery time vs. resource
+ usage.
+
+
+
+
+Klensin Standards Track [Page 58]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ An SMTP client may have a large queue of messages for each
+ unavailable destination host. If all of these messages were retried
+ in every retry cycle, there would be excessive Internet overhead and
+ the sending system would be blocked for a long period. Note that an
+ SMTP client can generally determine that a delivery attempt has
+ failed only after a timeout of several minutes and even a one-minute
+ timeout per connection will result in a very large delay if retries
+ are repeated for dozens, or even hundreds, of queued messages to the
+ same host.
+
+ At the same time, SMTP clients SHOULD use great care in caching
+ negative responses from servers. In an extreme case, if EHLO is
+ issued multiple times during the same SMTP connection, different
+ answers may be returned by the server. More significantly, 5yz
+ responses to the MAIL command MUST NOT be cached.
+
+ When a mail message is to be delivered to multiple recipients, and
+ the SMTP server to which a copy of the message is to be sent is the
+ same for multiple recipients, then only one copy of the message
+ SHOULD be transmitted. That is, the SMTP client SHOULD use the
+ command sequence: MAIL, RCPT, RCPT,... RCPT, DATA instead of the
+ sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there
+ are very many addresses, a limit on the number of RCPT commands per
+ MAIL command MAY be imposed. Implementation of this efficiency
+ feature is strongly encouraged.
+
+ Similarly, to achieve timely delivery, the SMTP client MAY support
+ multiple concurrent outgoing mail transactions. However, some limit
+ may be appropriate to protect the host from devoting all its
+ resources to mail.
+
+4.5.4.2 Receiving Strategy
+
+ The SMTP server SHOULD attempt to keep a pending listen on the SMTP
+ port at all times. This requires the support of multiple incoming
+ TCP connections for SMTP. Some limit MAY be imposed but servers that
+ cannot handle more than one SMTP transaction at a time are not in
+ conformance with the intent of this specification.
+
+ As discussed above, when the SMTP server receives mail from a
+ particular host address, it could activate its own SMTP queuing
+ mechanisms to retry any mail pending for that host address.
+
+4.5.5 Messages with a null reverse-path
+
+ There are several types of notification messages which are required
+ by existing and proposed standards to be sent with a null reverse
+ path, namely non-delivery notifications as discussed in section 3.7,
+
+
+
+Klensin Standards Track [Page 59]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ other kinds of Delivery Status Notifications (DSNs) [24], and also
+ Message Disposition Notifications (MDNs) [10]. All of these kinds of
+ messages are notifications about a previous message, and they are
+ sent to the reverse-path of the previous mail message. (If the
+ delivery of such a notification message fails, that usually indicates
+ a problem with the mail system of the host to which the notification
+ message is addressed. For this reason, at some hosts the MTA is set
+ up to forward such failed notification messages to someone who is
+ able to fix problems with the mail system, e.g., via the postmaster
+ alias.)
+
+ All other types of messages (i.e., any message which is not required
+ by a standards-track RFC to have a null reverse-path) SHOULD be sent
+ with with a valid, non-null reverse-path.
+
+ Implementors of automated email processors should be careful to make
+ sure that the various kinds of messages with null reverse-path are
+ handled correctly, in particular such systems SHOULD NOT reply to
+ messages with null reverse-path.
+
+5. Address Resolution and Mail Handling
+
+ Once an SMTP client lexically identifies a domain to which mail will
+ be delivered for processing (as described in sections 3.6 and 3.7), a
+ DNS lookup MUST be performed to resolve the domain name [22]. The
+ names are expected to be fully-qualified domain names (FQDNs):
+ mechanisms for inferring FQDNs from partial names or local aliases
+ are outside of this specification and, due to a history of problems,
+ are generally discouraged. The lookup first attempts to locate an MX
+ record associated with the name. If a CNAME record is found instead,
+ the resulting name is processed as if it were the initial name. If
+ no MX records are found, but an A RR is found, the A RR is treated as
+ if it was associated with an implicit MX RR, with a preference of 0,
+ pointing to that host. If one or more MX RRs are found for a given
+ name, SMTP systems MUST NOT utilize any A RRs associated with that
+ name unless they are located using the MX RRs; the "implicit MX" rule
+ above applies only if there are no MX records present. If MX records
+ are present, but none of them are usable, this situation MUST be
+ reported as an error.
+
+ When the lookup succeeds, the mapping can result in a list of
+ alternative delivery addresses rather than a single address, because
+ of multiple MX records, multihoming, or both. To provide reliable
+ mail transmission, the SMTP client MUST be able to try (and retry)
+ each of the relevant 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, the SMTP client SHOULD try at least two addresses.
+
+
+
+Klensin Standards Track [Page 60]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ Two types of information is used to rank the host addresses: multiple
+ MX records, and multihomed hosts.
+
+ Multiple MX records contain a preference indication that MUST be used
+ in sorting (see below). Lower numbers are more preferred than higher
+ ones. If there are multiple destinations with the same preference
+ and there is no clear reason to favor one (e.g., by recognition of an
+ easily-reached address), then the sender-SMTP MUST randomize them to
+ spread the load across multiple mail exchangers for a specific
+ organization.
+
+ 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 to have ordered this list by
+ decreasing preference if necessary, and SMTP MUST try them in the
+ order presented.
+
+ Although the capability to try multiple alternative addresses is
+ required, specific installations may want to limit or disable the use
+ of alternative addresses. The question of whether a sender should
+ attempt retries using the different addresses of a multihomed host
+ has been controversial. The main argument for using the multiple
+ addresses is that it maximizes the probability of timely delivery,
+ and indeed sometimes the probability of any delivery; the counter-
+ argument is that it may result in unnecessary resource use. Note
+ that resource use is also strongly determined by the sending strategy
+ discussed in section 4.5.4.1.
+
+ If an SMTP server receives a message with a destination for which it
+ is a designated Mail eXchanger, it MAY relay the message (potentially
+ after having rewritten the MAIL FROM and/or RCPT TO addresses), make
+ final delivery of the message, or hand it off using some mechanism
+ outside the SMTP-provided transport environment. Of course, neither
+ of the latter require that the list of MX records be examined
+ further.
+
+ If it determines that it should relay the message without rewriting
+ the address, it MUST sort the MX records to determine candidates for
+ delivery. The records are first ordered by preference, with the
+ lowest-numbered records being most preferred. The relay host MUST
+ then inspect the list for any of the names or addresses by which it
+ might be known in mail transactions. If a matching record is found,
+ all records at that preference level and higher-numbered ones MUST be
+ discarded from consideration. If there are no records left at that
+ point, it is an error condition, and the message MUST be returned as
+ undeliverable. If records do remain, they SHOULD be tried, best
+ preference first, as described above.
+
+
+
+Klensin Standards Track [Page 61]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+6. Problem Detection and Handling
+
+6.1 Reliable Delivery and Replies by Email
+
+ 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. It MUST NOT lose the message for frivolous reasons, such
+ as because the host later crashes or because of a predictable
+ resource shortage.
+
+ If there is a delivery failure after acceptance of a message, the
+ receiver-SMTP MUST formulate and mail a notification message. This
+ notification MUST be sent using a null ("<>") reverse path in the
+ envelope. The recipient of this notification MUST 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. Obviously, nothing in this section can or should
+ prohibit local decisions (i.e., as part of the same system
+ environment as the receiver-SMTP) to log or otherwise transmit
+ information about null address events locally if that is desired. If
+ the address is an explicit source route, it MUST be stripped down to
+ its final hop.
+
+ For example, suppose that an error notification must be sent for a
+ message that arrived with:
+
+ MAIL FROM:<@a,@b:user@d>
+
+ The notification message MUST be sent using:
+
+ RCPT TO:<user@d>
+
+ Some delivery failures after the message is accepted by SMTP will be
+ unavoidable. For example, it may be impossible for the receiving
+ SMTP server to validate all the delivery addresses in RCPT command(s)
+ due to a "soft" domain system error, because the target is a mailing
+ list (see earlier discussion of RCPT), or because the server is
+ acting as a relay and has no immediate access to the delivering
+ system.
+
+ 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 <CRLF>.<CRLF> end of data indicator. See RFC 1047 [28] for
+ a discussion of this problem.
+
+
+
+
+
+
+Klensin Standards Track [Page 62]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+6.2 Loop Detection
+
+ Simple counting of the number of "Received:" headers in a message has
+ proven to be an effective, although rarely optimal, method of
+ detecting loops in mail systems. SMTP servers using this technique
+ SHOULD use a large rejection threshold, normally at least 100
+ Received entries. Whatever mechanisms are used, servers MUST contain
+ provisions for detecting and stopping trivial loops.
+
+6.3 Compensating for Irregularities
+
+ Unfortunately, variations, creative interpretations, and outright
+ violations of Internet mail protocols do occur; some would suggest
+ that they occur quite frequently. The debate as to whether a well-
+ behaved SMTP receiver or relay should reject a malformed message,
+ attempt to pass it on unchanged, or attempt to repair it to increase
+ the odds of successful delivery (or subsequent reply) began almost
+ with the dawn of structured network mail and shows no signs of
+ abating. Advocates of rejection claim that attempted repairs are
+ rarely completely adequate and that rejection of bad messages is the
+ only way to get the offending software repaired. Advocates of
+ "repair" or "deliver no matter what" argue that users prefer that
+ mail go through it if at all possible and that there are significant
+ market pressures in that direction. In practice, these market
+ pressures may be more important to particular vendors than strict
+ conformance to the standards, regardless of the preference of the
+ actual developers.
+
+ The problems associated with ill-formed messages were exacerbated by
+ the introduction of the split-UA mail reading protocols [3, 26, 5,
+ 21]. These protocols have encouraged the use of SMTP as a posting
+ protocol, and SMTP servers as relay systems for these client hosts
+ (which are often only intermittently connected to the Internet).
+ Historically, many of those client machines lacked some of the
+ mechanisms and information assumed by SMTP (and indeed, by the mail
+ format protocol [7]). Some could not keep adequate track of time;
+ others had no concept of time zones; still others could not identify
+ their own names or addresses; and, of course, none could satisfy the
+ assumptions that underlay RFC 822's conception of authenticated
+ addresses.
+
+ In response to these weak SMTP clients, many SMTP systems now
+ complete messages that are delivered to them in incomplete or
+ incorrect form. This strategy is generally considered appropriate
+ when the server can identify or authenticate the client, and there
+ are prior agreements between them. By contrast, there is at best
+ great concern about fixes applied by a relay or delivery SMTP server
+ that has little or no knowledge of the user or client machine.
+
+
+
+Klensin Standards Track [Page 63]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ The following changes to a message being processed MAY be applied
+ when necessary by an originating SMTP server, or one used as the
+ target of SMTP as an initial posting protocol:
+
+ - Addition of a message-id field when none appears
+
+ - Addition of a date, time or time zone when none appears
+
+ - Correction of addresses to proper FQDN format
+
+ The less information the server has about the client, the less likely
+ these changes are to be correct and the more caution and conservatism
+ should be applied when considering whether or not to perform fixes
+ and how. These changes MUST NOT be applied by an SMTP server that
+ provides an intermediate relay function.
+
+ In all cases, properly-operating clients supplying correct
+ information are preferred to corrections by the SMTP server. In all
+ cases, documentation of actions performed by the servers (in trace
+ fields and/or header comments) is strongly encouraged.
+
+7. Security Considerations
+
+7.1 Mail Security and Spoofing
+
+ SMTP mail is inherently insecure in that it is feasible for even
+ fairly casual users to negotiate directly with receiving and relaying
+ SMTP servers and create messages that will trick a naive recipient
+ into believing that they came from somewhere else. Constructing such
+ a message so that the "spoofed" behavior cannot be detected by an
+ expert is somewhat more difficult, but not sufficiently so as to be a
+ deterrent to someone who is determined and knowledgeable.
+ Consequently, as knowledge of Internet mail increases, so does the
+ knowledge that SMTP mail inherently cannot be authenticated, or
+ integrity checks provided, at the transport level. Real mail
+ security lies only in end-to-end methods involving the message
+ bodies, such as those which use digital signatures (see [14] and,
+ e.g., PGP [4] or S/MIME [31]).
+
+ Various protocol extensions and configuration options that provide
+ authentication at the transport level (e.g., from an SMTP client to
+ an SMTP server) improve somewhat on the traditional situation
+ described above. However, unless they are accompanied by careful
+ handoffs of responsibility in a carefully-designed trust environment,
+ they remain inherently weaker than end-to-end mechanisms which use
+ digitally signed messages rather than depending on the integrity of
+ the transport system.
+
+
+
+
+Klensin Standards Track [Page 64]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ Efforts to make it more difficult for users to set envelope return
+ path and header "From" fields to point to valid addresses other than
+ their own are largely misguided: they frustrate legitimate
+ applications in which mail is sent by one user on behalf of another
+ or in which error (or normal) replies should be directed to a special
+ address. (Systems that provide convenient ways for users to alter
+ these fields on a per-message basis should attempt to establish a
+ primary and permanent mailbox address for the user so that Sender
+ fields within the message data can be generated sensibly.)
+
+ This specification does not further address the authentication issues
+ associated with SMTP other than to advocate that useful functionality
+ not be disabled in the hope of providing some small margin of
+ protection against an ignorant user who is trying to fake mail.
+
+7.2 "Blind" Copies
+
+ Addresses that do not appear in the message headers may appear in the
+ RCPT commands to an SMTP server for a number of reasons. The two
+ most common involve the use of a mailing address as a "list exploder"
+ (a single address that resolves into multiple addresses) and the
+ appearance of "blind copies". Especially when more than one RCPT
+ command is present, and in order to avoid defeating some of the
+ purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
+ the full set of RCPT command arguments into the headers, either as
+ part of trace headers or as informational or private-extension
+ headers. Since this rule is often violated in practice, and cannot
+ be enforced, sending SMTP systems that are aware of "bcc" use MAY
+ find it helpful to send each blind copy as a separate message
+ transaction containing only a single RCPT command.
+
+ There is no inherent relationship between either "reverse" (from
+ MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
+ transaction ("envelope") and the addresses in the headers. Receiving
+ systems SHOULD NOT attempt to deduce such relationships and use them
+ to alter the headers of the message for delivery. The popular
+ "Apparently-to" header is a violation of this principle as well as a
+ common source of unintended information disclosure and SHOULD NOT be
+ used.
+
+7.3 VRFY, EXPN, and Security
+
+ As discussed in section 3.5, individual sites may want to disable
+ either or both of VRFY or EXPN for security reasons. As a corollary
+ to the above, implementations that permit this MUST NOT appear to
+ have verified addresses that are not, in fact, verified. If a site
+
+
+
+
+
+Klensin Standards Track [Page 65]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ disables these commands for security reasons, the SMTP server MUST
+ return a 252 response, rather than a code that could be confused with
+ successful or unsuccessful verification.
+
+ Returning a 250 reply code with the address listed in the VRFY
+ command after having checked it only for syntax violates this rule.
+ Of course, an implementation that "supports" VRFY by always returning
+ 550 whether or not the address is valid is equally not in
+ conformance.
+
+ Within the last few years, the contents of mailing lists have become
+ popular as an address information source for so-called "spammers."
+ The use of EXPN to "harvest" addresses has increased as list
+ administrators have installed protections against inappropriate uses
+ of the lists themselves. Implementations SHOULD still provide
+ support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
+ As authentication mechanisms are introduced into SMTP, some sites may
+ choose to make EXPN available only to authenticated requestors.
+
+7.4 Information Disclosure in Announcements
+
+ There has been an ongoing debate about the tradeoffs between the
+ debugging advantages of announcing server type and version (and,
+ sometimes, even server domain name) in the greeting response or in
+ response to the HELP command and the disadvantages of exposing
+ information that might be useful in a potential hostile attack. The
+ utility of the debugging information is beyond doubt. Those who
+ argue for making it available point out that it is far better to
+ actually secure an SMTP server rather than hope that trying to
+ conceal known vulnerabilities by hiding the server's precise identity
+ will provide more protection. Sites are encouraged to evaluate the
+ tradeoff with that issue in mind; implementations are strongly
+ encouraged to minimally provide for making type and version
+ information available in some way to other network hosts.
+
+7.5 Information Disclosure in Trace Fields
+
+ In some circumstances, such as when mail originates from within a LAN
+ whose hosts are not directly on the public Internet, trace
+ ("Received") fields produced in conformance with this specification
+ may disclose host names and similar information that would not
+ normally be available. This ordinarily does not pose a problem, but
+ sites with special concerns about name disclosure should be aware of
+ it. Also, the optional FOR clause should be supplied with caution or
+ not at all when multiple recipients are involved lest it
+ inadvertently disclose the identities of "blind copy" recipients to
+ others.
+
+
+
+
+Klensin Standards Track [Page 66]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+7.6 Information Disclosure in Message Forwarding
+
+ As discussed in section 3.4, use of the 251 or 551 reply codes to
+ identify the replacement address associated with a mailbox may
+ inadvertently disclose sensitive information. Sites that are
+ concerned about those issues should ensure that they select and
+ configure servers appropriately.
+
+7.7 Scope of Operation of SMTP Servers
+
+ It is a well-established principle that an SMTP server may refuse to
+ accept mail for any operational or technical reason that makes sense
+ to the site providing the server. However, cooperation among sites
+ and installations makes the Internet possible. If sites take
+ excessive advantage of the right to reject traffic, the ubiquity of
+ email availability (one of the strengths of the Internet) will be
+ threatened; considerable care should be taken and balance maintained
+ if a site decides to be selective about the traffic it will accept
+ and process.
+
+ In recent years, use of the relay function through arbitrary sites
+ has been used as part of hostile efforts to hide the actual origins
+ of mail. Some sites have decided to limit the use of the relay
+ function to known or identifiable sources, and implementations SHOULD
+ provide the capability to perform this type of filtering. When mail
+ is rejected for these or other policy reasons, a 550 code SHOULD be
+ used in response to EHLO, MAIL, or RCPT as appropriate.
+
+8. IANA Considerations
+
+ IANA will maintain three registries in support of this specification.
+ The first consists of SMTP service extensions with the associated
+ keywords, and, as needed, parameters and verbs. As specified in
+ section 2.2.2, no entry may be made in this registry that starts in
+ an "X". Entries may be made only for service extensions (and
+ associated keywords, parameters, or verbs) that are defined in
+ standards-track or experimental RFCs specifically approved by the
+ IESG for this purpose.
+
+ The second registry consists of "tags" that identify forms of domain
+ literals other than those for IPv4 addresses (specified in RFC 821
+ and in this document) and IPv6 addresses (specified in this
+ document). Additional literal types require standardization before
+ being used; none are anticipated at this time.
+
+ The third, established by RFC 821 and renewed by this specification,
+ is a registry of link and protocol identifiers to be used with the
+ "via" and "with" subclauses of the time stamp ("Received: header")
+
+
+
+Klensin Standards Track [Page 67]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ described in section 4.4. Link and protocol identifiers in addition
+ to those specified in this document may be registered only by
+ standardization or by way of an RFC-documented, IESG-approved,
+ Experimental protocol extension.
+
+9. References
+
+ [1] American National Standards Institute (formerly United States of
+ America Standards Institute), X3.4, 1968, "USA Code for
+ Information Interchange". ANSI X3.4-1968 has been replaced by
+ newer versions with slight modifications, but the 1968 version
+ remains definitive for the Internet.
+
+ [2] Braden, R., "Requirements for Internet hosts - application and
+ support", STD 3, RFC 1123, October 1989.
+
+ [3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J.
+ Reynolds, "Post Office Protocol - version 2", RFC 937, February
+ 1985.
+
+ [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
+ Message Format", RFC 2440, November 1998.
+
+ [5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
+ 1176, August 1990.
+
+ [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
+ 2060, December 1996.
+
+ [7] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", RFC 822, August 1982.
+
+ [8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [9] De Winter, J., "SMTP Service Extension for Remote Message Queue
+ Starting", RFC 1985, August 1996.
+
+ [10] Fajman, R., "An Extensible Message Format for Message
+ Disposition Notifications", RFC 2298, March 1998.
+
+ [11] Freed, N, "Behavior of and Requirements for Internet Firewalls",
+ RFC 2979, October 2000.
+
+ [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message Bodies",
+ RFC 2045, December 1996.
+
+
+
+
+Klensin Standards Track [Page 68]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ [13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
+ 2920, September 2000.
+
+ [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
+ Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+ RFC 1847, October 1995.
+
+ [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
+ December 1998.
+
+ [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156,
+ January 1998.
+
+ [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for
+ Message Size Declaration", STD 10, RFC 1870, November 1995.
+
+ [19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
+ "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
+
+ [20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
+ "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July
+ 1994.
+
+ [21] Lambert, M., "PCMAIL: A distributed mail system for personal
+ computers", RFC 1056, July 1988.
+
+ [22] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ Mockapetris, P., "Domain names - concepts and facilities", STD
+ 13, RFC 1034, November 1987.
+
+ [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+ Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+ December 1996.
+
+ [24] Moore, K., "SMTP Service Extension for Delivery Status
+ Notifications", RFC 1891, January 1996.
+
+ [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+ Delivery Status Notifications", RFC 1894, January 1996.
+
+ [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
+ 53, RFC 1939, May 1996.
+
+
+
+
+Klensin Standards Track [Page 69]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ [27] Partridge, C., "Mail routing and the domain system", RFC 974,
+ January 1986.
+
+ [28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February
+ 1988.
+
+ [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+ Program Protocol Specification", STD 7, RFC 793, September 1981.
+
+ [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
+ 1982.
+
+ [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
+ 2633, June 1999.
+
+ [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
+ 2001.
+
+ [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of
+ Large and Binary MIME Messages", RFC 1830, August 1995.
+
+ [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+ January 1996.
+
+10. Editor's Address
+
+ John C. Klensin
+ AT&T Laboratories
+ 99 Bedford St
+ Boston, MA 02111 USA
+
+ Phone: 617-574-3076
+ EMail: klensin@research.att.com
+
+11. Acknowledgments
+
+ Many people worked long and hard on the many iterations of this
+ document. There was wide-ranging debate in the IETF DRUMS Working
+ Group, both on its mailing list and in face to face discussions,
+ about many technical issues and the role of a revised standard for
+ Internet mail transport, and many contributors helped form the
+ wording in this specification. The hundreds of participants in the
+ many discussions since RFC 821 was produced are too numerous to
+ mention, but they all helped this document become what it is.
+
+
+
+
+
+
+
+Klensin Standards Track [Page 70]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+APPENDICES
+
+A. TCP Transport Service
+
+ The TCP connection supports the transmission of 8-bit bytes. The
+ SMTP data is 7-bit ASCII characters. Each character is transmitted
+ as an 8-bit byte with the high-order bit cleared to zero. Service
+ extensions may modify this rule to permit transmission of full 8-bit
+ data bytes as part of the message body, but not in SMTP commands or
+ responses.
+
+B. Generating SMTP Commands from RFC 822 Headers
+
+ Some systems use RFC 822 headers (only) in a mail submission
+ protocol, or otherwise generate SMTP commands from RFC 822 headers
+ when such a message is handed to an MTA from a UA. While the MTA-UA
+ protocol is a private matter, not covered by any Internet Standard,
+ there are problems with this approach. For example, there have been
+ repeated problems with proper handling of "bcc" copies and
+ redistribution lists when information that conceptually belongs to a
+ mail envelopes is not separated early in processing from header
+ information (and kept separate).
+
+ It is recommended that the UA provide its initial ("submission
+ client") MTA with an envelope separate from the message itself.
+ However, if the envelope is not supplied, SMTP commands SHOULD be
+ generated as follows:
+
+ 1. Each recipient address from a TO, CC, or BCC header field SHOULD
+ be copied to a RCPT command (generating multiple message copies if
+ that is required for queuing or delivery). This includes any
+ addresses listed in a RFC 822 "group". Any BCC fields SHOULD then
+ be removed from the headers. Once this process is completed, the
+ remaining headers SHOULD be checked to verify that at least one
+ To:, Cc:, or Bcc: header remains. If none do, then a bcc: header
+ with no additional information SHOULD be inserted as specified in
+ [32].
+
+ 2. The return address in the MAIL command SHOULD, if possible, be
+ derived from the system's identity for the submitting (local)
+ user, and the "From:" header field otherwise. If there is a
+ system identity available, it SHOULD also be copied to the Sender
+ header field if it is different from the address in the From
+ header field. (Any Sender field that was already there SHOULD be
+ removed.) Systems may provide a way for submitters to override
+ the envelope return address, but may want to restrict its use to
+ privileged users. This will not prevent mail forgery, but may
+ lessen its incidence; see section 7.1.
+
+
+
+Klensin Standards Track [Page 71]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ When an MTA is being used in this way, it bears responsibility for
+ ensuring that the message being transmitted is valid. The mechanisms
+ for checking that validity, and for handling (or returning) messages
+ that are not valid at the time of arrival, are part of the MUA-MTA
+ interface and not covered by this specification.
+
+ A submission protocol based on Standard RFC 822 information alone
+ MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
+ system into an SMTP environment. Additional information to construct
+ an envelope must come from some source in the other environment,
+ whether supplemental headers or the foreign system's envelope.
+
+ Attempts to gateway messages using only their header "to" and "cc"
+ fields have repeatedly caused mail loops and other behavior adverse
+ to the proper functioning of the Internet mail environment. These
+ problems have been especially common when the message originates from
+ an Internet mailing list and is distributed into the foreign
+ environment using envelope information. When these messages are then
+ processed by a header-only remailer, loops back to the Internet
+ environment (and the mailing list) are almost inevitable.
+
+C. Source Routes
+
+ Historically, the <reverse-path> was a reverse source routing list of
+ hosts and a source mailbox. The first host in the <reverse-path>
+ SHOULD be the host sending the MAIL command. Similarly, the
+ <forward-path> may be a source routing lists of hosts and a
+ destination mailbox. However, in general, the <forward-path> SHOULD
+ contain only a mailbox and domain name, relying on the domain name
+ system to supply routing information if required. The use of source
+ routes is deprecated; while servers MUST be prepared to receive and
+ handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
+ transmit them and this section was included only to provide context.
+
+ For relay purposes, the forward-path may be a source route of the
+ form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-
+ qualified domain names. This form is used to emphasize the
+ distinction between an address and a route. The mailbox is an
+ absolute address, and the route is information about how to get
+ there. The two concepts should not be confused.
+
+ If source routes are used, RFC 821 and the text below should be
+ consulted for the mechanisms for constructing and updating the
+ forward- and reverse-paths.
+
+
+
+
+
+
+
+Klensin Standards Track [Page 72]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ The SMTP server transforms the command arguments by moving its own
+ identifier (its domain name or that of any domain for which it is
+ acting as a mail exchanger), if it appears, from the forward-path to
+ the beginning of the reverse-path.
+
+ Notice that the forward-path and reverse-path appear in the SMTP
+ commands and replies, but not necessarily in the message. That is,
+ there is no need for these paths and especially this syntax to appear
+ in the "To:" , "From:", "CC:", etc. fields of the message header.
+ Conversely, SMTP servers MUST NOT derive final message delivery
+ information from message header fields.
+
+ When the list of hosts is present, it is a "reverse" source route and
+ indicates that the mail was relayed through each host on the list
+ (the first host in the list was the most recent relay). This list is
+ used as a source route to return non-delivery notices to the sender.
+ As each relay host adds itself to the beginning of the list, it MUST
+ use its name as known in the transport environment to which it is
+ relaying the mail rather than that of the transport environment from
+ which the mail came (if they are different).
+
+D. Scenarios
+
+ This section presents complete scenarios of several types of SMTP
+ sessions. In the examples, "C:" indicates what is said by the SMTP
+ client, and "S:" indicates what is said by the SMTP server.
+
+D.1 A Typical SMTP Transaction Scenario
+
+ This SMTP example shows mail sent by Smith at host bar.com, to Jones,
+ Green, and Brown at host foo.com. Here we assume that host bar.com
+ contacts host foo.com directly. The mail is accepted for Jones and
+ Brown. Green does not have a mailbox at host foo.com.
+
+ S: 220 foo.com Simple Mail Transfer Service Ready
+ C: EHLO bar.com
+ S: 250-foo.com greets bar.com
+ S: 250-8BITMIME
+ S: 250-SIZE
+ S: 250-DSN
+ S: 250 HELP
+ C: MAIL FROM:<Smith@bar.com>
+ S: 250 OK
+ C: RCPT TO:<Jones@foo.com>
+ S: 250 OK
+ C: RCPT TO:<Green@foo.com>
+ S: 550 No such user here
+ C: RCPT TO:<Brown@foo.com>
+
+
+
+Klensin Standards Track [Page 73]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ S: 250 OK
+ C: DATA
+ S: 354 Start mail input; end with <CRLF>.<CRLF>
+ C: Blah blah blah...
+ C: ...etc. etc. etc.
+ C: .
+ S: 250 OK
+ C: QUIT
+ S: 221 foo.com Service closing transmission channel
+
+D.2 Aborted SMTP Transaction Scenario
+
+ S: 220 foo.com Simple Mail Transfer Service Ready
+ C: EHLO bar.com
+ S: 250-foo.com greets bar.com
+ S: 250-8BITMIME
+ S: 250-SIZE
+ S: 250-DSN
+ S: 250 HELP
+ C: MAIL FROM:<Smith@bar.com>
+ S: 250 OK
+ C: RCPT TO:<Jones@foo.com>
+ S: 250 OK
+ C: RCPT TO:<Green@foo.com>
+ S: 550 No such user here
+ C: RSET
+ S: 250 OK
+ C: QUIT
+ S: 221 foo.com Service closing transmission channel
+
+D.3 Relayed Mail Scenario
+
+ Step 1 -- Source Host to Relay Host
+
+ S: 220 foo.com Simple Mail Transfer Service Ready
+ C: EHLO bar.com
+ S: 250-foo.com greets bar.com
+ S: 250-8BITMIME
+ S: 250-SIZE
+ S: 250-DSN
+ S: 250 HELP
+ C: MAIL FROM:<JQP@bar.com>
+ S: 250 OK
+ C: RCPT TO:<@foo.com:Jones@XYZ.COM>
+ S: 250 OK
+ C: DATA
+ S: 354 Start mail input; end with <CRLF>.<CRLF>
+ C: Date: Thu, 21 May 1998 05:33:29 -0700
+
+
+
+Klensin Standards Track [Page 74]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ C: From: John Q. Public <JQP@bar.com>
+ C: Subject: The Next Meeting of the Board
+ C: To: Jones@xyz.com
+ C:
+ C: Bill:
+ C: The next meeting of the board of directors will be
+ C: on Tuesday.
+ C: John.
+ C: .
+ S: 250 OK
+ C: QUIT
+ S: 221 foo.com Service closing transmission channel
+
+ Step 2 -- Relay Host to Destination Host
+
+ S: 220 xyz.com Simple Mail Transfer Service Ready
+ C: EHLO foo.com
+ S: 250 xyz.com is on the air
+ C: MAIL FROM:<@foo.com:JQP@bar.com>
+ S: 250 OK
+ C: RCPT TO:<Jones@XYZ.COM>
+ S: 250 OK
+ C: DATA
+ S: 354 Start mail input; end with <CRLF>.<CRLF>
+ C: Received: from bar.com by foo.com ; Thu, 21 May 1998
+ C: 05:33:29 -0700
+ C: Date: Thu, 21 May 1998 05:33:22 -0700
+ C: From: John Q. Public <JQP@bar.com>
+ C: Subject: The Next Meeting of the Board
+ C: To: Jones@xyz.com
+ C:
+ C: Bill:
+ C: The next meeting of the board of directors will be
+ C: on Tuesday.
+ C: John.
+ C: .
+ S: 250 OK
+ C: QUIT
+ S: 221 foo.com Service closing transmission channel
+
+D.4 Verifying and Sending Scenario
+
+ S: 220 foo.com Simple Mail Transfer Service Ready
+ C: EHLO bar.com
+ S: 250-foo.com greets bar.com
+ S: 250-8BITMIME
+ S: 250-SIZE
+ S: 250-DSN
+
+
+
+Klensin Standards Track [Page 75]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+ S: 250-VRFY
+ S: 250 HELP
+ C: VRFY Crispin
+ S: 250 Mark Crispin <Admin.MRC@foo.com>
+ C: SEND FROM:<EAK@bar.com>
+ S: 250 OK
+ C: RCPT TO:<Admin.MRC@foo.com>
+ S: 250 OK
+ C: DATA
+ S: 354 Start mail input; end with <CRLF>.<CRLF>
+ C: Blah blah blah...
+ C: ...etc. etc. etc.
+ C: .
+ S: 250 OK
+ C: QUIT
+ S: 221 foo.com Service closing transmission channel
+
+E. Other Gateway Issues
+
+ In general, gateways between the Internet and other mail systems
+ SHOULD attempt to preserve any layering semantics across the
+ boundaries between the two mail systems involved. Gateway-
+ translation approaches that attempt to take shortcuts by mapping,
+ (such as envelope information from one system to the message headers
+ or body of another) have generally proven to be inadequate in
+ important ways. Systems translating between environments that do not
+ support both envelopes and headers and Internet mail must be written
+ with the understanding that some information loss is almost
+ inevitable.
+
+F. Deprecated Features of RFC 821
+
+ A few features of RFC 821 have proven to be problematic and SHOULD
+ NOT be used in Internet mail.
+
+F.1 TURN
+
+ This command, described in RFC 821, raises important security issues
+ since, in the absence of strong authentication of the host requesting
+ that the client and server switch roles, it can easily be used to
+ divert mail from its correct destination. Its use is deprecated;
+ SMTP systems SHOULD NOT use it unless the server can authenticate the
+ client.
+
+
+
+
+
+
+
+
+Klensin Standards Track [Page 76]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+F.2 Source Routing
+
+ RFC 821 utilized the concept of explicit source routing to get mail
+ from one host to another via a series of relays. The requirement to
+ utilize source routes in regular mail traffic was eliminated by the
+ introduction of the domain name system "MX" record and the last
+ significant justification for them was eliminated by the
+ introduction, in RFC 1123, of a clear requirement that addresses
+ following an "@" must all be fully-qualified domain names.
+ Consequently, the only remaining justifications for the use of source
+ routes are support for very old SMTP clients or MUAs and in mail
+ system debugging. They can, however, still be useful in the latter
+ circumstance and for routing mail around serious, but temporary,
+ problems such as problems with the relevant DNS records.
+
+ SMTP servers MUST continue to accept source route syntax as specified
+ in the main body of this document and in RFC 1123. They MAY, if
+ necessary, ignore the routes and utilize only the target domain in
+ the address. If they do utilize the source route, the message MUST
+ be sent to the first domain shown in the address. In particular, a
+ server MUST NOT guess at shortcuts within the source route.
+
+ Clients SHOULD NOT utilize explicit source routing except under
+ unusual circumstances, such as debugging or potentially relaying
+ around firewall or mail system configuration errors.
+
+F.3 HELO
+
+ As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to
+ HELO when the server will accept the former. Servers must continue
+ to accept and process HELO in order to support older clients.
+
+F.4 #-literals
+
+ RFC 821 provided for specifying an Internet address as a decimal
+ integer host number prefixed by a pound sign, "#". In practice, that
+ form has been obsolete since the introduction of TCP/IP. It is
+ deprecated and MUST NOT be used.
+
+F.5 Dates and Years
+
+ When dates are inserted into messages by SMTP clients or servers
+ (e.g., in trace fields), four-digit years MUST BE used. Two-digit
+ years are deprecated; three-digit years were never permitted in the
+ Internet mail system.
+
+
+
+
+
+
+Klensin Standards Track [Page 77]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+F.6 Sending versus Mailing
+
+ In addition to specifying a mechanism for delivering messages to
+ user's mailboxes, RFC 821 provided additional, optional, commands to
+ deliver messages directly to the user's terminal screen. These
+ commands (SEND, SAML, SOML) were rarely implemented, and changes in
+ workstation technology and the introduction of other protocols may
+ have rendered them obsolete even where they are implemented.
+
+ Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
+ MAY implement them. If they are implemented by servers, the
+ implementation model specified in RFC 821 MUST be used and the
+ command names MUST be published in the response to the EHLO command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin Standards Track [Page 78]
+
+RFC 2821 Simple Mail Transfer Protocol April 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin Standards Track [Page 79]
+
diff --git a/Documentation/en/rfc/rfc2822.txt b/Documentation/en/rfc/rfc2822.txt
new file mode 100644
index 00000000..9f698f77
--- /dev/null
+++ b/Documentation/en/rfc/rfc2822.txt
@@ -0,0 +1,2859 @@
+
+
+
+
+
+
+Network Working Group P. Resnick, Editor
+Request for Comments: 2822 QUALCOMM Incorporated
+Obsoletes: 822 April 2001
+Category: Standards Track
+
+
+ Internet Message Format
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This standard specifies a syntax for text messages that are sent
+ between computer users, within the framework of "electronic mail"
+ messages. This standard supersedes the one specified in Request For
+ Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
+ Messages", updating it to reflect current practice and incorporating
+ incremental changes that were specified in other RFCs.
+
+Table of Contents
+
+ 1. Introduction ............................................... 3
+ 1.1. Scope .................................................... 3
+ 1.2. Notational conventions ................................... 4
+ 1.2.1. Requirements notation .................................. 4
+ 1.2.2. Syntactic notation ..................................... 4
+ 1.3. Structure of this document ............................... 4
+ 2. Lexical Analysis of Messages ............................... 5
+ 2.1. General Description ...................................... 5
+ 2.1.1. Line Length Limits ..................................... 6
+ 2.2. Header Fields ............................................ 7
+ 2.2.1. Unstructured Header Field Bodies ....................... 7
+ 2.2.2. Structured Header Field Bodies ......................... 7
+ 2.2.3. Long Header Fields ..................................... 7
+ 2.3. Body ..................................................... 8
+ 3. Syntax ..................................................... 9
+ 3.1. Introduction ............................................. 9
+ 3.2. Lexical Tokens ........................................... 9
+
+
+
+Resnick Standards Track [Page 1]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ 3.2.1. Primitive Tokens ....................................... 9
+ 3.2.2. Quoted characters ......................................10
+ 3.2.3. Folding white space and comments .......................11
+ 3.2.4. Atom ...................................................12
+ 3.2.5. Quoted strings .........................................13
+ 3.2.6. Miscellaneous tokens ...................................13
+ 3.3. Date and Time Specification ..............................14
+ 3.4. Address Specification ....................................15
+ 3.4.1. Addr-spec specification ................................16
+ 3.5 Overall message syntax ....................................17
+ 3.6. Field definitions ........................................18
+ 3.6.1. The origination date field .............................20
+ 3.6.2. Originator fields ......................................21
+ 3.6.3. Destination address fields .............................22
+ 3.6.4. Identification fields ..................................23
+ 3.6.5. Informational fields ...................................26
+ 3.6.6. Resent fields ..........................................26
+ 3.6.7. Trace fields ...........................................28
+ 3.6.8. Optional fields ........................................29
+ 4. Obsolete Syntax ............................................29
+ 4.1. Miscellaneous obsolete tokens ............................30
+ 4.2. Obsolete folding white space .............................31
+ 4.3. Obsolete Date and Time ...................................31
+ 4.4. Obsolete Addressing ......................................33
+ 4.5. Obsolete header fields ...................................33
+ 4.5.1. Obsolete origination date field ........................34
+ 4.5.2. Obsolete originator fields .............................34
+ 4.5.3. Obsolete destination address fields ....................34
+ 4.5.4. Obsolete identification fields .........................35
+ 4.5.5. Obsolete informational fields ..........................35
+ 4.5.6. Obsolete resent fields .................................35
+ 4.5.7. Obsolete trace fields ..................................36
+ 4.5.8. Obsolete optional fields ...............................36
+ 5. Security Considerations ....................................36
+ 6. Bibliography ...............................................37
+ 7. Editor's Address ...........................................38
+ 8. Acknowledgements ...........................................39
+ Appendix A. Example messages ..................................41
+ A.1. Addressing examples ......................................41
+ A.1.1. A message from one person to another with simple
+ addressing .............................................41
+ A.1.2. Different types of mailboxes ...........................42
+ A.1.3. Group addresses ........................................43
+ A.2. Reply messages ...........................................43
+ A.3. Resent messages ..........................................44
+ A.4. Messages with trace fields ...............................46
+ A.5. White space, comments, and other oddities ................47
+ A.6. Obsoleted forms ..........................................47
+
+
+
+Resnick Standards Track [Page 2]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ A.6.1. Obsolete addressing ....................................48
+ A.6.2. Obsolete dates .........................................48
+ A.6.3. Obsolete white space and comments ......................48
+ Appendix B. Differences from earlier standards ................49
+ Appendix C. Notices ...........................................50
+ Full Copyright Statement ......................................51
+
+1. Introduction
+
+1.1. Scope
+
+ This standard specifies a syntax for text messages that are sent
+ between computer users, within the framework of "electronic mail"
+ messages. This standard supersedes the one specified in Request For
+ Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
+ Messages" [RFC822], updating it to reflect current practice and
+ incorporating incremental changes that were specified in other RFCs
+ [STD3].
+
+ This standard specifies a syntax only for text messages. In
+ particular, it makes no provision for the transmission of images,
+ audio, or other sorts of structured data in electronic mail messages.
+ There are several extensions published, such as the MIME document
+ series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the
+ transmission of such data through electronic mail, either by
+ extending the syntax provided here or by structuring such messages to
+ conform to this syntax. Those mechanisms are outside of the scope of
+ this standard.
+
+ In the context of electronic mail, messages are viewed as having an
+ envelope and contents. The envelope contains whatever information is
+ needed to accomplish transmission and delivery. (See [RFC2821] for a
+ discussion of the envelope.) The contents comprise the object to be
+ delivered to the recipient. This standard applies only to the format
+ and some of the semantics of message contents. It contains no
+ specification of the information in the envelope.
+
+ However, some message systems may use information from the contents
+ to create the envelope. It is intended that this standard facilitate
+ the acquisition of such information by programs.
+
+ This specification is intended as a definition of what message
+ content format is to be passed between systems. Though some message
+ systems locally store messages in this format (which eliminates the
+ need for translation between formats) and others use formats that
+ differ from the one specified in this standard, local storage is
+ outside of the scope of this standard.
+
+
+
+
+Resnick Standards Track [Page 3]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ Note: This standard is not intended to dictate the internal formats
+ used by sites, the specific message system features that they are
+ expected to support, or any of the characteristics of user interface
+ programs that create or read messages. In addition, this standard
+ does not specify an encoding of the characters for either transport
+ or storage; that is, it does not specify the number of bits used or
+ how those bits are specifically transferred over the wire or stored
+ on disk.
+
+1.2. Notational conventions
+
+1.2.1. Requirements notation
+
+ This document occasionally uses terms that appear in capital letters.
+ When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
+ NOT", and "MAY" appear capitalized, they are being used to indicate
+ particular requirements of this specification. A discussion of the
+ meanings of these terms appears in [RFC2119].
+
+1.2.2. Syntactic notation
+
+ This standard uses the Augmented Backus-Naur Form (ABNF) notation
+ specified in [RFC2234] for the formal definitions of the syntax of
+ messages. Characters will be specified either by a decimal value
+ (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
+ a case-insensitive literal value enclosed in quotation marks (e.g.,
+ "A" for either uppercase or lowercase A). See [RFC2234] for the full
+ description of the notation.
+
+1.3. Structure of this document
+
+ This document is divided into several sections.
+
+ This section, section 1, is a short introduction to the document.
+
+ Section 2 lays out the general description of a message and its
+ constituent parts. This is an overview to help the reader understand
+ some of the general principles used in the later portions of this
+ document. Any examples in this section MUST NOT be taken as
+ specification of the formal syntax of any part of a message.
+
+ Section 3 specifies formal ABNF rules for the structure of each part
+ of a message (the syntax) and describes the relationship between
+ those parts and their meaning in the context of a message (the
+ semantics). That is, it describes the actual rules for the structure
+ of each part of a message (the syntax) as well as a description of
+ the parts and instructions on how they ought to be interpreted (the
+ semantics). This includes analysis of the syntax and semantics of
+
+
+
+Resnick Standards Track [Page 4]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ subparts of messages that have specific structure. The syntax
+ included in section 3 represents messages as they MUST be created.
+ There are also notes in section 3 to indicate if any of the options
+ specified in the syntax SHOULD be used over any of the others.
+
+ Both sections 2 and 3 describe messages that are legal to generate
+ for purposes of this standard.
+
+ Section 4 of this document specifies an "obsolete" syntax. There are
+ references in section 3 to these obsolete syntactic elements. The
+ rules of the obsolete syntax are elements that have appeared in
+ earlier revisions of this standard or have previously been widely
+ used in Internet messages. As such, these elements MUST be
+ interpreted by parsers of messages in order to be conformant to this
+ standard. However, since items in this syntax have been determined
+ to be non-interoperable or to cause significant problems for
+ recipients of messages, they MUST NOT be generated by creators of
+ conformant messages.
+
+ Section 5 details security considerations to take into account when
+ implementing this standard.
+
+ Section 6 is a bibliography of references in this document.
+
+ Section 7 contains the editor's address.
+
+ Section 8 contains acknowledgements.
+
+ Appendix A lists examples of different sorts of messages. These
+ examples are not exhaustive of the types of messages that appear on
+ the Internet, but give a broad overview of certain syntactic forms.
+
+ Appendix B lists the differences between this standard and earlier
+ standards for Internet messages.
+
+ Appendix C has copyright and intellectual property notices.
+
+2. Lexical Analysis of Messages
+
+2.1. General Description
+
+ At the most basic level, a message is a series of characters. A
+ message that is conformant with this standard is comprised of
+ characters with values in the range 1 through 127 and interpreted as
+ US-ASCII characters [ASCII]. For brevity, this document sometimes
+ refers to this range of characters as simply "US-ASCII characters".
+
+
+
+
+
+Resnick Standards Track [Page 5]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ Note: This standard specifies that messages are made up of characters
+ in the US-ASCII range of 1 through 127. There are other documents,
+ specifically the MIME document series [RFC2045, RFC2046, RFC2047,
+ RFC2048, RFC2049], that extend this standard to allow for values
+ outside of that range. Discussion of those mechanisms is not within
+ the scope of this standard.
+
+ Messages are divided into lines of characters. A line is a series of
+ characters that is delimited with the two characters carriage-return
+ and line-feed; that is, the carriage return (CR) character (ASCII
+ value 13) followed immediately by the line feed (LF) character (ASCII
+ value 10). (The carriage-return/line-feed pair is usually written in
+ this document as "CRLF".)
+
+ A message consists of header fields (collectively called "the header
+ of the message") followed, optionally, by a body. The header is a
+ sequence of lines of characters with special syntax as defined in
+ this standard. The body is simply a sequence of characters that
+ follows the header and is separated from the header by an empty line
+ (i.e., a line with nothing preceding the CRLF).
+
+2.1.1. Line Length Limits
+
+ There are two limits that this standard places on the number of
+ characters in a line. Each line of characters MUST be no more than
+ 998 characters, and SHOULD be no more than 78 characters, excluding
+ the CRLF.
+
+ The 998 character limit is due to limitations in many implementations
+ which send, receive, or store Internet Message Format messages that
+ simply cannot handle more than 998 characters on a line. Receiving
+ implementations would do well to handle an arbitrarily large number
+ of characters in a line for robustness sake. However, there are so
+ many implementations which (in compliance with the transport
+ requirements of [RFC2821]) do not accept messages containing more
+ than 1000 character including the CR and LF per line, it is important
+ for implementations not to create such messages.
+
+ The more conservative 78 character recommendation is to accommodate
+ the many implementations of user interfaces that display these
+ messages which may truncate, or disastrously wrap, the display of
+ more than 78 characters per line, in spite of the fact that such
+ implementations are non-conformant to the intent of this
+ specification (and that of [RFC2821] if they actually cause
+ information to be lost). Again, even though this limitation is put on
+ messages, it is encumbant upon implementations which display messages
+
+
+
+
+
+Resnick Standards Track [Page 6]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ to handle an arbitrarily large number of characters in a line
+ (certainly at least up to the 998 character limit) for the sake of
+ robustness.
+
+2.2. Header Fields
+
+ Header fields are lines composed of a field name, followed by a colon
+ (":"), followed by a field body, and terminated by CRLF. A field
+ name MUST be composed of printable US-ASCII characters (i.e.,
+ characters that have values between 33 and 126, inclusive), except
+ colon. A field body may be composed of any US-ASCII characters,
+ except for CR and LF. However, a field body may contain CRLF when
+ used in header "folding" and "unfolding" as described in section
+ 2.2.3. All field bodies MUST conform to the syntax described in
+ sections 3 and 4 of this standard.
+
+2.2.1. Unstructured Header Field Bodies
+
+ Some field bodies in this standard are defined simply as
+ "unstructured" (which is specified below as any US-ASCII characters,
+ except for CR and LF) with no further restrictions. These are
+ referred to as unstructured field bodies. Semantically, unstructured
+ field bodies are simply to be treated as a single line of characters
+ with no further processing (except for header "folding" and
+ "unfolding" as described in section 2.2.3).
+
+2.2.2. Structured Header Field Bodies
+
+ Some field bodies in this standard have specific syntactical
+ structure more restrictive than the unstructured field bodies
+ described above. These are referred to as "structured" field bodies.
+ Structured field bodies are sequences of specific lexical tokens as
+ described in sections 3 and 4 of this standard. Many of these tokens
+ are allowed (according to their syntax) to be introduced or end with
+ comments (as described in section 3.2.3) as well as the space (SP,
+ ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters
+ (together known as the white space characters, WSP), and those WSP
+ characters are subject to header "folding" and "unfolding" as
+ described in section 2.2.3. Semantic analysis of structured field
+ bodies is given along with their syntax.
+
+2.2.3. Long Header Fields
+
+ Each header field is logically a single line of characters comprising
+ the field name, the colon, and the field body. For convenience
+ however, and to deal with the 998/78 character limitations per line,
+ the field body portion of a header field can be split into a multiple
+ line representation; this is called "folding". The general rule is
+
+
+
+Resnick Standards Track [Page 7]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ that wherever this standard allows for folding white space (not
+ simply WSP characters), a CRLF may be inserted before any WSP. For
+ example, the header field:
+
+ Subject: This is a test
+
+ can be represented as:
+
+ Subject: This
+ is a test
+
+ Note: Though structured field bodies are defined in such a way that
+ folding can take place between many of the lexical tokens (and even
+ within some of the lexical tokens), folding SHOULD be limited to
+ placing the CRLF at higher-level syntactic breaks. For instance, if
+ a field body is defined as comma-separated values, it is recommended
+ that folding occur after the comma separating the structured items in
+ preference to other places where the field could be folded, even if
+ it is allowed elsewhere.
+
+ The process of moving from this folded multiple-line representation
+ of a header field to its single line representation is called
+ "unfolding". Unfolding is accomplished by simply removing any CRLF
+ that is immediately followed by WSP. Each header field should be
+ treated in its unfolded form for further syntactic and semantic
+ evaluation.
+
+2.3. Body
+
+ The body of a message is simply lines of US-ASCII characters. The
+ only two limitations on the body are as follows:
+
+ - CR and LF MUST only occur together as CRLF; they MUST NOT appear
+ independently in the body.
+
+ - Lines of characters in the body MUST be limited to 998 characters,
+ and SHOULD be limited to 78 characters, excluding the CRLF.
+
+ Note: As was stated earlier, there are other standards documents,
+ specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049]
+ that extend this standard to allow for different sorts of message
+ bodies. Again, these mechanisms are beyond the scope of this
+ document.
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 8]
+
+RFC 2822 Internet Message Format April 2001
+
+
+3. Syntax
+
+3.1. Introduction
+
+ The syntax as given in this section defines the legal syntax of
+ Internet messages. Messages that are conformant to this standard
+ MUST conform to the syntax in this section. If there are options in
+ this section where one option SHOULD be generated, that is indicated
+ either in the prose or in a comment next to the syntax.
+
+ For the defined expressions, a short description of the syntax and
+ use is given, followed by the syntax in ABNF, followed by a semantic
+ analysis. Primitive tokens that are used but otherwise unspecified
+ come from [RFC2234].
+
+ In some of the definitions, there will be nonterminals whose names
+ start with "obs-". These "obs-" elements refer to tokens defined in
+ the obsolete syntax in section 4. In all cases, these productions
+ are to be ignored for the purposes of generating legal Internet
+ messages and MUST NOT be used as part of such a message. However,
+ when interpreting messages, these tokens MUST be honored as part of
+ the legal syntax. In this sense, section 3 defines a grammar for
+ generation of messages, with "obs-" elements that are to be ignored,
+ while section 4 adds grammar for interpretation of messages.
+
+3.2. Lexical Tokens
+
+ The following rules are used to define an underlying lexical
+ analyzer, which feeds tokens to the higher-level parsers. This
+ section defines the tokens used in structured header field bodies.
+
+ Note: Readers of this standard need to pay special attention to how
+ these lexical tokens are used in both the lower-level and
+ higher-level syntax later in the document. Particularly, the white
+ space tokens and the comment tokens defined in section 3.2.3 get used
+ in the lower-level tokens defined here, and those lower-level tokens
+ are in turn used as parts of the higher-level tokens defined later.
+ Therefore, the white space and comments may be allowed in the
+ higher-level tokens even though they may not explicitly appear in a
+ particular definition.
+
+3.2.1. Primitive Tokens
+
+ The following are primitive tokens referred to elsewhere in this
+ standard, but not otherwise defined in [RFC2234]. Some of them will
+ not appear anywhere else in the syntax, but they are convenient to
+ refer to in other parts of this document.
+
+
+
+
+Resnick Standards Track [Page 9]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ Note: The "specials" below are just such an example. Though the
+ specials token does not appear anywhere else in this standard, it is
+ useful for implementers who use tools that lexically analyze
+ messages. Each of the characters in specials can be used to indicate
+ a tokenization point in lexical analysis.
+
+NO-WS-CTL = %d1-8 / ; US-ASCII control characters
+ %d11 / ; that do not include the
+ %d12 / ; carriage return, line feed,
+ %d14-31 / ; and white space characters
+ %d127
+
+text = %d1-9 / ; Characters excluding CR and LF
+ %d11 /
+ %d12 /
+ %d14-127 /
+ obs-text
+
+specials = "(" / ")" / ; Special characters used in
+ "<" / ">" / ; other parts of the syntax
+ "[" / "]" /
+ ":" / ";" /
+ "@" / "\" /
+ "," / "." /
+ DQUOTE
+
+ No special semantics are attached to these tokens. They are simply
+ single characters.
+
+3.2.2. Quoted characters
+
+ Some characters are reserved for special interpretation, such as
+ delimiting lexical tokens. To permit use of these characters as
+ uninterpreted data, a quoting mechanism is provided.
+
+quoted-pair = ("\" text) / obs-qp
+
+ Where any quoted-pair appears, it is to be interpreted as the text
+ character alone. That is to say, the "\" character that appears as
+ part of a quoted-pair is semantically "invisible".
+
+ Note: The "\" character may appear in a message where it is not part
+ of a quoted-pair. A "\" character that does not appear in a
+ quoted-pair is not semantically invisible. The only places in this
+ standard where quoted-pair currently appears are ccontent, qcontent,
+ dcontent, no-fold-quote, and no-fold-literal.
+
+
+
+
+
+Resnick Standards Track [Page 10]
+
+RFC 2822 Internet Message Format April 2001
+
+
+3.2.3. Folding white space and comments
+
+ White space characters, including white space used in folding
+ (described in section 2.2.3), may appear between many elements in
+ header field bodies. Also, strings of characters that are treated as
+ comments may be included in structured field bodies as characters
+ enclosed in parentheses. The following defines the folding white
+ space (FWS) and comment constructs.
+
+ Strings of characters enclosed in parentheses are considered comments
+ so long as they do not appear within a "quoted-string", as defined in
+ section 3.2.5. Comments may nest.
+
+ There are several places in this standard where comments and FWS may
+ be freely inserted. To accommodate that syntax, an additional token
+ for "CFWS" is defined for places where comments and/or FWS can occur.
+ However, where CFWS occurs in this standard, it MUST NOT be inserted
+ in such a way that any line of a folded header field is made up
+ entirely of WSP characters and nothing else.
+
+FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
+ obs-FWS
+
+ctext = NO-WS-CTL / ; Non white space controls
+
+ %d33-39 / ; The rest of the US-ASCII
+ %d42-91 / ; characters not including "(",
+ %d93-126 ; ")", or "\"
+
+ccontent = ctext / quoted-pair / comment
+
+comment = "(" *([FWS] ccontent) [FWS] ")"
+
+CFWS = *([FWS] comment) (([FWS] comment) / FWS)
+
+ Throughout this standard, where FWS (the folding white space token)
+ appears, it indicates a place where header folding, as discussed in
+ section 2.2.3, may take place. Wherever header folding appears in a
+ message (that is, a header field body containing a CRLF followed by
+ any WSP), header unfolding (removal of the CRLF) is performed before
+ any further lexical analysis is performed on that header field
+ according to this standard. That is to say, any CRLF that appears in
+ FWS is semantically "invisible."
+
+ A comment is normally used in a structured field body to provide some
+ human readable informational text. Since a comment is allowed to
+ contain FWS, folding is permitted within the comment. Also note that
+ since quoted-pair is allowed in a comment, the parentheses and
+
+
+
+Resnick Standards Track [Page 11]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ backslash characters may appear in a comment so long as they appear
+ as a quoted-pair. Semantically, the enclosing parentheses are not
+ part of the comment; the comment is what is contained between the two
+ parentheses. As stated earlier, the "\" in any quoted-pair and the
+ CRLF in any FWS that appears within the comment are semantically
+ "invisible" and therefore not part of the comment either.
+
+ Runs of FWS, comment or CFWS that occur between lexical tokens in a
+ structured field header are semantically interpreted as a single
+ space character.
+
+3.2.4. Atom
+
+ Several productions in structured header field bodies are simply
+ strings of certain basic characters. Such productions are called
+ atoms.
+
+ Some of the structured header field bodies also allow the period
+ character (".", ASCII value 46) within runs of atext. An additional
+ "dot-atom" token is defined for those purposes.
+
+atext = ALPHA / DIGIT / ; Any character except controls,
+ "!" / "#" / ; SP, and specials.
+ "$" / "%" / ; Used for atoms
+ "&" / "'" /
+ "*" / "+" /
+ "-" / "/" /
+ "=" / "?" /
+ "^" / "_" /
+ "`" / "{" /
+ "|" / "}" /
+ "~"
+
+atom = [CFWS] 1*atext [CFWS]
+
+dot-atom = [CFWS] dot-atom-text [CFWS]
+
+dot-atom-text = 1*atext *("." 1*atext)
+
+ Both atom and dot-atom are interpreted as a single unit, comprised of
+ the string of characters that make it up. Semantically, the optional
+ comments and FWS surrounding the rest of the characters are not part
+ of the atom; the atom is only the run of atext characters in an atom,
+ or the atext and "." characters in a dot-atom.
+
+
+
+
+
+
+
+Resnick Standards Track [Page 12]
+
+RFC 2822 Internet Message Format April 2001
+
+
+3.2.5. Quoted strings
+
+ Strings of characters that include characters other than those
+ allowed in atoms may be represented in a quoted string format, where
+ the characters are surrounded by quote (DQUOTE, ASCII value 34)
+ characters.
+
+qtext = NO-WS-CTL / ; Non white space controls
+
+ %d33 / ; The rest of the US-ASCII
+ %d35-91 / ; characters not including "\"
+ %d93-126 ; or the quote character
+
+qcontent = qtext / quoted-pair
+
+quoted-string = [CFWS]
+ DQUOTE *([FWS] qcontent) [FWS] DQUOTE
+ [CFWS]
+
+ A quoted-string is treated as a unit. That is, quoted-string is
+ identical to atom, semantically. Since a quoted-string is allowed to
+ contain FWS, folding is permitted. Also note that since quoted-pair
+ is allowed in a quoted-string, the quote and backslash characters may
+ appear in a quoted-string so long as they appear as a quoted-pair.
+
+ Semantically, neither the optional CFWS outside of the quote
+ characters nor the quote characters themselves are part of the
+ quoted-string; the quoted-string is what is contained between the two
+ quote characters. As stated earlier, the "\" in any quoted-pair and
+ the CRLF in any FWS/CFWS that appears within the quoted-string are
+ semantically "invisible" and therefore not part of the quoted-string
+ either.
+
+3.2.6. Miscellaneous tokens
+
+ Three additional tokens are defined, word and phrase for combinations
+ of atoms and/or quoted-strings, and unstructured for use in
+ unstructured header fields and in some places within structured
+ header fields.
+
+word = atom / quoted-string
+
+phrase = 1*word / obs-phrase
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 13]
+
+RFC 2822 Internet Message Format April 2001
+
+
+utext = NO-WS-CTL / ; Non white space controls
+ %d33-126 / ; The rest of US-ASCII
+ obs-utext
+
+unstructured = *([FWS] utext) [FWS]
+
+3.3. Date and Time Specification
+
+ Date and time occur in several header fields. This section specifies
+ the syntax for a full date and time specification. Though folding
+ white space is permitted throughout the date-time specification, it
+ is RECOMMENDED that a single space be used in each place that FWS
+ appears (whether it is required or optional); some older
+ implementations may not interpret other occurrences of folding white
+ space correctly.
+
+date-time = [ day-of-week "," ] date FWS time [CFWS]
+
+day-of-week = ([FWS] day-name) / obs-day-of-week
+
+day-name = "Mon" / "Tue" / "Wed" / "Thu" /
+ "Fri" / "Sat" / "Sun"
+
+date = day month year
+
+year = 4*DIGIT / obs-year
+
+month = (FWS month-name FWS) / obs-month
+
+month-name = "Jan" / "Feb" / "Mar" / "Apr" /
+ "May" / "Jun" / "Jul" / "Aug" /
+ "Sep" / "Oct" / "Nov" / "Dec"
+
+day = ([FWS] 1*2DIGIT) / obs-day
+
+time = time-of-day FWS zone
+
+time-of-day = hour ":" minute [ ":" second ]
+
+hour = 2DIGIT / obs-hour
+
+minute = 2DIGIT / obs-minute
+
+second = 2DIGIT / obs-second
+
+zone = (( "+" / "-" ) 4DIGIT) / obs-zone
+
+
+
+
+
+Resnick Standards Track [Page 14]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ The day is the numeric day of the month. The year is any numeric
+ year 1900 or later.
+
+ The time-of-day specifies the number of hours, minutes, and
+ optionally seconds since midnight of the date indicated.
+
+ The date and time-of-day SHOULD express local time.
+
+ The zone specifies the offset from Coordinated Universal Time (UTC,
+ formerly referred to as "Greenwich Mean Time") that the date and
+ time-of-day represent. The "+" or "-" indicates whether the
+ time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
+ Universal Time. The first two digits indicate the number of hours
+ difference from Universal Time, and the last two digits indicate the
+ number of minutes difference from Universal Time. (Hence, +hhmm
+ means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
+ minutes). The form "+0000" SHOULD be used to indicate a time zone at
+ Universal Time. Though "-0000" also indicates Universal Time, it is
+ used to indicate that the time was generated on a system that may be
+ in a local time zone other than Universal Time and therefore
+ indicates that the date-time contains no information about the local
+ time zone.
+
+ A date-time specification MUST be semantically valid. That is, the
+ day-of-the-week (if included) MUST be the day implied by the date,
+ the numeric day-of-month MUST be between 1 and the number of days
+ allowed for the specified month (in the specified year), the
+ time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
+ number of seconds allowing for a leap second; see [STD12]), and the
+ zone MUST be within the range -9959 through +9959.
+
+3.4. Address Specification
+
+ Addresses occur in several message header fields to indicate senders
+ and recipients of messages. An address may either be an individual
+ mailbox, or a group of mailboxes.
+
+address = mailbox / group
+
+mailbox = name-addr / addr-spec
+
+name-addr = [display-name] angle-addr
+
+angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
+
+group = display-name ":" [mailbox-list / CFWS] ";"
+ [CFWS]
+
+
+
+
+Resnick Standards Track [Page 15]
+
+RFC 2822 Internet Message Format April 2001
+
+
+display-name = phrase
+
+mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
+
+address-list = (address *("," address)) / obs-addr-list
+
+ A mailbox receives mail. It is a conceptual entity which does not
+ necessarily pertain to file storage. For example, some sites may
+ choose to print mail on a printer and deliver the output to the
+ addressee's desk. Normally, a mailbox is comprised of two parts: (1)
+ an optional display name that indicates the name of the recipient
+ (which could be a person or a system) that could be displayed to the
+ user of a mail application, and (2) an addr-spec address enclosed in
+ angle brackets ("<" and ">"). There is also an alternate simple form
+ of a mailbox where the addr-spec address appears alone, without the
+ recipient's name or the angle brackets. The Internet addr-spec
+ address is described in section 3.4.1.
+
+ Note: Some legacy implementations used the simple form where the
+ addr-spec appears without the angle brackets, but included the name
+ of the recipient in parentheses as a comment following the addr-spec.
+ Since the meaning of the information in a comment is unspecified,
+ implementations SHOULD use the full name-addr form of the mailbox,
+ instead of the legacy form, to specify the display name associated
+ with a mailbox. Also, because some legacy implementations interpret
+ the comment, comments generally SHOULD NOT be used in address fields
+ to avoid confusing such implementations.
+
+ When it is desirable to treat several mailboxes as a single unit
+ (i.e., in a distribution list), the group construct can be used. The
+ group construct allows the sender to indicate a named group of
+ recipients. This is done by giving a display name for the group,
+ followed by a colon, followed by a comma separated list of any number
+ of mailboxes (including zero and one), and ending with a semicolon.
+ Because the list of mailboxes can be empty, using the group construct
+ is also a simple way to communicate to recipients that the message
+ was sent to one or more named sets of recipients, without actually
+ providing the individual mailbox address for each of those
+ recipients.
+
+3.4.1. Addr-spec specification
+
+ An addr-spec is a specific Internet identifier that contains a
+ locally interpreted string followed by the at-sign character ("@",
+ ASCII value 64) followed by an Internet domain. The locally
+ interpreted string is either a quoted-string or a dot-atom. If the
+ string can be represented as a dot-atom (that is, it contains no
+ characters other than atext characters or "." surrounded by atext
+
+
+
+Resnick Standards Track [Page 16]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ characters), then the dot-atom form SHOULD be used and the
+ quoted-string form SHOULD NOT be used. Comments and folding white
+ space SHOULD NOT be used around the "@" in the addr-spec.
+
+addr-spec = local-part "@" domain
+
+local-part = dot-atom / quoted-string / obs-local-part
+
+domain = dot-atom / domain-literal / obs-domain
+
+domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
+
+dcontent = dtext / quoted-pair
+
+dtext = NO-WS-CTL / ; Non white space controls
+
+ %d33-90 / ; The rest of the US-ASCII
+ %d94-126 ; characters not including "[",
+ ; "]", or "\"
+
+ The domain portion identifies the point to which the mail is
+ delivered. In the dot-atom form, this is interpreted as an Internet
+ domain name (either a host name or a mail exchanger name) as
+ described in [STD3, STD13, STD14]. In the domain-literal form, the
+ domain is interpreted as the literal Internet address of the
+ particular host. In both cases, how addressing is used and how
+ messages are transported to a particular host is covered in the mail
+ transport document [RFC2821]. These mechanisms are outside of the
+ scope of this document.
+
+ The local-part portion is a domain dependent string. In addresses,
+ it is simply interpreted on the particular host as a name of a
+ particular mailbox.
+
+3.5 Overall message syntax
+
+ A message consists of header fields, optionally followed by a message
+ body. Lines in a message MUST be a maximum of 998 characters
+ excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
+ characters excluding the CRLF. (See section 2.1.1 for explanation.)
+ In a message body, though all of the characters listed in the text
+ rule MAY be used, the use of US-ASCII control characters (values 1
+ through 8, 11, 12, and 14 through 31) is discouraged since their
+ interpretation by receivers for display is not guaranteed.
+
+
+
+
+
+
+
+Resnick Standards Track [Page 17]
+
+RFC 2822 Internet Message Format April 2001
+
+
+message = (fields / obs-fields)
+ [CRLF body]
+
+body = *(*998text CRLF) *998text
+
+ The header fields carry most of the semantic information and are
+ defined in section 3.6. The body is simply a series of lines of text
+ which are uninterpreted for the purposes of this standard.
+
+3.6. Field definitions
+
+ The header fields of a message are defined here. All header fields
+ have the same general syntactic structure: A field name, followed by
+ a colon, followed by the field body. The specific syntax for each
+ header field is defined in the subsequent sections.
+
+ Note: In the ABNF syntax for each field in subsequent sections, each
+ field name is followed by the required colon. However, for brevity
+ sometimes the colon is not referred to in the textual description of
+ the syntax. It is, nonetheless, required.
+
+ It is important to note that the header fields are not guaranteed to
+ be in a particular order. They may appear in any order, and they
+ have been known to be reordered occasionally when transported over
+ the Internet. However, for the purposes of this standard, header
+ fields SHOULD NOT be reordered when a message is transported or
+ transformed. More importantly, the trace header fields and resent
+ header fields MUST NOT be reordered, and SHOULD be kept in blocks
+ prepended to the message. See sections 3.6.6 and 3.6.7 for more
+ information.
+
+ The only required header fields are the origination date field and
+ the originator address field(s). All other header fields are
+ syntactically optional. More information is contained in the table
+ following this definition.
+
+fields = *(trace
+ *(resent-date /
+ resent-from /
+ resent-sender /
+ resent-to /
+ resent-cc /
+ resent-bcc /
+ resent-msg-id))
+ *(orig-date /
+ from /
+ sender /
+ reply-to /
+
+
+
+Resnick Standards Track [Page 18]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ to /
+ cc /
+ bcc /
+ message-id /
+ in-reply-to /
+ references /
+ subject /
+ comments /
+ keywords /
+ optional-field)
+
+ The following table indicates limits on the number of times each
+ field may occur in a message header as well as any special
+ limitations on the use of those fields. An asterisk next to a value
+ in the minimum or maximum column indicates that a special restriction
+ appears in the Notes column.
+
+Field Min number Max number Notes
+
+trace 0 unlimited Block prepended - see
+ 3.6.7
+
+resent-date 0* unlimited* One per block, required
+ if other resent fields
+ present - see 3.6.6
+
+resent-from 0 unlimited* One per block - see
+ 3.6.6
+
+resent-sender 0* unlimited* One per block, MUST
+ occur with multi-address
+ resent-from - see 3.6.6
+
+resent-to 0 unlimited* One per block - see
+ 3.6.6
+
+resent-cc 0 unlimited* One per block - see
+ 3.6.6
+
+resent-bcc 0 unlimited* One per block - see
+ 3.6.6
+
+resent-msg-id 0 unlimited* One per block - see
+ 3.6.6
+
+orig-date 1 1
+
+from 1 1 See sender and 3.6.2
+
+
+
+Resnick Standards Track [Page 19]
+
+RFC 2822 Internet Message Format April 2001
+
+
+sender 0* 1 MUST occur with multi-
+ address from - see 3.6.2
+
+reply-to 0 1
+
+to 0 1
+
+cc 0 1
+
+bcc 0 1
+
+message-id 0* 1 SHOULD be present - see
+ 3.6.4
+
+in-reply-to 0* 1 SHOULD occur in some
+ replies - see 3.6.4
+
+references 0* 1 SHOULD occur in some
+ replies - see 3.6.4
+
+subject 0 1
+
+comments 0 unlimited
+
+keywords 0 unlimited
+
+optional-field 0 unlimited
+
+ The exact interpretation of each field is described in subsequent
+ sections.
+
+3.6.1. The origination date field
+
+ The origination date field consists of the field name "Date" followed
+ by a date-time specification.
+
+orig-date = "Date:" date-time CRLF
+
+ The origination date specifies the date and time at which the creator
+ of the message indicated that the message was complete and ready to
+ enter the mail delivery system. For instance, this might be the time
+ that a user pushes the "send" or "submit" button in an application
+ program. In any case, it is specifically not intended to convey the
+ time that the message is actually transported, but rather the time at
+ which the human or other creator of the message has put the message
+ into its final form, ready for transport. (For example, a portable
+ computer user who is not connected to a network might queue a message
+
+
+
+
+Resnick Standards Track [Page 20]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ for delivery. The origination date is intended to contain the date
+ and time that the user queued the message, not the time when the user
+ connected to the network to send the message.)
+
+3.6.2. Originator fields
+
+ The originator fields of a message consist of the from field, the
+ sender field (when applicable), and optionally the reply-to field.
+ The from field consists of the field name "From" and a
+ comma-separated list of one or more mailbox specifications. If the
+ from field contains more than one mailbox specification in the
+ mailbox-list, then the sender field, containing the field name
+ "Sender" and a single mailbox specification, MUST appear in the
+ message. In either case, an optional reply-to field MAY also be
+ included, which contains the field name "Reply-To" and a
+ comma-separated list of one or more addresses.
+
+from = "From:" mailbox-list CRLF
+
+sender = "Sender:" mailbox CRLF
+
+reply-to = "Reply-To:" address-list CRLF
+
+ The originator fields indicate the mailbox(es) of the source of the
+ message. The "From:" field specifies the author(s) of the message,
+ that is, the mailbox(es) of the person(s) or system(s) responsible
+ for the writing of the message. The "Sender:" field specifies the
+ mailbox of the agent responsible for the actual transmission of the
+ message. For example, if a secretary were to send a message for
+ another person, the mailbox of the secretary would appear in the
+ "Sender:" field and the mailbox of the actual author would appear in
+ the "From:" field. If the originator of the message can be indicated
+ by a single mailbox and the author and transmitter are identical, the
+ "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
+ appear.
+
+ The originator fields also provide the information required when
+ replying to a message. When the "Reply-To:" field is present, it
+ indicates the mailbox(es) to which the author of the message suggests
+ that replies be sent. In the absence of the "Reply-To:" field,
+ replies SHOULD by default be sent to the mailbox(es) specified in the
+ "From:" field unless otherwise specified by the person composing the
+ reply.
+
+ In all cases, the "From:" field SHOULD NOT contain any mailbox that
+ does not belong to the author(s) of the message. See also section
+ 3.6.3 for more information on forming the destination addresses for a
+ reply.
+
+
+
+Resnick Standards Track [Page 21]
+
+RFC 2822 Internet Message Format April 2001
+
+
+3.6.3. Destination address fields
+
+ The destination fields of a message consist of three possible fields,
+ each of the same form: The field name, which is either "To", "Cc", or
+ "Bcc", followed by a comma-separated list of one or more addresses
+ (either mailbox or group syntax).
+
+to = "To:" address-list CRLF
+
+cc = "Cc:" address-list CRLF
+
+bcc = "Bcc:" (address-list / [CFWS]) CRLF
+
+ The destination fields specify the recipients of the message. Each
+ destination field may have one or more addresses, and each of the
+ addresses indicate the intended recipients of the message. The only
+ difference between the three fields is how each is used.
+
+ The "To:" field contains the address(es) of the primary recipient(s)
+ of the message.
+
+ The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
+ making a copy on a typewriter using carbon paper) contains the
+ addresses of others who are to receive the message, though the
+ content of the message may not be directed at them.
+
+ The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
+ addresses of recipients of the message whose addresses are not to be
+ revealed to other recipients of the message. There are three ways in
+ which the "Bcc:" field is used. In the first case, when a message
+ containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
+ removed even though all of the recipients (including those specified
+ in the "Bcc:" field) are sent a copy of the message. In the second
+ case, recipients specified in the "To:" and "Cc:" lines each are sent
+ a copy of the message with the "Bcc:" line removed as above, but the
+ recipients on the "Bcc:" line get a separate copy of the message
+ containing a "Bcc:" line. (When there are multiple recipient
+ addresses in the "Bcc:" field, some implementations actually send a
+ separate copy of the message to each recipient with a "Bcc:"
+ containing only the address of that particular recipient.) Finally,
+ since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
+ sent without any addresses indicating to the recipients that blind
+ copies were sent to someone. Which method to use with "Bcc:" fields
+ is implementation dependent, but refer to the "Security
+ Considerations" section of this document for a discussion of each.
+
+
+
+
+
+
+Resnick Standards Track [Page 22]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ When a message is a reply to another message, the mailboxes of the
+ authors of the original message (the mailboxes in the "From:" field)
+ or mailboxes specified in the "Reply-To:" field (if it exists) MAY
+ appear in the "To:" field of the reply since these would normally be
+ the primary recipients of the reply. If a reply is sent to a message
+ that has destination fields, it is often desirable to send a copy of
+ the reply to all of the recipients of the message, in addition to the
+ author. When such a reply is formed, addresses in the "To:" and
+ "Cc:" fields of the original message MAY appear in the "Cc:" field of
+ the reply, since these are normally secondary recipients of the
+ reply. If a "Bcc:" field is present in the original message,
+ addresses in that field MAY appear in the "Bcc:" field of the reply,
+ but SHOULD NOT appear in the "To:" or "Cc:" fields.
+
+ Note: Some mail applications have automatic reply commands that
+ include the destination addresses of the original message in the
+ destination addresses of the reply. How those reply commands behave
+ is implementation dependent and is beyond the scope of this document.
+ In particular, whether or not to include the original destination
+ addresses when the original message had a "Reply-To:" field is not
+ addressed here.
+
+3.6.4. Identification fields
+
+ Though optional, every message SHOULD have a "Message-ID:" field.
+ Furthermore, reply messages SHOULD have "In-Reply-To:" and
+ "References:" fields as appropriate, as described below.
+
+ The "Message-ID:" field contains a single unique message identifier.
+ The "References:" and "In-Reply-To:" field each contain one or more
+ unique message identifiers, optionally separated by CFWS.
+
+ The message identifier (msg-id) is similar in syntax to an angle-addr
+ construct without the internal CFWS.
+
+message-id = "Message-ID:" msg-id CRLF
+
+in-reply-to = "In-Reply-To:" 1*msg-id CRLF
+
+references = "References:" 1*msg-id CRLF
+
+msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
+
+id-left = dot-atom-text / no-fold-quote / obs-id-left
+
+id-right = dot-atom-text / no-fold-literal / obs-id-right
+
+no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE
+
+
+
+Resnick Standards Track [Page 23]
+
+RFC 2822 Internet Message Format April 2001
+
+
+no-fold-literal = "[" *(dtext / quoted-pair) "]"
+
+ The "Message-ID:" field provides a unique message identifier that
+ refers to a particular version of a particular message. The
+ uniqueness of the message identifier is guaranteed by the host that
+ generates it (see below). This message identifier is intended to be
+ machine readable and not necessarily meaningful to humans. A message
+ identifier pertains to exactly one instantiation of a particular
+ message; subsequent revisions to the message each receive new message
+ identifiers.
+
+ Note: There are many instances when messages are "changed", but those
+ changes do not constitute a new instantiation of that message, and
+ therefore the message would not get a new message identifier. For
+ example, when messages are introduced into the transport system, they
+ are often prepended with additional header fields such as trace
+ fields (described in section 3.6.7) and resent fields (described in
+ section 3.6.6). The addition of such header fields does not change
+ the identity of the message and therefore the original "Message-ID:"
+ field is retained. In all cases, it is the meaning that the sender
+ of the message wishes to convey (i.e., whether this is the same
+ message or a different message) that determines whether or not the
+ "Message-ID:" field changes, not any particular syntactic difference
+ that appears (or does not appear) in the message.
+
+ The "In-Reply-To:" and "References:" fields are used when creating a
+ reply to a message. They hold the message identifier of the original
+ message and the message identifiers of other messages (for example,
+ in the case of a reply to a message which was itself a reply). The
+ "In-Reply-To:" field may be used to identify the message (or
+ messages) to which the new message is a reply, while the
+ "References:" field may be used to identify a "thread" of
+ conversation.
+
+ When creating a reply to a message, the "In-Reply-To:" and
+ "References:" fields of the resultant message are constructed as
+ follows:
+
+ The "In-Reply-To:" field will contain the contents of the "Message-
+ ID:" field of the message to which this one is a reply (the "parent
+ message"). If there is more than one parent message, then the "In-
+ Reply-To:" field will contain the contents of all of the parents'
+ "Message-ID:" fields. If there is no "Message-ID:" field in any of
+ the parent messages, then the new message will have no "In-Reply-To:"
+ field.
+
+
+
+
+
+
+Resnick Standards Track [Page 24]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ The "References:" field will contain the contents of the parent's
+ "References:" field (if any) followed by the contents of the parent's
+ "Message-ID:" field (if any). If the parent message does not contain
+ a "References:" field but does have an "In-Reply-To:" field
+ containing a single message identifier, then the "References:" field
+ will contain the contents of the parent's "In-Reply-To:" field
+ followed by the contents of the parent's "Message-ID:" field (if
+ any). If the parent has none of the "References:", "In-Reply-To:",
+ or "Message-ID:" fields, then the new message will have no
+ "References:" field.
+
+ Note: Some implementations parse the "References:" field to display
+ the "thread of the discussion". These implementations assume that
+ each new message is a reply to a single parent and hence that they
+ can walk backwards through the "References:" field to find the parent
+ of each message listed there. Therefore, trying to form a
+ "References:" field for a reply that has multiple parents is
+ discouraged and how to do so is not defined in this document.
+
+ The message identifier (msg-id) itself MUST be a globally unique
+ identifier for a message. The generator of the message identifier
+ MUST guarantee that the msg-id is unique. There are several
+ algorithms that can be used to accomplish this. Since the msg-id has
+ a similar syntax to angle-addr (identical except that comments and
+ folding white space are not allowed), a good method is to put the
+ domain name (or a domain literal IP address) of the host on which the
+ message identifier was created on the right hand side of the "@", and
+ put a combination of the current absolute date and time along with
+ some other currently unique (perhaps sequential) identifier available
+ on the system (for example, a process id number) on the left hand
+ side. Using a date on the left hand side and a domain name or domain
+ literal on the right hand side makes it possible to guarantee
+ uniqueness since no two hosts use the same domain name or IP address
+ at the same time. Though other algorithms will work, it is
+ RECOMMENDED that the right hand side contain some domain identifier
+ (either of the host itself or otherwise) such that the generator of
+ the message identifier can guarantee the uniqueness of the left hand
+ side within the scope of that domain.
+
+ Semantically, the angle bracket characters are not part of the
+ msg-id; the msg-id is what is contained between the two angle bracket
+ characters.
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 25]
+
+RFC 2822 Internet Message Format April 2001
+
+
+3.6.5. Informational fields
+
+ The informational fields are all optional. The "Keywords:" field
+ contains a comma-separated list of one or more words or
+ quoted-strings. The "Subject:" and "Comments:" fields are
+ unstructured fields as defined in section 2.2.1, and therefore may
+ contain text or folding white space.
+
+subject = "Subject:" unstructured CRLF
+
+comments = "Comments:" unstructured CRLF
+
+keywords = "Keywords:" phrase *("," phrase) CRLF
+
+ These three fields are intended to have only human-readable content
+ with information about the message. The "Subject:" field is the most
+ common and contains a short string identifying the topic of the
+ message. When used in a reply, the field body MAY start with the
+ string "Re: " (from the Latin "res", in the matter of) followed by
+ the contents of the "Subject:" field body of the original message.
+ If this is done, only one instance of the literal string "Re: " ought
+ to be used since use of other strings or more than one instance can
+ lead to undesirable consequences. The "Comments:" field contains any
+ additional comments on the text of the body of the message. The
+ "Keywords:" field contains a comma-separated list of important words
+ and phrases that might be useful for the recipient.
+
+3.6.6. Resent fields
+
+ Resent fields SHOULD be added to any message that is reintroduced by
+ a user into the transport system. A separate set of resent fields
+ SHOULD be added each time this is done. All of the resent fields
+ corresponding to a particular resending of the message SHOULD be
+ together. Each new set of resent fields is prepended to the message;
+ that is, the most recent set of resent fields appear earlier in the
+ message. No other fields in the message are changed when resent
+ fields are added.
+
+ Each of the resent fields corresponds to a particular field elsewhere
+ in the syntax. For instance, the "Resent-Date:" field corresponds to
+ the "Date:" field and the "Resent-To:" field corresponds to the "To:"
+ field. In each case, the syntax for the field body is identical to
+ the syntax given previously for the corresponding field.
+
+ When resent fields are used, the "Resent-From:" and "Resent-Date:"
+ fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
+ "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
+ identical to "Resent-From:".
+
+
+
+Resnick Standards Track [Page 26]
+
+RFC 2822 Internet Message Format April 2001
+
+
+resent-date = "Resent-Date:" date-time CRLF
+
+resent-from = "Resent-From:" mailbox-list CRLF
+
+resent-sender = "Resent-Sender:" mailbox CRLF
+
+resent-to = "Resent-To:" address-list CRLF
+
+resent-cc = "Resent-Cc:" address-list CRLF
+
+resent-bcc = "Resent-Bcc:" (address-list / [CFWS]) CRLF
+
+resent-msg-id = "Resent-Message-ID:" msg-id CRLF
+
+ Resent fields are used to identify a message as having been
+ reintroduced into the transport system by a user. The purpose of
+ using resent fields is to have the message appear to the final
+ recipient as if it were sent directly by the original sender, with
+ all of the original fields remaining the same. Each set of resent
+ fields correspond to a particular resending event. That is, if a
+ message is resent multiple times, each set of resent fields gives
+ identifying information for each individual time. Resent fields are
+ strictly informational. They MUST NOT be used in the normal
+ processing of replies or other such automatic actions on messages.
+
+ Note: Reintroducing a message into the transport system and using
+ resent fields is a different operation from "forwarding".
+ "Forwarding" has two meanings: One sense of forwarding is that a mail
+ reading program can be told by a user to forward a copy of a message
+ to another person, making the forwarded message the body of the new
+ message. A forwarded message in this sense does not appear to have
+ come from the original sender, but is an entirely new message from
+ the forwarder of the message. On the other hand, forwarding is also
+ used to mean when a mail transport program gets a message and
+ forwards it on to a different destination for final delivery. Resent
+ header fields are not intended for use with either type of
+ forwarding.
+
+ The resent originator fields indicate the mailbox of the person(s) or
+ system(s) that resent the message. As with the regular originator
+ fields, there are two forms: a simple "Resent-From:" form which
+ contains the mailbox of the individual doing the resending, and the
+ more complex form, when one individual (identified in the
+ "Resent-Sender:" field) resends a message on behalf of one or more
+ others (identified in the "Resent-From:" field).
+
+ Note: When replying to a resent message, replies behave just as they
+ would with any other message, using the original "From:",
+
+
+
+Resnick Standards Track [Page 27]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ "Reply-To:", "Message-ID:", and other fields. The resent fields are
+ only informational and MUST NOT be used in the normal processing of
+ replies.
+
+ The "Resent-Date:" indicates the date and time at which the resent
+ message is dispatched by the resender of the message. Like the
+ "Date:" field, it is not the date and time that the message was
+ actually transported.
+
+ The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
+ identically to the "To:", "Cc:", and "Bcc:" fields respectively,
+ except that they indicate the recipients of the resent message, not
+ the recipients of the original message.
+
+ The "Resent-Message-ID:" field provides a unique identifier for the
+ resent message.
+
+3.6.7. Trace fields
+
+ The trace fields are a group of header fields consisting of an
+ optional "Return-Path:" field, and one or more "Received:" fields.
+ The "Return-Path:" header field contains a pair of angle brackets
+ that enclose an optional addr-spec. The "Received:" field contains a
+ (possibly empty) list of name/value pairs followed by a semicolon and
+ a date-time specification. The first item of the name/value pair is
+ defined by item-name, and the second item is either an addr-spec, an
+ atom, a domain, or a msg-id. Further restrictions may be applied to
+ the syntax of the trace fields by standards that provide for their
+ use, such as [RFC2821].
+
+trace = [return]
+ 1*received
+
+return = "Return-Path:" path CRLF
+
+path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) /
+ obs-path
+
+received = "Received:" name-val-list ";" date-time CRLF
+
+name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)]
+
+name-val-pair = item-name CFWS item-value
+
+item-name = ALPHA *(["-"] (ALPHA / DIGIT))
+
+item-value = 1*angle-addr / addr-spec /
+ atom / domain / msg-id
+
+
+
+Resnick Standards Track [Page 28]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ A full discussion of the Internet mail use of trace fields is
+ contained in [RFC2821]. For the purposes of this standard, the trace
+ fields are strictly informational, and any formal interpretation of
+ them is outside of the scope of this document.
+
+3.6.8. Optional fields
+
+ Fields may appear in messages that are otherwise unspecified in this
+ standard. They MUST conform to the syntax of an optional-field.
+ This is a field name, made up of the printable US-ASCII characters
+ except SP and colon, followed by a colon, followed by any text which
+ conforms to unstructured.
+
+ The field names of any optional-field MUST NOT be identical to any
+ field name specified elsewhere in this standard.
+
+optional-field = field-name ":" unstructured CRLF
+
+field-name = 1*ftext
+
+ftext = %d33-57 / ; Any character except
+ %d59-126 ; controls, SP, and
+ ; ":".
+
+ For the purposes of this standard, any optional field is
+ uninterpreted.
+
+4. Obsolete Syntax
+
+ Earlier versions of this standard allowed for different (usually more
+ liberal) syntax than is allowed in this version. Also, there have
+ been syntactic elements used in messages on the Internet whose
+ interpretation have never been documented. Though some of these
+ syntactic forms MUST NOT be generated according to the grammar in
+ section 3, they MUST be accepted and parsed by a conformant receiver.
+ This section documents many of these syntactic elements. Taking the
+ grammar in section 3 and adding the definitions presented in this
+ section will result in the grammar to use for interpretation of
+ messages.
+
+ Note: This section identifies syntactic forms that any implementation
+ MUST reasonably interpret. However, there are certainly Internet
+ messages which do not conform to even the additional syntax given in
+ this section. The fact that a particular form does not appear in any
+ section of this document is not justification for computer programs
+ to crash or for malformed data to be irretrievably lost by any
+ implementation. To repeat an example, though this document requires
+ lines in messages to be no longer than 998 characters, silently
+
+
+
+Resnick Standards Track [Page 29]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ discarding the 999th and subsequent characters in a line without
+ warning would still be bad behavior for an implementation. It is up
+ to the implementation to deal with messages robustly.
+
+ One important difference between the obsolete (interpreting) and the
+ current (generating) syntax is that in structured header field bodies
+ (i.e., between the colon and the CRLF of any structured header
+ field), white space characters, including folding white space, and
+ comments can be freely inserted between any syntactic tokens. This
+ allows many complex forms that have proven difficult for some
+ implementations to parse.
+
+ Another key difference between the obsolete and the current syntax is
+ that the rule in section 3.2.3 regarding lines composed entirely of
+ white space in comments and folding white space does not apply. See
+ the discussion of folding white space in section 4.2 below.
+
+ Finally, certain characters that were formerly allowed in messages
+ appear in this section. The NUL character (ASCII value 0) was once
+ allowed, but is no longer for compatibility reasons. CR and LF were
+ allowed to appear in messages other than as CRLF; this use is also
+ shown here.
+
+ Other differences in syntax and semantics are noted in the following
+ sections.
+
+4.1. Miscellaneous obsolete tokens
+
+ These syntactic elements are used elsewhere in the obsolete syntax or
+ in the main syntax. The obs-char and obs-qp elements each add ASCII
+ value 0. Bare CR and bare LF are added to obs-text and obs-utext.
+ The period character is added to obs-phrase. The obs-phrase-list
+ provides for "empty" elements in a comma-separated list of phrases.
+
+ Note: The "period" (or "full stop") character (".") in obs-phrase is
+ not a form that was allowed in earlier versions of this or any other
+ standard. Period (nor any other character from specials) was not
+ allowed in phrase because it introduced a parsing difficulty
+ distinguishing between phrases and portions of an addr-spec (see
+ section 4.4). It appears here because the period character is
+ currently used in many messages in the display-name portion of
+ addresses, especially for initials in names, and therefore must be
+ interpreted properly. In the future, period may appear in the
+ regular syntax of phrase.
+
+obs-qp = "\" (%d0-127)
+
+obs-text = *LF *CR *(obs-char *LF *CR)
+
+
+
+Resnick Standards Track [Page 30]
+
+RFC 2822 Internet Message Format April 2001
+
+
+obs-char = %d0-9 / %d11 / ; %d0-127 except CR and
+ %d12 / %d14-127 ; LF
+
+obs-utext = obs-text
+
+obs-phrase = word *(word / "." / CFWS)
+
+obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase]
+
+ Bare CR and bare LF appear in messages with two different meanings.
+ In many cases, bare CR or bare LF are used improperly instead of CRLF
+ to indicate line separators. In other cases, bare CR and bare LF are
+ used simply as ASCII control characters with their traditional ASCII
+ meanings.
+
+4.2. Obsolete folding white space
+
+ In the obsolete syntax, any amount of folding white space MAY be
+ inserted where the obs-FWS rule is allowed. This creates the
+ possibility of having two consecutive "folds" in a line, and
+ therefore the possibility that a line which makes up a folded header
+ field could be composed entirely of white space.
+
+ obs-FWS = 1*WSP *(CRLF 1*WSP)
+
+4.3. Obsolete Date and Time
+
+ The syntax for the obsolete date format allows a 2 digit year in the
+ date field and allows for a list of alphabetic time zone
+ specifications that were used in earlier versions of this standard.
+ It also permits comments and folding white space between many of the
+ tokens.
+
+obs-day-of-week = [CFWS] day-name [CFWS]
+
+obs-year = [CFWS] 2*DIGIT [CFWS]
+
+obs-month = CFWS month-name CFWS
+
+obs-day = [CFWS] 1*2DIGIT [CFWS]
+
+obs-hour = [CFWS] 2DIGIT [CFWS]
+
+obs-minute = [CFWS] 2DIGIT [CFWS]
+
+obs-second = [CFWS] 2DIGIT [CFWS]
+
+obs-zone = "UT" / "GMT" / ; Universal Time
+
+
+
+Resnick Standards Track [Page 31]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ ; North American UT
+ ; offsets
+ "EST" / "EDT" / ; Eastern: - 5/ - 4
+ "CST" / "CDT" / ; Central: - 6/ - 5
+ "MST" / "MDT" / ; Mountain: - 7/ - 6
+ "PST" / "PDT" / ; Pacific: - 8/ - 7
+
+ %d65-73 / ; Military zones - "A"
+ %d75-90 / ; through "I" and "K"
+ %d97-105 / ; through "Z", both
+ %d107-122 ; upper and lower case
+
+ Where a two or three digit year occurs in a date, the year is to be
+ interpreted as follows: If a two digit year is encountered whose
+ value is between 00 and 49, the year is interpreted by adding 2000,
+ ending up with a value between 2000 and 2049. If a two digit year is
+ encountered with a value between 50 and 99, or any three digit year
+ is encountered, the year is interpreted by adding 1900.
+
+ In the obsolete time zone, "UT" and "GMT" are indications of
+ "Universal Time" and "Greenwich Mean Time" respectively and are both
+ semantically identical to "+0000".
+
+ The remaining three character zones are the US time zones. The first
+ letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
+ "Mountain" and "Pacific". The second letter is either "S" for
+ "Standard" time, or "D" for "Daylight" (or summer) time. Their
+ interpretations are as follows:
+
+ EDT is semantically equivalent to -0400
+ EST is semantically equivalent to -0500
+ CDT is semantically equivalent to -0500
+ CST is semantically equivalent to -0600
+ MDT is semantically equivalent to -0600
+ MST is semantically equivalent to -0700
+ PDT is semantically equivalent to -0700
+ PST is semantically equivalent to -0800
+
+ The 1 character military time zones were defined in a non-standard
+ way in [RFC822] and are therefore unpredictable in their meaning.
+ The original definitions of the military zones "A" through "I" are
+ equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
+ are equivalent to "+1000", "+1100", and "+1200" respectively; "N"
+ through "Y" are equivalent to "-0100" through "-1200" respectively;
+ and "Z" is equivalent to "+0000". However, because of the error in
+ [RFC822], they SHOULD all be considered equivalent to "-0000" unless
+ there is out-of-band information confirming their meaning.
+
+
+
+
+Resnick Standards Track [Page 32]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ Other multi-character (usually between 3 and 5) alphabetic time zones
+ have been used in Internet messages. Any such time zone whose
+ meaning is not known SHOULD be considered equivalent to "-0000"
+ unless there is out-of-band information confirming their meaning.
+
+4.4. Obsolete Addressing
+
+ There are three primary differences in addressing. First, mailbox
+ addresses were allowed to have a route portion before the addr-spec
+ when enclosed in "<" and ">". The route is simply a comma-separated
+ list of domain names, each preceded by "@", and the list terminated
+ by a colon. Second, CFWS were allowed between the period-separated
+ elements of local-part and domain (i.e., dot-atom was not used). In
+ addition, local-part is allowed to contain quoted-string in addition
+ to just atom. Finally, mailbox-list and address-list were allowed to
+ have "null" members. That is, there could be two or more commas in
+ such a list with nothing in between them.
+
+obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS]
+
+obs-route = [CFWS] obs-domain-list ":" [CFWS]
+
+obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)
+
+obs-local-part = word *("." word)
+
+obs-domain = atom *("." atom)
+
+obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox]
+
+obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address]
+
+ When interpreting addresses, the route portion SHOULD be ignored.
+
+4.5. Obsolete header fields
+
+ Syntactically, the primary difference in the obsolete field syntax is
+ that it allows multiple occurrences of any of the fields and they may
+ occur in any order. Also, any amount of white space is allowed
+ before the ":" at the end of the field name.
+
+obs-fields = *(obs-return /
+ obs-received /
+ obs-orig-date /
+ obs-from /
+ obs-sender /
+ obs-reply-to /
+ obs-to /
+
+
+
+Resnick Standards Track [Page 33]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ obs-cc /
+ obs-bcc /
+ obs-message-id /
+ obs-in-reply-to /
+ obs-references /
+ obs-subject /
+ obs-comments /
+ obs-keywords /
+ obs-resent-date /
+ obs-resent-from /
+ obs-resent-send /
+ obs-resent-rply /
+ obs-resent-to /
+ obs-resent-cc /
+ obs-resent-bcc /
+ obs-resent-mid /
+ obs-optional)
+
+ Except for destination address fields (described in section 4.5.3),
+ the interpretation of multiple occurrences of fields is unspecified.
+ Also, the interpretation of trace fields and resent fields which do
+ not occur in blocks prepended to the message is unspecified as well.
+ Unless otherwise noted in the following sections, interpretation of
+ other fields is identical to the interpretation of their non-obsolete
+ counterparts in section 3.
+
+4.5.1. Obsolete origination date field
+
+obs-orig-date = "Date" *WSP ":" date-time CRLF
+
+4.5.2. Obsolete originator fields
+
+obs-from = "From" *WSP ":" mailbox-list CRLF
+
+obs-sender = "Sender" *WSP ":" mailbox CRLF
+
+obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF
+
+4.5.3. Obsolete destination address fields
+
+obs-to = "To" *WSP ":" address-list CRLF
+
+obs-cc = "Cc" *WSP ":" address-list CRLF
+
+obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF
+
+
+
+
+
+
+Resnick Standards Track [Page 34]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ When multiple occurrences of destination address fields occur in a
+ message, they SHOULD be treated as if the address-list in the first
+ occurrence of the field is combined with the address lists of the
+ subsequent occurrences by adding a comma and concatenating.
+
+4.5.4. Obsolete identification fields
+
+ The obsolete "In-Reply-To:" and "References:" fields differ from the
+ current syntax in that they allow phrase (words or quoted strings) to
+ appear. The obsolete forms of the left and right sides of msg-id
+ allow interspersed CFWS, making them syntactically identical to
+ local-part and domain respectively.
+
+obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
+
+obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
+
+obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
+
+obs-id-left = local-part
+
+obs-id-right = domain
+
+ For purposes of interpretation, the phrases in the "In-Reply-To:" and
+ "References:" fields are ignored.
+
+ Semantically, none of the optional CFWS surrounding the local-part
+ and the domain are part of the obs-id-left and obs-id-right
+ respectively.
+
+4.5.5. Obsolete informational fields
+
+obs-subject = "Subject" *WSP ":" unstructured CRLF
+
+obs-comments = "Comments" *WSP ":" unstructured CRLF
+
+obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
+
+4.5.6. Obsolete resent fields
+
+ The obsolete syntax adds a "Resent-Reply-To:" field, which consists
+ of the field name, the optional comments and folding white space, the
+ colon, and a comma separated list of addresses.
+
+obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
+
+obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
+
+
+
+
+Resnick Standards Track [Page 35]
+
+RFC 2822 Internet Message Format April 2001
+
+
+obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
+
+obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
+
+obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
+
+obs-resent-bcc = "Resent-Bcc" *WSP ":"
+ (address-list / [CFWS]) CRLF
+
+obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
+
+obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
+
+ As with other resent fields, the "Resent-Reply-To:" field is to be
+ treated as trace information only.
+
+4.5.7. Obsolete trace fields
+
+ The obs-return and obs-received are again given here as template
+ definitions, just as return and received are in section 3. Their
+ full syntax is given in [RFC2821].
+
+obs-return = "Return-Path" *WSP ":" path CRLF
+
+obs-received = "Received" *WSP ":" name-val-list CRLF
+
+obs-path = obs-angle-addr
+
+4.5.8. Obsolete optional fields
+
+obs-optional = field-name *WSP ":" unstructured CRLF
+
+5. Security Considerations
+
+ Care needs to be taken when displaying messages on a terminal or
+ terminal emulator. Powerful terminals may act on escape sequences
+ and other combinations of ASCII control characters with a variety of
+ consequences. They can remap the keyboard or permit other
+ modifications to the terminal which could lead to denial of service
+ or even damaged data. They can trigger (sometimes programmable)
+ answerback messages which can allow a message to cause commands to be
+ issued on the recipient's behalf. They can also effect the operation
+ of terminal attached devices such as printers. Message viewers may
+ wish to strip potentially dangerous terminal escape sequences from
+ the message prior to display. However, other escape sequences appear
+ in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047,
+ RFC2048, RFC2049, ISO2022]) and therefore should not be stripped
+ indiscriminately.
+
+
+
+Resnick Standards Track [Page 36]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ Transmission of non-text objects in messages raises additional
+ security issues. These issues are discussed in [RFC2045, RFC2046,
+ RFC2047, RFC2048, RFC2049].
+
+ Many implementations use the "Bcc:" (blind carbon copy) field
+ described in section 3.6.3 to facilitate sending messages to
+ recipients without revealing the addresses of one or more of the
+ addressees to the other recipients. Mishandling this use of "Bcc:"
+ has implications for confidential information that might be revealed,
+ which could eventually lead to security problems through knowledge of
+ even the existence of a particular mail address. For example, if
+ using the first method described in section 3.6.3, where the "Bcc:"
+ line is removed from the message, blind recipients have no explicit
+ indication that they have been sent a blind copy, except insofar as
+ their address does not appear in the message header. Because of
+ this, one of the blind addressees could potentially send a reply to
+ all of the shown recipients and accidentally reveal that the message
+ went to the blind recipient. When the second method from section
+ 3.6.3 is used, the blind recipient's address appears in the "Bcc:"
+ field of a separate copy of the message. If the "Bcc:" field sent
+ contains all of the blind addressees, all of the "Bcc:" recipients
+ will be seen by each "Bcc:" recipient. Even if a separate message is
+ sent to each "Bcc:" recipient with only the individual's address,
+ implementations still need to be careful to process replies to the
+ message as per section 3.6.3 so as not to accidentally reveal the
+ blind recipient to other recipients.
+
+6. Bibliography
+
+ [ASCII] American National Standards Institute (ANSI), Coded
+ Character Set - 7-Bit American National Standard Code for
+ Information Interchange, ANSI X3.4, 1986.
+
+ [ISO2022] International Organization for Standardization (ISO),
+ Information processing - ISO 7-bit and 8-bit coded
+ character sets - Code extension techniques, Third edition
+ - 1986-05-01, ISO 2022, 1986.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", RFC 822, August 1982.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ November 1996.
+
+
+
+Resnick Standards Track [Page 37]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
+ Part Three: Message Header Extensions for Non-ASCII Text",
+ RFC 2047, November 1996.
+
+ [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
+ Internet Mail Extensions (MIME) Part Four: Format of
+ Internet Message Bodies", RFC 2048, November 1996.
+
+ [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Five: Conformance Criteria and
+ Examples", RFC 2049, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
+ 2821, March 2001.
+
+ [STD3] Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC
+ 1123, October 1989.
+
+ [STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119,
+ September 1989.
+
+ [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034
+ and RFC 1035, November 1987.
+
+ [STD14] Partridge, C., "Mail Routing and the Domain System", STD
+ 14, RFC 974, January 1986.
+
+7. Editor's Address
+
+ Peter W. Resnick
+ QUALCOMM Incorporated
+ 5775 Morehouse Drive
+ San Diego, CA 92121-1714
+ USA
+
+ Phone: +1 858 651 4478
+ Fax: +1 858 651 1102
+ EMail: presnick@qualcomm.com
+
+
+
+
+
+
+
+Resnick Standards Track [Page 38]
+
+RFC 2822 Internet Message Format April 2001
+
+
+8. Acknowledgements
+
+ Many people contributed to this document. They included folks who
+ participated in the Detailed Revision and Update of Messaging
+ Standards (DRUMS) Working Group of the Internet Engineering Task
+ Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
+ people who simply sent their comments in via e-mail. The editor is
+ deeply indebted to them all and thanks them sincerely. The below
+ list includes everyone who sent e-mail concerning this document.
+ Hopefully, everyone who contributed is named here:
+
+ Matti Aarnio Barry Finkel Larry Masinter
+ Tanaka Akira Erik Forsberg Denis McKeon
+ Russ Allbery Chuck Foster William P McQuillan
+ Eric Allman Paul Fox Alexey Melnikov
+ Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger
+ Ran Atkinson Ned Freed Steven Miller
+ Jos Backus Jochen Friedrich Keith Moore
+ Bruce Balden Randall C. Gellens John Gardiner Myers
+ Dave Barr Sukvinder Singh Gill Chris Newman
+ Alan Barrett Tim Goodwin John W. Noerenberg
+ John Beck Philip Guenther Eric Norman
+ J. Robert von Behren Tony Hansen Mike O'Dell
+ Jos den Bekker John Hawkinson Larry Osterman
+ D. J. Bernstein Philip Hazel Paul Overell
+ James Berriman Kai Henningsen Jacob Palme
+ Norbert Bollow Robert Herriot Michael A. Patton
+ Raj Bose Paul Hethmon Uzi Paz
+ Antony Bowesman Jim Hill Michael A. Quinlan
+ Scott Bradner Paul E. Hoffman Eric S. Raymond
+ Randy Bush Steve Hole Sam Roberts
+ Tom Byrer Kari Hurtta Hugh Sasse
+ Bruce Campbell Marco S. Hyman Bart Schaefer
+ Larry Campbell Ofer Inbar Tom Scola
+ W. J. Carpenter Olle Jarnefors Wolfgang Segmuller
+ Michael Chapman Kevin Johnson Nick Shelness
+ Richard Clayton Sudish Joseph John Stanley
+ Maurizio Codogno Maynard Kang Einar Stefferud
+ Jim Conklin Prabhat Keni Jeff Stephenson
+ R. Kelley Cook John C. Klensin Bernard Stern
+ Steve Coya Graham Klyne Peter Sylvester
+ Mark Crispin Brad Knowles Mark Symons
+ Dave Crocker Shuhei Kobayashi Eric Thomas
+ Matt Curtin Peter Koch Lee Thompson
+ Michael D'Errico Dan Kohn Karel De Vriendt
+ Cyrus Daboo Christian Kuhtz Matthew Wall
+ Jutta Degener Anand Kumria Rolf Weber
+ Mark Delany Steen Larsen Brent B. Welch
+
+
+
+Resnick Standards Track [Page 39]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ Steve Dorner Eliot Lear Dan Wing
+ Harold A. Driscoll Barry Leiba Jack De Winter
+ Michael Elkins Jay Levitt Gregory J. Woodhouse
+ Robert Elz Lars-Johan Liman Greg A. Woods
+ Johnny Eriksson Charles Lindsey Kazu Yamamoto
+ Erik E. Fair Pete Loshin Alain Zahm
+ Roger Fajman Simon Lyall Jamie Zawinski
+ Patrik Faltstrom Bill Manning Timothy S. Zurcher
+ Claus Andre Farber John Martin
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 40]
+
+RFC 2822 Internet Message Format April 2001
+
+
+Appendix A. Example messages
+
+ This section presents a selection of messages. These are intended to
+ assist in the implementation of this standard, but should not be
+ taken as normative; that is to say, although the examples in this
+ section were carefully reviewed, if there happens to be a conflict
+ between these examples and the syntax described in sections 3 and 4
+ of this document, the syntax in those sections is to be taken as
+ correct.
+
+ Messages are delimited in this section between lines of "----". The
+ "----" lines are not part of the message itself.
+
+A.1. Addressing examples
+
+ The following are examples of messages that might be sent between two
+ individuals.
+
+A.1.1. A message from one person to another with simple addressing
+
+ This could be called a canonical message. It has a single author,
+ John Doe, a single recipient, Mary Smith, a subject, the date, a
+ message identifier, and a textual message in the body.
+
+----
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 41]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ If John's secretary Michael actually sent the message, though John
+ was the author and replies to this message should go back to him, the
+ sender field would be used:
+
+----
+From: John Doe <jdoe@machine.example>
+Sender: Michael Jones <mjones@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+A.1.2. Different types of mailboxes
+
+ This message includes multiple addresses in the destination fields
+ and also uses several different forms of addresses.
+
+----
+From: "Joe Q. Public" <john.q.public@example.com>
+To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
+Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
+Date: Tue, 1 Jul 2003 10:52:37 +0200
+Message-ID: <5678.21-Nov-1997@example.com>
+
+Hi everyone.
+----
+
+ Note that the display names for Joe Q. Public and Giant; "Big" Box
+ needed to be enclosed in double-quotes because the former contains
+ the period and the latter contains both semicolon and double-quote
+ characters (the double-quote characters appearing as quoted-pair
+ construct). Conversely, the display name for Who? could appear
+ without them because the question mark is legal in an atom. Notice
+ also that jdoe@example.org and boss@nil.test have no display names
+ associated with them at all, and jdoe@example.org uses the simpler
+ address form without the angle brackets.
+
+
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 42]
+
+RFC 2822 Internet Message Format April 2001
+
+
+A.1.3. Group addresses
+
+----
+From: Pete <pete@silly.example>
+To: A Group:Chris Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
+Cc: Undisclosed recipients:;
+Date: Thu, 13 Feb 1969 23:32:54 -0330
+Message-ID: <testabcd.1234@silly.example>
+
+Testing.
+----
+
+ In this message, the "To:" field has a single group recipient named A
+ Group which contains 3 addresses, and a "Cc:" field with an empty
+ group recipient named Undisclosed recipients.
+
+A.2. Reply messages
+
+ The following is a series of three messages that make up a
+ conversation thread between John and Mary. John firsts sends a
+ message to Mary, Mary then replies to John's message, and then John
+ replies to Mary's reply message.
+
+ Note especially the "Message-ID:", "References:", and "In-Reply-To:"
+ fields in each message.
+
+----
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 43]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ When sending replies, the Subject field is often retained, though
+ prepended with "Re: " as described in section 3.6.5.
+
+----
+From: Mary Smith <mary@example.net>
+To: John Doe <jdoe@machine.example>
+Reply-To: "Mary Smith: Personal Account" <smith@home.example>
+Subject: Re: Saying Hello
+Date: Fri, 21 Nov 1997 10:01:10 -0600
+Message-ID: <3456@example.net>
+In-Reply-To: <1234@local.machine.example>
+References: <1234@local.machine.example>
+
+This is a reply to your hello.
+----
+
+ Note the "Reply-To:" field in the above message. When John replies
+ to Mary's message above, the reply should go to the address in the
+ "Reply-To:" field instead of the address in the "From:" field.
+
+----
+To: "Mary Smith: Personal Account" <smith@home.example>
+From: John Doe <jdoe@machine.example>
+Subject: Re: Saying Hello
+Date: Fri, 21 Nov 1997 11:00:00 -0600
+Message-ID: <abcd.1234@local.machine.tld>
+In-Reply-To: <3456@example.net>
+References: <1234@local.machine.example> <3456@example.net>
+
+This is a reply to your reply.
+----
+
+A.3. Resent messages
+
+ Start with the message that has been used as an example several
+ times:
+
+----
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+
+
+
+Resnick Standards Track [Page 44]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ Say that Mary, upon receiving this message, wishes to send a copy of
+ the message to Jane such that (a) the message would appear to have
+ come straight from John; (b) if Jane replies to the message, the
+ reply should go back to John; and (c) all of the original
+ information, like the date the message was originally sent to Mary,
+ the message identifier, and the original addressee, is preserved. In
+ this case, resent fields are prepended to the message:
+
+----
+Resent-From: Mary Smith <mary@example.net>
+Resent-To: Jane Brown <j-brown@other.example>
+Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
+Resent-Message-ID: <78910@example.net>
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+ If Jane, in turn, wished to resend this message to another person,
+ she would prepend her own set of resent header fields to the above
+ and send that.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 45]
+
+RFC 2822 Internet Message Format April 2001
+
+
+A.4. Messages with trace fields
+
+ As messages are sent through the transport system as described in
+ [RFC2821], trace fields are prepended to the message. The following
+ is an example of what those trace fields might look like. Note that
+ there is some folding white space in the first one since these lines
+ can be long.
+
+----
+Received: from x.y.test
+ by example.net
+ via TCP
+ with ESMTP
+ id ABC12345
+ for <mary@example.net>; 21 Nov 1997 10:05:43 -0600
+Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: Fri, 21 Nov 1997 09:55:06 -0600
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 46]
+
+RFC 2822 Internet Message Format April 2001
+
+
+A.5. White space, comments, and other oddities
+
+ White space, including folding white space, and comments can be
+ inserted between many of the tokens of fields. Taking the example
+ from A.1.3, white space and comments can be inserted into all of the
+ fields.
+
+----
+From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
+To:A Group(Some people)
+ :Chris Jones <c@(Chris's host.)public.example>,
+ joe@example.org,
+ John <jdoe@one.test> (my dear friend); (the end of the group)
+Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ;
+Date: Thu,
+ 13
+ Feb
+ 1969
+ 23:32
+ -0330 (Newfoundland Time)
+Message-ID: <testabcd.1234@silly.test>
+
+Testing.
+----
+
+ The above example is aesthetically displeasing, but perfectly legal.
+ Note particularly (1) the comments in the "From:" field (including
+ one that has a ")" character appearing as part of a quoted-pair); (2)
+ the white space absent after the ":" in the "To:" field as well as
+ the comment and folding white space after the group name, the special
+ character (".") in the comment in Chris Jones's address, and the
+ folding white space before and after "joe@example.org,"; (3) the
+ multiple and nested comments in the "Cc:" field as well as the
+ comment immediately following the ":" after "Cc"; (4) the folding
+ white space (but no comments except at the end) and the missing
+ seconds in the time of the date field; and (5) the white space before
+ (but not within) the identifier in the "Message-ID:" field.
+
+A.6. Obsoleted forms
+
+ The following are examples of obsolete (that is, the "MUST NOT
+ generate") syntactic elements described in section 4 of this
+ document.
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 47]
+
+RFC 2822 Internet Message Format April 2001
+
+
+A.6.1. Obsolete addressing
+
+ Note in the below example the lack of quotes around Joe Q. Public,
+ the route that appears in the address for Mary Smith, the two commas
+ that appear in the "To:" field, and the spaces that appear around the
+ "." in the jdoe address.
+
+----
+From: Joe Q. Public <john.q.public@example.com>
+To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example
+Date: Tue, 1 Jul 2003 10:52:37 +0200
+Message-ID: <5678.21-Nov-1997@example.com>
+
+Hi everyone.
+----
+
+A.6.2. Obsolete dates
+
+ The following message uses an obsolete date format, including a non-
+ numeric time zone and a two digit year. Note that although the
+ day-of-week is missing, that is not specific to the obsolete syntax;
+ it is optional in the current syntax as well.
+
+----
+From: John Doe <jdoe@machine.example>
+To: Mary Smith <mary@example.net>
+Subject: Saying Hello
+Date: 21 Nov 97 09:55:06 GMT
+Message-ID: <1234@local.machine.example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+A.6.3. Obsolete white space and comments
+
+ White space and comments can appear between many more elements than
+ in the current syntax. Also, folding lines that are made up entirely
+ of white space are legal.
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 48]
+
+RFC 2822 Internet Message Format April 2001
+
+
+----
+From : John Doe <jdoe@machine(comment). example>
+To : Mary Smith
+__
+ <mary@example.net>
+Subject : Saying Hello
+Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
+Message-ID : <1234 @ local(blah) .machine .example>
+
+This is a message just to say hello.
+So, "Hello".
+----
+
+ Note especially the second line of the "To:" field. It starts with
+ two space characters. (Note that "__" represent blank spaces.)
+ Therefore, it is considered part of the folding as described in
+ section 4.2. Also, the comments and white space throughout
+ addresses, dates, and message identifiers are all part of the
+ obsolete syntax.
+
+Appendix B. Differences from earlier standards
+
+ This appendix contains a list of changes that have been made in the
+ Internet Message Format from earlier standards, specifically [RFC822]
+ and [STD3]. Items marked with an asterisk (*) below are items which
+ appear in section 4 of this document and therefore can no longer be
+ generated.
+
+ 1. Period allowed in obsolete form of phrase.
+ 2. ABNF moved out of document to [RFC2234].
+ 3. Four or more digits allowed for year.
+ 4. Header field ordering (and lack thereof) made explicit.
+ 5. Encrypted header field removed.
+ 6. Received syntax loosened to allow any token/value pair.
+ 7. Specifically allow and give meaning to "-0000" time zone.
+ 8. Folding white space is not allowed between every token.
+ 9. Requirement for destinations removed.
+ 10. Forwarding and resending redefined.
+ 11. Extension header fields no longer specifically called out.
+ 12. ASCII 0 (null) removed.*
+ 13. Folding continuation lines cannot contain only white space.*
+ 14. Free insertion of comments not allowed in date.*
+ 15. Non-numeric time zones not allowed.*
+ 16. Two digit years not allowed.*
+ 17. Three digit years interpreted, but not allowed for generation.
+ 18. Routes in addresses not allowed.*
+ 19. CFWS within local-parts and domains not allowed.*
+ 20. Empty members of address lists not allowed.*
+
+
+
+Resnick Standards Track [Page 49]
+
+RFC 2822 Internet Message Format April 2001
+
+
+ 21. Folding white space between field name and colon not allowed.*
+ 22. Comments between field name and colon not allowed.
+ 23. Tightened syntax of in-reply-to and references.*
+ 24. CFWS within msg-id not allowed.*
+ 25. Tightened semantics of resent fields as informational only.
+ 26. Resent-Reply-To not allowed.*
+ 27. No multiple occurrences of fields (except resent and received).*
+ 28. Free CR and LF not allowed.*
+ 29. Routes in return path not allowed.*
+ 30. Line length limits specified.
+ 31. Bcc more clearly specified.
+
+Appendix C. Notices
+
+ Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 50]
+
+RFC 2822 Internet Message Format April 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Resnick Standards Track [Page 51]
+
diff --git a/Documentation/en/rfc/rfc2852.txt b/Documentation/en/rfc/rfc2852.txt
new file mode 100644
index 00000000..5e491b6f
--- /dev/null
+++ b/Documentation/en/rfc/rfc2852.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group D. Newman
+Request for Comments: 2852 Sun Microsystems
+Updates: 1894 June 2000
+Category: Standards Track
+
+
+ Deliver By SMTP Service Extension
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This memo defines a mechanism whereby a SMTP client can request, when
+ transmitting a message to a SMTP server, that the server deliver the
+ message within a prescribed period of time. A client making such a
+ request also specifies the message handling which is to occur if the
+ message cannot be delivered within the specified time period: either
+ the message is to be returned as undeliverable with no further
+ processing, or a "delayed" delivery status notification (DSN) [6] is
+ to be issued.
+
+ This extension should not be viewed as a vehicle for requesting
+ "priority" processing. A receiving SMTP server may assign whatever
+ processing priority it wishes to a message transmitted with a Deliver
+ By request. A Deliver By request serves to express a message's
+ urgency and to provide an additional degree of determinancy in its
+ processing. An indication of an urgent message's status within a
+ given time period may be requested and will be honored. Moreover,
+ the message may be withdrawn if not delivered within that time
+ period.
+
+ A typical usage of this mechanism is to prevent delivery of a message
+ beyond some future time of significance to the sender or recipient
+ but not known by the MTAs handling the message. For instance, the
+ sender may know that the message will be delivered as a page but does
+ not consider the message to be sufficiently important as to warrant
+ paging the recipient after business hours. In that case, the message
+ could be marked such that delivery attempts are not made beyond
+
+
+
+Newman Standards Track [Page 1]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+ 17:00. Another common usage arises when a sender wishes to be
+ alerted to delivery delays. In this case, the sender can mark a
+ message such that if it is not delivered within, say, 30 minutes, a
+ "delayed" DSN is generated but delivery attempts are nonetheless
+ continued. In this case the sender has been allowed to express a
+ preference for when they would like to learn of delivery problems.
+
+1. Definitions
+
+ Throughout this document, the term "deliver" is taken to mean the act
+ of transmitting a message to its "final" destination by a message
+ transport agent (MTA). Usually, but not always, this means storing
+ or otherwise handing off the message to the recipient's mailbox.
+ Thus, an MTA which accepts a message to be delivered within a
+ specified time period is agreeing to store or handoff the message to
+ the recipient's mailbox within the specified time period. Outside
+ the scope of the term "deliver" are any user-specified actions which
+ might take place after the MTA stores or hands off the message; e.g.,
+ user-programmed filters which, often unbeknownst to the MTA, resend
+ the message to some other location.
+
+ The key words "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in this
+ document are to be interpreted as described in RFC 2119 [7].
+
+2. Framework for the Deliver By SMTP service extension
+
+ The Deliver By SMTP service extension uses the SMTP service extension
+ mechanism described in [4]. The following SMTP service extension is
+ therefore defined:
+
+ (1) The name of the SMTP service extension is "Deliver By".
+
+ (2) The EHLO keyword value associated with this service extension is
+ "DELIVERBY".
+
+ (3) One optional parameter is allowed with this EHLO keyword value.
+ The optional parameter, when supplied, is a comma separated list
+ of options. Only one option, a min-by-time, is specified in
+ this document. Future documents may extend this specification
+ by specifying additional options. The min-by-time is a fixed
+ integer indicating the fixed minimum by-time that the server
+ will accept when a by-mode of "R" is specified as per Section 4.
+
+ The syntax of the optional parameter is as follows, using the
+ augmented BNF notation of RFC 2234 [2]:
+
+
+
+
+
+
+Newman Standards Track [Page 2]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+ deliverby-param = min-by-time *( ',' extension-token )
+ min-by-time = [1*9DIGIT]
+ extension-token = 1*<any CHAR excluding SP, COMMA and all control
+ characters (US ASCII 0-31 inclusive)>
+ SP = <the space character (ASCII decimal code 32)>
+ COMMA = <the comma character (ASCII decimal code 44)>
+
+ If the parameter is omitted, no information is conveyed about
+ the server's fixed minimum by-time.
+
+ (4) One optional parameter using the keyword "BY" is added to the
+ MAIL FROM command.
+
+ (5) The maximum length of a MAIL FROM command line is increased by
+ 17 characters by the possible addition of the BY keyword and
+ value.
+
+ (6) No additional SMTP verbs are defined by this extension.
+
+3. The Deliver By SMTP service extension
+
+ A SMTP client wishing to use the Deliver By SMTP service extension
+ may issue the EHLO command to start a SMTP session and to determine
+ if the SMTP server supports the service extension. If the server
+ responds with code 250 to the EHLO command, and the response includes
+ the EHLO keyword DELIVERBY, then the Deliver By SMTP service
+ extension is supported by the server.
+
+ If a numeric parameter follows the DELIVERBY keyword value of the
+ EHLO response then that parameter indicates the minimum value allowed
+ for the by-time when a by-mode of "R" is specified with the extended
+ MAIL FROM command as described in Section 4. Any attempt by a client
+ to specify a by-mode of "R" and a by-time strictly less than this
+ limit, min-by-time, will be rejected with a permanent failure (55z)
+ reply code.
+
+ A SMTP server that supports the Deliver By SMTP service extension
+ will accept the extended version of the MAIL FROM command described
+ in Section 4. When supported by the server, a SMTP client may use
+ the extended MAIL FROM command (instead of the MAIL FROM command
+ described in [1]) to request that the message be delivered within the
+ specified time period. The server may then return an appropriate
+ error code if it determines that the request cannot be honored. Note
+ that this may not be apparent to the server until either presentation
+ of the recipient addresses with RCPT TO commands or completion of the
+ transfer of the message data with the dot (.) command. As such, the
+
+
+
+
+
+Newman Standards Track [Page 3]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+ server may send to the client a success response to the MAIL FROM
+ command only to later return an error response to the RCPT TO, DATA,
+ or dot command.
+
+4. The extended MAIL FROM command
+
+ The extended MAIL FROM command is issued by a SMTP client when it
+ wishes to inform a SMTP server that a message is to be delivered
+ within a specified period of time and further what action to take
+ should the message prove undeliverable within that time period. The
+ extended MAIL FROM command is identical to the MAIL FROM command as
+ defined in RFC 821 [1], except that a BY parameter appears after the
+ address.
+
+ The complete syntax of this extended command is defined in [4]. The
+ esmtp-keyword is "BY" and the syntax for the esmtp-value is given by
+ the syntax for by-value shown below. In the augmented BNF of RFC
+ 2234 [2], the syntax for the BY esmtp-parameter is
+
+ by-parameter = "BY="by-value
+ by-value = by-time";"by-mode[by-trace]
+ by-time = ["-" / "+"]1*9digit ; a negative or zero value is not
+ ; allowed with a by-mode of "R"
+ by-mode = "N" / "R" ; "Notify" or "Return"
+ by-trace = "T" ; "Trace"
+
+ Note that the BY esmtp-keyword MUST have an associated esmtp-value.
+ The by-time is a decimal representation of the number of seconds
+ within which the message should be delivered and has the range
+
+ -999,999,999 seconds <= by-time <= +999,999,999 seconds
+
+ and is thus sufficient to represent a time anywhere from
+ approximately 31.6 years in the past to 31.6 years in the future.
+
+ As described in Section 4.1, the by-mode indicates the action the
+ SMTP server must take should it not be possible to transmit the
+ message within by-time seconds.
+
+ Note that by-time is a delta time: the number of seconds within which
+ to deliver the message. This delta time does not extend an MTA's
+ normal retention period for undeliverable messages nor is it a
+ "deliver after" time.
+
+ A delta time is used so as to prevent problems associated with
+ differences in system clocks between clients and servers. Servers in
+ receipt of a valid by-parameter are expected to convert the by-time
+ into a locale-specific absolute time called the deliver-by-time.
+
+
+
+Newman Standards Track [Page 4]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+ This is done by adding the by-time upon receipt to the current
+ locale-specific time and thereby arriving at a locale-specific
+ absolute time which is by-time seconds in the future or past,
+ depending upon the arithmetic sign of by-time. The message is then
+ to be delivered by the deliver-by-time. The sending client and
+ receiving server should assume the transmission time of the MAIL FROM
+ command to be instantaneous. Clearly, it will not be and network
+ latency will introduce an error, the nature of which will be to
+ extend slightly the effective by-time. The more hops the message
+ takes, the more pronounced the effect will be owing to the cumulative
+ nature of this latency-induced error.
+
+ In the case of a by-mode of "N", it is possible that by-time may be
+ zero or negative. This is not an error and should not be rejected as
+ such. It indicates a message for which the deliver-by-time occurred
+ -(by-time) seconds in the past. [Here, "-(by-time)" represents the
+ arithmetic negation of the by-time value.] Zero and negative values
+ are allowed so as to preserve information about any requested
+ delivery time information -- information which the delivering MTA may
+ wish to include with the delivered message for the benefit of the
+ recipient or to show in a DSN or NDN (non delivery notification).
+
+ In the case of a by-mode of "R", a zero or negative by-time is a
+ syntax error. In such a case, the SMTP server SHOULD return a
+ permanent failure (501) SMTP reply code in response to the extended
+ MAIL FROM command. If the SMTP server also supports enhanced error
+ codes [8], then an enhanced error code of 5.5.4 SHOULD also be
+ returned.
+
+ If the by-time is a valid by-time specification but the SMTP server
+ cannot honor or accept it for a server-specific reason, then SMTP
+ server SHOULD respond with either a 455 SMTP response if the
+ condition is transient or a 555 SMTP response if the condition is
+ permanent. In addition, if the SMTP server also supports [8], a
+ suitable 4.X.X or 5.X.X enhanced error code SHOULD also be returned.
+
+4.1. Server behavior upon receipt of the extended MAIL FROM command
+
+ Upon receipt of an extended MAIL FROM command containing a valid BY
+ parameter, a SMTP server and associated MTA must handle the message
+ in accord with the following subsections, Sections 4.1.1-4.1.5.
+ Delivery status notifications generated in response to processing a
+ message with a Deliver By request should include both the optional
+ Arrival-Date DSN field as well as the new Deliver-By-Date DSN field
+ described in Section 5 of this memo.
+
+
+
+
+
+
+Newman Standards Track [Page 5]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+ A by-time Note that a message's by-time does not extend the MTA's
+ normal message retention period: an MTA MAY return a message as
+ undeliverable before the deliver-by-time has been reached.
+
+4.1.1. Successful delivery
+
+ If the message is delivered before deliver-by-time, no special action
+ need be taken. If the SMTP server or MTA also supports the Delivery
+ Status Notification SMTP service extension [5] and a NOTIFY parameter
+ including "SUCCESS" was specified, a "delivered" DSN with appropriate
+ status must be returned as per [5].
+
+4.1.2. Unsuccessful delivery; deliver-by-time not yet reached
+
+ If deliver-by-time has not yet passed and the message has proved
+ undeliverable for temporary reasons, then the SMTP server or MTA
+ should continue delivery or relay attempts as per the site's message
+ handling policy. If the MTA's message retention period is less than
+ by-time, the MTA MAY return the message as undeliverable before
+ deliver-by-time has been reached. However, the message MUST still be
+ handled in accord with Sections 4.1.1-4.1.5.
+
+ If deliver-by-time has not yet passed and the message cannot be
+ delivered for permanent reasons, then the SMTP server or MTA MUST
+ return a "failed" DSN with an appropriate status for each recipient
+ address with either no NOTIFY parameter specified or for which the
+ NOTIFY parameter includes "FAILURE".
+
+4.1.3. Time has expired; deliver-by-time reached or passed
+
+ If the message is not delivered or relayed before deliver-by-time and
+ a by-mode of "R" was specified, no further delivery attempts may be
+ made for the message. The server or MTA MUST issue a "failed" DSN
+ with status 5.4.7, "delivery time expired", for each recipient
+ address with either no NOTIFY parameter specified or for which the
+ NOTIFY parameter includes "FAILURE".
+
+ If the message is not delivered or relayed before deliver-by-time and
+ a by-mode of "N" was specified, the server or MTA should continue
+ attempts to deliver or relay the message using the site's message
+ handling policy. In addition, the server or MTA MUST issue a
+ "delayed" DSN with status 4.4.7, "delivery time expired", for each
+ recipient address with either no NOTIFY parameter specified or for
+ which the NOTIFY parameter includes "DELAY".
+
+
+
+
+
+
+
+Newman Standards Track [Page 6]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+4.1.4. Relaying to another SMTP server
+
+ Sections 4.1.4.1 and 4.1.4.2 below describe when a message with a
+ Deliver By request may be relayed to another SMTP server and what
+ additional actions, if any, should or must be taken. In addition to
+ that discussed in those sections, the following must also be observed
+ when relaying is permitted.
+
+ If the message is relayed to a SMTP server that supports the Deliver
+ By extension, a new BY parameter MUST be relayed specifying a by-time
+ value indicating the number of seconds remaining until deliver-by-
+ time. The new by-time value should be computed as close to the time
+ the MAIL FROM command is transmitted by the relaying SMTP client as
+ is reasonably possible. Note that if deliver-by-time has passed, the
+ relayed by-time will be a negative value indicating how may seconds
+ has elapsed since delivery-by-time. Such a case -- relay of a
+ message for which deliver-by-time has just arrived or passed -- may
+ only happen with a message that has a by-mode of "N".
+
+ When a message with a by-trace field with value "T" is relayed, a
+ "relayed" DSN SHOULD be generated by the relaying SMTP client for
+ each recipient which either did not specify a NOTIFY parameter or the
+ NOTIFY parameter does not have the value "NEVER".
+
+ Note that these "relayed" DSNs are generated regardless of whether
+ success notifications were explicitly requested with a NOTIFY=SUCCESS
+ parameter. Note further that the "relayed" DSNs discussed here are
+ not terminal notifications: downstream SMTP servers and MTAs may
+ still support [5] and as such additional notifications may still
+ result.
+
+4.1.4.1. Relaying a message with a by-mode of "R"
+
+ A message for which a by-mode of "R" was specified MUST NOT be
+ relayed to a SMTP server which does not support the Deliver By SMTP
+ service extension. Moreover, the server to which it is relayed MUST
+ NOT have a fixed minimum by-time which is greater than the time
+ remaining in which the message is to be delivered. The fixed minimum
+ by-time is expressed by the optional deliverby-param discussed in
+ Section 2.
+
+ If the message requires relaying in order to be delivered yet cannot
+ be relayed, then the message is deemed to be undeliverable for
+ permanent reasons and Section 4.1.2 should be applied.
+
+
+
+
+
+
+
+Newman Standards Track [Page 7]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+4.1.4.2. Relaying a message with a by-mode of "N"
+
+ A message with a by-mode of "N" may be relayed to another server
+ regardless of whether or not the SMTP server to which it is relayed
+ supports the Deliver By extension.
+
+ If the message is relayed before deliver-by-time to a SMTP server
+ that does not support the Deliver By extension, then the relaying
+ SMTP client MUST issue a "relayed" DSN for each recipient which
+ either did not specify a NOTIFY parameter or the NOTIFY parameter
+ does not have the value "NEVER". Further, if the SMTP server being
+ relayed to supports the Delivery Status Notification SMTP service
+ extension [5] then for each recipient: if no NOTIFY parameter was
+ supplied, "NOTIFY=FAILURE,DELAY" SHOULD be requested; if a NOTIFY
+ parameter was specified and does not have the value "NEVER", "DELAY"
+ SHOULD be added to the list of notify-list-element values if not
+ already present. Note that this explicitly overrides the "MUST NOT"
+ wording of Section 6.2.1(c) of [5].
+
+4.1.5. Relaying to a foreign mail system
+
+ If the foreign mail system supports semantics similar to the Deliver
+ By SMTP service extension described in this memo, then convey the
+ Deliver By request to that system. Otherwise, relay the message as
+ if relaying to a SMTP server which does not support the Deliver By
+ extension.
+
+5. Delivery status notifications and extension
+
+ The format of delivery status notifications (DSNs) is specified in
+ [6]. DSNs generated in response to a Deliver By request should
+ include an Arrival-Date DSN field. This memo also extends the per-
+ message-fields of [6] to include a new DSN field, Deliver-By-Date,
+ indicating the deliver-by-time as computed by the MTA or SMTP server
+ generating the DSN. In the augmented BNF of RFC 822 [2], per-
+ message-fields is therefore extended as follows:
+
+ per-message-fields =
+ [ original-envelope-id-field CRLF ]
+ reporting-mta-field CRLF
+ [ dsn-gateway-field CRLF ]
+ [ received-from-mta-field CRLF ]
+ [ arrival-date-field CRLF ]
+ [ deliver-by-date-field CRLF ]
+ *( extension-field CRLF )
+ deliver-by-date-field = "Deliver-by-date" ":" date-time
+
+
+
+
+
+Newman Standards Track [Page 8]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+ where date-time is a RFC 822 [2] date-time field as ammended by RFC
+ 1123 [3].
+
+6. Examples
+
+ In the following sample SMTP dialog, the SMTP client requests that a
+ message from <eljefe@bigbiz.com> be delivered to
+ <topbanana@other.com> within 2 minutes (120 seconds) and returned
+ otherwise. This request takes the form of a BY parameter on the MAIL
+ FROM line of "BY=120;R" as shown below:
+
+ S: 220 acme.net SMTP server here
+ C: EHLO bigbiz.com
+ S: 250-acme.net
+ S: 250 DELIVERBY
+ C: MAIL FROM:<eljefe@bigbiz.com> BY=120;R
+ S: 250 <eljefe@bigbiz.com> sender ok
+ C: RCPT TO:<topbanana@other.com>
+ S: 250 <topbanana@wherever.com> recipient ok
+
+ Suppose now that the receiving SMTP server in the above example needs
+ to relay the message to another SMTP server, mail.other.com. Owing
+ to the original by-mode of "R", the message may only be relayed to
+ another SMTP server which supports the Deliver By extension (Section
+ 4.1.4). Further, when relaying the message, the Deliver By request
+ must be relayed. With this in mind, consider the following SMTP
+ dialog:
+
+ S: 220 mail.other.com ESMTP server at your service
+ C: EHLO acme.net
+ S: 250-mail.other.com
+ S: 250 DELIVERBY 240
+ C: QUIT
+
+ In the above dialog, the relaying SMTP server, acme.net, connects to
+ mail.other.com and issues an EHLO command. It then learns that the
+ Deliver By extension is supported but that the minimum by-time for a
+ by-mode of "R" is 4 minutes (240 seconds). This value exceeds the
+ message's original by-time and therefore necessarily exceeds the
+ remaining by-time. The relaying SMTP server thus ends the SMTP
+ session after which it must either attempt to follow any other MX
+ records or, if there are no more MX records to follow, must return
+ the message as undeliverable. Similar behavior would result if the
+ EHLO command was met with an error or did not include the DELIVERBY
+ keyword.
+
+ Consider instead, the relaying SMTP session:
+
+
+
+
+Newman Standards Track [Page 9]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+ S: 220 mail.other.com ESMTP server at your service
+ C: EHLO acme.net
+ S: 250-mail.other.com
+ S: 250 DELIVERBY 30
+ C: MAIL FROM:<eljefe@bigbiz.com> BY=98;R
+ S: 250 <eljefe@bigbiz.com> Sender okay
+ C: RCPT TO:<topbanana@other.com>
+ S: 250 <topbanana@wherever.com> Recipient okay
+
+ In the above, the relaying SMTP client relays the BY parameter with
+ the by-mode preserved and the by-time computed to be the remaining
+ number of seconds at the approximate time that the MAIL FROM command
+ was transmitted from the relaying SMTP client (acme.net) to the
+ receiving SMTP server (mail.other.com). In this example, 22 seconds
+ have elapsed since acme.net received the MAIL FROM line from the
+ original sending client and relayed the Deliver By request to
+ mail.other.com.
+
+7. MX based relaying considerations
+
+ Sites which wish to use the Deliver By SMTP service extension and
+ which direct their mail via MX records [9] need to ensure that all of
+ their MX hosts -- hosts to which their mail is directed by MX records
+ -- support the Deliver By extension. SMTP clients which support
+ Deliver By SHOULD NOT attempt multiple MX hosts looking for one which
+ supports Deliver By.
+
+ MX hosts should pay careful attention to the min-by-time value they
+ present in response to EHLO commands. It is not practical for an MX
+ host to present a value which either (1) is substantially different
+ from that which can be handled by the destination host to which it
+ relays, or (2) doesn't recognize normal delivery latencies introduced
+ when the MX host relays mail to the destination host.
+
+8. Security Considerations
+
+ Implemention of Deliver By allows tracing of a mail transport system.
+ The by-trace field "T" explicitly requests that a trace be generated.
+ Moreover, even when the by-trace field is not used, a crude trace may
+ be generated by entering a series of messages into the transport
+ system, each with successively increasing by-time values; e.g.,
+ "BY=0;R", "BY=1;R", "BY=2;R". Probing, and in some cases tracing, can
+ be accomplished through other means: querying the visible SMTP
+ servers, investigating Received: header lines in bounced messages,
+ and using utilities such as "traceroute".
+
+
+
+
+
+
+Newman Standards Track [Page 10]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+9. Other Considerations
+
+ SMTP servers which support the Deliver By SMTP service extension as
+ well as their associated MTAs are not required to assign any special
+ processing priority to messages with Deliver By requests. Of course,
+ some SMTP servers and MTAs may do so if they desire. Moreover,
+ delivery status notifications generated in response to messages with
+ Deliver By requests are not required to receive any special
+ processing. Consequently, users of this service should not, in
+ general, expect expedited processing of their messages. Moreover,
+ just because a message is sent with a "BY=60;R" parameter does not
+ guarantee that the sender will learn of a delivery failure within any
+ specified time period as the DSN will not necessarily be expedited
+ back to sender.
+
+10. Acknowledgments
+
+ The author wishes to thank Keith Moore for providing much of the
+ initial impetus for this document as well as the basic ideas embodied
+ within it. Further thanks are due to Ned Freed and Chris Newman for
+ their reviews of this document and suggestions for improvement.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman Standards Track [Page 11]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+11. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ August 1982.
+
+ [2] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [3] Braden, R., Editor, "Requirements for Internet Hosts --
+ Application and Support", STD 3, RFC 1123, October 1989.
+
+ [4] Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed,
+ "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
+
+ [5] Moore, K., "SMTP Service Extension for Delivery Status
+ Notifications", RFC 1891, January 1996.
+
+ [6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
+ Delivery Status Notifications", RFC 1894, January 1996.
+
+ [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [8] Freed, N., "SMTP Service Extension for Returning Enhanced Error
+ Codes", RFC 2034, October 1996.
+
+ [9] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+ 974, January 1986.
+
+12. Author's Address
+
+ Dan Newman
+ Sun Microsystems, Inc.
+ 1050 Lakes Drive, Suite 250
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 626 919 3600
+ Fax: +1 626 919 3614
+ EMail: dan.newman@sun.com
+
+
+
+
+
+
+
+
+
+
+
+Newman Standards Track [Page 12]
+
+RFC 2852 Deliver By SMTP Service Extension June 2000
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman Standards Track [Page 13]
+
diff --git a/Documentation/en/rfc/rfc2870.txt b/Documentation/en/rfc/rfc2870.txt
new file mode 100644
index 00000000..2bc176b0
--- /dev/null
+++ b/Documentation/en/rfc/rfc2870.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group R. Bush
+Request for Comments: 2870 Verio
+Obsoletes: 2010 D. Karrenberg
+BCP: 40 RIPE NCC
+Category: Best Current Practice M. Kosters
+ Network Solutions
+ R. Plzak
+ SAIC
+ June 2000
+
+
+ Root Name Server Operational Requirements
+
+Status of this Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ As the internet becomes increasingly critical to the world's social
+ and economic infrastructure, attention has rightly focused on the
+ correct, safe, reliable, and secure operation of the internet
+ infrastructure itself. The root domain name servers are seen as a
+ crucial part of that technical infrastructure. The primary focus of
+ this document is to provide guidelines for operation of the root name
+ servers. Other major zone server operators (gTLDs, ccTLDs, major
+ zones) may also find it useful. These guidelines are intended to
+ meet the perceived societal needs without overly prescribing
+ technical details.
+
+1. Background
+
+ The resolution of domain names on the internet is critically
+ dependent on the proper, safe, and secure operation of the root
+ domain name servers. Currently, these dozen or so servers are
+ provided and operated by a very competent and trusted group of
+ volunteers. This document does not propose to change that, but
+ merely to provide formal guidelines so that the community understands
+ how and why this is done.
+
+
+
+
+
+
+Bush, et al. Best Current Practice [Page 1]
+
+RFC 2870 Root Name Server Operational Requirements June 2000
+
+
+ 1.1 The Internet Corporation for Assigned Names and Numbers (ICANN)
+ has become responsible for the operation of the root servers.
+ The ICANN has appointed a Root Server System Advisory Committee
+ (RSSAC) to give technical and operational advice to the ICANN
+ board. The ICANN and the RSSAC look to the IETF to provide
+ engineering standards.
+
+ 1.2 The root servers serve the root, aka ".", zone. Although today
+ some of the root servers also serve some TLDs (top level domains)
+ such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as
+ INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE
+ for Sweden), this is likely to change (see 2.5).
+
+ 1.3 The root servers are neither involved with nor dependent upon the
+ 'whois' data.
+
+ 1.4 The domain name system has proven to be sufficiently robust that
+ we are confident that the, presumably temporary, loss of most of
+ the root servers should not significantly affect operation of the
+ internet.
+
+ 1.5 Experience has shown that the internet is quite vulnerable to
+ incorrect data in the root zone or TLDs. Hence authentication,
+ validation, and security of these data are of great concern.
+
+2. The Servers Themselves
+
+ The following are requirements for the technical details of the root
+ servers themselves:
+
+ 2.1 It would be short-sighted of this document to specify particular
+ hardware, operating systems, or name serving software.
+ Variations in these areas would actually add overall robustness.
+
+ 2.2 Each server MUST run software which correctly implements the IETF
+ standards for the DNS, currently [RFC1035] [RFC2181]. While
+ there are no formal test suites for standards compliance, the
+ maintainers of software used on root servers are expected to take
+ all reasonable actions to conform to the IETF's then current
+ documented expectations.
+
+ 2.3 At any time, each server MUST be able to handle a load of
+ requests for root data which is three times the measured peak of
+ such requests on the most loaded server in then current normal
+ conditions. This is usually expressed in requests per second.
+ This is intended to ensure continued operation of root services
+ should two thirds of the servers be taken out of operation,
+ whether by intent, accident, or malice.
+
+
+
+Bush, et al. Best Current Practice [Page 2]
+
+RFC 2870 Root Name Server Operational Requirements June 2000
+
+
+ 2.4 Each root server should have sufficient connectivity to the
+ internet to support the bandwidth needs of the above requirement.
+ Connectivity to the internet SHOULD be as diverse as possible.
+
+ Root servers SHOULD have mechanisms in place to accept IP
+ connectivity to the root server from any internet provider
+ delivering connectivity at their own cost.
+
+ 2.5 Servers MUST provide authoritative responses only from the zones
+ they serve. The servers MUST disable recursive lookup,
+ forwarding, or any other function that may allow them to provide
+ cached answers. They also MUST NOT provide secondary service for
+ any zones other than the root and root-servers.net zones. These
+ restrictions help prevent undue load on the root servers and
+ reduce the chance of their caching incorrect data.
+
+ 2.6 Root servers MUST answer queries from any internet host, i.e. may
+ not block root name resolution from any valid IP address, except
+ in the case of queries causing operational problems, in which
+ case the blocking SHOULD last only as long as the problem, and be
+ as specific as reasonably possible.
+
+ 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
+ queries from clients other than other root servers. This
+ restriction is intended to, among other things, prevent
+ unnecessary load on the root servers as advice has been heard
+ such as "To avoid having a corruptible cache, make your server a
+ stealth secondary for the root zone." The root servers MAY put
+ the root zone up for ftp or other access on one or more less
+ critical servers.
+
+ 2.8 Servers MUST generate checksums when sending UDP datagrams and
+ MUST verify checksums when receiving UDP datagrams containing a
+ non-zero checksum.
+
+3. Security Considerations
+
+ The servers need both physical and protocol security as well as
+ unambiguous authentication of their responses.
+
+ 3.1 Physical security MUST be ensured in a manner expected of data
+ centers critical to a major enterprise.
+
+ 3.1.1 Whether or not the overall site in which a root server is
+ located has access control, the specific area in which the
+ root server is located MUST have positive access control,
+ i.e. the number of individuals permitted access to the
+ area MUST be limited, controlled, and recorded. At a
+
+
+
+Bush, et al. Best Current Practice [Page 3]
+
+RFC 2870 Root Name Server Operational Requirements June 2000
+
+
+ minimum, control measures SHOULD be either mechanical or
+ electronic locks. Physical security MAY be enhanced by
+ the use of intrusion detection and motion sensors,
+ multiple serial access points, security personnel, etc.
+
+ 3.1.2 Unless there is documentable experience that the local
+ power grid is more reliable than the MTBF of a UPS (i.e.
+ five to ten years), power continuity for at least 48 hours
+ MUST be assured, whether through on-site batteries, on-
+ site power generation, or some combination thereof. This
+ MUST supply the server itself, as well as the
+ infrastructure necessary to connect the server to the
+ internet. There MUST be procedures which ensure that
+ power fallback mechanisms and supplies are tested no less
+ frequently than the specifications and recommendations of
+ the manufacturer.
+
+ 3.1.3 Fire detection and/or retardation MUST be provided.
+
+ 3.1.4 Provision MUST be made for rapid return to operation after
+ a system outage. This SHOULD involve backup of systems
+ software and configuration. But SHOULD also involve
+ backup hardware which is pre-configured and ready to take
+ over operation, which MAY require manual procedures.
+
+ 3.2 Network security should be of the level provided for critical
+ infrastructure of a major commercial enterprise.
+
+ 3.2.1 The root servers themselves MUST NOT provide services
+ other than root name service e.g. remote internet
+ protocols such as http, telnet, rlogin, ftp, etc. The
+ only login accounts permitted should be for the server
+ administrator(s). "Root" or "privileged user" access MUST
+ NOT be permitted except through an intermediate user
+ account.
+
+ Servers MUST have a secure mechanism for remote
+ administrative access and maintenance. Failures happen;
+ given the 24x7 support requirement (per 4.5), there will
+ be times when something breaks badly enough that senior
+ wizards will have to connect remotely. Remote logins MUST
+ be protected by a secure means that is strongly
+ authenticated and encrypted, and sites from which remote
+ login is allowed MUST be protected and hardened.
+
+ 3.2.2 Root name servers SHOULD NOT trust other hosts, except
+ secondary servers trusting the primary server, for matters
+ of authentication, encryption keys, or other access or
+
+
+
+Bush, et al. Best Current Practice [Page 4]
+
+RFC 2870 Root Name Server Operational Requirements June 2000
+
+
+ security information. If a root operator uses kerberos
+ authentication to manage access to the root server, then
+ the associated kerberos key server MUST be protected with
+ the same prudence as the root server itself. This applies
+ to all related services which are trusted in any manner.
+
+ 3.2.3 The LAN segment(s) on which a root server is homed MUST
+ NOT also home crackable hosts. I.e. the LAN segments
+ should be switched or routed so there is no possibility of
+ masquerading. Some LAN switches aren't suitable for
+ security purposes, there have been published attacks on
+ their filtering. While these can often be prevented by
+ careful configuration, extreme prudence is recommended.
+ It is best if the LAN segment simply does not have any
+ other hosts on it.
+
+ 3.2.4 The LAN segment(s) on which a root server is homed SHOULD
+ be separately firewalled or packet filtered to discourage
+ network access to any port other than those needed for
+ name service.
+
+ 3.2.5 The root servers SHOULD have their clocks synchronized via
+ NTP [RFC1305] [RFC2030] or similar mechanisms, in as
+ secure manner as possible. For this purpose, servers and
+ their associated firewalls SHOULD allow the root servers
+ to be NTP clients. Root servers MUST NOT act as NTP peers
+ or servers.
+
+ 3.2.6 All attempts at intrusion or other compromise SHOULD be
+ logged, and all such logs from all root servers SHOULD be
+ analyzed by a cooperative security team communicating with
+ all server operators to look for patterns, serious
+ attempts, etc. Servers SHOULD log in GMT to facilitate
+ log comparison.
+
+ 3.2.7 Server logging SHOULD be to separate hosts which SHOULD be
+ protected similarly to the root servers themselves.
+
+ 3.2.8 The server SHOULD be protected from attacks based on
+ source routing. The server MUST NOT rely on address- or
+ name-based authentication.
+
+ 3.2.9 The network on which the server is homed SHOULD have
+ in-addr.arpa service.
+
+ 3.3 Protocol authentication and security are required to ensure that
+ data presented by the root servers are those created by those
+ authorized to maintain the root zone data.
+
+
+
+Bush, et al. Best Current Practice [Page 5]
+
+RFC 2870 Root Name Server Operational Requirements June 2000
+
+
+ 3.3.1 The root zone MUST be signed by the Internet Assigned
+ Numbers Authority (IANA) in accordance with DNSSEC, see
+ [RFC2535] or its replacements. It is understood that
+ DNSSEC is not yet deployable on some common platforms, but
+ will be deployed when supported.
+
+ 3.3.2 Root servers MUST be DNSSEC-capable so that queries may be
+ authenticated by clients with security and authentication
+ concerns. It is understood that DNSSEC is not yet
+ deployable on some common platforms, but will be deployed
+ when supported.
+
+ 3.3.3 Transfer of the root zone between root servers MUST be
+ authenticated and be as secure as reasonably possible.
+ Out of band security validation of updates MUST be
+ supported. Servers MUST use DNSSEC to authenticate root
+ zones received from other servers. It is understood that
+ DNSSEC is not yet deployable on some common platforms, but
+ will be deployed when supported.
+
+ 3.3.4 A 'hidden primary' server, which only allows access by the
+ authorized secondary root servers, MAY be used.
+
+ 3.3.5 Root zone updates SHOULD only progress after a number of
+ heuristic checks designed to detect erroneous updates have
+ been passed. In case the update fails the tests, human
+ intervention MUST be requested.
+
+ 3.3.6 Root zone updates SHOULD normally be effective no later
+ than 6 hours from notification of the root server
+ operator.
+
+ 3.3.7 A special procedure for emergency updates SHOULD be
+ defined. Updates initiated by the emergency procedure
+ SHOULD be made no later than 12 hours after notification.
+
+ 3.3.8 In the advent of a critical network failure, each root
+ server MUST have a method to update the root zone data via
+ a medium which is delivered through an alternative, non-
+ network, path.
+
+ 3.3.9 Each root MUST keep global statistics on the amount and
+ types of queries received/answered on a daily basis. These
+ statistics must be made available to RSSAC and RSSAC
+ sponsored researchers to help determine how to better
+ deploy these machines more efficiently across the
+
+
+
+
+
+Bush, et al. Best Current Practice [Page 6]
+
+RFC 2870 Root Name Server Operational Requirements June 2000
+
+
+ internet. Each root MAY collect data snapshots to help
+ determine data points such as DNS query storms,
+ significant implementation bugs, etc.
+
+4. Communications
+
+ Communications and coordination between root server operators and
+ between the operators and the IANA and ICANN are necessary.
+
+ 4.1 Planned outages and other down times SHOULD be coordinated
+ between root server operators to ensure that a significant number
+ of the root servers are not all down at the same time.
+ Preannouncement of planned outages also keeps other operators
+ from wasting time wondering about any anomalies.
+
+ 4.2 Root server operators SHOULD coordinate backup timing so that
+ many servers are not off-line being backed up at the same time.
+ Backups SHOULD be frequently transferred off site.
+
+ 4.3 Root server operators SHOULD exchange log files, particularly as
+ they relate to security, loading, and other significant events.
+ This MAY be through a central log coordination point, or MAY be
+ informal.
+
+ 4.4 Statistics as they concern usage rates, loading, and resource
+ utilization SHOULD be exchanged between operators, and MUST be
+ reported to the IANA for planning and reporting purposes.
+
+ 4.5 Root name server administrative personnel MUST be available to
+ provide service 24 hours a day, 7 days per week. On call
+ personnel MAY be used to provide this service outside of normal
+ working hours.
+
+5. Acknowledgements
+
+ The authors would like to thank Scott Bradner, Robert Elz, Chris
+ Fletcher, John Klensin, Steve Bellovin, and Vern Paxson for their
+ constructive comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush, et al. Best Current Practice [Page 7]
+
+RFC 2870 Root Name Server Operational Requirements June 2000
+
+
+6. References
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1305] Mills, D., "Network Time Protocol (Version 3)
+ Specification, Implementation", RFC 1305, March 1992.
+
+ [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
+ for IPv4, IPv6 and OSI", RFC 2030, October 1996.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security
+ Extensions", RFC 2535, March 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush, et al. Best Current Practice [Page 8]
+
+RFC 2870 Root Name Server Operational Requirements June 2000
+
+
+7. Authors' Addresses
+
+ Randy Bush
+ Verio, Inc.
+ 5147 Crystal Springs
+ Bainbridge Island, WA US-98110
+
+ Phone: +1 206 780 0431
+ EMail: randy@psg.com
+
+
+ Daniel Karrenberg
+ RIPE Network Coordination Centre (NCC)
+ Singel 258
+ NL-1016 AB Amsterdam
+ Netherlands
+
+ Phone: +31 20 535 4444
+ EMail: daniel.karrenberg@ripe.net
+
+
+ Mark Kosters
+ Network Solutions
+ 505 Huntmar Park Drive
+ Herndon, VA 22070-5100
+
+ Phone: +1 703 742 0400
+ EMail: markk@netsol.com
+
+
+ Raymond Plzak
+ SAIC
+ 1710 Goodridge Drive
+ McLean, Virginia 22102
+ +1 703 821 6535
+
+ EMail: plzakr@saic.com
+
+8. Specification of Requirements
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119.
+
+
+
+
+
+
+
+
+Bush, et al. Best Current Practice [Page 9]
+
+RFC 2870 Root Name Server Operational Requirements June 2000
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush, et al. Best Current Practice [Page 10]
+
diff --git a/Documentation/en/rfc/rfc2919.txt b/Documentation/en/rfc/rfc2919.txt
new file mode 100644
index 00000000..f2ed316e
--- /dev/null
+++ b/Documentation/en/rfc/rfc2919.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group R. Chandhok
+Request for Comments: 2919 G. Wenger
+Category: Standards Track QUALCOMM, Inc.
+ March 2001
+
+
+ List-Id:
+ A Structured Field and Namespace for the
+ Identification of Mailing Lists
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ Software that handles electronic mailing list messages (servers and
+ user agents) needs a way to reliably identify messages that belong to
+ a particular mailing list. With the advent of list management
+ headers, it has become even more important to provide a unique
+ identifier for a mailing list regardless of the particular host that
+ serves as the list processor at any given time.
+
+ The List-Id header provides a standard location for such an
+ identifier. In addition, a namespace for list identifiers based on
+ fully qualified domain names is described. This namespace is
+ intended to guarantee uniqueness for list owners who require it,
+ while allowing for a less rigorous namespace for experimental and
+ personal use.
+
+ By including the List-Id field, list servers can make it easier for
+ mail clients to provide automated tools for users to perform list
+ functions. The list identifier can serve as a key to make many
+ automated processing tasks easier, and hence more widely available.
+
+1. Introduction
+
+ Internet mailing lists have evolved into fairly sophisticated forums
+ for group communication and collaboration; however, corresponding
+ changes in the underlying infrastructure have lagged behind. Recent
+
+
+
+Chandhok & Wenger Standards Track [Page 1]
+
+RFC 2919 List-Id March 2001
+
+
+ proposals like [RFC2369] have expanded the functionality that the MUA
+ can provide by providing more information in each message sent by the
+ mailing list distribution software.
+
+ Actually implementing such functionality in the MUA depends on the
+ ability to accurately identify messages as belonging to a particular
+ mailing list. The problem then becomes what attribute or property to
+ use to identify a mailing list. The most likely candidate is the
+ submission address of the mailing list itself. Unfortunately, when
+ the list server host, the list processing software, or the submission
+ policy of the list changes the submission address itself can change.
+ This causes great difficulty for automated processing and filtering.
+
+ In order to further automate (and make more accurate) the processing
+ a software agent can do, there needs to be some unique identifier to
+ use as an identifier for the mailing list. This identifier can be
+ simply used for string matching in a filter, or it can be used in
+ more sophisticated systems to uniquely identify messages as belonging
+ to a particular mailing list independent of the particular host
+ delivering the actual messages. This identifier can also act as a
+ key into a database of mailing lists.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119.
+
+2. The List Identifier Syntax
+
+ The list identifier will, in most cases, appear like a host name in a
+ domain of the list owner. In other words, the domain name system is
+ used to delegate namespace authority for list identifiers just as it
+ has been used to distribute that authority for other internet
+ resources.
+
+ Using the domain name system as a basis for the list identifier
+ namespace is intended to leverage an existing authority structure
+ into a new area of application. By using the domain name system to
+ delegate list identifier namespace authority, it becomes instantly
+ clear who has the right to create a particular list identifier, and
+ separates the list identifier from any particular delivery host or
+ mechanism. Only the rights-holder of a domain or subdomain has the
+ authority to create list identifiers in the namespace of that domain.
+ For example, only the rights-holder to the "acm.org" domain has the
+ authority to create list identifiers in "acm.org" domain.
+
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 2]
+
+RFC 2919 List-Id March 2001
+
+
+ While it is perfectly acceptable for a list identifier to be
+ completely independent of the domain name of the host machine
+ servicing the mailing list, the owner of a mailing list MUST NOT
+ generate list identifiers in any domain namespace for which they do
+ not have authority. For example, a mailing list hosting service may
+ choose to assign list identifiers in their own domain based
+ namespace, or they may allow their clients (the list owners) to
+ provide list identifiers in a namespace for which the owner has
+ authority.
+
+ If the owner of the list does not have the authority to create a list
+ identifier in a domain-based namespace, they may create unmanaged
+ list identifiers in the special unmanaged domain "localhost". This
+ would apply to personal users, or users unable to afford domain name
+ registration fees.
+
+ The syntax for a list identifier in ABNF [RFC2234] follows:
+
+ list-id = list-label "." list-id-namespace
+
+ list-label = dot-atom-text
+
+ list-id-namespace = domain-name / unmanaged-list-id-namespace
+
+ unmanaged-list-id-namespace = "localhost"
+
+ domain-name = dot-atom-text
+
+ Where:
+
+ dot-atom-text is defined in [DRUMS]
+
+ "localhost" is a reserved domain name is defined in [RFC2606]
+
+ In addition, a list identifier (list-id) MUST NOT be longer than 255
+ octets in length, for future compatibility. It should be noted that
+ "localhost" is not valid for the domain-name rule.
+
+3. The List-Id Header Field
+
+ This document presents a header field which will provide an
+ identifier for an e-mail distribution list. This header SHOULD be
+ included on all messages distributed by the list (including command
+ responses to individual users), and on other messages where the
+ message clearly applies to this particular distinct list. There MUST
+ be no more than one of each field present in any given message.
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 3]
+
+RFC 2919 List-Id March 2001
+
+
+ This field MUST only be generated by mailing list software, not end
+ users.
+
+ The contents of the List-Id header mostly consist of angle-bracket
+ ('<', '>') enclosed identifier, with internal whitespace being
+ ignored. MTAs MUST NOT insert whitespace within the brackets, but
+ client applications should treat any such whitespace, that might be
+ inserted by poorly behaved MTAs, as characters to ignore.
+
+ The list header fields are subject to the encoding and character
+ restrictions for mail headers as described in [RFC822].
+
+ The List-Id header MAY optionally include a description by including
+ it as a "phrase" [DRUMS] before the angle-bracketed list identifier.
+ The MUA MAY choose to use this description in its user interface;
+ however, any MUA that intends to make use of the description should
+ be prepared to properly parse and decode any encoded strings or other
+ legal phrase components. For many MUAs the parsing of the List-Id
+ header will simply consist of extracting the list identifier from
+ between the delimiting angle brackets.
+
+ The syntax of the List-Id header follows:
+
+ list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF
+
+ where phrase and CRLF are as defined in [DRUMS]. Unlike most headers
+ in [RFC822], the List-Id header does not allow free insertion of
+ whitespace and comments around tokens. Any descriptive text must be
+ presented in the optional phrase component of the header.
+
+ Examples:
+
+List-Id: List Header Mailing List <list-header.nisto.com>
+List-Id: <commonspace-users.list-id.within.com>
+List-Id: "Lena's Personal Joke List"
+ <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
+List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
+List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>
+
+4. Persistence of List Identifiers
+
+ Although the list identifier MAY be changed by the mailing list
+ administrator this is not desirable. (Note that there is no
+ disadvantage to changing the description portion of the List-Id
+ header.) A MUA may not recognize the change to the list identifier
+ because the MUA SHOULD treat a different list identifier as a
+ different list. As such the mailing list administrator SHOULD avoid
+ changing the list identifier even when the host serving the list
+
+
+
+Chandhok & Wenger Standards Track [Page 4]
+
+RFC 2919 List-Id March 2001
+
+
+ changes. On the other hand, transitioning from an informal
+ unmanaged-list-id-namespace to a domain namespace is an acceptable
+ reason to change the list identifier. Also if the focus of the list
+ changes sufficiently the administrator may wish to retire the
+ previous list and its associated identifier to start a new list
+ reflecting the new focus.
+
+5. Uniqueness of List Identifiers
+
+ This proposal seeks to leverage the existing administrative process
+ already in place for domain name allocation. In particular, we
+ exploit the fact that domain name ownership creates a namespace that
+ by definition can be used to create unique identifiers within the
+ domain.
+
+ In addition, there must be a mechanism for identification of mailing
+ lists that are administrated by some entity without administrative
+ access to a domain. In this case, general heuristics can be given to
+ reduce the chance of collision, but it cannot be guaranteed. If a
+ list owner requires a guarantee, they are free to register a domain
+ name under their control.
+
+ It is suggested, but not required, that list identifiers be created
+ under a subdomain of "list-id" within any given domain. This can
+ help to reduce internal conflicts between the administrators of the
+ subdomains of large organizations. For example, list identifiers at
+ "within.com" are generated in the subdomain of "list-id.within.com".
+
+ List-IDs not ending with ".localhost" MUST be globally unique in
+ reference to all other mailing lists.
+
+ List owners wishing to use the special "localhost" namespace for
+ their list identifier SHOULD use the month and year (in the form
+ MMYYYY) that they create the list identifier as a "subdomain" of the
+ "localhost" namespace. In addition, some portion of the list
+ identifier MUST be a randomly generated string. List owners
+ generating such identifiers should refer to [MSGID] for further
+ suggestions on generating a unique identifier, and [RFC1750] for
+ suggestions on generating random numbers. In particular, list
+ identifiers that have a random component SHOULD contain a hex
+ encoding of 128 bits of randomness (resulting in 32 hex characters)
+ as part of the list identifier
+
+ Thus, list identifiers such as
+ <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and
+ <da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these
+ guidelines, while <lenas-jokes.021999.localhost> and
+
+
+
+
+Chandhok & Wenger Standards Track [Page 5]
+
+RFC 2919 List-Id March 2001
+
+
+ <mylist.localhost> do not. A particular list owner with several
+ lists MAY choose to use the same random number subdomain when
+ generating list identifiers for each of the lists.
+
+ List-IDs ending with ".localhost" are not guaranteed to be globally
+ unique.
+
+6. Operations on List Identifiers
+
+ There is only one operation defined for list identifiers, that of
+ case insensitive equality (See Section 3.4.7., CASE INDEPENDENCE
+ [RFC822]). The sole use of a list identifier is to identify a
+ mailing list, and the sole use of the List-Id header is to mark a
+ particular message as belonging to that list. The comparison
+ operation MUST ignore any part of the List-Id header outside of the
+ angle brackets, the MUA MAY choose to inform the user if the
+ descriptive name of a mailing list changes.
+
+7. Supporting Nested Lists
+
+ A list that is a sublist for another list in a nested mailing list
+ hierarchy MUST NOT modify the List-Id header field; however, this
+ will only be possible when the nested mailing list is aware of the
+ relationship between it and its "parent" mailing lists. If a mailing
+ list processor encounters a List-Id header field from any unexpected
+ source it SHOULD NOT pass it through to the list. This implies that
+ mailing list processors may have to be updated to properly support
+ List-Ids for nested lists.
+
+8. Security Considerations
+
+ There are very few new security concerns generated with this
+ proposal. Message headers are an existing standard, designed to
+ easily accommodate new types. There may be concern with headers
+ being forged, but this problem is inherent in Internet e-mail, not
+ specific to the header described in this document. Further, the
+ implications are relatively harmless.
+
+ As mentioned above, mail list processors SHOULD NOT allow any user-
+ originated List-Id fields to pass through to their lists, lest they
+ confuse the user and have the potential to create security problems.
+
+ On the client side, a forged list identifier may break automated
+ processing. The list identifier (in its current form) SHOULD NOT be
+ used as an indication of the authenticity of the message.
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 6]
+
+RFC 2919 List-Id March 2001
+
+
+9. Acknowledgements
+
+ The numerous participants of the List-Header [LISTHEADER] and
+ ListMom-Talk [LISTMOM] mailing lists contributed much to the
+ formation and structure of this document.
+
+ Grant Neufeld <grant@acm.org> focused much of the early discussion,
+ and thus was essential in the creation of this document.
+
+References
+
+ [LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com
+ <http://www.nisto.com/listspec/mail/>
+ <http://www.nisto.com/listspec/>
+
+ [LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
+ <http://cgi.skyweyr.com/ListMom.Home>
+
+ [MSGID] J. Zawinski, M. Curtin, "Recommendations for generating
+ Message IDs", Work in Progress.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", RFC 822, August 1982.
+
+ [RFC1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness
+ Recommendations for Security", RFC 1750, December 1994.
+
+ [RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2369] Neufeld G. and J. Baer, "The Use of URLs as Meta-Syntax
+ for Core Mail List Commands and their Transport through
+ Message Header Fields", RFC 2369, July 1998.
+
+ [RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level
+ DNS Names", BCP 32, RFC 2606, June 1999.
+
+ [RFC2822] Resnick, P., Editor, "Internet Message Format Standard",
+ STD 11, RFC 2822, March 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 7]
+
+RFC 2919 List-Id March 2001
+
+
+Authors' Addresses
+
+ Ravinder Chandhok
+ QUALCOMM, Inc.
+ 5775 Morehouse Drive
+ San Diego, CA 92121 USA
+
+ EMail: chandhok@qualcomm.com
+
+
+ Geoffrey Wenger
+ QUALCOMM, Inc.
+ 5775 Morehouse Drive
+ San Diego, CA 92121 USA
+
+ EMail: gwenger@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 8]
+
+RFC 2919 List-Id March 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 9]
+
diff --git a/Documentation/en/rfc/rfc821.txt b/Documentation/en/rfc/rfc821.txt
new file mode 100644
index 00000000..d877b72c
--- /dev/null
+++ b/Documentation/en/rfc/rfc821.txt
@@ -0,0 +1,4050 @@
+
+
+
+ RFC 821
+
+
+
+
+
+ SIMPLE MAIL TRANSFER PROTOCOL
+
+
+
+ Jonathan B. Postel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 1982
+
+
+
+ Information Sciences Institute
+ University of Southern California
+ 4676 Admiralty Way
+ Marina del Rey, California 90291
+
+ (213) 822-1511
+
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ TABLE OF CONTENTS
+
+ 1. INTRODUCTION .................................................. 1
+
+ 2. THE SMTP MODEL ................................................ 2
+
+ 3. THE SMTP PROCEDURE ............................................ 4
+
+ 3.1. Mail ..................................................... 4
+ 3.2. Forwarding ............................................... 7
+ 3.3. Verifying and Expanding .................................. 8
+ 3.4. Sending and Mailing ..................................... 11
+ 3.5. Opening and Closing ..................................... 13
+ 3.6. Relaying ................................................ 14
+ 3.7. Domains ................................................. 17
+ 3.8. Changing Roles .......................................... 18
+
+ 4. THE SMTP SPECIFICATIONS ...................................... 19
+
+ 4.1. SMTP Commands ........................................... 19
+ 4.1.1. Command Semantics ..................................... 19
+ 4.1.2. Command Syntax ........................................ 27
+ 4.2. SMTP Replies ............................................ 34
+ 4.2.1. Reply Codes by Function Group ......................... 35
+ 4.2.2. Reply Codes in Numeric Order .......................... 36
+ 4.3. Sequencing of Commands and Replies ...................... 37
+ 4.4. State Diagrams .......................................... 39
+ 4.5. Details ................................................. 41
+ 4.5.1. Minimum Implementation ................................ 41
+ 4.5.2. Transparency .......................................... 41
+ 4.5.3. Sizes ................................................. 42
+
+ APPENDIX A: TCP ................................................. 44
+ APPENDIX B: NCP ................................................. 45
+ APPENDIX C: NITS ................................................ 46
+ APPENDIX D: X.25 ................................................ 47
+ APPENDIX E: Theory of Reply Codes ............................... 48
+ APPENDIX F: Scenarios ........................................... 51
+
+ GLOSSARY ......................................................... 64
+
+ REFERENCES ....................................................... 67
+
+
+
+
+Network Working Group J. Postel
+Request for Comments: DRAFT ISI
+Replaces: RFC 788, 780, 772 August 1982
+
+ SIMPLE MAIL TRANSFER PROTOCOL
+
+
+1. INTRODUCTION
+
+ The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
+ mail reliably and efficiently.
+
+ SMTP is independent of the particular transmission subsystem and
+ requires only a reliable ordered data stream channel. Appendices A,
+ B, C, and D describe the use of SMTP with various transport services.
+ A Glossary provides the definitions of terms as used in this
+ document.
+
+ An important feature of SMTP is its capability to relay mail across
+ transport service environments. A transport service provides an
+ interprocess communication environment (IPCE). An IPCE may cover one
+ network, several networks, or a subset of a network. It is important
+ to realize that transport systems (or IPCEs) are not one-to-one with
+ networks. A process can communicate directly with another process
+ through any mutually known IPCE. Mail is an application or use of
+ interprocess communication. Mail can be communicated between
+ processes in different IPCEs by relaying through a process connected
+ to two (or more) IPCEs. More specifically, mail can be relayed
+ between hosts on different transport systems by a host on both
+ transport systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 1]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+2. THE SMTP MODEL
+
+ The SMTP design is based on the following model of communication: as
+ the result of a user mail request, the sender-SMTP establishes a
+ two-way transmission channel to a receiver-SMTP. The receiver-SMTP
+ may be either the ultimate destination or an intermediate. SMTP
+ commands are generated by the sender-SMTP and sent to the
+ receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the
+ sender-SMTP in response to the commands.
+
+ Once the transmission channel is established, the SMTP-sender sends a
+ MAIL command indicating the sender of the mail. If the SMTP-receiver
+ can accept mail it responds with an OK reply. The SMTP-sender then
+ sends a RCPT command identifying a recipient of the mail. If the
+ SMTP-receiver can accept mail for that recipient it responds with an
+ OK reply; if not, it responds with a reply rejecting that recipient
+ (but not the whole mail transaction). The SMTP-sender and
+ SMTP-receiver may negotiate several recipients. When the recipients
+ have been negotiated the SMTP-sender sends the mail data, terminating
+ with a special sequence. If the SMTP-receiver successfully processes
+ the mail data it responds with an OK reply. The dialog is purposely
+ lock-step, one-at-a-time.
+
+ -------------------------------------------------------------
+
+
+ +----------+ +----------+
+ +------+ | | | |
+ | User |<-->| | SMTP | |
+ +------+ | Sender- |Commands/Replies| Receiver-|
+ +------+ | SMTP |<-------------->| SMTP | +------+
+ | File |<-->| | and Mail | |<-->| File |
+ |System| | | | | |System|
+ +------+ +----------+ +----------+ +------+
+
+
+ Sender-SMTP Receiver-SMTP
+
+ Model for SMTP Use
+
+ Figure 1
+
+ -------------------------------------------------------------
+
+ The SMTP provides mechanisms for the transmission of mail; directly
+ from the sending user's host to the receiving user's host when the
+
+
+
+[Page 2] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ two host are connected to the same transport service, or via one or
+ more relay SMTP-servers when the source and destination hosts are not
+ connected to the same transport service.
+
+ To be able to provide the relay capability the SMTP-server must be
+ supplied with the name of the ultimate destination host as well as
+ the destination mailbox name.
+
+ The argument to the MAIL command is a reverse-path, which specifies
+ who the mail is from. The argument to the RCPT command is a
+ forward-path, which specifies who the mail is to. The forward-path
+ is a source route, while the reverse-path is a return route (which
+ may be used to return a message to the sender when an error occurs
+ with a relayed message).
+
+ When the same message is sent to multiple recipients the SMTP
+ encourages the transmission of only one copy of the data for all the
+ recipients at the same destination host.
+
+ The mail commands and replies have a rigid syntax. Replies also have
+ a numeric code. In the following, examples appear which use actual
+ commands and replies. The complete lists of commands and replies
+ appears in Section 4 on specifications.
+
+ Commands and replies are not case sensitive. That is, a command or
+ reply word may be upper case, lower case, or any mixture of upper and
+ lower case. Note that this is not true of mailbox user names. For
+ some hosts the user name is case sensitive, and SMTP implementations
+ must take case to preserve the case of user names as they appear in
+ mailbox arguments. Host names are not case sensitive.
+
+ Commands and replies are composed of characters from the ASCII
+ character set [1]. When the transport service provides an 8-bit byte
+ (octet) transmission channel, each 7-bit character is transmitted
+ right justified in an octet with the high order bit cleared to zero.
+
+ When specifying the general form of a command or reply, an argument
+ (or special symbol) will be denoted by a meta-linguistic variable (or
+ constant), for example, "<string>" or "<reverse-path>". Here the
+ angle brackets indicate these are meta-linguistic variables.
+ However, some arguments use the angle brackets literally. For
+ example, an actual reverse-path is enclosed in angle brackets, i.e.,
+ "<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (the
+ angle brackets are actually transmitted in the command or reply).
+
+
+
+
+
+Postel [Page 3]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+3. THE SMTP PROCEDURES
+
+ This section presents the procedures used in SMTP in several parts.
+ First comes the basic mail procedure defined as a mail transaction.
+ Following this are descriptions of forwarding mail, verifying mailbox
+ names and expanding mailing lists, sending to terminals instead of or
+ in combination with mailboxes, and the opening and closing exchanges.
+ At the end of this section are comments on relaying, a note on mail
+ domains, and a discussion of changing roles. Throughout this section
+ are examples of partial command and reply sequences, several complete
+ scenarios are presented in Appendix F.
+
+ 3.1. MAIL
+
+ There are three steps to SMTP mail transactions. The transaction
+ is started with a MAIL command which gives the sender
+ identification. A series of one or more RCPT commands follows
+ giving the receiver information. Then a DATA command gives the
+ mail data. And finally, the end of mail data indicator confirms
+ the transaction.
+
+ The first step in the procedure is the MAIL command. The
+ <reverse-path> contains the source mailbox.
+
+ MAIL <SP> FROM:<reverse-path> <CRLF>
+
+ This command tells the SMTP-receiver that a new mail
+ transaction is starting and to reset all its state tables and
+ buffers, including any recipients or mail data. It gives the
+ reverse-path which can be used to report errors. If accepted,
+ the receiver-SMTP returns a 250 OK reply.
+
+ The <reverse-path> can contain more than just a mailbox. The
+ <reverse-path> is a reverse source routing list of hosts and
+ source mailbox. The first host in the <reverse-path> should be
+ the host sending this command.
+
+ The second step in the procedure is the RCPT command.
+
+ RCPT <SP> TO:<forward-path> <CRLF>
+
+ This command gives a forward-path identifying one recipient.
+ If accepted, the receiver-SMTP returns a 250 OK reply, and
+ stores the forward-path. If the recipient is unknown the
+ receiver-SMTP returns a 550 Failure reply. This second step of
+ the procedure can be repeated any number of times.
+
+
+
+[Page 4] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ The <forward-path> can contain more than just a mailbox. The
+ <forward-path> is a source routing list of hosts and the
+ destination mailbox. The first host in the <forward-path>
+ should be the host receiving this command.
+
+ The third step in the procedure is the DATA command.
+
+ DATA <CRLF>
+
+ If accepted, the receiver-SMTP returns a 354 Intermediate reply
+ and considers all succeeding lines to be the message text.
+ When the end of text is received and stored the SMTP-receiver
+ sends a 250 OK reply.
+
+ Since the mail data is sent on the transmission channel the end
+ of the mail data must be indicated so that the command and
+ reply dialog can be resumed. SMTP indicates the end of the
+ mail data by sending a line containing only a period. A
+ transparency procedure is used to prevent this from interfering
+ with the user's text (see Section 4.5.2).
+
+ Please note that the mail data includes the memo header
+ items such as Date, Subject, To, Cc, From [2].
+
+ The end of mail data indicator also confirms the mail
+ transaction and tells the receiver-SMTP to now process the
+ stored recipients and mail data. If accepted, the
+ receiver-SMTP returns a 250 OK reply. The DATA command should
+ fail only if the mail transaction was incomplete (for example,
+ no recipients), or if resources are not available.
+
+ The above procedure is an example of a mail transaction. These
+ commands must be used only in the order discussed above.
+ Example 1 (below) illustrates the use of these commands in a mail
+ transaction.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 5]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ -------------------------------------------------------------
+
+ Example of the SMTP Procedure
+
+ This SMTP example shows mail sent by Smith at host Alpha.ARPA,
+ to Jones, Green, and Brown at host Beta.ARPA. Here we assume
+ that host Alpha contacts host Beta directly.
+
+ S: MAIL FROM:<Smith@Alpha.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Jones@Beta.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Green@Beta.ARPA>
+ R: 550 No such user here
+
+ S: RCPT TO:<Brown@Beta.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: <CRLF>.<CRLF>
+ R: 250 OK
+
+ The mail has now been accepted for Jones and Brown. Green did
+ not have a mailbox at host Beta.
+
+ Example 1
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 6] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ 3.2. FORWARDING
+
+ There are some cases where the destination information in the
+ <forward-path> is incorrect, but the receiver-SMTP knows the
+ correct destination. In such cases, one of the following replies
+ should be used to allow the sender to contact the correct
+ destination.
+
+ 251 User not local; will forward to <forward-path>
+
+ This reply indicates that the receiver-SMTP knows the user's
+ mailbox is on another host and indicates the correct
+ forward-path to use in the future. Note that either the
+ host or user or both may be different. The receiver takes
+ responsibility for delivering the message.
+
+ 551 User not local; please try <forward-path>
+
+ This reply indicates that the receiver-SMTP knows the user's
+ mailbox is on another host and indicates the correct
+ forward-path to use. Note that either the host or user or
+ both may be different. The receiver refuses to accept mail
+ for this user, and the sender must either redirect the mail
+ according to the information provided or return an error
+ response to the originating user.
+
+ Example 2 illustrates the use of these responses.
+
+ -------------------------------------------------------------
+
+ Example of Forwarding
+
+ Either
+
+ S: RCPT TO:<Postel@USC-ISI.ARPA>
+ R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
+
+ Or
+
+ S: RCPT TO:<Paul@USC-ISIB.ARPA>
+ R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>
+
+ Example 2
+
+ -------------------------------------------------------------
+
+
+
+
+Postel [Page 7]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ 3.3. VERIFYING AND EXPANDING
+
+ SMTP provides as additional features, commands to verify a user
+ name or expand a mailing list. This is done with the VRFY and
+ EXPN commands, which have character string arguments. For the
+ VRFY command, the string is a user name, and the response may
+ include the full name of the user and must include the mailbox of
+ the user. For the EXPN command, the string identifies a mailing
+ list, and the multiline response may include the full name of the
+ users and must give the mailboxes on the mailing list.
+
+ "User name" is a fuzzy term and used purposely. If a host
+ implements the VRFY or EXPN commands then at least local mailboxes
+ must be recognized as "user names". If a host chooses to
+ recognize other strings as "user names" that is allowed.
+
+ In some hosts the distinction between a mailing list and an alias
+ for a single mailbox is a bit fuzzy, since a common data structure
+ may hold both types of entries, and it is possible to have mailing
+ lists of one mailbox. If a request is made to verify a mailing
+ list a positive response can be given if on receipt of a message
+ so addressed it will be delivered to everyone on the list,
+ otherwise an error should be reported (e.g., "550 That is a
+ mailing list, not a user"). If a request is made to expand a user
+ name a positive response can be formed by returning a list
+ containing one name, or an error can be reported (e.g., "550 That
+ is a user name, not a mailing list").
+
+ In the case of a multiline reply (normal for EXPN) exactly one
+ mailbox is to be specified on each line of the reply. In the case
+ of an ambiguous request, for example, "VRFY Smith", where there
+ are two Smith's the response must be "553 User ambiguous".
+
+ The case of verifying a user name is straightforward as shown in
+ example 3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 8] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ -------------------------------------------------------------
+
+ Example of Verifying a User Name
+
+ Either
+
+ S: VRFY Smith
+ R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
+
+ Or
+
+ S: VRFY Smith
+ R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
+
+ Or
+
+ S: VRFY Jones
+ R: 550 String does not match anything.
+
+ Or
+
+ S: VRFY Jones
+ R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
+
+ Or
+
+ S: VRFY Gourzenkyinplatz
+ R: 553 User ambiguous.
+
+ Example 3
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 9]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ The case of expanding a mailbox list requires a multiline reply as
+ shown in example 4.
+
+ -------------------------------------------------------------
+
+ Example of Expanding a Mailing List
+
+ Either
+
+ S: EXPN Example-People
+ R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
+ R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+ R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
+ R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+ R: 250-<joe@foo-unix.ARPA>
+ R: 250 <xyz@bar-unix.ARPA>
+
+ Or
+
+ S: EXPN Executive-Washroom-List
+ R: 550 Access Denied to You.
+
+ Example 4
+
+ -------------------------------------------------------------
+
+ The character string arguments of the VRFY and EXPN commands
+ cannot be further restricted due to the variety of implementations
+ of the user name and mailbox list concepts. On some systems it
+ may be appropriate for the argument of the EXPN command to be a
+ file name for a file containing a mailing list, but again there is
+ a variety of file naming conventions in the Internet.
+
+ The VRFY and EXPN commands are not included in the minimum
+ implementation (Section 4.5.1), and are not required to work
+ across relays when they are implemented.
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 10] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ 3.4. SENDING AND MAILING
+
+ The main purpose of SMTP is to deliver messages to user's
+ mailboxes. A very similar service provided by some hosts is to
+ deliver messages to user's terminals (provided the user is active
+ on the host). The delivery to the user's mailbox is called
+ "mailing", the delivery to the user's terminal is called
+ "sending". Because in many hosts the implementation of sending is
+ nearly identical to the implementation of mailing these two
+ functions are combined in SMTP. However the sending commands are
+ not included in the required minimum implementation
+ (Section 4.5.1). Users should have the ability to control the
+ writing of messages on their terminals. Most hosts permit the
+ users to accept or refuse such messages.
+
+ The following three command are defined to support the sending
+ options. These are used in the mail transaction instead of the
+ MAIL command and inform the receiver-SMTP of the special semantics
+ of this transaction:
+
+ SEND <SP> FROM:<reverse-path> <CRLF>
+
+ The SEND command requires that the mail data be delivered to
+ the user's terminal. If the user is not active (or not
+ accepting terminal messages) on the host a 450 reply may
+ returned to a RCPT command. The mail transaction is
+ successful if the message is delivered the terminal.
+
+ SOML <SP> FROM:<reverse-path> <CRLF>
+
+ The Send Or MaiL command requires that the mail data be
+ delivered to the user's terminal if the user is active (and
+ accepting terminal messages) on the host. If the user is
+ not active (or not accepting terminal messages) then the
+ mail data is entered into the user's mailbox. The mail
+ transaction is successful if the message is delivered either
+ to the terminal or the mailbox.
+
+ SAML <SP> FROM:<reverse-path> <CRLF>
+
+ The Send And MaiL command requires that the mail data be
+ delivered to the user's terminal if the user is active (and
+ accepting terminal messages) on the host. In any case the
+ mail data is entered into the user's mailbox. The mail
+ transaction is successful if the message is delivered the
+ mailbox.
+
+
+
+Postel [Page 11]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ The same reply codes that are used for the MAIL commands are used
+ for these commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 12] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ 3.5. OPENING AND CLOSING
+
+ At the time the transmission channel is opened there is an
+ exchange to ensure that the hosts are communicating with the hosts
+ they think they are.
+
+ The following two commands are used in transmission channel
+ opening and closing:
+
+ HELO <SP> <domain> <CRLF>
+
+ QUIT <CRLF>
+
+ In the HELO command the host sending the command identifies
+ itself; the command may be interpreted as saying "Hello, I am
+ <domain>".
+
+ -------------------------------------------------------------
+
+ Example of Connection Opening
+
+ R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIF.ARPA
+ R: 250 BBN-UNIX.ARPA
+
+ Example 5
+
+ -------------------------------------------------------------
+
+ -------------------------------------------------------------
+
+ Example of Connection Closing
+
+ S: QUIT
+ R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+ Example 6
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+Postel [Page 13]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ 3.6. RELAYING
+
+ The forward-path may be a source route of the form
+ "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts. This
+ form is used to emphasize the distinction between an address and a
+ route. The mailbox is an absolute address, and the route is
+ information about how to get there. The two concepts should not
+ be confused.
+
+ Conceptually the elements of the forward-path are moved to the
+ reverse-path as the message is relayed from one server-SMTP to
+ another. The reverse-path is a reverse source route, (i.e., a
+ source route from the current location of the message to the
+ originator of the message). When a server-SMTP deletes its
+ identifier from the forward-path and inserts it into the
+ reverse-path, it must use the name it is known by in the
+ environment it is sending into, not the environment the mail came
+ from, in case the server-SMTP is known by different names in
+ different environments.
+
+ If when the message arrives at an SMTP the first element of the
+ forward-path is not the identifier of that SMTP the element is not
+ deleted from the forward-path and is used to determine the next
+ SMTP to send the message to. In any case, the SMTP adds its own
+ identifier to the reverse-path.
+
+ Using source routing the receiver-SMTP receives mail to be relayed
+ to another server-SMTP The receiver-SMTP may accept or reject the
+ task of relaying the mail in the same way it accepts or rejects
+ mail for a local user. The receiver-SMTP transforms the command
+ arguments by moving its own identifier from the forward-path to
+ the beginning of the reverse-path. The receiver-SMTP then becomes
+ a sender-SMTP, establishes a transmission channel to the next SMTP
+ in the forward-path, and sends it the mail.
+
+ The first host in the reverse-path should be the host sending the
+ SMTP commands, and the first host in the forward-path should be
+ the host receiving the SMTP commands.
+
+ Notice that the forward-path and reverse-path appear in the SMTP
+ commands and replies, but not necessarily in the message. That
+ is, there is no need for these paths and especially this syntax to
+ appear in the "To:" , "From:", "CC:", etc. fields of the message
+ header.
+
+ If a server-SMTP has accepted the task of relaying the mail and
+
+
+
+[Page 14] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ later finds that the forward-path is incorrect or that the mail
+ cannot be delivered for whatever reason, then it must construct an
+ "undeliverable mail" notification message and send it to the
+ originator of the undeliverable mail (as indicated by the
+ reverse-path).
+
+ This notification message must be from the server-SMTP at this
+ host. Of course, server-SMTPs should not send notification
+ messages about problems with notification messages. One way to
+ prevent loops in error reporting is to specify a null reverse-path
+ in the MAIL command of a notification message. When such a
+ message is relayed it is permissible to leave the reverse-path
+ null. A MAIL command with a null reverse-path appears as follows:
+
+ MAIL FROM:<>
+
+ An undeliverable mail notification message is shown in example 7.
+ This notification is in response to a message originated by JOE at
+ HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
+ to HOSTZ. What we see in the example is the transaction between
+ HOSTY and HOSTX, which is the first step in the return of the
+ notification message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 15]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ -------------------------------------------------------------
+
+ Example Undeliverable Mail Notification Message
+
+ S: MAIL FROM:<>
+ R: 250 ok
+ S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
+ R: 250 ok
+ S: DATA
+ R: 354 send the mail data, end with .
+ S: Date: 23 Oct 81 11:22:33
+ S: From: SMTP@HOSTY.ARPA
+ S: To: JOE@HOSTW.ARPA
+ S: Subject: Mail System Problem
+ S:
+ S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost.
+ S: HOSTZ.ARPA said this:
+ S: "550 No Such User"
+ S: .
+ R: 250 ok
+
+ Example 7
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 16] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ 3.7. DOMAINS
+
+ Domains are a recently introduced concept in the ARPA Internet
+ mail system. The use of domains changes the address space from a
+ flat global space of simple character string host names to a
+ hierarchically structured rooted tree of global addresses. The
+ host name is replaced by a domain and host designator which is a
+ sequence of domain element strings separated by periods with the
+ understanding that the domain elements are ordered from the most
+ specific to the most general.
+
+ For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
+ "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
+
+ Whenever domain names are used in SMTP only the official names are
+ used, the use of nicknames or aliases is not allowed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 17]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ 3.8. CHANGING ROLES
+
+ The TURN command may be used to reverse the roles of the two
+ programs communicating over the transmission channel.
+
+ If program-A is currently the sender-SMTP and it sends the TURN
+ command and receives an ok reply (250) then program-A becomes the
+ receiver-SMTP.
+
+ If program-B is currently the receiver-SMTP and it receives the
+ TURN command and sends an ok reply (250) then program-B becomes
+ the sender-SMTP.
+
+ To refuse to change roles the receiver sends the 502 reply.
+
+ Please note that this command is optional. It would not normally
+ be used in situations where the transmission channel is TCP.
+ However, when the cost of establishing the transmission channel is
+ high, this command may be quite useful. For example, this command
+ may be useful in supporting be mail exchange using the public
+ switched telephone system as a transmission channel, especially if
+ some hosts poll other hosts for mail exchanges.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 18] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+4. THE SMTP SPECIFICATIONS
+
+ 4.1. SMTP COMMANDS
+
+ 4.1.1. COMMAND SEMANTICS
+
+ The SMTP commands define the mail transfer or the mail system
+ function requested by the user. SMTP commands are character
+ strings terminated by <CRLF>. The command codes themselves are
+ alphabetic characters terminated by <SP> if parameters follow
+ and <CRLF> otherwise. The syntax of mailboxes must conform to
+ receiver site conventions. The SMTP commands are discussed
+ below. The SMTP replies are discussed in the Section 4.2.
+
+ A mail transaction involves several data objects which are
+ communicated as arguments to different commands. The
+ reverse-path is the argument of the MAIL command, the
+ forward-path is the argument of the RCPT command, and the mail
+ data is the argument of the DATA command. These arguments or
+ data objects must be transmitted and held pending the
+ confirmation communicated by the end of mail data indication
+ which finalizes the transaction. The model for this is that
+ distinct buffers are provided to hold the types of data
+ objects, that is, there is a reverse-path buffer, a
+ forward-path buffer, and a mail data buffer. Specific commands
+ cause information to be appended to a specific buffer, or cause
+ one or more buffers to be cleared.
+
+ HELLO (HELO)
+
+ This command is used to identify the sender-SMTP to the
+ receiver-SMTP. The argument field contains the host name of
+ the sender-SMTP.
+
+ The receiver-SMTP identifies itself to the sender-SMTP in
+ the connection greeting reply, and in the response to this
+ command.
+
+ This command and an OK reply to it confirm that both the
+ sender-SMTP and the receiver-SMTP are in the initial state,
+ that is, there is no transaction in progress and all state
+ tables and buffers are cleared.
+
+
+
+
+
+
+
+Postel [Page 19]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ MAIL (MAIL)
+
+ This command is used to initiate a mail transaction in which
+ the mail data is delivered to one or more mailboxes. The
+ argument field contains a reverse-path.
+
+ The reverse-path consists of an optional list of hosts and
+ the sender mailbox. When the list of hosts is present, it
+ is a "reverse" source route and indicates that the mail was
+ relayed through each host on the list (the first host in the
+ list was the most recent relay). This list is used as a
+ source route to return non-delivery notices to the sender.
+ As each relay host adds itself to the beginning of the list,
+ it must use its name as known in the IPCE to which it is
+ relaying the mail rather than the IPCE from which the mail
+ came (if they are different). In some types of error
+ reporting messages (for example, undeliverable mail
+ notifications) the reverse-path may be null (see Example 7).
+
+ This command clears the reverse-path buffer, the
+ forward-path buffer, and the mail data buffer; and inserts
+ the reverse-path information from this command into the
+ reverse-path buffer.
+
+ RECIPIENT (RCPT)
+
+ This command is used to identify an individual recipient of
+ the mail data; multiple recipients are specified by multiple
+ use of this command.
+
+ The forward-path consists of an optional list of hosts and a
+ required destination mailbox. When the list of hosts is
+ present, it is a source route and indicates that the mail
+ must be relayed to the next host on the list. If the
+ receiver-SMTP does not implement the relay function it may
+ user the same reply it would for an unknown local user
+ (550).
+
+ When mail is relayed, the relay host must remove itself from
+ the beginning forward-path and put itself at the beginning
+ of the reverse-path. When mail reaches its ultimate
+ destination (the forward-path contains only a destination
+ mailbox), the receiver-SMTP inserts it into the destination
+ mailbox in accordance with its host mail conventions.
+
+
+
+
+
+[Page 20] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ For example, mail received at relay host A with arguments
+
+ FROM:<USERX@HOSTY.ARPA>
+ TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
+
+ will be relayed on to host B with arguments
+
+ FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
+ TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
+
+ This command causes its forward-path argument to be appended
+ to the forward-path buffer.
+
+ DATA (DATA)
+
+ The receiver treats the lines following the command as mail
+ data from the sender. This command causes the mail data
+ from this command to be appended to the mail data buffer.
+ The mail data may contain any of the 128 ASCII character
+ codes.
+
+ The mail data is terminated by a line containing only a
+ period, that is the character sequence "<CRLF>.<CRLF>" (see
+ Section 4.5.2 on Transparency). This is the end of mail
+ data indication.
+
+ The end of mail data indication requires that the receiver
+ must now process the stored mail transaction information.
+ This processing consumes the information in the reverse-path
+ buffer, the forward-path buffer, and the mail data buffer,
+ and on the completion of this command these buffers are
+ cleared. If the processing is successful the receiver must
+ send an OK reply. If the processing fails completely the
+ receiver must send a failure reply.
+
+ When the receiver-SMTP accepts a message either for relaying
+ or for final delivery it inserts at the beginning of the
+ mail data a time stamp line. The time stamp line indicates
+ the identity of the host that sent the message, and the
+ identity of the host that received the message (and is
+ inserting this time stamp), and the date and time the
+ message was received. Relayed messages will have multiple
+ time stamp lines.
+
+ When the receiver-SMTP makes the "final delivery" of a
+ message it inserts at the beginning of the mail data a
+
+
+
+Postel [Page 21]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ return path line. The return path line preserves the
+ information in the <reverse-path> from the MAIL command.
+ Here, final delivery means the message leaves the SMTP
+ world. Normally, this would mean it has been delivered to
+ the destination user, but in some cases it may be further
+ processed and transmitted by another mail system.
+
+ It is possible for the mailbox in the return path be
+ different from the actual sender's mailbox, for example,
+ if error responses are to be delivered a special error
+ handling mailbox rather than the message senders.
+
+ The preceding two paragraphs imply that the final mail data
+ will begin with a return path line, followed by one or more
+ time stamp lines. These lines will be followed by the mail
+ data header and body [2]. See Example 8.
+
+ Special mention is needed of the response and further action
+ required when the processing following the end of mail data
+ indication is partially successful. This could arise if
+ after accepting several recipients and the mail data, the
+ receiver-SMTP finds that the mail data can be successfully
+ delivered to some of the recipients, but it cannot be to
+ others (for example, due to mailbox space allocation
+ problems). In such a situation, the response to the DATA
+ command must be an OK reply. But, the receiver-SMTP must
+ compose and send an "undeliverable mail" notification
+ message to the originator of the message. Either a single
+ notification which lists all of the recipients that failed
+ to get the message, or separate notification messages must
+ be sent for each failed recipient (see Example 7). All
+ undeliverable mail notification messages are sent using the
+ MAIL command (even if they result from processing a SEND,
+ SOML, or SAML command).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 22] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ -------------------------------------------------------------
+
+ Example of Return Path and Received Time Stamps
+
+ Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>
+ Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
+ Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
+ Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
+ Date: 27 Oct 81 15:01:01 PST
+ From: JOE@ABC.ARPA
+ Subject: Improved Mailing System Installed
+ To: SAM@JKL.ARPA
+
+ This is to inform you that ...
+
+ Example 8
+
+ -------------------------------------------------------------
+
+ SEND (SEND)
+
+ This command is used to initiate a mail transaction in which
+ the mail data is delivered to one or more terminals. The
+ argument field contains a reverse-path. This command is
+ successful if the message is delivered to a terminal.
+
+ The reverse-path consists of an optional list of hosts and
+ the sender mailbox. When the list of hosts is present, it
+ is a "reverse" source route and indicates that the mail was
+ relayed through each host on the list (the first host in the
+ list was the most recent relay). This list is used as a
+ source route to return non-delivery notices to the sender.
+ As each relay host adds itself to the beginning of the list,
+ it must use its name as known in the IPCE to which it is
+ relaying the mail rather than the IPCE from which the mail
+ came (if they are different).
+
+ This command clears the reverse-path buffer, the
+ forward-path buffer, and the mail data buffer; and inserts
+ the reverse-path information from this command into the
+ reverse-path buffer.
+
+ SEND OR MAIL (SOML)
+
+ This command is used to initiate a mail transaction in which
+ the mail data is delivered to one or more terminals or
+
+
+
+Postel [Page 23]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ mailboxes. For each recipient the mail data is delivered to
+ the recipient's terminal if the recipient is active on the
+ host (and accepting terminal messages), otherwise to the
+ recipient's mailbox. The argument field contains a
+ reverse-path. This command is successful if the message is
+ delivered to a terminal or the mailbox.
+
+ The reverse-path consists of an optional list of hosts and
+ the sender mailbox. When the list of hosts is present, it
+ is a "reverse" source route and indicates that the mail was
+ relayed through each host on the list (the first host in the
+ list was the most recent relay). This list is used as a
+ source route to return non-delivery notices to the sender.
+ As each relay host adds itself to the beginning of the list,
+ it must use its name as known in the IPCE to which it is
+ relaying the mail rather than the IPCE from which the mail
+ came (if they are different).
+
+ This command clears the reverse-path buffer, the
+ forward-path buffer, and the mail data buffer; and inserts
+ the reverse-path information from this command into the
+ reverse-path buffer.
+
+ SEND AND MAIL (SAML)
+
+ This command is used to initiate a mail transaction in which
+ the mail data is delivered to one or more terminals and
+ mailboxes. For each recipient the mail data is delivered to
+ the recipient's terminal if the recipient is active on the
+ host (and accepting terminal messages), and for all
+ recipients to the recipient's mailbox. The argument field
+ contains a reverse-path. This command is successful if the
+ message is delivered to the mailbox.
+
+ The reverse-path consists of an optional list of hosts and
+ the sender mailbox. When the list of hosts is present, it
+ is a "reverse" source route and indicates that the mail was
+ relayed through each host on the list (the first host in the
+ list was the most recent relay). This list is used as a
+ source route to return non-delivery notices to the sender.
+ As each relay host adds itself to the beginning of the list,
+ it must use its name as known in the IPCE to which it is
+ relaying the mail rather than the IPCE from which the mail
+ came (if they are different).
+
+ This command clears the reverse-path buffer, the
+
+
+
+[Page 24] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ forward-path buffer, and the mail data buffer; and inserts
+ the reverse-path information from this command into the
+ reverse-path buffer.
+
+ RESET (RSET)
+
+ This command specifies that the current mail transaction is
+ to be aborted. Any stored sender, recipients, and mail data
+ must be discarded, and all buffers and state tables cleared.
+ The receiver must send an OK reply.
+
+ VERIFY (VRFY)
+
+ This command asks the receiver to confirm that the argument
+ identifies a user. If it is a user name, the full name of
+ the user (if known) and the fully specified mailbox are
+ returned.
+
+ This command has no effect on any of the reverse-path
+ buffer, the forward-path buffer, or the mail data buffer.
+
+ EXPAND (EXPN)
+
+ This command asks the receiver to confirm that the argument
+ identifies a mailing list, and if so, to return the
+ membership of that list. The full name of the users (if
+ known) and the fully specified mailboxes are returned in a
+ multiline reply.
+
+ This command has no effect on any of the reverse-path
+ buffer, the forward-path buffer, or the mail data buffer.
+
+ HELP (HELP)
+
+ This command causes the receiver to send helpful information
+ to the sender of the HELP command. The command may take an
+ argument (e.g., any command name) and return more specific
+ information as a response.
+
+ This command has no effect on any of the reverse-path
+ buffer, the forward-path buffer, or the mail data buffer.
+
+
+
+
+
+
+
+
+Postel [Page 25]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ NOOP (NOOP)
+
+ This command does not affect any parameters or previously
+ entered commands. It specifies no action other than that
+ the receiver send an OK reply.
+
+ This command has no effect on any of the reverse-path
+ buffer, the forward-path buffer, or the mail data buffer.
+
+ QUIT (QUIT)
+
+ This command specifies that the receiver must send an OK
+ reply, and then close the transmission channel.
+
+ The receiver should not close the transmission channel until
+ it receives and replies to a QUIT command (even if there was
+ an error). The sender should not close the transmission
+ channel until it send a QUIT command and receives the reply
+ (even if there was an error response to a previous command).
+ If the connection is closed prematurely the receiver should
+ act as if a RSET command had been received (canceling any
+ pending transaction, but not undoing any previously
+ completed transaction), the sender should act as if the
+ command or transaction in progress had received a temporary
+ error (4xx).
+
+ TURN (TURN)
+
+ This command specifies that the receiver must either (1)
+ send an OK reply and then take on the role of the
+ sender-SMTP, or (2) send a refusal reply and retain the role
+ of the receiver-SMTP.
+
+ If program-A is currently the sender-SMTP and it sends the
+ TURN command and receives an OK reply (250) then program-A
+ becomes the receiver-SMTP. Program-A is then in the initial
+ state as if the transmission channel just opened, and it
+ then sends the 220 service ready greeting.
+
+ If program-B is currently the receiver-SMTP and it receives
+ the TURN command and sends an OK reply (250) then program-B
+ becomes the sender-SMTP. Program-B is then in the initial
+ state as if the transmission channel just opened, and it
+ then expects to receive the 220 service ready greeting.
+
+ To refuse to change roles the receiver sends the 502 reply.
+
+
+
+[Page 26] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ There are restrictions on the order in which these command may
+ be used.
+
+ The first command in a session must be the HELO command.
+ The HELO command may be used later in a session as well. If
+ the HELO command argument is not acceptable a 501 failure
+ reply must be returned and the receiver-SMTP must stay in
+ the same state.
+
+ The NOOP, HELP, EXPN, and VRFY commands can be used at any
+ time during a session.
+
+ The MAIL, SEND, SOML, or SAML commands begin a mail
+ transaction. Once started a mail transaction consists of
+ one of the transaction beginning commands, one or more RCPT
+ commands, and a DATA command, in that order. A mail
+ transaction may be aborted by the RSET command. There may
+ be zero or more transactions in a session.
+
+ If the transaction beginning command argument is not
+ acceptable a 501 failure reply must be returned and the
+ receiver-SMTP must stay in the same state. If the commands
+ in a transaction are out of order a 503 failure reply must
+ be returned and the receiver-SMTP must stay in the same
+ state.
+
+ The last command in a session must be the QUIT command. The
+ QUIT command can not be used at any other time in a session.
+
+ 4.1.2. COMMAND SYNTAX
+
+ The commands consist of a command code followed by an argument
+ field. Command codes are four alphabetic characters. Upper
+ and lower case alphabetic characters are to be treated
+ identically. Thus, any of the following may represent the mail
+ command:
+
+ MAIL Mail mail MaIl mAIl
+
+ This also applies to any symbols representing parameter values,
+ such as "TO" or "to" for the forward-path. Command codes and
+ the argument fields are separated by one or more spaces.
+ However, within the reverse-path and forward-path arguments
+ case is important. In particular, in some hosts the user
+ "smith" is different from the user "Smith".
+
+
+
+
+Postel [Page 27]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ The argument field consists of a variable length character
+ string ending with the character sequence <CRLF>. The receiver
+ is to take no action until this sequence is received.
+
+ Square brackets denote an optional argument field. If the
+ option is not taken, the appropriate default is implied.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 28] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ The following are the SMTP commands:
+
+ HELO <SP> <domain> <CRLF>
+
+ MAIL <SP> FROM:<reverse-path> <CRLF>
+
+ RCPT <SP> TO:<forward-path> <CRLF>
+
+ DATA <CRLF>
+
+ RSET <CRLF>
+
+ SEND <SP> FROM:<reverse-path> <CRLF>
+
+ SOML <SP> FROM:<reverse-path> <CRLF>
+
+ SAML <SP> FROM:<reverse-path> <CRLF>
+
+ VRFY <SP> <string> <CRLF>
+
+ EXPN <SP> <string> <CRLF>
+
+ HELP [<SP> <string>] <CRLF>
+
+ NOOP <CRLF>
+
+ QUIT <CRLF>
+
+ TURN <CRLF>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 29]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ The syntax of the above argument fields (using BNF notation
+ where applicable) is given below. The "..." notation indicates
+ that a field may be repeated one or more times.
+
+ <reverse-path> ::= <path>
+
+ <forward-path> ::= <path>
+
+ <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
+
+ <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
+
+ <at-domain> ::= "@" <domain>
+
+ <domain> ::= <element> | <element> "." <domain>
+
+ <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
+
+ <mailbox> ::= <local-part> "@" <domain>
+
+ <local-part> ::= <dot-string> | <quoted-string>
+
+ <name> ::= <a> <ldh-str> <let-dig>
+
+ <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+ <let-dig> ::= <a> | <d>
+
+ <let-dig-hyp> ::= <a> | <d> | "-"
+
+ <dot-string> ::= <string> | <string> "." <dot-string>
+
+ <string> ::= <char> | <char> <string>
+
+ <quoted-string> ::= """ <qtext> """
+
+ <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
+
+ <char> ::= <c> | "\" <x>
+
+ <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
+
+ <number> ::= <d> | <d> <number>
+
+ <CRLF> ::= <CR> <LF>
+
+
+
+
+[Page 30] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ <CR> ::= the carriage return character (ASCII code 13)
+
+ <LF> ::= the line feed character (ASCII code 10)
+
+ <SP> ::= the space character (ASCII code 32)
+
+ <snum> ::= one, two, or three digits representing a decimal
+ integer value in the range 0 through 255
+
+ <a> ::= any one of the 52 alphabetic characters A through Z
+ in upper case and a through z in lower case
+
+ <c> ::= any one of the 128 ASCII characters, but not any
+ <special> or <SP>
+
+ <d> ::= any one of the ten digits 0 through 9
+
+ <q> ::= any one of the 128 ASCII characters except <CR>,
+ <LF>, quote ("), or backslash (\)
+
+ <x> ::= any one of the 128 ASCII characters (no exceptions)
+
+ <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
+ | "," | ";" | ":" | "@" """ | the control
+ characters (ASCII codes 0 through 31 inclusive and
+ 127)
+
+ Note that the backslash, "\", is a quote character, which is
+ used to indicate that the next character is to be used
+ literally (instead of its normal interpretation). For example,
+ "Joe\,Smith" could be used to indicate a single nine character
+ user field with comma being the fourth character of the field.
+
+ Hosts are generally known by names which are translated to
+ addresses in each host. Note that the name elements of domains
+ are the official names -- no use of nicknames or aliases is
+ allowed.
+
+ Sometimes a host is not known to the translation function and
+ communication is blocked. To bypass this barrier two numeric
+ forms are also allowed for host "names". One form is a decimal
+ integer prefixed by a pound sign, "#", which indicates the
+ number is the address of the host. Another form is four small
+ decimal integers separated by dots and enclosed by brackets,
+ e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
+ Address in four 8-bit fields.
+
+
+
+Postel [Page 31]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ The time stamp line and the return path line are formally
+ defined as follows:
+
+ <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
+
+ <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
+
+ <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
+ <daytime>
+
+ <from-domain> ::= "FROM" <SP> <domain> <SP>
+
+ <by-domain> ::= "BY" <SP> <domain> <SP>
+
+ <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
+
+ <via> ::= "VIA" <SP> <link> <SP>
+
+ <with> ::= "WITH" <SP> <protocol> <SP>
+
+ <id> ::= "ID" <SP> <string> <SP>
+
+ <for> ::= "FOR" <SP> <path> <SP>
+
+ <link> ::= The standard names for links are registered with
+ the Network Information Center.
+
+ <protocol> ::= The standard names for protocols are
+ registered with the Network Information Center.
+
+ <daytime> ::= <SP> <date> <SP> <time>
+
+ <date> ::= <dd> <SP> <mon> <SP> <yy>
+
+ <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
+
+ <dd> ::= the one or two decimal integer day of the month in
+ the range 1 to 31.
+
+ <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+ "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+
+ <yy> ::= the two decimal integer year of the century in the
+ range 00 to 99.
+
+
+
+
+
+[Page 32] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ <hh> ::= the two decimal integer hour of the day in the
+ range 00 to 24.
+
+ <mm> ::= the two decimal integer minute of the hour in the
+ range 00 to 59.
+
+ <ss> ::= the two decimal integer second of the minute in the
+ range 00 to 59.
+
+ <zone> ::= "UT" for Universal Time (the default) or other
+ time zone designator (as in [2]).
+
+
+
+ -------------------------------------------------------------
+
+ Return Path Example
+
+ Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA>
+
+ Example 9
+
+ -------------------------------------------------------------
+
+ -------------------------------------------------------------
+
+ Time Stamp Line Example
+
+ Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
+
+ Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
+ id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT
+
+ Example 10
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 33]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ 4.2. SMTP REPLIES
+
+ Replies to SMTP commands are devised to ensure the synchronization
+ of requests and actions in the process of mail transfer, and to
+ guarantee that the sender-SMTP always knows the state of the
+ receiver-SMTP. Every command must generate exactly one reply.
+
+ The details of the command-reply sequence are made explicit in
+ Section 5.3 on Sequencing and Section 5.4 State Diagrams.
+
+ An SMTP reply consists of a three digit number (transmitted as
+ three alphanumeric characters) followed by some text. The number
+ is intended for use by automata to determine what state to enter
+ next; the text is meant for the human user. It is intended that
+ the three digits contain enough encoded information that the
+ sender-SMTP need not examine the text and may either discard it or
+ pass it on to the user, as appropriate. In particular, the text
+ may be receiver-dependent and context dependent, so there are
+ likely to be varying texts for each reply code. A discussion of
+ the theory of reply codes is given in Appendix E. Formally, a
+ reply is defined to be the sequence: a three-digit code, <SP>,
+ one line of text, and <CRLF>, or a multiline reply (as defined in
+ Appendix E). Only the EXPN and HELP commands are expected to
+ result in multiline replies in normal circumstances, however
+ multiline replies are allowed for any command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 34] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ 4.2.1. REPLY CODES BY FUNCTION GROUPS
+
+ 500 Syntax error, command unrecognized
+ [This may include errors such as command line too long]
+ 501 Syntax error in parameters or arguments
+ 502 Command not implemented
+ 503 Bad sequence of commands
+ 504 Command parameter not implemented
+
+ 211 System status, or system help reply
+ 214 Help message
+ [Information on how to use the receiver or the meaning of a
+ particular non-standard command; this reply is useful only
+ to the human user]
+
+ 220 <domain> Service ready
+ 221 <domain> Service closing transmission channel
+ 421 <domain> Service not available,
+ closing transmission channel
+ [This may be a reply to any command if the service knows it
+ must shut down]
+
+ 250 Requested mail action okay, completed
+ 251 User not local; will forward to <forward-path>
+ 450 Requested mail action not taken: mailbox unavailable
+ [E.g., mailbox busy]
+ 550 Requested action not taken: mailbox unavailable
+ [E.g., mailbox not found, no access]
+ 451 Requested action aborted: error in processing
+ 551 User not local; please try <forward-path>
+ 452 Requested action not taken: insufficient system storage
+ 552 Requested mail action aborted: exceeded storage allocation
+ 553 Requested action not taken: mailbox name not allowed
+ [E.g., mailbox syntax incorrect]
+ 354 Start mail input; end with <CRLF>.<CRLF>
+ 554 Transaction failed
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 35]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ 4.2.2. NUMERIC ORDER LIST OF REPLY CODES
+
+ 211 System status, or system help reply
+ 214 Help message
+ [Information on how to use the receiver or the meaning of a
+ particular non-standard command; this reply is useful only
+ to the human user]
+ 220 <domain> Service ready
+ 221 <domain> Service closing transmission channel
+ 250 Requested mail action okay, completed
+ 251 User not local; will forward to <forward-path>
+
+ 354 Start mail input; end with <CRLF>.<CRLF>
+
+ 421 <domain> Service not available,
+ closing transmission channel
+ [This may be a reply to any command if the service knows it
+ must shut down]
+ 450 Requested mail action not taken: mailbox unavailable
+ [E.g., mailbox busy]
+ 451 Requested action aborted: local error in processing
+ 452 Requested action not taken: insufficient system storage
+
+ 500 Syntax error, command unrecognized
+ [This may include errors such as command line too long]
+ 501 Syntax error in parameters or arguments
+ 502 Command not implemented
+ 503 Bad sequence of commands
+ 504 Command parameter not implemented
+ 550 Requested action not taken: mailbox unavailable
+ [E.g., mailbox not found, no access]
+ 551 User not local; please try <forward-path>
+ 552 Requested mail action aborted: exceeded storage allocation
+ 553 Requested action not taken: mailbox name not allowed
+ [E.g., mailbox syntax incorrect]
+ 554 Transaction failed
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 36] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ 4.3. SEQUENCING OF COMMANDS AND REPLIES
+
+ The communication between the sender and receiver is intended to
+ be an alternating dialogue, controlled by the sender. As such,
+ the sender issues a command and the receiver responds with a
+ reply. The sender must wait for this response before sending
+ further commands.
+
+ One important reply is the connection greeting. Normally, a
+ receiver will send a 220 "Service ready" reply when the connection
+ is completed. The sender should wait for this greeting message
+ before sending any commands.
+
+ Note: all the greeting type replies have the official name of
+ the server host as the first word following the reply code.
+
+ For example,
+
+ 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
+
+ The table below lists alternative success and failure replies for
+ each command. These must be strictly adhered to; a receiver may
+ substitute text in the replies, but the meaning and action implied
+ by the code numbers and by the specific command reply sequence
+ cannot be altered.
+
+ COMMAND-REPLY SEQUENCES
+
+ Each command is listed with its possible replies. The prefixes
+ used before the possible replies are "P" for preliminary (not
+ used in SMTP), "I" for intermediate, "S" for success, "F" for
+ failure, and "E" for error. The 421 reply (service not
+ available, closing transmission channel) may be given to any
+ command if the SMTP-receiver knows it must shut down. This
+ listing forms the basis for the State Diagrams in Section 4.4.
+
+ CONNECTION ESTABLISHMENT
+ S: 220
+ F: 421
+ HELO
+ S: 250
+ E: 500, 501, 504, 421
+ MAIL
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 421
+
+
+
+Postel [Page 37]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ RCPT
+ S: 250, 251
+ F: 550, 551, 552, 553, 450, 451, 452
+ E: 500, 501, 503, 421
+ DATA
+ I: 354 -> data -> S: 250
+ F: 552, 554, 451, 452
+ F: 451, 554
+ E: 500, 501, 503, 421
+ RSET
+ S: 250
+ E: 500, 501, 504, 421
+ SEND
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 502, 421
+ SOML
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 502, 421
+ SAML
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 502, 421
+ VRFY
+ S: 250, 251
+ F: 550, 551, 553
+ E: 500, 501, 502, 504, 421
+ EXPN
+ S: 250
+ F: 550
+ E: 500, 501, 502, 504, 421
+ HELP
+ S: 211, 214
+ E: 500, 501, 502, 504, 421
+ NOOP
+ S: 250
+ E: 500, 421
+ QUIT
+ S: 221
+ E: 500
+ TURN
+ S: 250
+ F: 502
+ E: 500, 503
+
+
+
+
+[Page 38] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ 4.4. STATE DIAGRAMS
+
+ Following are state diagrams for a simple-minded SMTP
+ implementation. Only the first digit of the reply codes is used.
+ There is one state diagram for each group of SMTP commands. The
+ command groupings were determined by constructing a model for each
+ command and then collecting together the commands with
+ structurally identical models.
+
+ For each command there are three possible outcomes: "success"
+ (S), "failure" (F), and "error" (E). In the state diagrams below
+ we use the symbol B for "begin", and the symbol W for "wait for
+ reply".
+
+ First, the diagram that represents most of the SMTP commands:
+
+
+ 1,3 +---+
+ ----------->| E |
+ | +---+
+ |
+ +---+ cmd +---+ 2 +---+
+ | B |---------->| W |---------->| S |
+ +---+ +---+ +---+
+ |
+ | 4,5 +---+
+ ----------->| F |
+ +---+
+
+
+ This diagram models the commands:
+
+ HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
+ NOOP, QUIT, TURN.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 39]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ A more complex diagram models the DATA command:
+
+
+ +---+ DATA +---+ 1,2 +---+
+ | B |---------->| W |-------------------->| E |
+ +---+ +---+ ------------>+---+
+ 3| |4,5 |
+ | | |
+ -------------- ----- |
+ | | | +---+
+ | ---------- -------->| S |
+ | | | | +---+
+ | | ------------
+ | | | |
+ V 1,3| |2 |
+ +---+ data +---+ --------------->+---+
+ | |---------->| W | | F |
+ +---+ +---+-------------------->+---+
+ 4,5
+
+
+ Note that the "data" here is a series of lines sent from the
+ sender to the receiver with no response expected until the last
+ line is sent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 40] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ 4.5. DETAILS
+
+ 4.5.1. MINIMUM IMPLEMENTATION
+
+ In order to make SMTP workable, the following minimum
+ implementation is required for all receivers:
+
+ COMMANDS -- HELO
+ MAIL
+ RCPT
+ DATA
+ RSET
+ NOOP
+ QUIT
+
+ 4.5.2. TRANSPARENCY
+
+ Without some provision for data transparency the character
+ sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
+ by the user. In general, users are not aware of such
+ "forbidden" sequences. To allow all user composed text to be
+ transmitted transparently the following procedures are used.
+
+ 1. Before sending a line of mail text the sender-SMTP checks
+ the first character of the line. If it is a period, one
+ additional period is inserted at the beginning of the line.
+
+ 2. When a line of mail text is received by the receiver-SMTP
+ it checks the line. If the line is composed of a single
+ period it is the end of mail. If the first character is a
+ period and there are other characters on the line, the first
+ character is deleted.
+
+ The mail data may contain any of the 128 ASCII characters. All
+ characters are to be delivered to the recipient's mailbox
+ including format effectors and other control characters. If
+ the transmission channel provides an 8-bit byte (octets) data
+ stream, the 7-bit ASCII codes are transmitted right justified
+ in the octets with the high order bits cleared to zero.
+
+ In some systems it may be necessary to transform the data as
+ it is received and stored. This may be necessary for hosts
+ that use a different character set than ASCII as their local
+ character set, or that store data in records rather than
+
+
+
+
+
+Postel [Page 41]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ strings. If such transforms are necessary, they must be
+ reversible -- especially if such transforms are applied to
+ mail being relayed.
+
+ 4.5.3. SIZES
+
+ There are several objects that have required minimum maximum
+ sizes. That is, every implementation must be able to receive
+ objects of at least these sizes, but must not send objects
+ larger than these sizes.
+
+
+ ****************************************************
+ * *
+ * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
+ * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+ * OF THESE OBJECTS SHOULD BE USED. *
+ * *
+ ****************************************************
+
+ user
+
+ The maximum total length of a user name is 64 characters.
+
+ domain
+
+ The maximum total length of a domain name or number is 64
+ characters.
+
+ path
+
+ The maximum total length of a reverse-path or
+ forward-path is 256 characters (including the punctuation
+ and element separators).
+
+ command line
+
+ The maximum total length of a command line including the
+ command word and the <CRLF> is 512 characters.
+
+ reply line
+
+ The maximum total length of a reply line including the
+ reply code and the <CRLF> is 512 characters.
+
+
+
+
+
+[Page 42] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ text line
+
+ The maximum total length of a text line including the
+ <CRLF> is 1000 characters (but not counting the leading
+ dot duplicated for transparency).
+
+ recipients buffer
+
+ The maximum total number of recipients that must be
+ buffered is 100 recipients.
+
+
+ ****************************************************
+ * *
+ * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
+ * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+ * OF THESE OBJECTS SHOULD BE USED. *
+ * *
+ ****************************************************
+
+ Errors due to exceeding these limits may be reported by using
+ the reply codes, for example:
+
+ 500 Line too long.
+
+ 501 Path too long
+
+ 552 Too many recipients.
+
+ 552 Too much mail data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 43]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+APPENDIX A
+
+ TCP Transport service
+
+ The Transmission Control Protocol [3] is used in the ARPA
+ Internet, and in any network following the US DoD standards for
+ internetwork protocols.
+
+ Connection Establishment
+
+ The SMTP transmission channel is a TCP connection established
+ between the sender process port U and the receiver process port
+ L. This single full duplex connection is used as the
+ transmission channel. This protocol is assigned the service
+ port 25 (31 octal), that is L=25.
+
+ Data Transfer
+
+ The TCP connection supports the transmission of 8-bit bytes.
+ The SMTP data is 7-bit ASCII characters. Each character is
+ transmitted as an 8-bit byte with the high-order bit cleared to
+ zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 44] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+APPENDIX B
+
+ NCP Transport service
+
+ The ARPANET Host-to-Host Protocol [4] (implemented by the Network
+ Control Program) may be used in the ARPANET.
+
+ Connection Establishment
+
+ The SMTP transmission channel is established via NCP between
+ the sender process socket U and receiver process socket L. The
+ Initial Connection Protocol [5] is followed resulting in a pair
+ of simplex connections. This pair of connections is used as
+ the transmission channel. This protocol is assigned the
+ contact socket 25 (31 octal), that is L=25.
+
+ Data Transfer
+
+ The NCP data connections are established in 8-bit byte mode.
+ The SMTP data is 7-bit ASCII characters. Each character is
+ transmitted as an 8-bit byte with the high-order bit cleared to
+ zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 45]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+APPENDIX C
+
+ NITS
+
+ The Network Independent Transport Service [6] may be used.
+
+ Connection Establishment
+
+ The SMTP transmission channel is established via NITS between
+ the sender process and receiver process. The sender process
+ executes the CONNECT primitive, and the waiting receiver
+ process executes the ACCEPT primitive.
+
+ Data Transfer
+
+ The NITS connection supports the transmission of 8-bit bytes.
+ The SMTP data is 7-bit ASCII characters. Each character is
+ transmitted as an 8-bit byte with the high-order bit cleared to
+ zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 46] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+APPENDIX D
+
+ X.25 Transport service
+
+ It may be possible to use the X.25 service [7] as provided by the
+ Public Data Networks directly, however, it is suggested that a
+ reliable end-to-end protocol such as TCP be used on top of X.25
+ connections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 47]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+APPENDIX E
+
+ Theory of Reply Codes
+
+ The three digits of the reply each have a special significance.
+ The first digit denotes whether the response is good, bad or
+ incomplete. An unsophisticated sender-SMTP will be able to
+ determine its next action (proceed as planned, redo, retrench,
+ etc.) by simply examining this first digit. A sender-SMTP that
+ wants to know approximately what kind of error occurred (e.g.,
+ mail system error, command syntax error) may examine the second
+ digit, reserving the third digit for the finest gradation of
+ information.
+
+ There are five values for the first digit of the reply code:
+
+ 1yz Positive Preliminary reply
+
+ The command has been accepted, but the requested action
+ is being held in abeyance, pending confirmation of the
+ information in this reply. The sender-SMTP should send
+ another command specifying whether to continue or abort
+ the action.
+
+ [Note: SMTP does not have any commands that allow this
+ type of reply, and so does not have the continue or
+ abort commands.]
+
+ 2yz Positive Completion reply
+
+ The requested action has been successfully completed. A
+ new request may be initiated.
+
+ 3yz Positive Intermediate reply
+
+ The command has been accepted, but the requested action
+ is being held in abeyance, pending receipt of further
+ information. The sender-SMTP should send another command
+ specifying this information. This reply is used in
+ command sequence groups.
+
+ 4yz Transient Negative Completion reply
+
+ The command was not accepted and the requested action did
+ not occur. However, the error condition is temporary and
+ the action may be requested again. The sender should
+
+
+
+[Page 48] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ return to the beginning of the command sequence (if any).
+ It is difficult to assign a meaning to "transient" when
+ two different sites (receiver- and sender- SMTPs) must
+ agree on the interpretation. Each reply in this category
+ might have a different time value, but the sender-SMTP is
+ encouraged to try again. A rule of thumb to determine if
+ a reply fits into the 4yz or the 5yz category (see below)
+ is that replies are 4yz if they can be repeated without
+ any change in command form or in properties of the sender
+ or receiver. (E.g., the command is repeated identically
+ and the receiver does not put up a new implementation.)
+
+ 5yz Permanent Negative Completion reply
+
+ The command was not accepted and the requested action did
+ not occur. The sender-SMTP is discouraged from repeating
+ the exact request (in the same sequence). Even some
+ "permanent" error conditions can be corrected, so the
+ human user may want to direct the sender-SMTP to
+ reinitiate the command sequence by direct action at some
+ point in the future (e.g., after the spelling has been
+ changed, or the user has altered the account status).
+
+ The second digit encodes responses in specific categories:
+
+ x0z Syntax -- These replies refer to syntax errors,
+ syntactically correct commands that don't fit any
+ functional category, and unimplemented or superfluous
+ commands.
+
+ x1z Information -- These are replies to requests for
+ information, such as status or help.
+
+ x2z Connections -- These are replies referring to the
+ transmission channel.
+
+ x3z Unspecified as yet.
+
+ x4z Unspecified as yet.
+
+ x5z Mail system -- These replies indicate the status of
+ the receiver mail system vis-a-vis the requested
+ transfer or other mail system action.
+
+ The third digit gives a finer gradation of meaning in each
+ category specified by the second digit. The list of replies
+
+
+
+Postel [Page 49]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ illustrates this. Each reply text is recommended rather than
+ mandatory, and may even change according to the command with
+ which it is associated. On the other hand, the reply codes
+ must strictly follow the specifications in this section.
+ Receiver implementations should not invent new codes for
+ slightly different situations from the ones described here, but
+ rather adapt codes already defined.
+
+ For example, a command such as NOOP whose successful execution
+ does not offer the sender-SMTP any new information will return
+ a 250 reply. The response is 502 when the command requests an
+ unimplemented non-site-specific action. A refinement of that
+ is the 504 reply for a command that is implemented, but that
+ requests an unimplemented parameter.
+
+ The reply text may be longer than a single line; in these cases
+ the complete text must be marked so the sender-SMTP knows when it
+ can stop reading the reply. This requires a special format to
+ indicate a multiple line reply.
+
+ The format for multiline replies requires that every line,
+ except the last, begin with the reply code, followed
+ immediately by a hyphen, "-" (also known as minus), followed by
+ text. The last line will begin with the reply code, followed
+ immediately by <SP>, optionally some text, and <CRLF>.
+
+ For example:
+ 123-First line
+ 123-Second line
+ 123-234 text beginning with numbers
+ 123 The last line
+
+ In many cases the sender-SMTP then simply needs to search for
+ the reply code followed by <SP> at the beginning of a line, and
+ ignore all preceding lines. In a few cases, there is important
+ data for the sender in the reply "text". The sender will know
+ these cases from the current context.
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 50] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+APPENDIX F
+
+ Scenarios
+
+ This section presents complete scenarios of several types of SMTP
+ sessions.
+
+ A Typical SMTP Transaction Scenario
+
+ This SMTP example shows mail sent by Smith at host USC-ISIF, to
+ Jones, Green, and Brown at host BBN-UNIX. Here we assume that
+ host USC-ISIF contacts host BBN-UNIX directly. The mail is
+ accepted for Jones and Brown. Green does not have a mailbox at
+ host BBN-UNIX.
+
+ -------------------------------------------------------------
+
+ R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIF.ARPA
+ R: 250 BBN-UNIX.ARPA
+
+ S: MAIL FROM:<Smith@USC-ISIF.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Jones@BBN-UNIX.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Green@BBN-UNIX.ARPA>
+ R: 550 No such user here
+
+ S: RCPT TO:<Brown@BBN-UNIX.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+ Scenario 1
+
+ -------------------------------------------------------------
+
+
+
+Postel [Page 51]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ Aborted SMTP Transaction Scenario
+
+ -------------------------------------------------------------
+
+ R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
+ S: HELO ISI-VAXA.ARPA
+ R: 250 MIT-Multics.ARPA
+
+ S: MAIL FROM:<Smith@ISI-VAXA.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Jones@MIT-Multics.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Green@MIT-Multics.ARPA>
+ R: 550 No such user here
+
+ S: RSET
+ R: 250 OK
+
+ S: QUIT
+ R: 221 MIT-Multics.ARPA Service closing transmission channel
+
+ Scenario 2
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 52] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ Relayed Mail Scenario
+
+ -------------------------------------------------------------
+
+ Step 1 -- Source Host to Relay Host
+
+ R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-AI.ARPA
+ R: 250 USC-ISIE.ARPA
+
+ S: MAIL FROM:<JQP@MIT-AI.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Date: 2 Nov 81 22:33:44
+ S: From: John Q. Public <JQP@MIT-AI.ARPA>
+ S: Subject: The Next Meeting of the Board
+ S: To: Jones@BBN-Vax.ARPA
+ S:
+ S: Bill:
+ S: The next meeting of the board of directors will be
+ S: on Tuesday.
+ S: John.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 53]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ Step 2 -- Relay Host to Destination Host
+
+ R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIE.ARPA
+ R: 250 BBN-VAX.ARPA
+
+ S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Jones@BBN-VAX.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
+ 2 Nov 81 22:40:10 UT
+ S: Date: 2 Nov 81 22:33:44
+ S: From: John Q. Public <JQP@MIT-AI.ARPA>
+ S: Subject: The Next Meeting of the Board
+ S: To: Jones@BBN-Vax.ARPA
+ S:
+ S: Bill:
+ S: The next meeting of the board of directors will be
+ S: on Tuesday.
+ S: John.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+ Scenario 3
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 54] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ Verifying and Sending Scenario
+
+ -------------------------------------------------------------
+
+ R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-MC.ARPA
+ R: 250 SU-SCORE.ARPA
+
+ S: VRFY Crispin
+ R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+ S: SEND FROM:<EAK@MIT-MC.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+ Scenario 4
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 55]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ Sending and Mailing Scenarios
+
+ First the user's name is verified, then an attempt is made to
+ send to the user's terminal. When that fails, the messages is
+ mailed to the user's mailbox.
+
+ -------------------------------------------------------------
+
+ R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-MC.ARPA
+ R: 250 SU-SCORE.ARPA
+
+ S: VRFY Crispin
+ R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+ S: SEND FROM:<EAK@MIT-MC.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+ R: 450 User not active now
+
+ S: RSET
+ R: 250 OK
+
+ S: MAIL FROM:<EAK@MIT-MC.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+ Scenario 5
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+[Page 56] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ Doing the preceding scenario more efficiently.
+
+ -------------------------------------------------------------
+
+ R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-MC.ARPA
+ R: 250 SU-SCORE.ARPA
+
+ S: VRFY Crispin
+ R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+ S: SOML FROM:<EAK@MIT-MC.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+ R: 250 User not active now, so will do mail.
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+ Scenario 6
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 57]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ Mailing List Scenario
+
+ First each of two mailing lists are expanded in separate sessions
+ with different hosts. Then the message is sent to everyone that
+ appeared on either list (but no duplicates) via a relay host.
+
+ -------------------------------------------------------------
+
+ Step 1 -- Expanding the First List
+
+ R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
+ S: HELO SU-SCORE.ARPA
+ R: 250 MIT-AI.ARPA
+
+ S: EXPN Example-People
+ R: 250-<ABC@MIT-MC.ARPA>
+ R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+ R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA>
+ R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+ R: 250-<joe@foo-unix.ARPA>
+ R: 250 <xyz@bar-unix.ARPA>
+
+ S: QUIT
+ R: 221 MIT-AI.ARPA Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 58] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ Step 2 -- Expanding the Second List
+
+ R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
+ S: HELO SU-SCORE.ARPA
+ R: 250 MIT-MC.ARPA
+
+ S: EXPN Interested-Parties
+ R: 250-Al Calico <ABC@MIT-MC.ARPA>
+ R: 250-<XYZ@MIT-AI.ARPA>
+ R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+ R: 250-<fred@BBN-UNIX.ARPA>
+ R: 250 <xyz@bar-unix.ARPA>
+
+ S: QUIT
+ R: 221 MIT-MC.ARPA Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 59]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ Step 3 -- Mailing to All via a Relay Host
+
+ R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+ S: HELO SU-SCORE.ARPA
+ R: 250 USC-ISIE.ARPA
+
+ S: MAIL FROM:<Account.Person@SU-SCORE.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA>
+ R: 250 OK
+ S: RCPT
+ TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+ Scenario 7
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 60] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ Forwarding Scenarios
+
+ -------------------------------------------------------------
+
+ R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
+ S: HELO LBL-UNIX.ARPA
+ R: 250 USC-ISIF.ARPA
+
+ S: MAIL FROM:<mo@LBL-UNIX.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<fred@USC-ISIF.ARPA>
+ R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIF.ARPA Service closing transmission channel
+
+ Scenario 8
+
+ -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 61]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ -------------------------------------------------------------
+
+ Step 1 -- Trying the Mailbox at the First Host
+
+ R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
+ S: HELO LBL-UNIX.ARPA
+ R: 250 USC-ISIF.ARPA
+
+ S: MAIL FROM:<mo@LBL-UNIX.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<fred@USC-ISIF.ARPA>
+ R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
+
+ S: RSET
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIF.ARPA Service closing transmission channel
+
+ Step 2 -- Delivering the Mail at the Second Host
+
+ R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
+ S: HELO LBL-UNIX.ARPA
+ R: 250 USC-ISI.ARPA
+
+ S: MAIL FROM:<mo@LBL-UNIX.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Jones@USC-ISI.ARPA>
+ R: OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISI.ARPA Service closing transmission channel
+
+ Scenario 9
+
+ -------------------------------------------------------------
+
+
+
+
+[Page 62] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ Too Many Recipients Scenario
+
+ -------------------------------------------------------------
+
+ R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIF.ARPA
+ R: 250 BERKELEY.ARPA
+
+ S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<fabry@BERKELEY.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<eric@BERKELEY.ARPA>
+ R: 552 Recipient storage full, try again in another transaction
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<eric@BERKELEY.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 BERKELEY.ARPA Service closing transmission channel
+
+ Scenario 10
+
+ -------------------------------------------------------------
+
+ Note that a real implementation must handle many recipients as
+ specified in Section 4.5.3.
+
+
+
+Postel [Page 63]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+GLOSSARY
+
+ ASCII
+
+ American Standard Code for Information Interchange [1].
+
+ command
+
+ A request for a mail service action sent by the sender-SMTP to the
+ receiver-SMTP.
+
+ domain
+
+ The hierarchially structured global character string address of a
+ host computer in the mail system.
+
+ end of mail data indication
+
+ A special sequence of characters that indicates the end of the
+ mail data. In particular, the five characters carriage return,
+ line feed, period, carriage return, line feed, in that order.
+
+ host
+
+ A computer in the internetwork environment on which mailboxes or
+ SMTP processes reside.
+
+ line
+
+ A a sequence of ASCII characters ending with a <CRLF>.
+
+ mail data
+
+ A sequence of ASCII characters of arbitrary length, which conforms
+ to the standard set in the Standard for the Format of ARPA
+ Internet Text Messages (RFC 822 [2]).
+
+ mailbox
+
+ A character string (address) which identifies a user to whom mail
+ is to be sent. Mailbox normally consists of the host and user
+ specifications. The standard mailbox naming convention is defined
+ to be "user@domain". Additionally, the "container" in which mail
+ is stored.
+
+
+
+
+
+[Page 64] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+ receiver-SMTP process
+
+ A process which transfers mail in cooperation with a sender-SMTP
+ process. It waits for a connection to be established via the
+ transport service. It receives SMTP commands from the
+ sender-SMTP, sends replies, and performs the specified operations.
+
+ reply
+
+ A reply is an acknowledgment (positive or negative) sent from
+ receiver to sender via the transmission channel in response to a
+ command. The general form of a reply is a completion code
+ (including error codes) followed by a text string. The codes are
+ for use by programs and the text is usually intended for human
+ users.
+
+ sender-SMTP process
+
+ A process which transfers mail in cooperation with a receiver-SMTP
+ process. A local language may be used in the user interface
+ command/reply dialogue. The sender-SMTP initiates the transport
+ service connection. It initiates SMTP commands, receives replies,
+ and governs the transfer of mail.
+
+ session
+
+ The set of exchanges that occur while the transmission channel is
+ open.
+
+ transaction
+
+ The set of exchanges required for one message to be transmitted
+ for one or more recipients.
+
+ transmission channel
+
+ A full-duplex communication path between a sender-SMTP and a
+ receiver-SMTP for the exchange of commands, replies, and mail
+ text.
+
+ transport service
+
+ Any reliable stream-oriented data communication services. For
+ example, NCP, TCP, NITS.
+
+
+
+
+
+Postel [Page 65]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ user
+
+ A human being (or a process on behalf of a human being) wishing to
+ obtain mail transfer service. In addition, a recipient of
+ computer mail.
+
+ word
+
+ A sequence of printing characters.
+
+ <CRLF>
+
+ The characters carriage return and line feed (in that order).
+
+ <SP>
+
+ The space character.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 66] Postel
+
+
+
+RFC 821 August 1982
+ Simple Mail Transfer Protocol
+
+
+
+REFERENCES
+
+ [1] ASCII
+
+ ASCII, "USA Code for Information Interchange", United States of
+ America Standards Institute, X3.4, 1968. Also in: Feinler, E.
+ and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
+ the Defense Communications Agency by SRI International, Menlo
+ Park, California, Revised January 1978.
+
+ [2] RFC 822
+
+ Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages," RFC 822, Department of Electrical Engineering,
+ University of Delaware, August 1982.
+
+ [3] TCP
+
+ Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+ Program Protocol Specification", RFC 793, USC/Information Sciences
+ Institute, NTIS AD Number A111091, September 1981. Also in:
+ Feinler, E. and J. Postel, eds., "Internet Protocol Transition
+ Workbook", SRI International, Menlo Park, California, March 1982.
+
+ [4] NCP
+
+ McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
+ January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET
+ Protocol Handbook", NIC 7104, for the Defense Communications
+ Agency by SRI International, Menlo Park, California, Revised
+ January 1978.
+
+ [5] Initial Connection Protocol
+
+ Postel, J., "Official Initial Connection Protocol", NIC 7101,
+ 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET
+ Protocol Handbook", NIC 7104, for the Defense Communications
+ Agency by SRI International, Menlo Park, California, Revised
+ January 1978.
+
+ [6] NITS
+
+ PSS/SG3, "A Network Independent Transport Service", Study Group 3,
+ The Post Office PSS Users Group, February 1980. Available from
+ the DCPU, National Physical Laboratory, Teddington, UK.
+
+
+
+
+Postel [Page 67]
+
+
+
+August 1982 RFC 821
+Simple Mail Transfer Protocol
+
+
+
+ [7] X.25
+
+ CCITT, "Recommendation X.25 - Interface Between Data Terminal
+ Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
+ Terminals Operating in the Packet Mode on Public Data Networks,"
+ CCITT Orange Book, Vol. VIII.2, International Telephone and
+ Telegraph Consultative Committee, Geneva, 1976.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 68] Postel
+
diff --git a/Documentation/en/rfc/rfc822.txt b/Documentation/en/rfc/rfc822.txt
new file mode 100644
index 00000000..35b09a3c
--- /dev/null
+++ b/Documentation/en/rfc/rfc822.txt
@@ -0,0 +1,2901 @@
+
+
+
+
+
+
+ RFC # 822
+
+ Obsoletes: RFC #733 (NIC #41952)
+
+
+
+
+
+
+
+
+
+
+
+
+ STANDARD FOR THE FORMAT OF
+
+ ARPA INTERNET TEXT MESSAGES
+
+
+
+
+
+
+ August 13, 1982
+
+
+
+
+
+
+ Revised by
+
+ David H. Crocker
+
+
+ Dept. of Electrical Engineering
+ University of Delaware, Newark, DE 19711
+ Network: DCrocker @ UDel-Relay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ TABLE OF CONTENTS
+
+
+ PREFACE .................................................... ii
+
+ 1. INTRODUCTION ........................................... 1
+
+ 1.1. Scope ............................................ 1
+ 1.2. Communication Framework .......................... 2
+
+ 2. NOTATIONAL CONVENTIONS ................................. 3
+
+ 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5
+
+ 3.1. General Description .............................. 5
+ 3.2. Header Field Definitions ......................... 9
+ 3.3. Lexical Tokens ................................... 10
+ 3.4. Clarifications ................................... 11
+
+ 4. MESSAGE SPECIFICATION .................................. 17
+
+ 4.1. Syntax ........................................... 17
+ 4.2. Forwarding ....................................... 19
+ 4.3. Trace Fields ..................................... 20
+ 4.4. Originator Fields ................................ 21
+ 4.5. Receiver Fields .................................. 23
+ 4.6. Reference Fields ................................. 23
+ 4.7. Other Fields ..................................... 24
+
+ 5. DATE AND TIME SPECIFICATION ............................ 26
+
+ 5.1. Syntax ........................................... 26
+ 5.2. Semantics ........................................ 26
+
+ 6. ADDRESS SPECIFICATION .................................. 27
+
+ 6.1. Syntax ........................................... 27
+ 6.2. Semantics ........................................ 27
+ 6.3. Reserved Address ................................. 33
+
+ 7. BIBLIOGRAPHY ........................................... 34
+
+
+ APPENDIX
+
+ A. EXAMPLES ............................................... 36
+ B. SIMPLE FIELD PARSING ................................... 40
+ C. DIFFERENCES FROM RFC #733 .............................. 41
+ D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44
+
+
+ August 13, 1982 - i - RFC #822
+
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ PREFACE
+
+
+ By 1977, the Arpanet employed several informal standards for
+ the text messages (mail) sent among its host computers. It was
+ felt necessary to codify these practices and provide for those
+ features that seemed imminent. The result of that effort was
+ Request for Comments (RFC) #733, "Standard for the Format of ARPA
+ Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
+ The specification attempted to avoid major changes in existing
+ software, while permitting several new features.
+
+ This document revises the specifications in RFC #733, in
+ order to serve the needs of the larger and more complex ARPA
+ Internet. Some of RFC #733's features failed to gain adequate
+ acceptance. In order to simplify the standard and the software
+ that follows it, these features have been removed. A different
+ addressing scheme is used, to handle the case of inter-network
+ mail; and the concept of re-transmission has been introduced.
+
+ This specification is intended for use in the ARPA Internet.
+ However, an attempt has been made to free it of any dependence on
+ that environment, so that it can be applied to other network text
+ message systems.
+
+ The specification of RFC #733 took place over the course of
+ one year, using the ARPANET mail environment, itself, to provide
+ an on-going forum for discussing the capabilities to be included.
+ More than twenty individuals, from across the country, partici-
+ pated in the original discussion. The development of this
+ revised specification has, similarly, utilized network mail-based
+ group discussion. Both specification efforts greatly benefited
+ from the comments and ideas of the participants.
+
+ The syntax of the standard, in RFC #733, was originally
+ specified in the Backus-Naur Form (BNF) meta-language. Ken L.
+ Harrenstien, of SRI International, was responsible for re-coding
+ the BNF into an augmented BNF that makes the representation
+ smaller and easier to understand.
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - ii - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 1. INTRODUCTION
+
+ 1.1. SCOPE
+
+ This standard specifies a syntax for text messages that are
+ sent among computer users, within the framework of "electronic
+ mail". The standard supersedes the one specified in ARPANET
+ Request for Comments #733, "Standard for the Format of ARPA Net-
+ work Text Messages".
+
+ In this context, messages are viewed as having an envelope
+ and contents. The envelope contains whatever information is
+ needed to accomplish transmission and delivery. The contents
+ compose the object to be delivered to the recipient. This stan-
+ dard applies only to the format and some of the semantics of mes-
+ sage contents. It contains no specification of the information
+ in the envelope.
+
+ However, some message systems may use information from the
+ contents to create the envelope. It is intended that this stan-
+ dard facilitate the acquisition of such information by programs.
+
+ Some message systems may store messages in formats that
+ differ from the one specified in this standard. This specifica-
+ tion is intended strictly as a definition of what message content
+ format is to be passed BETWEEN hosts.
+
+ Note: This standard is NOT intended to dictate the internal for-
+ mats used by sites, the specific message system features
+ that they are expected to support, or any of the charac-
+ teristics of user interface programs that create or read
+ messages.
+
+ A distinction should be made between what the specification
+ REQUIRES and what it ALLOWS. Messages can be made complex and
+ rich with formally-structured components of information or can be
+ kept small and simple, with a minimum of such information. Also,
+ the standard simplifies the interpretation of differing visual
+ formats in messages; only the visual aspect of a message is
+ affected and not the interpretation of information within it.
+ Implementors may choose to retain such visual distinctions.
+
+ The formal definition is divided into four levels. The bot-
+ tom level describes the meta-notation used in this document. The
+ second level describes basic lexical analyzers that feed tokens
+ to higher-level parsers. Next is an overall specification for
+ messages; it permits distinguishing individual fields. Finally,
+ there is definition of the contents of several structured fields.
+
+
+
+ August 13, 1982 - 1 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 1.2. COMMUNICATION FRAMEWORK
+
+ Messages consist of lines of text. No special provisions
+ are made for encoding drawings, facsimile, speech, or structured
+ text. No significant consideration has been given to questions
+ of data compression or to transmission and storage efficiency,
+ and the standard tends to be free with the number of bits con-
+ sumed. For example, field names are specified as free text,
+ rather than special terse codes.
+
+ A general "memo" framework is used. That is, a message con-
+ sists of some information in a rigid format, followed by the main
+ part of the message, with a format that is not specified in this
+ document. The syntax of several fields of the rigidly-formated
+ ("headers") section is defined in this specification; some of
+ these fields must be included in all messages.
+
+ The syntax that distinguishes between header fields is
+ specified separately from the internal syntax for particular
+ fields. This separation is intended to allow simple parsers to
+ operate on the general structure of messages, without concern for
+ the detailed structure of individual header fields. Appendix B
+ is provided to facilitate construction of these parsers.
+
+ In addition to the fields specified in this document, it is
+ expected that other fields will gain common use. As necessary,
+ the specifications for these "extension-fields" will be published
+ through the same mechanism used to publish this document. Users
+ may also wish to extend the set of fields that they use
+ privately. Such "user-defined fields" are permitted.
+
+ The framework severely constrains document tone and appear-
+ ance and is primarily useful for most intra-organization communi-
+ cations and well-structured inter-organization communication.
+ It also can be used for some types of inter-process communica-
+ tion, such as simple file transfer and remote job entry. A more
+ robust framework might allow for multi-font, multi-color, multi-
+ dimension encoding of information. A less robust one, as is
+ present in most single-machine message systems, would more
+ severely constrain the ability to add fields and the decision to
+ include specific fields. In contrast with paper-based communica-
+ tion, it is interesting to note that the RECEIVER of a message
+ can exercise an extraordinary amount of control over the
+ message's appearance. The amount of actual control available to
+ message receivers is contingent upon the capabilities of their
+ individual message systems.
+
+
+
+
+
+ August 13, 1982 - 2 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 2. NOTATIONAL CONVENTIONS
+
+ This specification uses an augmented Backus-Naur Form (BNF)
+ notation. The differences from standard BNF involve naming rules
+ and indicating repetition and "local" alternatives.
+
+ 2.1. RULE NAMING
+
+ Angle brackets ("<", ">") are not used, in general. The
+ name of a rule is simply the name itself, rather than "<name>".
+ Quotation-marks enclose literal text (which may be upper and/or
+ lower case). Certain basic rules are in uppercase, such as
+ SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in
+ rule definitions, and in the rest of this document, whenever
+ their presence will facilitate discerning the use of rule names.
+
+ 2.2. RULE1 / RULE2: ALTERNATIVES
+
+ Elements separated by slash ("/") are alternatives. There-
+ fore "foo / bar" will accept foo or bar.
+
+ 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES
+
+ Elements enclosed in parentheses are treated as a single
+ element. Thus, "(elem (foo / bar) elem)" allows the token
+ sequences "elem foo elem" and "elem bar elem".
+
+ 2.4. *RULE: REPETITION
+
+ The character "*" preceding an element indicates repetition.
+ The full form is:
+
+ <l>*<m>element
+
+ indicating at least <l> and at most <m> occurrences of element.
+ Default values are 0 and infinity so that "*(element)" allows any
+ number, including zero; "1*element" requires at least one; and
+ "1*2element" allows one or two.
+
+ 2.5. [RULE]: OPTIONAL
+
+ Square brackets enclose optional elements; "[foo bar]" is
+ equivalent to "*1(foo bar)".
+
+ 2.6. NRULE: SPECIFIC REPETITION
+
+ "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
+ exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit
+ number, and 3ALPHA is a string of three alphabetic characters.
+
+
+ August 13, 1982 - 3 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 2.7. #RULE: LISTS
+
+ A construct "#" is defined, similar to "*", as follows:
+
+ <l>#<m>element
+
+ indicating at least <l> and at most <m> elements, each separated
+ by one or more commas (","). This makes the usual form of lists
+ very easy; a rule such as '(element *("," element))' can be shown
+ as "1#element". Wherever this construct is used, null elements
+ are allowed, but do not contribute to the count of elements
+ present. That is, "(element),,(element)" is permitted, but
+ counts as only two elements. Therefore, where at least one ele-
+ ment is required, at least one non-null element must be present.
+ Default values are 0 and infinity so that "#(element)" allows any
+ number, including zero; "1#element" requires at least one; and
+ "1#2element" allows one or two.
+
+ 2.8. ; COMMENTS
+
+ A semi-colon, set off some distance to the right of rule
+ text, starts a comment that continues to the end of line. This
+ is a simple way of including useful notes in parallel with the
+ specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 4 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 3. LEXICAL ANALYSIS OF MESSAGES
+
+ 3.1. GENERAL DESCRIPTION
+
+ A message consists of header fields and, optionally, a body.
+ The body is simply a sequence of lines containing ASCII charac-
+ ters. It is separated from the headers by a null line (i.e., a
+ line with nothing preceding the CRLF).
+
+ 3.1.1. LONG HEADER FIELDS
+
+ Each header field can be viewed as a single, logical line of
+ ASCII characters, comprising a field-name and a field-body.
+ For convenience, the field-body portion of this conceptual
+ entity can be split into a multiple-line representation; this
+ is called "folding". The general rule is that wherever there
+ may be linear-white-space (NOT simply LWSP-chars), a CRLF
+ immediately followed by AT LEAST one LWSP-char may instead be
+ inserted. Thus, the single line
+
+ To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
+
+ can be represented as:
+
+ To: "Joe & J. Harvey" <ddd @ Org>,
+ JJV@BBN
+
+ and
+
+ To: "Joe & J. Harvey"
+ <ddd@ Org>, JJV
+ @BBN
+
+ and
+
+ To: "Joe &
+ J. Harvey" <ddd @ Org>, JJV @ BBN
+
+ The process of moving from this folded multiple-line
+ representation of a header field to its single line represen-
+ tation is called "unfolding". Unfolding is accomplished by
+ regarding CRLF immediately followed by a LWSP-char as
+ equivalent to the LWSP-char.
+
+ Note: While the standard permits folding wherever linear-
+ white-space is permitted, it is recommended that struc-
+ tured fields, such as those containing addresses, limit
+ folding to higher-level syntactic breaks. For address
+ fields, it is recommended that such folding occur
+
+
+ August 13, 1982 - 5 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ between addresses, after the separating comma.
+
+ 3.1.2. STRUCTURE OF HEADER FIELDS
+
+ Once a field has been unfolded, it may be viewed as being com-
+ posed of a field-name followed by a colon (":"), followed by a
+ field-body, and terminated by a carriage-return/line-feed.
+ The field-name must be composed of printable ASCII characters
+ (i.e., characters that have values between 33. and 126.,
+ decimal, except colon). The field-body may be composed of any
+ ASCII characters, except CR or LF. (While CR and/or LF may be
+ present in the actual text, they are removed by the action of
+ unfolding the field.)
+
+ Certain field-bodies of headers may be interpreted according
+ to an internal syntax that some systems may wish to parse.
+ These fields are called "structured fields". Examples
+ include fields containing dates and addresses. Other fields,
+ such as "Subject" and "Comments", are regarded simply as
+ strings of text.
+
+ Note: Any field which has a field-body that is defined as
+ other than simply <text> is to be treated as a struc-
+ tured field.
+
+ Field-names, unstructured field bodies and structured
+ field bodies each are scanned by their own, independent
+ "lexical" analyzers.
+
+ 3.1.3. UNSTRUCTURED FIELD BODIES
+
+ For some fields, such as "Subject" and "Comments", no struc-
+ turing is assumed, and they are treated simply as <text>s, as
+ in the message body. Rules of folding apply to these fields,
+ so that such field bodies which occupy several lines must
+ therefore have the second and successive lines indented by at
+ least one LWSP-char.
+
+ 3.1.4. STRUCTURED FIELD BODIES
+
+ To aid in the creation and reading of structured fields, the
+ free insertion of linear-white-space (which permits folding
+ by inclusion of CRLFs) is allowed between lexical tokens.
+ Rather than obscuring the syntax specifications for these
+ structured fields with explicit syntax for this linear-white-
+ space, the existence of another "lexical" analyzer is assumed.
+ This analyzer does not apply for unstructured field bodies
+ that are simply strings of text, as described above. The
+ analyzer provides an interpretation of the unfolded text
+
+
+ August 13, 1982 - 6 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ composing the body of the field as a sequence of lexical sym-
+ bols.
+
+ These symbols are:
+
+ - individual special characters
+ - quoted-strings
+ - domain-literals
+ - comments
+ - atoms
+
+ The first four of these symbols are self-delimiting. Atoms
+ are not; they are delimited by the self-delimiting symbols and
+ by linear-white-space. For the purposes of regenerating
+ sequences of atoms and quoted-strings, exactly one SPACE is
+ assumed to exist, and should be used, between them. (Also, in
+ the "Clarifications" section on "White Space", below, note the
+ rules about treatment of multiple contiguous LWSP-chars.)
+
+ So, for example, the folded body of an address field
+
+ ":sysmail"@ Some-Group. Some-Org,
+ Muhammed.(I am the greatest) Ali @(the)Vegas.WBA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 7 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ is analyzed into the following lexical symbols and types:
+
+ :sysmail quoted string
+ @ special
+ Some-Group atom
+ . special
+ Some-Org atom
+ , special
+ Muhammed atom
+ . special
+ (I am the greatest) comment
+ Ali atom
+ @ atom
+ (the) comment
+ Vegas atom
+ . special
+ WBA atom
+
+ The canonical representations for the data in these addresses
+ are the following strings:
+
+ ":sysmail"@Some-Group.Some-Org
+
+ and
+
+ Muhammed.Ali@Vegas.WBA
+
+ Note: For purposes of display, and when passing such struc-
+ tured information to other systems, such as mail proto-
+ col services, there must be NO linear-white-space
+ between <word>s that are separated by period (".") or
+ at-sign ("@") and exactly one SPACE between all other
+ <word>s. Also, headers should be in a folded form.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 8 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 3.2. HEADER FIELD DEFINITIONS
+
+ These rules show a field meta-syntax, without regard for the
+ particular type or internal syntax. Their purpose is to permit
+ detection of fields; also, they present to higher-level parsers
+ an image of each field as fitting on one line.
+
+ field = field-name ":" [ field-body ] CRLF
+
+ field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
+
+ field-body = field-body-contents
+ [CRLF LWSP-char field-body]
+
+ field-body-contents =
+ <the ASCII characters making up the field-body, as
+ defined in the following sections, and consisting
+ of combinations of atom, quoted-string, and
+ specials tokens, or else consisting of texts>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 9 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 3.3. LEXICAL TOKENS
+
+ The following rules are used to define an underlying lexical
+ analyzer, which feeds tokens to higher level parsers. See the
+ ANSI references, in the Bibliography.
+
+ ; ( Octal, Decimal.)
+ CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
+ ALPHA = <any ASCII alphabetic character>
+ ; (101-132, 65.- 90.)
+ ; (141-172, 97.-122.)
+ DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
+ CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
+ character and DEL> ; ( 177, 127.)
+ CR = <ASCII CR, carriage return> ; ( 15, 13.)
+ LF = <ASCII LF, linefeed> ; ( 12, 10.)
+ SPACE = <ASCII SP, space> ; ( 40, 32.)
+ HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
+ <"> = <ASCII quote mark> ; ( 42, 34.)
+ CRLF = CR LF
+
+ LWSP-char = SPACE / HTAB ; semantics = SPACE
+
+ linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
+ ; CRLF => folding
+
+ specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
+ / "," / ";" / ":" / "\" / <"> ; string, to use
+ / "." / "[" / "]" ; within a word.
+
+ delimiters = specials / linear-white-space / comment
+
+ text = <any CHAR, including bare ; => atoms, specials,
+ CR & bare LF, but NOT ; comments and
+ including CRLF> ; quoted-strings are
+ ; NOT recognized.
+
+ atom = 1*<any CHAR except specials, SPACE and CTLs>
+
+ quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
+ ; quoted chars.
+
+ qtext = <any CHAR excepting <">, ; => may be folded
+ "\" & CR, and including
+ linear-white-space>
+
+ domain-literal = "[" *(dtext / quoted-pair) "]"
+
+
+
+
+ August 13, 1982 - 10 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ dtext = <any CHAR excluding "[", ; => may be folded
+ "]", "\" & CR, & including
+ linear-white-space>
+
+ comment = "(" *(ctext / quoted-pair / comment) ")"
+
+ ctext = <any CHAR excluding "(", ; => may be folded
+ ")", "\" & CR, & including
+ linear-white-space>
+
+ quoted-pair = "\" CHAR ; may quote any char
+
+ phrase = 1*word ; Sequence of words
+
+ word = atom / quoted-string
+
+
+ 3.4. CLARIFICATIONS
+
+ 3.4.1. QUOTING
+
+ Some characters are reserved for special interpretation, such
+ as delimiting lexical tokens. To permit use of these charac-
+ ters as uninterpreted data, a quoting mechanism is provided.
+ To quote a character, precede it with a backslash ("\").
+
+ This mechanism is not fully general. Characters may be quoted
+ only within a subset of the lexical constructs. In particu-
+ lar, quoting is limited to use within:
+
+ - quoted-string
+ - domain-literal
+ - comment
+
+ Within these constructs, quoting is REQUIRED for CR and "\"
+ and for the character(s) that delimit the token (e.g., "(" and
+ ")" for a comment). However, quoting is PERMITTED for any
+ character.
+
+ Note: In particular, quoting is NOT permitted within atoms.
+ For example when the local-part of an addr-spec must
+ contain a special character, a quoted string must be
+ used. Therefore, a specification such as:
+
+ Full\ Name@Domain
+
+ is not legal and must be specified as:
+
+ "Full Name"@Domain
+
+
+ August 13, 1982 - 11 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 3.4.2. WHITE SPACE
+
+ Note: In structured field bodies, multiple linear space ASCII
+ characters (namely HTABs and SPACEs) are treated as
+ single spaces and may freely surround any symbol. In
+ all header fields, the only place in which at least one
+ LWSP-char is REQUIRED is at the beginning of continua-
+ tion lines in a folded field.
+
+ When passing text to processes that do not interpret text
+ according to this standard (e.g., mail protocol servers), then
+ NO linear-white-space characters should occur between a period
+ (".") or at-sign ("@") and a <word>. Exactly ONE SPACE should
+ be used in place of arbitrary linear-white-space and comment
+ sequences.
+
+ Note: Within systems conforming to this standard, wherever a
+ member of the list of delimiters is allowed, LWSP-chars
+ may also occur before and/or after it.
+
+ Writers of mail-sending (i.e., header-generating) programs
+ should realize that there is no network-wide definition of the
+ effect of ASCII HT (horizontal-tab) characters on the appear-
+ ance of text at another network host; therefore, the use of
+ tabs in message headers, though permitted, is discouraged.
+
+ 3.4.3. COMMENTS
+
+ A comment is a set of ASCII characters, which is enclosed in
+ matching parentheses and which is not within a quoted-string
+ The comment construct permits message originators to add text
+ which will be useful for human readers, but which will be
+ ignored by the formal semantics. Comments should be retained
+ while the message is subject to interpretation according to
+ this standard. However, comments must NOT be included in
+ other cases, such as during protocol exchanges with mail
+ servers.
+
+ Comments nest, so that if an unquoted left parenthesis occurs
+ in a comment string, there must also be a matching right
+ parenthesis. When a comment acts as the delimiter between a
+ sequence of two lexical symbols, such as two atoms, it is lex-
+ ically equivalent with a single SPACE, for the purposes of
+ regenerating the sequence, such as when passing the sequence
+ onto a mail protocol server. Comments are detected as such
+ only within field-bodies of structured fields.
+
+ If a comment is to be "folded" onto multiple lines, then the
+ syntax for folding must be adhered to. (See the "Lexical
+
+
+ August 13, 1982 - 12 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ Analysis of Messages" section on "Folding Long Header Fields"
+ above, and the section on "Case Independence" below.) Note
+ that the official semantics therefore do not "see" any
+ unquoted CRLFs that are in comments, although particular pars-
+ ing programs may wish to note their presence. For these pro-
+ grams, it would be reasonable to interpret a "CRLF LWSP-char"
+ as being a CRLF that is part of the comment; i.e., the CRLF is
+ kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a
+ backslash followed by a CR followed by a LF) still must be
+ followed by at least one LWSP-char.
+
+ 3.4.4. DELIMITING AND QUOTING CHARACTERS
+
+ The quote character (backslash) and characters that delimit
+ syntactic units are not, generally, to be taken as data that
+ are part of the delimited or quoted unit(s). In particular,
+ the quotation-marks that define a quoted-string, the
+ parentheses that define a comment and the backslash that
+ quotes a following character are NOT part of the quoted-
+ string, comment or quoted character. A quotation-mark that is
+ to be part of a quoted-string, a parenthesis that is to be
+ part of a comment and a backslash that is to be part of either
+ must each be preceded by the quote-character backslash ("\").
+ Note that the syntax allows any character to be quoted within
+ a quoted-string or comment; however only certain characters
+ MUST be quoted to be included as data. These characters are
+ the ones that are not part of the alternate text group (i.e.,
+ ctext or qtext).
+
+ The one exception to this rule is that a single SPACE is
+ assumed to exist between contiguous words in a phrase, and
+ this interpretation is independent of the actual number of
+ LWSP-chars that the creator places between the words. To
+ include more than one SPACE, the creator must make the LWSP-
+ chars be part of a quoted-string.
+
+ Quotation marks that delimit a quoted string and backslashes
+ that quote the following character should NOT accompany the
+ quoted-string when the string is passed to processes that do
+ not interpret data according to this specification (e.g., mail
+ protocol servers).
+
+ 3.4.5. QUOTED-STRINGS
+
+ Where permitted (i.e., in words in structured fields) quoted-
+ strings are treated as a single symbol. That is, a quoted-
+ string is equivalent to an atom, syntactically. If a quoted-
+ string is to be "folded" onto multiple lines, then the syntax
+ for folding must be adhered to. (See the "Lexical Analysis of
+
+
+ August 13, 1982 - 13 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ Messages" section on "Folding Long Header Fields" above, and
+ the section on "Case Independence" below.) Therefore, the
+ official semantics do not "see" any bare CRLFs that are in
+ quoted-strings; however particular parsing programs may wish
+ to note their presence. For such programs, it would be rea-
+ sonable to interpret a "CRLF LWSP-char" as being a CRLF which
+ is part of the quoted-string; i.e., the CRLF is kept and the
+ LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol-
+ lowed by a CR followed by a LF) are also subject to rules of
+ folding, but the presence of the quoting character (backslash)
+ explicitly indicates that the CRLF is data to the quoted
+ string. Stripping off the first following LWSP-char is also
+ appropriate when parsing quoted CRLFs.
+
+ 3.4.6. BRACKETING CHARACTERS
+
+ There is one type of bracket which must occur in matched pairs
+ and may have pairs nested within each other:
+
+ o Parentheses ("(" and ")") are used to indicate com-
+ ments.
+
+ There are three types of brackets which must occur in matched
+ pairs, and which may NOT be nested:
+
+ o Colon/semi-colon (":" and ";") are used in address
+ specifications to indicate that the included list of
+ addresses are to be treated as a group.
+
+ o Angle brackets ("<" and ">") are generally used to
+ indicate the presence of a one machine-usable refer-
+ ence (e.g., delimiting mailboxes), possibly including
+ source-routing to the machine.
+
+ o Square brackets ("[" and "]") are used to indicate the
+ presence of a domain-literal, which the appropriate
+ name-domain is to use directly, bypassing normal
+ name-resolution mechanisms.
+
+ 3.4.7. CASE INDEPENDENCE
+
+ Except as noted, alphabetic strings may be represented in any
+ combination of upper and lower case. The only syntactic units
+
+
+
+
+
+
+
+
+ August 13, 1982 - 14 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ which requires preservation of case information are:
+
+ - text
+ - qtext
+ - dtext
+ - ctext
+ - quoted-pair
+ - local-part, except "Postmaster"
+
+ When matching any other syntactic unit, case is to be ignored.
+ For example, the field-names "From", "FROM", "from", and even
+ "FroM" are semantically equal and should all be treated ident-
+ ically.
+
+ When generating these units, any mix of upper and lower case
+ alphabetic characters may be used. The case shown in this
+ specification is suggested for message-creating processes.
+
+ Note: The reserved local-part address unit, "Postmaster", is
+ an exception. When the value "Postmaster" is being
+ interpreted, it must be accepted in any mixture of
+ case, including "POSTMASTER", and "postmaster".
+
+ 3.4.8. FOLDING LONG HEADER FIELDS
+
+ Each header field may be represented on exactly one line con-
+ sisting of the name of the field and its body, and terminated
+ by a CRLF; this is what the parser sees. For readability, the
+ field-body portion of long header fields may be "folded" onto
+ multiple lines of the actual field. "Long" is commonly inter-
+ preted to mean greater than 65 or 72 characters. The former
+ length serves as a limit, when the message is to be viewed on
+ most simple terminals which use simple display software; how-
+ ever, the limit is not imposed by this standard.
+
+ Note: Some display software often can selectively fold lines,
+ to suit the display terminal. In such cases, sender-
+ provided folding can interfere with the display
+ software.
+
+ 3.4.9. BACKSPACE CHARACTERS
+
+ ASCII BS characters (Backspace, decimal 8) may be included in
+ texts and quoted-strings to effect overstriking. However, any
+ use of backspaces which effects an overstrike to the left of
+ the beginning of the text or quoted-string is prohibited.
+
+
+
+
+
+ August 13, 1982 - 15 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS
+
+ During transmission through heterogeneous networks, it may be
+ necessary to force data to conform to a network's local con-
+ ventions. For example, it may be required that a CR be fol-
+ lowed either by LF, making a CRLF, or by <null>, if the CR is
+ to stand alone). Such transformations are reversed, when the
+ message exits that network.
+
+ When crossing network boundaries, the message should be
+ treated as passing through two modules. It will enter the
+ first module containing whatever network-specific transforma-
+ tions that were necessary to permit migration through the
+ "current" network. It then passes through the modules:
+
+ o Transformation Reversal
+
+ The "current" network's idiosyncracies are removed and
+ the message is returned to the canonical form speci-
+ fied in this standard.
+
+ o Transformation
+
+ The "next" network's local idiosyncracies are imposed
+ on the message.
+
+ ------------------
+ From ==> | Remove Net-A |
+ Net-A | idiosyncracies |
+ ------------------
+ ||
+ \/
+ Conformance
+ with standard
+ ||
+ \/
+ ------------------
+ | Impose Net-B | ==> To
+ | idiosyncracies | Net-B
+ ------------------
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 16 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 4. MESSAGE SPECIFICATION
+
+ 4.1. SYNTAX
+
+ Note: Due to an artifact of the notational conventions, the syn-
+ tax indicates that, when present, some fields, must be in
+ a particular order. Header fields are NOT required to
+ occur in any particular order, except that the message
+ body must occur AFTER the headers. It is recommended
+ that, if present, headers be sent in the order "Return-
+ Path", "Received", "Date", "From", "Subject", "Sender",
+ "To", "cc", etc.
+
+ This specification permits multiple occurrences of most
+ fields. Except as noted, their interpretation is not
+ specified here, and their use is discouraged.
+
+ The following syntax for the bodies of various fields should
+ be thought of as describing each field body as a single long
+ string (or line). The "Lexical Analysis of Message" section on
+ "Long Header Fields", above, indicates how such long strings can
+ be represented on more than one line in the actual transmitted
+ message.
+
+ message = fields *( CRLF *text ) ; Everything after
+ ; first null line
+ ; is message body
+
+ fields = dates ; Creation time,
+ source ; author id & one
+ 1*destination ; address required
+ *optional-field ; others optional
+
+ source = [ trace ] ; net traversals
+ originator ; original mail
+ [ resent ] ; forwarded
+
+ trace = return ; path to sender
+ 1*received ; receipt tags
+
+ return = "Return-path" ":" route-addr ; return address
+
+ received = "Received" ":" ; one per relay
+ ["from" domain] ; sending host
+ ["by" domain] ; receiving host
+ ["via" atom] ; physical path
+ *("with" atom) ; link/mail protocol
+ ["id" msg-id] ; receiver msg id
+ ["for" addr-spec] ; initial form
+
+
+ August 13, 1982 - 17 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ ";" date-time ; time received
+
+ originator = authentic ; authenticated addr
+ [ "Reply-To" ":" 1#address] )
+
+ authentic = "From" ":" mailbox ; Single author
+ / ( "Sender" ":" mailbox ; Actual submittor
+ "From" ":" 1#mailbox) ; Multiple authors
+ ; or not sender
+
+ resent = resent-authentic
+ [ "Resent-Reply-To" ":" 1#address] )
+
+ resent-authentic =
+ = "Resent-From" ":" mailbox
+ / ( "Resent-Sender" ":" mailbox
+ "Resent-From" ":" 1#mailbox )
+
+ dates = orig-date ; Original
+ [ resent-date ] ; Forwarded
+
+ orig-date = "Date" ":" date-time
+
+ resent-date = "Resent-Date" ":" date-time
+
+ destination = "To" ":" 1#address ; Primary
+ / "Resent-To" ":" 1#address
+ / "cc" ":" 1#address ; Secondary
+ / "Resent-cc" ":" 1#address
+ / "bcc" ":" #address ; Blind carbon
+ / "Resent-bcc" ":" #address
+
+ optional-field =
+ / "Message-ID" ":" msg-id
+ / "Resent-Message-ID" ":" msg-id
+ / "In-Reply-To" ":" *(phrase / msg-id)
+ / "References" ":" *(phrase / msg-id)
+ / "Keywords" ":" #phrase
+ / "Subject" ":" *text
+ / "Comments" ":" *text
+ / "Encrypted" ":" 1#2word
+ / extension-field ; To be defined
+ / user-defined-field ; May be pre-empted
+
+ msg-id = "<" addr-spec ">" ; Unique message id
+
+
+
+
+
+
+ August 13, 1982 - 18 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ extension-field =
+ <Any field which is defined in a document
+ published as a formal extension to this
+ specification; none will have names beginning
+ with the string "X-">
+
+ user-defined-field =
+ <Any field which has not been defined
+ in this specification or published as an
+ extension to this specification; names for
+ such fields must be unique and may be
+ pre-empted by published extensions>
+
+ 4.2. FORWARDING
+
+ Some systems permit mail recipients to forward a message,
+ retaining the original headers, by adding some new fields. This
+ standard supports such a service, through the "Resent-" prefix to
+ field names.
+
+ Whenever the string "Resent-" begins a field name, the field
+ has the same semantics as a field whose name does not have the
+ prefix. However, the message is assumed to have been forwarded
+ by an original recipient who attached the "Resent-" field. This
+ new field is treated as being more recent than the equivalent,
+ original field. For example, the "Resent-From", indicates the
+ person that forwarded the message, whereas the "From" field indi-
+ cates the original author.
+
+ Use of such precedence information depends upon partici-
+ pants' communication needs. For example, this standard does not
+ dictate when a "Resent-From:" address should receive replies, in
+ lieu of sending them to the "From:" address.
+
+ Note: In general, the "Resent-" fields should be treated as con-
+ taining a set of information that is independent of the
+ set of original fields. Information for one set should
+ not automatically be taken from the other. The interpre-
+ tation of multiple "Resent-" fields, of the same type, is
+ undefined.
+
+ In the remainder of this specification, occurrence of legal
+ "Resent-" fields are treated identically with the occurrence of
+
+
+
+
+
+
+
+
+ August 13, 1982 - 19 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ fields whose names do not contain this prefix.
+
+ 4.3. TRACE FIELDS
+
+ Trace information is used to provide an audit trail of mes-
+ sage handling. In addition, it indicates a route back to the
+ sender of the message.
+
+ The list of known "via" and "with" values are registered
+ with the Network Information Center, SRI International, Menlo
+ Park, California.
+
+ 4.3.1. RETURN-PATH
+
+ This field is added by the final transport system that
+ delivers the message to its recipient. The field is intended
+ to contain definitive information about the address and route
+ back to the message's originator.
+
+ Note: The "Reply-To" field is added by the originator and
+ serves to direct replies, whereas the "Return-Path"
+ field is used to identify a path back to the origina-
+ tor.
+
+ While the syntax indicates that a route specification is
+ optional, every attempt should be made to provide that infor-
+ mation in this field.
+
+ 4.3.2. RECEIVED
+
+ A copy of this field is added by each transport service that
+ relays the message. The information in the field can be quite
+ useful for tracing transport problems.
+
+ The names of the sending and receiving hosts and time-of-
+ receipt may be specified. The "via" parameter may be used, to
+ indicate what physical mechanism the message was sent over,
+ such as Arpanet or Phonenet, and the "with" parameter may be
+ used to indicate the mail-, or connection-, level protocol
+ that was used, such as the SMTP mail protocol, or X.25 tran-
+ sport protocol.
+
+ Note: Several "with" parameters may be included, to fully
+ specify the set of protocols that were used.
+
+ Some transport services queue mail; the internal message iden-
+ tifier that is assigned to the message may be noted, using the
+ "id" parameter. When the sending host uses a destination
+ address specification that the receiving host reinterprets, by
+
+
+ August 13, 1982 - 20 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ expansion or transformation, the receiving host may wish to
+ record the original specification, using the "for" parameter.
+ For example, when a copy of mail is sent to the member of a
+ distribution list, this parameter may be used to record the
+ original address that was used to specify the list.
+
+ 4.4. ORIGINATOR FIELDS
+
+ The standard allows only a subset of the combinations possi-
+ ble with the From, Sender, Reply-To, Resent-From, Resent-Sender,
+ and Resent-Reply-To fields. The limitation is intentional.
+
+ 4.4.1. FROM / RESENT-FROM
+
+ This field contains the identity of the person(s) who wished
+ this message to be sent. The message-creation process should
+ default this field to be a single, authenticated machine
+ address, indicating the AGENT (person, system or process)
+ entering the message. If this is not done, the "Sender" field
+ MUST be present. If the "From" field IS defaulted this way,
+ the "Sender" field is optional and is redundant with the
+ "From" field. In all cases, addresses in the "From" field
+ must be machine-usable (addr-specs) and may not contain named
+ lists (groups).
+
+ 4.4.2. SENDER / RESENT-SENDER
+
+ This field contains the authenticated identity of the AGENT
+ (person, system or process) that sends the message. It is
+ intended for use when the sender is not the author of the mes-
+ sage, or to indicate who among a group of authors actually
+ sent the message. If the contents of the "Sender" field would
+ be completely redundant with the "From" field, then the
+ "Sender" field need not be present and its use is discouraged
+ (though still legal). In particular, the "Sender" field MUST
+ be present if it is NOT the same as the "From" Field.
+
+ The Sender mailbox specification includes a word sequence
+ which must correspond to a specific agent (i.e., a human user
+ or a computer program) rather than a standard address. This
+ indicates the expectation that the field will identify the
+ single AGENT (person, system, or process) responsible for
+ sending the mail and not simply include the name of a mailbox
+ from which the mail was sent. For example in the case of a
+ shared login name, the name, by itself, would not be adequate.
+ The local-part address unit, which refers to this agent, is
+ expected to be a computer system term, and not (for example) a
+ generalized person reference which can be used outside the
+ network text message context.
+
+
+ August 13, 1982 - 21 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ Since the critical function served by the "Sender" field is
+ identification of the agent responsible for sending mail and
+ since computer programs cannot be held accountable for their
+ behavior, it is strongly recommended that when a computer pro-
+ gram generates a message, the HUMAN who is responsible for
+ that program be referenced as part of the "Sender" field mail-
+ box specification.
+
+ 4.4.3. REPLY-TO / RESENT-REPLY-TO
+
+ This field provides a general mechanism for indicating any
+ mailbox(es) to which responses are to be sent. Three typical
+ uses for this feature can be distinguished. In the first
+ case, the author(s) may not have regular machine-based mail-
+ boxes and therefore wish(es) to indicate an alternate machine
+ address. In the second case, an author may wish additional
+ persons to be made aware of, or responsible for, replies. A
+ somewhat different use may be of some help to "text message
+ teleconferencing" groups equipped with automatic distribution
+ services: include the address of that service in the "Reply-
+ To" field of all messages submitted to the teleconference;
+ then participants can "reply" to conference submissions to
+ guarantee the correct distribution of any submission of their
+ own.
+
+ Note: The "Return-Path" field is added by the mail transport
+ service, at the time of final deliver. It is intended
+ to identify a path back to the orginator of the mes-
+ sage. The "Reply-To" field is added by the message
+ originator and is intended to direct replies.
+
+ 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO
+
+ For systems which automatically generate address lists for
+ replies to messages, the following recommendations are made:
+
+ o The "Sender" field mailbox should be sent notices of
+ any problems in transport or delivery of the original
+ messages. If there is no "Sender" field, then the
+ "From" field mailbox should be used.
+
+ o The "Sender" field mailbox should NEVER be used
+ automatically, in a recipient's reply message.
+
+ o If the "Reply-To" field exists, then the reply should
+ go to the addresses indicated in that field and not to
+ the address(es) indicated in the "From" field.
+
+
+
+
+ August 13, 1982 - 22 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ o If there is a "From" field, but no "Reply-To" field,
+ the reply should be sent to the address(es) indicated
+ in the "From" field.
+
+ Sometimes, a recipient may actually wish to communicate with
+ the person that initiated the message transfer. In such
+ cases, it is reasonable to use the "Sender" address.
+
+ This recommendation is intended only for automated use of
+ originator-fields and is not intended to suggest that replies
+ may not also be sent to other recipients of messages. It is
+ up to the respective mail-handling programs to decide what
+ additional facilities will be provided.
+
+ Examples are provided in Appendix A.
+
+ 4.5. RECEIVER FIELDS
+
+ 4.5.1. TO / RESENT-TO
+
+ This field contains the identity of the primary recipients of
+ the message.
+
+ 4.5.2. CC / RESENT-CC
+
+ This field contains the identity of the secondary (informa-
+ tional) recipients of the message.
+
+ 4.5.3. BCC / RESENT-BCC
+
+ This field contains the identity of additional recipients of
+ the message. The contents of this field are not included in
+ copies of the message sent to the primary and secondary reci-
+ pients. Some systems may choose to include the text of the
+ "Bcc" field only in the author(s)'s copy, while others may
+ also include it in the text sent to all those indicated in the
+ "Bcc" list.
+
+ 4.6. REFERENCE FIELDS
+
+ 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID
+
+ This field contains a unique identifier (the local-part
+ address unit) which refers to THIS version of THIS message.
+ The uniqueness of the message identifier is guaranteed by the
+ host which generates it. This identifier is intended to be
+ machine readable and not necessarily meaningful to humans. A
+ message identifier pertains to exactly one instantiation of a
+ particular message; subsequent revisions to the message should
+
+
+ August 13, 1982 - 23 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ each receive new message identifiers.
+
+ 4.6.2. IN-REPLY-TO
+
+ The contents of this field identify previous correspon-
+ dence which this message answers. Note that if message iden-
+ tifiers are used in this field, they must use the msg-id
+ specification format.
+
+ 4.6.3. REFERENCES
+
+ The contents of this field identify other correspondence
+ which this message references. Note that if message identif-
+ iers are used, they must use the msg-id specification format.
+
+ 4.6.4. KEYWORDS
+
+ This field contains keywords or phrases, separated by
+ commas.
+
+ 4.7. OTHER FIELDS
+
+ 4.7.1. SUBJECT
+
+ This is intended to provide a summary, or indicate the
+ nature, of the message.
+
+ 4.7.2. COMMENTS
+
+ Permits adding text comments onto the message without
+ disturbing the contents of the message's body.
+
+ 4.7.3. ENCRYPTED
+
+ Sometimes, data encryption is used to increase the
+ privacy of message contents. If the body of a message has
+ been encrypted, to keep its contents private, the "Encrypted"
+ field can be used to note the fact and to indicate the nature
+ of the encryption. The first <word> parameter indicates the
+ software used to encrypt the body, and the second, optional
+ <word> is intended to aid the recipient in selecting the
+ proper decryption key. This code word may be viewed as an
+ index to a table of keys held by the recipient.
+
+ Note: Unfortunately, headers must contain envelope, as well
+ as contents, information. Consequently, it is neces-
+ sary that they remain unencrypted, so that mail tran-
+ sport services may access them. Since names,
+ addresses, and "Subject" field contents may contain
+
+
+ August 13, 1982 - 24 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ sensitive information, this requirement limits total
+ message privacy.
+
+ Names of encryption software are registered with the Net-
+ work Information Center, SRI International, Menlo Park, Cali-
+ fornia.
+
+ 4.7.4. EXTENSION-FIELD
+
+ A limited number of common fields have been defined in
+ this document. As network mail requirements dictate, addi-
+ tional fields may be standardized. To provide user-defined
+ fields with a measure of safety, in name selection, such
+ extension-fields will never have names that begin with the
+ string "X-".
+
+ Names of Extension-fields are registered with the Network
+ Information Center, SRI International, Menlo Park, California.
+
+ 4.7.5. USER-DEFINED-FIELD
+
+ Individual users of network mail are free to define and
+ use additional header fields. Such fields must have names
+ which are not already used in the current specification or in
+ any definitions of extension-fields, and the overall syntax of
+ these user-defined-fields must conform to this specification's
+ rules for delimiting and folding fields. Due to the
+ extension-field publishing process, the name of a user-
+ defined-field may be pre-empted
+
+ Note: The prefatory string "X-" will never be used in the
+ names of Extension-fields. This provides user-defined
+ fields with a protected set of names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 25 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 5. DATE AND TIME SPECIFICATION
+
+ 5.1. SYNTAX
+
+ date-time = [ day "," ] date time ; dd mm yy
+ ; hh:mm:ss zzz
+
+ day = "Mon" / "Tue" / "Wed" / "Thu"
+ / "Fri" / "Sat" / "Sun"
+
+ date = 1*2DIGIT month 2DIGIT ; day month year
+ ; e.g. 20 Jun 82
+
+ month = "Jan" / "Feb" / "Mar" / "Apr"
+ / "May" / "Jun" / "Jul" / "Aug"
+ / "Sep" / "Oct" / "Nov" / "Dec"
+
+ time = hour zone ; ANSI and Military
+
+ hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
+ ; 00:00:00 - 23:59:59
+
+ zone = "UT" / "GMT" ; Universal Time
+ ; North American : UT
+ / "EST" / "EDT" ; Eastern: - 5/ - 4
+ / "CST" / "CDT" ; Central: - 6/ - 5
+ / "MST" / "MDT" ; Mountain: - 7/ - 6
+ / "PST" / "PDT" ; Pacific: - 8/ - 7
+ / 1ALPHA ; Military: Z = UT;
+ ; A:-1; (J not used)
+ ; M:-12; N:+1; Y:+12
+ / ( ("+" / "-") 4DIGIT ) ; Local differential
+ ; hours+min. (HHMM)
+
+ 5.2. SEMANTICS
+
+ If included, day-of-week must be the day implied by the date
+ specification.
+
+ Time zone may be indicated in several ways. "UT" is Univer-
+ sal Time (formerly called "Greenwich Mean Time"); "GMT" is per-
+ mitted as a reference to Universal Time. The military standard
+ uses a single character for each zone. "Z" is Universal Time.
+ "A" indicates one hour earlier, and "M" indicates 12 hours ear-
+ lier; "N" is one hour later, and "Y" is 12 hours later. The
+ letter "J" is not used. The other remaining two forms are taken
+ from ANSI standard X3.51-1975. One allows explicit indication of
+ the amount of offset from UT; the other uses common 3-character
+ strings for indicating time zones in North America.
+
+
+ August 13, 1982 - 26 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 6. ADDRESS SPECIFICATION
+
+ 6.1. SYNTAX
+
+ address = mailbox ; one addressee
+ / group ; named list
+
+ group = phrase ":" [#mailbox] ";"
+
+ mailbox = addr-spec ; simple address
+ / phrase route-addr ; name & addr-spec
+
+ route-addr = "<" [route] addr-spec ">"
+
+ route = 1#("@" domain) ":" ; path-relative
+
+ addr-spec = local-part "@" domain ; global address
+
+ local-part = word *("." word) ; uninterpreted
+ ; case-preserved
+
+ domain = sub-domain *("." sub-domain)
+
+ sub-domain = domain-ref / domain-literal
+
+ domain-ref = atom ; symbolic reference
+
+ 6.2. SEMANTICS
+
+ A mailbox receives mail. It is a conceptual entity which
+ does not necessarily pertain to file storage. For example, some
+ sites may choose to print mail on their line printer and deliver
+ the output to the addressee's desk.
+
+ A mailbox specification comprises a person, system or pro-
+ cess name reference, a domain-dependent string, and a name-domain
+ reference. The name reference is optional and is usually used to
+ indicate the human name of a recipient. The name-domain refer-
+ ence specifies a sequence of sub-domains. The domain-dependent
+ string is uninterpreted, except by the final sub-domain; the rest
+ of the mail service merely transmits it as a literal string.
+
+ 6.2.1. DOMAINS
+
+ A name-domain is a set of registered (mail) names. A name-
+ domain specification resolves to a subordinate name-domain
+ specification or to a terminal domain-dependent string.
+ Hence, domain specification is extensible, permitting any
+ number of registration levels.
+
+
+ August 13, 1982 - 27 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ Name-domains model a global, logical, hierarchical addressing
+ scheme. The model is logical, in that an address specifica-
+ tion is related to name registration and is not necessarily
+ tied to transmission path. The model's hierarchy is a
+ directed graph, called an in-tree, such that there is a single
+ path from the root of the tree to any node in the hierarchy.
+ If more than one path actually exists, they are considered to
+ be different addresses.
+
+ The root node is common to all addresses; consequently, it is
+ not referenced. Its children constitute "top-level" name-
+ domains. Usually, a service has access to its own full domain
+ specification and to the names of all top-level name-domains.
+
+ The "top" of the domain addressing hierarchy -- a child of the
+ root -- is indicated by the right-most field, in a domain
+ specification. Its child is specified to the left, its child
+ to the left, and so on.
+
+ Some groups provide formal registration services; these con-
+ stitute name-domains that are independent logically of
+ specific machines. In addition, networks and machines impli-
+ citly compose name-domains, since their membership usually is
+ registered in name tables.
+
+ In the case of formal registration, an organization implements
+ a (distributed) data base which provides an address-to-route
+ mapping service for addresses of the form:
+
+ person@registry.organization
+
+ Note that "organization" is a logical entity, separate from
+ any particular communication network.
+
+ A mechanism for accessing "organization" is universally avail-
+ able. That mechanism, in turn, seeks an instantiation of the
+ registry; its location is not indicated in the address specif-
+ ication. It is assumed that the system which operates under
+ the name "organization" knows how to find a subordinate regis-
+ try. The registry will then use the "person" string to deter-
+ mine where to send the mail specification.
+
+ The latter, network-oriented case permits simple, direct,
+ attachment-related address specification, such as:
+
+ user@host.network
+
+ Once the network is accessed, it is expected that a message
+ will go directly to the host and that the host will resolve
+
+
+ August 13, 1982 - 28 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ the user name, placing the message in the user's mailbox.
+
+ 6.2.2. ABBREVIATED DOMAIN SPECIFICATION
+
+ Since any number of levels is possible within the domain
+ hierarchy, specification of a fully qualified address can
+ become inconvenient. This standard permits abbreviated domain
+ specification, in a special case:
+
+ For the address of the sender, call the left-most
+ sub-domain Level N. In a header address, if all of
+ the sub-domains above (i.e., to the right of) Level N
+ are the same as those of the sender, then they do not
+ have to appear in the specification. Otherwise, the
+ address must be fully qualified.
+
+ This feature is subject to approval by local sub-
+ domains. Individual sub-domains may require their
+ member systems, which originate mail, to provide full
+ domain specification only. When permitted, abbrevia-
+ tions may be present only while the message stays
+ within the sub-domain of the sender.
+
+ Use of this mechanism requires the sender's sub-domain
+ to reserve the names of all top-level domains, so that
+ full specifications can be distinguished from abbrevi-
+ ated specifications.
+
+ For example, if a sender's address is:
+
+ sender@registry-A.registry-1.organization-X
+
+ and one recipient's address is:
+
+ recipient@registry-B.registry-1.organization-X
+
+ and another's is:
+
+ recipient@registry-C.registry-2.organization-X
+
+ then ".registry-1.organization-X" need not be specified in the
+ the message, but "registry-C.registry-2" DOES have to be
+ specified. That is, the first two addresses may be abbrevi-
+ ated, but the third address must be fully specified.
+
+ When a message crosses a domain boundary, all addresses must
+ be specified in the full format, ending with the top-level
+ name-domain in the right-most field. It is the responsibility
+ of mail forwarding services to ensure that addresses conform
+
+
+ August 13, 1982 - 29 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ with this requirement. In the case of abbreviated addresses,
+ the relaying service must make the necessary expansions. It
+ should be noted that it often is difficult for such a service
+ to locate all occurrences of address abbreviations. For exam-
+ ple, it will not be possible to find such abbreviations within
+ the body of the message. The "Return-Path" field can aid
+ recipients in recovering from these errors.
+
+ Note: When passing any portion of an addr-spec onto a process
+ which does not interpret data according to this stan-
+ dard (e.g., mail protocol servers). There must be NO
+ LWSP-chars preceding or following the at-sign or any
+ delimiting period ("."), such as shown in the above
+ examples, and only ONE SPACE between contiguous
+ <word>s.
+
+ 6.2.3. DOMAIN TERMS
+
+ A domain-ref must be THE official name of a registry, network,
+ or host. It is a symbolic reference, within a name sub-
+ domain. At times, it is necessary to bypass standard mechan-
+ isms for resolving such references, using more primitive
+ information, such as a network host address rather than its
+ associated host name.
+
+ To permit such references, this standard provides the domain-
+ literal construct. Its contents must conform with the needs
+ of the sub-domain in which it is interpreted.
+
+ Domain-literals which refer to domains within the ARPA Inter-
+ net specify 32-bit Internet addresses, in four 8-bit fields
+ noted in decimal, as described in Request for Comments #820,
+ "Assigned Numbers." For example:
+
+ [10.0.3.19]
+
+ Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It
+ is permitted only as a means of bypassing temporary
+ system limitations, such as name tables which are not
+ complete.
+
+ The names of "top-level" domains, and the names of domains
+ under in the ARPA Internet, are registered with the Network
+ Information Center, SRI International, Menlo Park, California.
+
+ 6.2.4. DOMAIN-DEPENDENT LOCAL STRING
+
+ The local-part of an addr-spec in a mailbox specification
+ (i.e., the host's name for the mailbox) is understood to be
+
+
+ August 13, 1982 - 30 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ whatever the receiving mail protocol server allows. For exam-
+ ple, some systems do not understand mailbox references of the
+ form "P. D. Q. Bach", but others do.
+
+ This specification treats periods (".") as lexical separators.
+ Hence, their presence in local-parts which are not quoted-
+ strings, is detected. However, such occurrences carry NO
+ semantics. That is, if a local-part has periods within it, an
+ address parser will divide the local-part into several tokens,
+ but the sequence of tokens will be treated as one uninter-
+ preted unit. The sequence will be re-assembled, when the
+ address is passed outside of the system such as to a mail pro-
+ tocol service.
+
+ For example, the address:
+
+ First.Last@Registry.Org
+
+ is legal and does not require the local-part to be surrounded
+ with quotation-marks. (However, "First Last" DOES require
+ quoting.) The local-part of the address, when passed outside
+ of the mail system, within the Registry.Org domain, is
+ "First.Last", again without quotation marks.
+
+ 6.2.5. BALANCING LOCAL-PART AND DOMAIN
+
+ In some cases, the boundary between local-part and domain can
+ be flexible. The local-part may be a simple string, which is
+ used for the final determination of the recipient's mailbox.
+ All other levels of reference are, therefore, part of the
+ domain.
+
+ For some systems, in the case of abbreviated reference to the
+ local and subordinate sub-domains, it may be possible to
+ specify only one reference within the domain part and place
+ the other, subordinate name-domain references within the
+ local-part. This would appear as:
+
+ mailbox.sub1.sub2@this-domain
+
+ Such a specification would be acceptable to address parsers
+ which conform to RFC #733, but do not support this newer
+ Internet standard. While contrary to the intent of this stan-
+ dard, the form is legal.
+
+ Also, some sub-domains have a specification syntax which does
+ not conform to this standard. For example:
+
+ sub-net.mailbox@sub-domain.domain
+
+
+ August 13, 1982 - 31 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ uses a different parsing sequence for local-part than for
+ domain.
+
+ Note: As a rule, the domain specification should contain
+ fields which are encoded according to the syntax of
+ this standard and which contain generally-standardized
+ information. The local-part specification should con-
+ tain only that portion of the address which deviates
+ from the form or intention of the domain field.
+
+ 6.2.6. MULTIPLE MAILBOXES
+
+ An individual may have several mailboxes and wish to receive
+ mail at whatever mailbox is convenient for the sender to
+ access. This standard does not provide a means of specifying
+ "any member of" a list of mailboxes.
+
+ A set of individuals may wish to receive mail as a single unit
+ (i.e., a distribution list). The <group> construct permits
+ specification of such a list. Recipient mailboxes are speci-
+ fied within the bracketed part (":" - ";"). A copy of the
+ transmitted message is to be sent to each mailbox listed.
+ This standard does not permit recursive specification of
+ groups within groups.
+
+ While a list must be named, it is not required that the con-
+ tents of the list be included. In this case, the <address>
+ serves only as an indication of group distribution and would
+ appear in the form:
+
+ name:;
+
+ Some mail services may provide a group-list distribution
+ facility, accepting a single mailbox reference, expanding it
+ to the full distribution list, and relaying the mail to the
+ list's members. This standard provides no additional syntax
+ for indicating such a service. Using the <group> address
+ alternative, while listing one mailbox in it, can mean either
+ that the mailbox reference will be expanded to a list or that
+ there is a group with one member.
+
+ 6.2.7. EXPLICIT PATH SPECIFICATION
+
+ At times, a message originator may wish to indicate the
+ transmission path that a message should follow. This is
+ called source routing. The normal addressing scheme, used in
+ an addr-spec, is carefully separated from such information;
+ the <route> portion of a route-addr is provided for such occa-
+ sions. It specifies the sequence of hosts and/or transmission
+
+
+ August 13, 1982 - 32 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ services that are to be traversed. Both domain-refs and
+ domain-literals may be used.
+
+ Note: The use of source routing is discouraged. Unless the
+ sender has special need of path restriction, the choice
+ of transmission route should be left to the mail tran-
+ sport service.
+
+ 6.3. RESERVED ADDRESS
+
+ It often is necessary to send mail to a site, without know-
+ ing any of its valid addresses. For example, there may be mail
+ system dysfunctions, or a user may wish to find out a person's
+ correct address, at that site.
+
+ This standard specifies a single, reserved mailbox address
+ (local-part) which is to be valid at each site. Mail sent to
+ that address is to be routed to a person responsible for the
+ site's mail system or to a person with responsibility for general
+ site operation. The name of the reserved local-part address is:
+
+ Postmaster
+
+ so that "Postmaster@domain" is required to be valid.
+
+ Note: This reserved local-part must be matched without sensi-
+ tivity to alphabetic case, so that "POSTMASTER", "postmas-
+ ter", and even "poStmASteR" is to be accepted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 33 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ 7. BIBLIOGRAPHY
+
+
+ ANSI. "USA Standard Code for Information Interchange," X3.4.
+ American National Standards Institute: New York (1968). Also
+ in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand-
+ book", NIC 7104.
+
+ ANSI. "Representations of Universal Time, Local Time Differen-
+ tials, and United States Time Zone References for Information
+ Interchange," X3.51-1975. American National Standards Insti-
+ tute: New York (1975).
+
+ Bemer, R.W., "Time and the Computer." In: Interface Age (Feb.
+ 1979).
+
+ Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther-
+ ford and Appleton Laboratory: Didcot, England.
+
+ Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E.
+ "Standardizing Network Mail Headers," ARPANET Request for
+ Comments No. 561, Network Information Center No. 18516; SRI
+ International: Menlo Park (September 1973).
+
+ Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D.
+ "Grapevine: An Exercise in Distributed Computing," Communica-
+ tions of the ACM 25, 4 (April 1982), 260-274.
+
+ Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A.
+ "Standard for the Format of ARPA Network Text Message,"
+ ARPANET Request for Comments No. 733, Network Information
+ Center No. 41952. SRI International: Menlo Park (November
+ 1977).
+
+ Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net-
+ work Information Center No. 7104 (NTIS AD A003890). SRI
+ International: Menlo Park (April 1976).
+
+ Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass.
+ (1969).
+
+ Levin, R. and Schroeder, M. "Transport of Electronic Messages
+ through a Network," TeleInformatics 79, pp. 29-33. North
+ Holland (1979). Also as Xerox Palo Alto Research Center
+ Technical Report CSL-79-4.
+
+ Myer, T.H. and Henderson, D.A. "Message Transmission Protocol,"
+ ARPANET Request for Comments, No. 680, Network Information
+ Center No. 32116. SRI International: Menlo Park (1975).
+
+
+ August 13, 1982 - 34 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ NBS. "Specification of Message Format for Computer Based Message
+ Systems, Recommended Federal Information Processing Standard."
+ National Bureau of Standards: Gaithersburg, Maryland
+ (October 1981).
+
+ NIC. Internet Protocol Transition Workbook. Network Information
+ Center, SRI-International, Menlo Park, California (March
+ 1982).
+
+ Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized
+ Agent for Locating Named Objects in a Distributed Environ-
+ ment," OPD-T8103. Xerox Office Products Division: Palo Alto,
+ CA. (October 1981).
+
+ Postel, J.B. "Assigned Numbers," ARPANET Request for Comments,
+ No. 820. SRI International: Menlo Park (August 1982).
+
+ Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request
+ for Comments, No. 821. SRI International: Menlo Park (August
+ 1982).
+
+ Shoch, J.F. "Internetwork naming, addressing and routing," in
+ Proc. 17th IEEE Computer Society International Conference, pp.
+ 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
+
+ Su, Z. and Postel, J. "The Domain Naming Convention for Internet
+ User Applications," ARPANET Request for Comments, No. 819.
+ SRI International: Menlo Park (August 1982).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 35 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ APPENDIX
+
+
+ A. EXAMPLES
+
+ A.1. ADDRESSES
+
+ A.1.1. Alfred Neuman <Neuman@BBN-TENEXA>
+
+ A.1.2. Neuman@BBN-TENEXA
+
+ These two "Alfred Neuman" examples have identical seman-
+ tics, as far as the operation of the local host's mail sending
+ (distribution) program (also sometimes called its "mailer")
+ and the remote host's mail protocol server are concerned. In
+ the first example, the "Alfred Neuman" is ignored by the
+ mailer, as "Neuman@BBN-TENEXA" completely specifies the reci-
+ pient. The second example contains no superfluous informa-
+ tion, and, again, "Neuman@BBN-TENEXA" is the intended reci-
+ pient.
+
+ Note: When the message crosses name-domain boundaries, then
+ these specifications must be changed, so as to indicate
+ the remainder of the hierarchy, starting with the top
+ level.
+
+ A.1.3. "George, Ted" <Shared@Group.Arpanet>
+
+ This form might be used to indicate that a single mailbox
+ is shared by several users. The quoted string is ignored by
+ the originating host's mailer, because "Shared@Group.Arpanet"
+ completely specifies the destination mailbox.
+
+ A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US
+
+ The "(the Stilt)" is a comment, which is NOT included in
+ the destination mailbox address handed to the originating
+ system's mailer. The local-part of the address is the string
+ "Wilt.Chamberlain", with NO space between the first and second
+ words.
+
+ A.1.5. Address Lists
+
+ Gourmets: Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
+ Childs@WGBH.Boston, Galloping Gourmet@
+ ANT.Down-Under (Australian National Television),
+ Cheapie@Discount-Liquors;,
+ Cruisers: Port@Portugal, Jones@SEA;,
+ Another@Somewhere.SomeOrg
+
+
+ August 13, 1982 - 36 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ This group list example points out the use of comments and the
+ mixing of addresses and groups.
+
+ A.2. ORIGINATOR ITEMS
+
+ A.2.1. Author-sent
+
+ George Jones logs into his host as "Jones". He sends
+ mail himself.
+
+ From: Jones@Group.Org
+
+ or
+
+ From: George Jones <Jones@Group.Org>
+
+ A.2.2. Secretary-sent
+
+ George Jones logs in as Jones on his host. His secre-
+ tary, who logs in as Secy sends mail for him. Replies to the
+ mail should go to George.
+
+ From: George Jones <Jones@Group>
+ Sender: Secy@Other-Group
+
+ A.2.3. Secretary-sent, for user of shared directory
+
+ George Jones' secretary sends mail for George. Replies
+ should go to George.
+
+ From: George Jones<Shared@Group.Org>
+ Sender: Secy@Other-Group
+
+ Note that there need not be a space between "Jones" and the
+ "<", but adding a space enhances readability (as is the case
+ in other examples.
+
+ A.2.4. Committee activity, with one author
+
+ George is a member of a committee. He wishes to have any
+ replies to his message go to all committee members.
+
+ From: George Jones <Jones@Host.Net>
+ Sender: Jones@Host
+ Reply-To: The Committee: Jones@Host.Net,
+ Smith@Other.Org,
+ Doe@Somewhere-Else;
+
+ Note that if George had not included himself in the
+
+
+ August 13, 1982 - 37 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ enumeration of The Committee, he would not have gotten an
+ implicit reply; the presence of the "Reply-to" field SUPER-
+ SEDES the sending of a reply to the person named in the "From"
+ field.
+
+ A.2.5. Secretary acting as full agent of author
+
+ George Jones asks his secretary (Secy@Host) to send a
+ message for him in his capacity as Group. He wants his secre-
+ tary to handle all replies.
+
+ From: George Jones <Group@Host>
+ Sender: Secy@Host
+ Reply-To: Secy@Host
+
+ A.2.6. Agent for user without online mailbox
+
+ A friend of George's, Sarah, is visiting. George's
+ secretary sends some mail to a friend of Sarah in computer-
+ land. Replies should go to George, whose mailbox is Jones at
+ Registry.
+
+ From: Sarah Friendly <Secy@Registry>
+ Sender: Secy-Name <Secy@Registry>
+ Reply-To: Jones@Registry.
+
+ A.2.7. Agent for member of a committee
+
+ George's secretary sends out a message which was authored
+ jointly by all the members of a committee. Note that the name
+ of the committee cannot be specified, since <group> names are
+ not permitted in the From field.
+
+ From: Jones@Host,
+ Smith@Other-Host,
+ Doe@Somewhere-Else
+ Sender: Secy@SHost
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 38 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ A.3. COMPLETE HEADERS
+
+ A.3.1. Minimum required
+
+ Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT
+ From: Jones@Registry.Org or From: Jones@Registry.Org
+ Bcc: To: Smith@Registry.Org
+
+ Note that the "Bcc" field may be empty, while the "To" field
+ is required to have at least one address.
+
+ A.3.2. Using some of the additional fields
+
+ Date: 26 Aug 76 1430 EDT
+ From: George Jones<Group@Host>
+ Sender: Secy@SHOST
+ To: "Al Neuman"@Mad-Host,
+ Sam.Irving@Other-Host
+ Message-ID: <some.string@SHOST>
+
+ A.3.3. About as complex as you're going to get
+
+ Date : 27 Aug 76 0932 PDT
+ From : Ken Davis <KDavis@This-Host.This-net>
+ Subject : Re: The Syntax in the RFC
+ Sender : KSecy@Other-Host
+ Reply-To : Sam.Irving@Reg.Organization
+ To : George Jones <Group@Some-Reg.An-Org>,
+ Al.Neuman@MAD.Publisher
+ cc : Important folk:
+ Tom Softwood <Balsa@Tree.Root>,
+ "Sam Irving"@Other-Host;,
+ Standard Distribution:
+ /main/davis/people/standard@Other-Host,
+ "<Jones>standard.dist.3"@Tops-20-Host>;
+ Comment : Sam is away on business. He asked me to handle
+ his mail for him. He'll be able to provide a
+ more accurate explanation when he returns
+ next week.
+ In-Reply-To: <some.string@DBM.Group>, George's message
+ X-Special-action: This is a sample of user-defined field-
+ names. There could also be a field-name
+ "Special-action", but its name might later be
+ preempted
+ Message-ID: <4231.629.XYzi-What@Other-Host>
+
+
+
+
+
+
+ August 13, 1982 - 39 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ B. SIMPLE FIELD PARSING
+
+ Some mail-reading software systems may wish to perform only
+ minimal processing, ignoring the internal syntax of structured
+ field-bodies and treating them the same as unstructured-field-
+ bodies. Such software will need only to distinguish:
+
+ o Header fields from the message body,
+
+ o Beginnings of fields from lines which continue fields,
+
+ o Field-names from field-contents.
+
+ The abbreviated set of syntactic rules which follows will
+ suffice for this purpose. It describes a limited view of mes-
+ sages and is a subset of the syntactic rules provided in the main
+ part of this specification. One small exception is that the con-
+ tents of field-bodies consist only of text:
+
+ B.1. SYNTAX
+
+
+ message = *field *(CRLF *text)
+
+ field = field-name ":" [field-body] CRLF
+
+ field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
+
+ field-body = *text [CRLF LWSP-char field-body]
+
+
+ B.2. SEMANTICS
+
+ Headers occur before the message body and are terminated by
+ a null line (i.e., two contiguous CRLFs).
+
+ A line which continues a header field begins with a SPACE or
+ HTAB character, while a line beginning a field starts with a
+ printable character which is not a colon.
+
+ A field-name consists of one or more printable characters
+ (excluding colon, space, and control-characters). A field-name
+ MUST be contained on one line. Upper and lower case are not dis-
+ tinguished when comparing field-names.
+
+
+
+
+
+
+
+ August 13, 1982 - 40 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ C. DIFFERENCES FROM RFC #733
+
+ The following summarizes the differences between this stan-
+ dard and the one specified in Arpanet Request for Comments #733,
+ "Standard for the Format of ARPA Network Text Messages". The
+ differences are listed in the order of their occurrence in the
+ current specification.
+
+ C.1. FIELD DEFINITIONS
+
+ C.1.1. FIELD NAMES
+
+ These now must be a sequence of printable characters. They
+ may not contain any LWSP-chars.
+
+ C.2. LEXICAL TOKENS
+
+ C.2.1. SPECIALS
+
+ The characters period ("."), left-square bracket ("["), and
+ right-square bracket ("]") have been added. For presentation
+ purposes, and when passing a specification to a system that
+ does not conform to this standard, periods are to be contigu-
+ ous with their surrounding lexical tokens. No linear-white-
+ space is permitted between them. The presence of one LWSP-
+ char between other tokens is still directed.
+
+ C.2.2. ATOM
+
+ Atoms may not contain SPACE.
+
+ C.2.3. SPECIAL TEXT
+
+ ctext and qtext have had backslash ("\") added to the list of
+ prohibited characters.
+
+ C.2.4. DOMAINS
+
+ The lexical tokens <domain-literal> and <dtext> have been
+ added.
+
+ C.3. MESSAGE SPECIFICATION
+
+ C.3.1. TRACE
+
+ The "Return-path:" and "Received:" fields have been specified.
+
+
+
+
+
+ August 13, 1982 - 41 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ C.3.2. FROM
+
+ The "From" field must contain machine-usable addresses (addr-
+ spec). Multiple addresses may be specified, but named-lists
+ (groups) may not.
+
+ C.3.3. RESENT
+
+ The meta-construct of prefacing field names with the string
+ "Resent-" has been added, to indicate that a message has been
+ forwarded by an intermediate recipient.
+
+ C.3.4. DESTINATION
+
+ A message must contain at least one destination address field.
+ "To" and "CC" are required to contain at least one address.
+
+ C.3.5. IN-REPLY-TO
+
+ The field-body is no longer a comma-separated list, although a
+ sequence is still permitted.
+
+ C.3.6. REFERENCE
+
+ The field-body is no longer a comma-separated list, although a
+ sequence is still permitted.
+
+ C.3.7. ENCRYPTED
+
+ A field has been specified that permits senders to indicate
+ that the body of a message has been encrypted.
+
+ C.3.8. EXTENSION-FIELD
+
+ Extension fields are prohibited from beginning with the char-
+ acters "X-".
+
+ C.4. DATE AND TIME SPECIFICATION
+
+ C.4.1. SIMPLIFICATION
+
+ Fewer optional forms are permitted and the list of three-
+ letter time zones has been shortened.
+
+ C.5. ADDRESS SPECIFICATION
+
+
+
+
+
+
+ August 13, 1982 - 42 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ C.5.1. ADDRESS
+
+ The use of quoted-string, and the ":"-atom-":" construct, have
+ been removed. An address now is either a single mailbox
+ reference or is a named list of addresses. The latter indi-
+ cates a group distribution.
+
+ C.5.2. GROUPS
+
+ Group lists are now required to to have a name. Group lists
+ may not be nested.
+
+ C.5.3. MAILBOX
+
+ A mailbox specification may indicate a person's name, as
+ before. Such a named list no longer may specify multiple
+ mailboxes and may not be nested.
+
+ C.5.4. ROUTE ADDRESSING
+
+ Addresses now are taken to be absolute, global specifications,
+ independent of transmission paths. The <route> construct has
+ been provided, to permit explicit specification of transmis-
+ sion path. RFC #733's use of multiple at-signs ("@") was
+ intended as a general syntax for indicating routing and/or
+ hierarchical addressing. The current standard separates these
+ specifications and only one at-sign is permitted.
+
+ C.5.5. AT-SIGN
+
+ The string " at " no longer is used as an address delimiter.
+ Only at-sign ("@") serves the function.
+
+ C.5.6. DOMAINS
+
+ Hierarchical, logical name-domains have been added.
+
+ C.6. RESERVED ADDRESS
+
+ The local-part "Postmaster" has been reserved, so that users can
+ be guaranteed at least one valid address at a site.
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 43 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ D. ALPHABETICAL LISTING OF SYNTAX RULES
+
+ address = mailbox ; one addressee
+ / group ; named list
+ addr-spec = local-part "@" domain ; global address
+ ALPHA = <any ASCII alphabetic character>
+ ; (101-132, 65.- 90.)
+ ; (141-172, 97.-122.)
+ atom = 1*<any CHAR except specials, SPACE and CTLs>
+ authentic = "From" ":" mailbox ; Single author
+ / ( "Sender" ":" mailbox ; Actual submittor
+ "From" ":" 1#mailbox) ; Multiple authors
+ ; or not sender
+ CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
+ comment = "(" *(ctext / quoted-pair / comment) ")"
+ CR = <ASCII CR, carriage return> ; ( 15, 13.)
+ CRLF = CR LF
+ ctext = <any CHAR excluding "(", ; => may be folded
+ ")", "\" & CR, & including
+ linear-white-space>
+ CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
+ character and DEL> ; ( 177, 127.)
+ date = 1*2DIGIT month 2DIGIT ; day month year
+ ; e.g. 20 Jun 82
+ dates = orig-date ; Original
+ [ resent-date ] ; Forwarded
+ date-time = [ day "," ] date time ; dd mm yy
+ ; hh:mm:ss zzz
+ day = "Mon" / "Tue" / "Wed" / "Thu"
+ / "Fri" / "Sat" / "Sun"
+ delimiters = specials / linear-white-space / comment
+ destination = "To" ":" 1#address ; Primary
+ / "Resent-To" ":" 1#address
+ / "cc" ":" 1#address ; Secondary
+ / "Resent-cc" ":" 1#address
+ / "bcc" ":" #address ; Blind carbon
+ / "Resent-bcc" ":" #address
+ DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
+ domain = sub-domain *("." sub-domain)
+ domain-literal = "[" *(dtext / quoted-pair) "]"
+ domain-ref = atom ; symbolic reference
+ dtext = <any CHAR excluding "[", ; => may be folded
+ "]", "\" & CR, & including
+ linear-white-space>
+ extension-field =
+ <Any field which is defined in a document
+ published as a formal extension to this
+ specification; none will have names beginning
+ with the string "X-">
+
+
+ August 13, 1982 - 44 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ field = field-name ":" [ field-body ] CRLF
+ fields = dates ; Creation time,
+ source ; author id & one
+ 1*destination ; address required
+ *optional-field ; others optional
+ field-body = field-body-contents
+ [CRLF LWSP-char field-body]
+ field-body-contents =
+ <the ASCII characters making up the field-body, as
+ defined in the following sections, and consisting
+ of combinations of atom, quoted-string, and
+ specials tokens, or else consisting of texts>
+ field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
+ group = phrase ":" [#mailbox] ";"
+ hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
+ ; 00:00:00 - 23:59:59
+ HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
+ LF = <ASCII LF, linefeed> ; ( 12, 10.)
+ linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
+ ; CRLF => folding
+ local-part = word *("." word) ; uninterpreted
+ ; case-preserved
+ LWSP-char = SPACE / HTAB ; semantics = SPACE
+ mailbox = addr-spec ; simple address
+ / phrase route-addr ; name & addr-spec
+ message = fields *( CRLF *text ) ; Everything after
+ ; first null line
+ ; is message body
+ month = "Jan" / "Feb" / "Mar" / "Apr"
+ / "May" / "Jun" / "Jul" / "Aug"
+ / "Sep" / "Oct" / "Nov" / "Dec"
+ msg-id = "<" addr-spec ">" ; Unique message id
+ optional-field =
+ / "Message-ID" ":" msg-id
+ / "Resent-Message-ID" ":" msg-id
+ / "In-Reply-To" ":" *(phrase / msg-id)
+ / "References" ":" *(phrase / msg-id)
+ / "Keywords" ":" #phrase
+ / "Subject" ":" *text
+ / "Comments" ":" *text
+ / "Encrypted" ":" 1#2word
+ / extension-field ; To be defined
+ / user-defined-field ; May be pre-empted
+ orig-date = "Date" ":" date-time
+ originator = authentic ; authenticated addr
+ [ "Reply-To" ":" 1#address] )
+ phrase = 1*word ; Sequence of words
+
+
+
+
+ August 13, 1982 - 45 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ qtext = <any CHAR excepting <">, ; => may be folded
+ "\" & CR, and including
+ linear-white-space>
+ quoted-pair = "\" CHAR ; may quote any char
+ quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
+ ; quoted chars.
+ received = "Received" ":" ; one per relay
+ ["from" domain] ; sending host
+ ["by" domain] ; receiving host
+ ["via" atom] ; physical path
+ *("with" atom) ; link/mail protocol
+ ["id" msg-id] ; receiver msg id
+ ["for" addr-spec] ; initial form
+ ";" date-time ; time received
+
+ resent = resent-authentic
+ [ "Resent-Reply-To" ":" 1#address] )
+ resent-authentic =
+ = "Resent-From" ":" mailbox
+ / ( "Resent-Sender" ":" mailbox
+ "Resent-From" ":" 1#mailbox )
+ resent-date = "Resent-Date" ":" date-time
+ return = "Return-path" ":" route-addr ; return address
+ route = 1#("@" domain) ":" ; path-relative
+ route-addr = "<" [route] addr-spec ">"
+ source = [ trace ] ; net traversals
+ originator ; original mail
+ [ resent ] ; forwarded
+ SPACE = <ASCII SP, space> ; ( 40, 32.)
+ specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
+ / "," / ";" / ":" / "\" / <"> ; string, to use
+ / "." / "[" / "]" ; within a word.
+ sub-domain = domain-ref / domain-literal
+ text = <any CHAR, including bare ; => atoms, specials,
+ CR & bare LF, but NOT ; comments and
+ including CRLF> ; quoted-strings are
+ ; NOT recognized.
+ time = hour zone ; ANSI and Military
+ trace = return ; path to sender
+ 1*received ; receipt tags
+ user-defined-field =
+ <Any field which has not been defined
+ in this specification or published as an
+ extension to this specification; names for
+ such fields must be unique and may be
+ pre-empted by published extensions>
+ word = atom / quoted-string
+
+
+
+
+ August 13, 1982 - 46 - RFC #822
+
+
+
+ Standard for ARPA Internet Text Messages
+
+
+ zone = "UT" / "GMT" ; Universal Time
+ ; North American : UT
+ / "EST" / "EDT" ; Eastern: - 5/ - 4
+ / "CST" / "CDT" ; Central: - 6/ - 5
+ / "MST" / "MDT" ; Mountain: - 7/ - 6
+ / "PST" / "PDT" ; Pacific: - 8/ - 7
+ / 1ALPHA ; Military: Z = UT;
+ <"> = <ASCII quote mark> ; ( 42, 34.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ August 13, 1982 - 47 - RFC #822
+
diff --git a/Documentation/en/rfc/rfc974.txt b/Documentation/en/rfc/rfc974.txt
new file mode 100644
index 00000000..97d79a4f
--- /dev/null
+++ b/Documentation/en/rfc/rfc974.txt
@@ -0,0 +1,399 @@
+
+
+Network Working Group Craig Partridge
+Request for Comments: 974 CSNET CIC BBN Laboratories Inc
+ January 1986
+
+ MAIL ROUTING AND THE DOMAIN SYSTEM
+
+
+Status of this Memo
+
+ This RFC presents a description of how mail systems on the Internet
+ are expected to route messages based on information from the domain
+ system described in RFCs 882, 883 and 973. Distribution of this memo
+ is unlimited.
+
+Introduction
+
+ The purpose of this memo is to explain how mailers are to decide how
+ to route a message addressed to a given Internet domain name. This
+ involves a discussion of how mailers interpret MX RRs, which are used
+ for message routing. Note that this memo makes no statement about
+ how mailers are to deal with MB and MG RRs, which are used for
+ interpreting mailbox names.
+
+ Under RFC-882 and RFC-883 certain assumptions about mail addresses
+ have been changed. Up to now, one could usually assume that if a
+ message was addressed to a mailbox, for example, at LOKI.BBN.COM,
+ that one could just open an SMTP connection to LOKI.BBN.COM and pass
+ the message along. This system broke down in certain situations,
+ such as for certain UUCP and CSNET hosts which were not directly
+ attached to the Internet, but these hosts could be handled as special
+ cases in configuration files (for example, most mailers were set up
+ to automatically forward mail addressed to a CSNET host to
+ CSNET-RELAY.ARPA).
+
+ Under domains, one cannot simply open a connection to LOKI.BBN.COM,
+ but must instead ask the domain system where messages to LOKI.BBN.COM
+ are to be delivered. And the domain system may direct a mailer to
+ deliver messages to an entirely different host, such as SH.CS.NET.
+ Or, in a more complicated case, the mailer may learn that it has a
+ choice of routes to LOKI.BBN.COM. This memo is essentially a set of
+ guidelines on how mailers should behave in this more complex world.
+
+ Readers are expected to be familiar with RFCs 882, 883, and the
+ updates to them (e.g., RFC-973).
+
+
+
+
+
+
+
+
+
+Partridge [Page 1]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+What the Domain Servers Know
+
+ The domain servers store information as a series of resource records
+ (RRs), each of which contains a particular piece of information about
+ a given domain name (which is usually, but not always, a host). The
+ simplest way to think of a RR is as a typed pair of datum, a domain
+ name matched with relevant data, and stored with some additional type
+ information to help systems determine when the RR is relevant. For
+ the purposes of message routing, the system stores RRs known as MX
+ RRs. Each MX matches a domain name with two pieces of data, a
+ preference value (an unsigned 16-bit integer), and the name of a
+ host. The preference number is used to indicate in what order the
+ mailer should attempt deliver to the MX hosts, with the lowest
+ numbered MX being the one to try first. Multiple MXs with the same
+ preference are permitted and have the same priority.
+
+ In addition to mail information, the servers store certain other
+ types of RR's which mailers may encounter or choose to use. These
+ are: the canonical name (CNAME) RR, which simply states that the
+ domain name queried for is actually an alias for another domain name,
+ which is the proper, or canonical, name; and the Well Known Service
+ (WKS) RR, which stores information about network services (such as
+ SMTP) a given domain name supports.
+
+General Routing Guidelines
+
+ Before delving into a detailed discussion of how mailers are expected
+ to do mail routing, it would seem to make sense to give a brief
+ overview of how this memo is approaching the problems that routing
+ poses.
+
+ The first major principle is derived from the definition of the
+ preference field in MX records, and is intended to prevent mail
+ looping. If the mailer is on a host which is listed as an MX for the
+ destination host, the mailer may only deliver to an MX which has a
+ lower preference count than its own host.
+
+ It is also possible to cause mail looping because routing information
+ is out of date or incomplete. Out of date information is only a
+ problem when domain tables are changed. The changes will not be
+ known to all affected hosts until their resolver caches time out.
+ There is no way to ensure that this will not happen short of
+ requiring mailers and their resolvers to always send their queries to
+ an authoritative server, and never use data stored in a cache. This
+ is an impractical solution, since eliminating resolver caching would
+ make mailing inordinately expensive. What is more, the out-of-date
+ RR problem should not happen if, when a domain table is changed,
+
+
+Partridge [Page 2]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+ affected hosts (those in the list of MXs) have their resolver caches
+ flushed. In other words, given proper precautions, mail looping as a
+ result of domain information should be avoidable, without requiring
+ mailers to query authoritative servers. (The appropriate precaution
+ is to check with a host's administrator before adding that host to a
+ list of MXs).
+
+ The incomplete data problem also requires some care when handling
+ domain queries. If the answer section of a query is incomplete
+ critical MX RRs may be left out. This may result in mail looping, or
+ in a message being mistakenly labelled undeliverable. As a result,
+ mailers may only accept responses from the domain system which have
+ complete answer sections. Note that this entire problem can be
+ avoided by only using virtual circuits for queries, but since this
+ situation is likely to be very rare and datagrams are the preferred
+ way to interact with the domain system, implementors should probably
+ just ensure that their mailer will repeat a query with virtual
+ circuits should the truncation bit ever be set.
+
+Determining Where to Send a Message
+
+ The explanation of how mailers should decide how to route a message
+ is discussed in terms of the problem of a mailer on a host with
+ domain name LOCAL trying to deliver a message addressed to the domain
+ name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically
+ correct domain names. Furthermore, LOCAL is assumed to be the
+ official name for the host on which the mailer resides (i.e., it is
+ not a alias).
+
+Issuing a Query
+
+ The first step for the mailer at LOCAL is to issue a query for MX RRs
+ for REMOTE. It is strongly urged that this step be taken every time
+ a mailer attempts to send the message. The hope is that changes in
+ the domain database will rapidly be used by mailers, and thus domain
+ administrators will be able to re-route in-transit messages for
+ defective hosts by simply changing their domain databases.
+
+ Certain responses to the query are considered errors:
+
+ Getting no response to the query. The domain server the mailer
+ queried never sends anything back. (This is distinct from an
+ answer which contains no answers to the query, which is not an
+ error).
+
+ Getting a response in which the truncation field of the header is
+
+
+
+Partridge [Page 3]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+ set. (Recall discussion of incomplete queries above). Mailers
+ may not use responses of this type, and should repeat the query
+ using virtual circuits instead of datagrams.
+
+ Getting a response in which the response code is non-zero.
+
+ Mailers are expected to do something reasonable in the face of an
+ error. The behaviour for each type of error is not specified here,
+ but implementors should note that different types of errors should
+ probably be treated differently. For example, a response code of
+ "non-existent domain" should probably cause the message to be
+ returned to the sender as invalid, while a response code of "server
+ failure" should probably cause the message to be retried later.
+
+ There is one other special case. If the response contains an answer
+ which is a CNAME RR, it indicates that REMOTE is actually an alias
+ for some other domain name. The query should be repeated with the
+ canonical domain name.
+
+ If the response does not contain an error response, and does not
+ contain aliases, its answer section should be a (possibly zero
+ length) list of MX RRs for domain name REMOTE (or REMOTE's true
+ domain name if REMOTE was a alias). The next section describes how
+ this list is interpreted.
+
+Interpreting the List of MX RRs
+
+ NOTE: This section only discusses how mailers choose which names to
+ try to deliver a message to, working from a list of RR's. It does
+ not discuss how the mailers actually make delivery. Where ever
+ delivering a message is mentioned, all that is meant is that the
+ mailer should do whatever it needs to do to transfer a message to a
+ remote site, given a domain name for that site. (For example, an
+ SMTP mailer will try to get an address for the domain name, which
+ involves another query to the domain system, and then, if it gets an
+ address, connect to the SMTP TCP port). The mechanics of actually
+ transferring the message over the network to the address associated
+ with a given domain name is not within the scope of this memo.
+
+ It is possible that the list of MXs in the response to the query will
+ be empty. This is a special case. If the list is empty, mailers
+ should treat it as if it contained one RR, an MX RR with a preference
+ value of 0, and a host name of REMOTE. (I.e., REMOTE is its only
+ MX). In addition, the mailer should do no further processing on the
+ list, but should attempt to deliver the message to REMOTE. The idea
+
+
+
+
+Partridge [Page 4]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+ here is that if a domain fails to advertise any information about a
+ particular name we will give it the benefit of the doubt and attempt
+ delivery.
+
+ If the list is not empty, the mailer should remove irrelevant RR's
+ from the list according to the following steps. Note that the order
+ is significant.
+
+ For each MX, a WKS query should be issued to see if the domain
+ name listed actually supports the mail service desired. MX RRs
+ which list domain names which do not support the service should be
+ discarded. This step is optional, but strongly encouraged.
+
+ If the domain name LOCAL is listed as an MX RR, all MX RRs with a
+ preference value greater than or equal to that of LOCAL's must be
+ discarded.
+
+ After removing irrelevant RRs, the list can again be empty. This is
+ now an error condition and can occur in several ways. The simplest
+ case is that the WKS queries have discovered that none of the hosts
+ listed supports the mail service desired. The message is thus deemed
+ undeliverable, though extremely persistent mail systems might want to
+ try a delivery to REMOTE's address (if it exists) before returning
+ the message. Another, more dangerous, possibility is that the domain
+ system believes that LOCAL is handling message for REMOTE, but the
+ mailer on LOCAL is not set up to handle mail for REMOTE. For
+ example, if the domain system lists LOCAL as the only MX for REMOTE,
+ LOCAL will delete all the entries in the list. But LOCAL is
+ presumably querying the domain system because it didn't know what to
+ do with a message addressed to REMOTE. Clearly something is wrong.
+ How a mailer chooses to handle these situations is to some extent
+ implementation dependent, and is thus left to the implementor's
+ discretion.
+
+ If the list of MX RRs is not empty, the mailer should try to deliver
+ the message to the MXs in order (lowest preference value tried
+ first). The mailer is required to attempt delivery to the lowest
+ valued MX. Implementors are encouraged to write mailers so that they
+ try the MXs in order until one of the MXs accepts the message, or all
+ the MXs have been tried. A somewhat less demanding system, in which
+ a fixed number of MXs is tried, is also reasonable. Note that
+ multiple MXs may have the same preference value. In this case, all
+ MXs at with a given value must be tried before any of a higher value
+ are tried. In addition, in the special case in which there are
+ several MXs with the lowest preference value, all of them should be
+ tried before a message is deemed undeliverable.
+
+
+
+Partridge [Page 5]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+Minor Special Issues
+
+ There are a couple of special issues left out of the preceding
+ section because they complicated the discussion. They are treated
+ here in no particular order.
+
+ Wildcard names, those containing the character '*' in them, may be
+ used for mail routing. There are likely to be servers on the network
+ which simply state that any mail to a domain is to be routed through
+ a relay. For example, at the time that this RFC is being written, all
+ mail to hosts in the domain IL is routed through RELAY.CS.NET. This
+ is done by creating a wildcard RR, which states that *.IL has an MX
+ of RELAY.CS.NET. This should be transparent to the mailer since the
+ domain servers will hide this wildcard match. (If it matches *.IL
+ with HUJI.IL for example, a domain server will return an RR
+ containing HUJI.IL, not *.IL). If by some accident a mailer receives
+ an RR with a wildcard domain name in its name or data section it
+ should discard the RR.
+
+ Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
+ a alias and the alias is listed in the MX records for REMOTE. (E.g.
+ REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
+ can be avoided if aliases are never used in the data section of MX
+ RRs.
+
+ Implementors should understand that the query and interpretation of
+ the query is only performed for REMOTE. It is not repeated for the
+ MX RRs listed for REMOTE. You cannot try to support more extravagant
+ mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX
+ for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
+ but this does not mean that UNIX.BBN.COM accepts any responsibility
+ for mail for .IL).
+
+ Finally, it should be noted that this is a standard for routing on
+ the Internet. Mailers serving hosts which lie on multiple networks
+ will presumably have to make some decisions about which network to
+ route through. This decision making is outside the scope of this
+ memo, although mailers may well use the domain system to help them
+ decide. However, once a mailer decides to deliver a message via the
+ Internet it must apply these rules to route the message.
+
+
+
+
+
+
+
+
+
+Partridge [Page 6]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+Examples
+
+ To illustrate the discussion above, here are three examples of how
+ mailers should route messages. All examples work with the following
+ database:
+
+ A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG
+ A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG
+ A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG
+ A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP
+
+ B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG
+ B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG
+ B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP
+
+ C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
+ C.EXAMPLE.ORG IN WKS 10.0.0.3 TCP SMTP
+
+ D.EXAMPLE.ORG IN MX 0 D.EXAMPLE.ORG
+ D.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
+ D.EXAMPLE.ORG IN WKS 10.0.0.4 TCP SMTP
+
+ In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to
+ deliver a message addressed to A.EXAMPLE.ORG. From the answer to its
+ query, it learns that A.EXAMPLE.ORG has three MX RRs. D.EXAMPLE.ORG
+ is not one of the MX RRs and all three MXs support SMTP mail
+ (determined from the WKS entries), so none of the MXs are eliminated.
+ The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the
+ lowest valued MX. If it cannot reach A.EXAMPLE.ORG it can (but is
+ not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not
+ responding, it can try C.EXAMPLE.ORG.
+
+ In the second example, the mailer is on B.EXAMPLE.ORG, and is again
+ trying to deliver a message addressed to A.EXAMPLE.ORG. There are
+ once again three MX RRs for A.EXAMPLE.ORG, but in this case the
+ mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the
+ MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for
+ B.EXAMPLE.ORG). It is left only with the RR for A.EXAMPLE.ORG, and
+ can only try delivery to A.EXAMPLE.ORG.
+
+ In the third example, consider a mailer on A.EXAMPLE.ORG trying to
+ deliver a message to D.EXAMPLE.ORG. In this case there are only two
+ MX RRs, both with the same preference value. Either MX will accept
+ messages for D.EXAMPLE.ORG. The mailer should try one MX first (which
+ one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable),
+ and if that delivery fails should try the other MX (e.g.
+ C.EXAMPLE.ORG).
+
+
+Partridge [Page 7]
+
generated by cgit v1.2.1 (git 2.18.0) at 2026-09-04 14:52:18 +0000