idnits 2.17.1 draft-ietf-drums-smtpupd-08.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 3575 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 815 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The abstract seems to contain references ([RFC-POP2,RFC-POP3], [RFC-1123], [RFC-IMAP4], [SMTPEXT], [RFC-974], [MSGFMT], [RFC-821], [RFC-DNS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 331: '... implementations MUST support the basi...' RFC 2119 keyword, line 332: '...nstance, servers MUST support the EHLO...' RFC 2119 keyword, line 333: '...specific extensions and clients SHOULD...' RFC 2119 keyword, line 335: '...tations, SMTP clients and servers MUST...' RFC 2119 keyword, line 396: '...ginning with "X" MUST NOT be used in a...' (297 more instances...) -- The abstract seems to indicate that this document obsoletes RFC974, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC821, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 212 has weird spacing: '...service envir...' == Line 213 has weird spacing: '...osts on the p...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Eight-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the "8BITMIME" extension [8BITMIME]. 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The forward-path normally consists of the required destination mailbox or mailboxes. Sending systems SHOULD not generate the optional list of hosts known as a source route. Receiving systems MUST recognize 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 4, 1998) is 9391 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-821' is mentioned on line 2376, but not defined ** Obsolete undefined reference: RFC 821 (Obsoleted by RFC 2821) == Missing Reference: 'SMTPEXT' is mentioned on line 171, but not defined == Missing Reference: 'RFC-Pipeline' is mentioned on line 297, but not defined == Missing Reference: '8BitMIME' is mentioned on line 433, but not defined == Unused Reference: 'RFC-IMAP2' is defined on line 2897, but no explicit reference was found in the text == Unused Reference: 'RFC-NOTARY2' is defined on line 2915, but no explicit reference was found in the text == Unused Reference: 'RFC-PCMAIL' is defined on line 2918, but no explicit reference was found in the text == Unused Reference: 'RFC-PIPELINE' is defined on line 2921, but no explicit reference was found in the text == Unused Reference: 'SMTPEX' is defined on line 2939, but no explicit reference was found in the text == Unused Reference: 'TCP' is defined on line 2942, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1652 (ref. '8BITMIME') (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1884 (ref. 'IPv6AddrString') (Obsoleted by RFC 2373) == Outdated reference: A later version (-09) exists of draft-ietf-drums-msg-fmt-05 ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 974 (Obsoleted by RFC 2821) ** Downref: Normative reference to an Unknown state RFC: RFC 1047 ** Obsolete normative reference: RFC 1830 (ref. 'RFC-BDAT') (Obsoleted by RFC 3030) ** Downref: Normative reference to an Experimental RFC: RFC 1176 (ref. 'RFC-IMAP2') ** Obsolete normative reference: RFC 2060 (ref. 'RFC-IMAP4') (Obsoleted by RFC 3501) ** Downref: Normative reference to an Historic RFC: RFC 1848 (ref. 'RFC-MOSS') ** Obsolete normative reference: RFC 1891 (ref. 'RFC-NOTARY1') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1894 (ref. 'RFC-NOTARY2') (Obsoleted by RFC 3464) ** Downref: Normative reference to an Informational RFC: RFC 1056 (ref. 'RFC-PCMAIL') ** Obsolete normative reference: RFC 1854 (ref. 'RFC-PIPELINE') (Obsoleted by RFC 2197) ** Downref: Normative reference to an Historic RFC: RFC 937 (ref. 'RFC-POP2') ** Obsolete normative reference: RFC 1893 (ref. 'RFC-REPLY') (Obsoleted by RFC 3463) ** Obsolete normative reference: RFC 1327 (ref. 'RFC-X400') (Obsoleted by RFC 2156) ** Obsolete normative reference: RFC 1869 (ref. 'SMTPEX') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' Summary: 32 errors (**), 0 flaws (~~), 18 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT John C. Klensin, Editor 2 Expires in six months 3 August 4, 1998 5 Simple Mail Transfer Protocol 7 draft-ietf-drums-smtpupd-08.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working documents 12 of the Internet Engineering Task Force (IETF), its areas, and its working 13 groups. Note that other groups may also distribute working documents as 14 Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months and 17 may be updated, replaced, or obsoleted by other documents at any time. It 18 is inappropriate to use Internet- Drafts as reference material or to cite 19 them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 24 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 25 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 [[Sections marked with doubled brackets (e.g., "<<") are explicit 28 placeholders or known major loose ends. Please review these ASAP. The 29 sections with these placeholders are 4.1.1.1, 4.1.2, 4.4, 8, and X.2.]] 31 [[Appendix X will be removed before the document is submitted to the 32 IESG.]] 34 [[If consensus is reached on this document, it will be forwarded to the 35 IESG with the recommendation that it be processed onto the Standards 36 track.]] 38 Copyright Notice 40 Copyright (C) The Internet Society (1998). All Rights Reserved. 42 Table of Contents 44 0. Abstract 46 1. Introduction 48 2. The SMTP Model 49 2.1 Basic Structure 50 2.2 The Extension Model 51 2.2.1 Background 52 2.2.2 Definition and Registration of Extensions 53 2.3 Terminology 54 2.3.1 Mail Objects 55 2.3.2 Senders and Receivers 56 2.3.3 Mail Agents 57 2.3.4 Host 58 2.3.5 Domain 59 2.3.6 Buffer and State Table 60 2.3.7 Lines 61 2.3.8 Originator, Delivery, Relay, and Gateway Systems 62 2.3.9 Message Content and Mail Data 63 2.3.10 Mailbox and Address 64 2.3.11 Reply 65 2.4 Syntax Principles 66 2.4.1 General Syntax and Transaction Model 67 2.4.2 Command and Reply Syntax 69 3. The SMTP Procedures: An Overview 70 3.1 Session Initiation 71 3.2 Client Initiation 72 3.3 Mail Transactions 73 3.4 Forwarding for Address Correction or Updating 74 3.5 Commands for Debugging Addresses 75 3.5.1 Overview 76 3.5.2 VRFY Normal Response 77 3.5.3 Meaning of VRFY or EXPN Success Response 78 3.5.4 Semantics and Applications of EXPN 79 3.6 Domains 80 3.7 Relaying 81 3.8 Mail Gatewaying 82 3.8.1 Header Fields in Gatewaying 83 3.8.2 Received Lines in Gatewaying 84 3.8.3 Addresses in Gatewaying 85 3.8.4 Other Header Fields in Gatewaying 86 3.8.5 Envelopes in Gatewaying 87 3.9 Terminating Sessions and Connections 88 3.10 Mailing Lists and Aliases 89 3.10.1 Alias 90 3.10.2 List 92 4. The SMTP Specifications 93 4.1 SMTP Commands 94 4.1.1 Command Semantics and Syntax 95 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) 96 4.1.1.2 MAIL (MAIL) 97 4.1.1.3 RECIPIENT (RCPT) 98 4.1.1.4 DATA (DATA) 99 4.1.1.5 RESET (RSET) 100 4.1.1.6 VERIFY (VRFY) 101 4.1.1.7 EXPAND (EXPN) 102 4.1.1.8 HELP (HELP) 103 4.1.1.9 NOOP (NOOP) 104 4.1.1.10 QUIT (QUIT) 105 4.1.2 Lower-level Syntax 106 4.1.3 Address Literals 107 4.1.4 Order of Commands 108 4.1.5 Private-use Commands 109 4.2 SMTP Replies 110 4.2.1 Reply Code Severities and Theory 111 4.2.2 Reply Codes by Function Groups 112 4.2.3 Reply Codes in Numeric Order 113 4.2.4 Reply Code 502 114 4.2.5 Reply Codes After DATA and the Subsequent . 115 4.3 Sequencing of Commands and Replies 116 4.3.1 Sequencing Overview 117 4.3.2 Command-Reply Sequences 118 4.4 Trace Information 119 4.5 Additional Implementation Issues 120 4.5.1 Minimum Implementation 121 4.5.2 Transparency 122 4.5.3 Sizes and Timeouts 123 4.5.4 Queuing Strategies 124 4.5.4.1 Sending Strategy 125 4.5.4.2 Receiving Strategy 127 5. Address Resolution and Mail Handling 129 6. Problem Detection and Handling 130 6.1 Reliable Delivery and Replies by Email 131 6.2 Loop Detection 132 6.3 Compensating for Irregularities 134 7. Security Considerations 135 7.1 Mail Security and Spoofing 136 7.2 "Blind" Copies 137 7.3 VRFY, EXPN, and Security 138 7.4 Information Disclosure in Announcements 139 7.5 Information Disclosure in Trace Fields 140 7.6 Scope of Operation of SMTP Servers 142 8. IANA Considerations 144 9. References 146 10. Editors' Addresses 148 11. Acknowledgments 150 A. TCP Transport Service 151 B. Generating SMTP Commands from RFC 822 Headers 152 C. Source Routes 153 D. Scenarios 154 E. Other Gateway Issues 155 F. Deprecated Features of RFC 821 156 X. Change Summary and Loose Ends (Temporary) 158 0. Abstract 160 This document is a self-contained specification of the basic protocol for 161 the Internet electronic mail transport, consolidating and updating: 163 - the original SMTP specification of RFC 821 [RFC-821], 165 - domain name system requirements and implications for mail transport from 166 RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], 168 - the clarifications and applicability statements in RFC 1123 [RFC-1123], 169 and 171 - material drawn from the SMTP Extension mechanisms [SMTPEXT]. 173 It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123. 174 However, RFC 821 specifies some features that are not in significant use in 175 the Internet of the mid-1990s and (in appendices) some additional transport 176 models. Those sections are omitted here in the interest of clarity and 177 brevity; readers needing them should refer to RFC 821. 179 It also includes some additional material from RFC 1123 that required 180 amplification. This material has been identified in multiple ways, mostly 181 by tracking flaming on various lists and newsgroups and problems of unusual 182 readings or interpretations that have turned up as the SMTP extensions have 183 been deployed. Where this specification moves beyond consolidation and 184 actually differs from earlier documents, it supersedes them technically as 185 well as textually. 187 Although SMTP was designed as a mail transport and delivery protocol, this 188 specification also contains information that is important to its use as a 189 "mail posting" protocol, as recommended for POP [RFC-POP2, RFC-POP3] and 190 IMAP [RFC-IMAP4]. 192 Section 2.3 provides definitions of terms specific to this document. Except 193 when the historical terminology is necessary for clarity, this document 194 uses the current "client" and "server" terminology to identify the sending 195 and receiving SMTP processes, respectively. 197 A companion document discusses message headers, message bodies and formats 198 and structures for them, and their relationship - [MSGFMT]. 200 1. Introduction 202 The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer 203 mail reliably and efficiently. 205 SMTP is independent of the particular transmission subsystem and requires 206 only a reliable ordered data stream channel. While this document 207 specifically discusses transport over TCP, other transports are possible. 208 Appendices to RFC 821 describe some of them. 210 An important feature of SMTP is its capability to transport mail across 211 transport service environments, usually referred to as "SMTP mail relaying" 212 (see section 3.8). A transport service environment might consist of the 213 mutually-TCP-accessible hosts on the public Internet, the 214 mutually-TCP-accessible hosts on a firewall-isolated private TCP/IP 215 Intranet, or hosts in some other LAN or WAN environment utilizing a 216 different transport-level protocol. It is important to realize that 217 "transport service environments" are one-to-one with usual definitions of 218 "networks". A process can communicate directly with another process, and 219 transport mail using this protocol, through any mutually known and 220 connected transport service. Conversely, mail can be relayed or gatewayed 221 between processes in two different transport service environments by a 222 process known and connected to each of the two transport service 223 environments. The Mail eXchanger mechanisms of the domain name system 224 [RFC-DNS, and section 5 of this document] allows the identity of hosts 225 supporting SMTP relay and gateway processes to be specified. 227 2. The SMTP Model 229 2.1 Basic Structure 231 The SMTP design can be pictured as: 233 +----------+ +----------+ 234 +------+ | | | | 235 | User |<-->| | SMTP | | 236 +------+ | Sender- |Commands/Replies| Receiver-| 237 +------+ | SMTP |<-------------->| SMTP | +------+ 238 | File |<-->| | and Mail | |<-->| File | 239 |System| | | | | |System| 240 +------+ +----------+ +----------+ +------+ 241 SMTP client SMTP server 243 When an SMTP client has a message to transmit, it establishes a two-way 244 transmission channel to an SMTP server. The role of an SMTP client is to 245 transfer mail messages to one or more SMTP servers, or report its failure 246 to do so. 248 The means by which a mail message is transferred to an SMTP client, and how 249 that client determines the domain name(s) to which mail messages are to be 250 transferred is a local matter, and is not addressed by this document. In 251 some cases, the domain name(s) transferred to, or determined by, an SMTP 252 client will identify the final destination(s) of the mail message. In other 253 cases, common with SMTP clients associated with implementations of the POP 254 [RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client 255 is inside an isolated transport service environment, the domain name 256 determined will identify an intermediate destination through which all mail 257 messages are to be relayed. SMTP clients that transfer all traffic, 258 regardless of the target domain names associated with the individual 259 messages, or that do not maintain queues for retrying message transmissions 260 that initially cannot be completed, may otherwise conform to this 261 specification but are not considered fully-capable. Fully-capable SMTP 262 implementations, including the relays used by these less capable ones, and 263 their destinations, are expected to support all of the queuing, retrying, 264 and alternate address functions discussed in this specification. 266 The means by which an SMTP client, once it has determined a target domain 267 name, determines the identity of an SMTP server to which a copy of a 268 message is to be transferred, and then performs that transfer, is covered 269 by this document. To effect a mail transfer to an SMTP server, an SMTP 270 client establishes a two-way transmission channel to that SMTP server. An 271 SMTP client determines the address of an appropriate host running an SMTP 272 server by resolving a destination domain name to either an intermediate 273 Mail eXchanger host or a final target host. 275 An SMTP server may be either the ultimate destination or an intermediate 276 "relay" (that is, it may assume the role of an SMTP client after receiving 277 the message) or "gateway" (that is, it may transport the message further 278 using some protocol other than SMTP). SMTP commands are generated by the 279 SMTP client and sent to the SMTP server. SMTP replies are sent from the 280 SMTP server to the SMTP client in response to the commands. 282 Once the transmission channel is established and initial handshaking 283 completed, the SMTP client normally initiates a mail transaction. Such a 284 transaction consists of a series of commands to specify the originator and 285 destination of the mail and transmission of the message content (including 286 any headers or other structure) itself. When the same message is sent to 287 multiple recipients, this protocol encourages the transmission of only one 288 copy of the data for all recipients at the same destination (or 289 intermediate relay) host. 291 The server responds to each command with a reply; replies may indicate that 292 the command was accepted, that additional commands are expected, or that a 293 temporary or permanent error condition exists. Commands specifying the 294 sender or recipients may include server-permitted SMTP service extension 295 requests as discussed in section 2.2. The dialog is purposely lock-step, 296 one-at-a-time, although this can be modified by mutually-agreed extension 297 requests such as in [RFC-Pipeline]. 299 Once a given mail message has been transmitted, the client may either 300 request that the connection be shut down or may initiate other mail 301 transactions. In addition, an SMTP client may use a connection to an SMTP 302 server for ancillary services such as verification of email addresses or 303 retrieval of mailing list subscriber addresses. 305 As suggested above, this protocol provides mechanisms for the transmission 306 of mail. This transmission normally occurs directly from the sending 307 user's host to the receiving user's host when the two hosts are connected 308 to the same transport service. When they are not connected to the same 309 transport service, transmission occurs via one or more relay SMTP servers. 310 An intermediate host that acts as either an SMTP relay or as a gateway into 311 some other transmission environment is usually selected through the use of 312 the domain name service (DNS) Mail eXchanger mechanism. 314 To provide relay capability, the SMTP server is supplied with the name of 315 the ultimate destination host as well as the destination mailbox name. 316 Usually, intermediate hosts are determined via the DNS MX record, not by 317 explicit "source" routing (see appendices C and F.2). 319 2.2 The Extension Model 321 2.2.1 Background 323 In an effort that started in 1990, approximately a decade after RFC 821 was 324 completed, the protocol was modified with a "service extensions" model that 325 permits the client and server to agree to utilize shared functionality 326 beyond the original SMTP requirements. The SMTP extension mechanism defines 327 a means whereby an extended SMTP client and server may recognize each 328 other, and the server can inform the client as to the service extensions 329 that it supports. 331 Contemporary SMTP implementations MUST support the basic extension 332 mechanisms. For instance, servers MUST support the EHLO command even if 333 they do not implement any specific extensions and clients SHOULD 334 preferentially utilize EHLO rather than HELO. (However, for compatibility 335 with older conforming implementations, SMTP clients and servers MUST 336 support the original HELO mechanisms as a fallback.) Unless the different 337 characteristics of HELO must be identified for interoperability purposes, 338 this document discusses only EHLO. 340 SMTP is widely deployed and high-quality implementations have proven to be 341 very robust. However, the Internet community now considers some services to 342 be important that were not anticipated when the protocol was first 343 designed. If support for those services is to be added, it must be done in 344 a way that permits older implementations to continue working acceptably. 345 The extension framework consists of: 347 - The SMTP command EHLO, superseding the earlier HELO, 349 - a registry of SMTP service extensions, 351 - additional parameters to the SMTP MAIL FROM and RCPT TO commands, and 353 - optional replacements for verbs defined in this protocol, such as for 354 DATA (see [RFC-BDAT]). 356 SMTP's strength comes primarily from its simplicity. Experience with many 357 protocols has shown that protocols with few options tend towards ubiquity, 358 whereas protocols with many options tend towards obscurity. 360 Each and every extension, regardless of its benefits, must be carefully 361 scrutinized with respect to its implementation, deployment, and 362 interoperability costs. In many cases, the cost of extending the SMTP 363 service will likely outweigh the benefit. 365 2.2.2 Definition and Registration of Extensions 367 The IANA maintains a registry of SMTP service extensions. A corresponding 368 EHLO keyword value is associated with each extension. Each service 369 extension registered with the IANA must be defined in a formal 370 standards-track or IESG-approved experimental protocol document. The 371 definition must include: 373 - the textual name of the SMTP service extension; 375 - the EHLO keyword value associated with the extension; 377 - the syntax and possible values of parameters associated with the 378 EHLO keyword value; 380 - any additional SMTP verbs associated with the extension (additional 381 verbs will usually be, but are not required to be, the same as the 382 EHLO keyword value); 384 - any new parameters the extension associates with the MAIL FROM or 385 RCPT TO verbs; 387 - a description of how support for the extension affects the behavior 388 of a server and client SMTP; and, 390 - the increment by which the extension is increasing the maximum 391 length of the commands MAIL FROM and/or RCPT TO, over that specified 392 in RFC 821. 394 In addition, any EHLO keyword value starting with an upper or lower case 395 "X" refers to a local SMTP service extension used exclusively through 396 bilateral agreement. Keywords beginning with "X" MUST NOT be used in a 397 registered service extension. Conversely, keyword values presented in the 398 EHLO response that do not begin with "X" MUST correspond to a standard, 399 standards-track, or IESG-approved experimental SMTP service extension 400 registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed 401 keyword values that are not described in a registered extension. 403 Additional verbs and parameter names are bound by the same rules as EHLO 404 keywords; specifically, verbs beginning with "X" are local extensions that 405 may not be registered or standardized. Conversely, verbs not beginning 406 with "X" must always be registered. 408 2.3 Terminology 410 Most of the terminology in this document is common in the Internet at the 411 time of its writing. However, the following terms and concepts are used in 412 special ways here, or represent differences in terminology between RFC 821 413 and this document, and should be understood before reading further. These 414 definitions are normative, that is, they contain specifications to which 415 SMTP implementations are required to conform. 417 2.3.1 Mail Objects 419 SMTP transports a mail object. A mail object contains an envelope and 420 content. 422 The SMTP envelope is sent as a series of SMTP protocol units (described in 423 section 3). It consists of an originator address (to which error reports 424 should be directed); a delivery mode (e.g., deliver to recipient 425 mailboxes); one or more recipient addresses; and optional protocol 426 extension material. 428 The SMTP content is sent in the SMTP DATA protocol unit and has two parts: 429 the headers and the body. If the content conforms to existing standards, 430 the headers form a collection of field/value pairs structured as described 431 in [MSGFMT]; the body, if structured, is defined according to MIME 432 [RFC-MIME]. The content is textual in nature, expressed using the US-ASCII 433 repertoire [US-ASCII]. Although SMTP extensions (such as [8BitMIME]) may 434 relax this restriction for the content body, the content headers are always 435 encoded using the US-ASCII repertoire. The algorithm defined in 436 [RFC-INTLHDR] is used to represent header values outside the US-ASCII 437 repertoire, while still encoding them using the US-ASCII repertoire. 439 2.3.2 Senders and Receivers 441 In RFC 821, the two hosts participating in an SMTP transaction were 442 described as the "SMTP-sender" and "SMTP-receiver". This document has been 443 changed to reflect current industry terminology and hence refers to them as 444 the "SMTP client" (or sometimes just "the client") and "SMTP server" (or 445 just "the server"), respectively. Since a given host may act both as 446 server and client in a relay situation, "receiver" and "sender" terminology 447 is still used where needed for clarity. 449 2.3.3 Mail Agents 451 Additional mail system terminology became common after RFC 821 was 452 published and, where convenient, is used in this specification. In 453 particular, SMTP servers and clients provide a mail transport service and 454 therefore act as Mail Transfer Agents (MTAs). Mail User Agents (MUAs or 455 UAs) are normally thought of as the sources and targets of mail. At the 456 source, an MUA might collect mail to be transmitted from a user and hand it 457 off to an MTA; the final ("delivery") MTA would be thought of as handing 458 the mail off to an MUA (or at least transferring responsibility to it). 459 However, while these terms are used with at least the appearance of great 460 precision in other environments, the implied boundaries between MUAs and 461 MTAs often do not accurately match common, and conforming, practices with 462 Internet mail. Hence, the reader should be cautious about inferring the 463 strong relationships and responsibilities that might be implied if these 464 terms were used elsewhere. 466 2.3.4 Host 468 For the purposes of this specification, a host is a computer system 469 attached to the Internet (or, in some cases, to a private TCP/IP network) 470 and supporting the SMTP protocol. Hosts are known by names (see "domain"); 471 identifying them by numerical address is discouraged. 473 2.3.5 Domain 475 A domain (or domain name) consists of one or more dot-separated components, 476 each consisting of a sequence of letters, digits, and hyphens. Domain 477 names are used as names of hosts and of other entities in the domain name 478 hierarchy. For example, a domain may refer to an alias (label of a CNAME 479 RR) or the label of Mail eXchanger records to be used to deliver mail 480 instead of representing a host name. See [RFC-DNS] and section 5. 482 The domain name, as described in this document and in [RFC-DNS], is the 483 entire, fully-qualified name (often referred to as an "FQDN"). A domain 484 name that is not in FQDN form is no more than a local alias. Local aliases 485 MUST NOT appear in any SMTP transaction. 487 2.3.6 Buffer and State Table 489 SMTP sessions are stateful, with both parties carefully maintaining a 490 common view of the current state. In this document we model this state by 491 a virtual "buffer" and a "state table" on the server which may be used by 492 the client to, for example, "clear the buffer" or "reset the state table," 493 causing the information in the buffer to be discarded and the state to be 494 returned to some previous state 496 2.3.7 Lines 498 SMTP commands and, unless altered by a service extension, message data, are 499 transmitted in "lines". Lines consist of zero or more data characters 500 terminated by the sequence ASCII character "CR" (hex value 0D) followed 501 immediately by ASCII character "LF" (hex value 0A). This termination 502 sequence is denoted as in this document. Conforming implementations 503 MUST NOT recognize or generate any other character or character sequence as 504 a line terminator. 506 2.3.8 Originator, Delivery, Relay, and Gateway Systems 508 This specification makes a distinction among four types of SMTP systems, 509 based on the role those systems play in transmitting electronic mail. An 510 "originating" system (sometimes called an SMTP originator) introduces mail 511 into the Internet or, more generally, into a transport service environment. 512 A "delivery" SMTP system is one that receives mail from a transport service 513 environment and hands it to a mail user agent or deposits it in a message 514 store which a mail user agent is expected to subsequently access. A 515 "relay" SMTP system (usually referred to just as a "relay") receives mail 516 from an SMTP client and transmits it, without modification to the message 517 data other than adding trace information, to another SMTP server for 518 further relaying or for delivery. 520 A "gateway" SMTP system (usually referred to just as a "gateway") receives 521 mail from a client system in one transport environment and transmits it to 522 a server system in another transport environment. Differences in protocols 523 or message semantics between the transport environments on either side of a 524 gateway may require that the gateway system perform transformations to the 525 message that are not permitted to SMTP relay systems. 527 2.3.9 Message Content and Mail Data 529 The terms "message content" and "mail data" are used interchangeably in 530 this document to describe the material transmitted after the DATA command 531 is accepted and before the end of data indication is transmitted. Message 532 content includes message headers and the possibly-structured message body. 533 The MIME specification [RFC-MIME] provides the Standard mechanisms for 534 structured message bodies. 536 2.3.10 Mailbox and Address 538 As used in this specification, an "address" is a character string that 539 identifies a user to whom mail will be sent or a location into which mail 540 will be deposited. The term "mailbox" refers to that depository. The two 541 terms are typically used interchangeably unless the distinction between the 542 location in which mail is placed (the mailbox) and a reference to it (the 543 address) is important. An address normally consists of user and domain 544 specifications. The standard mailbox naming convention is defined to be 545 "local-part@domain": contemporary usage permits a much broader set of 546 applications than simple "user names" and, consequently, the local-part is 547 interpreted and assigned semantics only by the host specified in the domain 548 part of the address. 550 2.3.11 Reply 552 An SMTP reply is an acknowledgment (positive or negative) sent from 553 receiver to sender via the transmission channel in response to a command. 554 The general form of a reply is a numeric completion code (indicating 555 failure or success) followed by a text string. The codes are for use by 556 programs and the text is usually intended for human users. 558 2.4 Syntax Principles 560 2.4.1 General Syntax and Transaction Model 562 SMTP commands and replies have a rigid syntax. All commands begin with a 563 four letter command verb. All Replies begin with a three digit numeric 564 code. In some commands and replies, arguments MUST follow the verb or reply 565 code. Some commands do not accept arguments (after the verb), and some 566 reply codes are followed, sometimes optionally, by free form text. In both 567 cases, where text appears, it is separated from the verb or reply code by a 568 . Complete definitions of commands and replies appear in section 4. 570 Verbs and argument values are not case sensitive, with the sole exception 571 of a mailbox local-part. That is, a command verb, an argument value other 572 than a mailbox local-part, and free form text MAY be encoded in upper case, 573 lower case, or any mixture of upper and lower case with no impact on its 574 meaning. This is NOT true of a mailbox local-part. The local-part of a 575 mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations 576 MUST take care to preserve the case of mailbox local-parts. Mailbox 577 domains are not case sensitive. However, exploiting the case sensitivity 578 of mailbox local-parts impedes interoperability and is discouraged. 580 Commands and replies are composed of characters from the ASCII character 581 set [US-ASCII]. When the transport service provides an 8-bit byte (octet) 582 transmission channel, each 7-bit character is transmitted right justified 583 in an octet with the high order bit cleared to zero. More specifically, the 584 unextended SMTP service provides seven bit transport only. An originating 585 SMTP client which has not successfully negotiated an appropriate extension 586 with a particular server MUST NOT transmit messages with information in the 587 high-order bit of octets. If such messages are transmitted in violation of 588 this rule, receiving SMTP servers MAY clear the high-order bit or reject 589 the message as invalid. In general, a relay SMTP SHOULD assume that the 590 message content it has received is valid and, assuming that the envelope 591 permits doing so, relay it without inspecting that content. Of course, if 592 the content is mislabeled and the data path cannot accept the actual 593 content, this may result in ultimate delivery of a severely garbled message 594 to the recipient. Delivery SMTP systems MAY reject ("bounce") such 595 messages rather than deliver them. No sending SMTP system is permitted to 596 send envelope commands in any character set other than US-ASCII; receiving 597 systems SHOULD reject such commands, normally using "500 syntax error - 598 invalid character" replies. 600 Eight-bit message content transmission MAY be requested of the server by a 601 client using extended SMTP facilities, notably the "8BITMIME" extension 602 [8BITMIME]. 8BITMIME SHOULD be supported by SMTP servers. However, it MUST 603 not be construed as authorization to transmit unrestricted eight bit 604 material. 8BITMIME MUST NOT be requested by senders for material with the 605 high bit on that is not in MIME format with an appropriate content-transfer 606 encoding; servers MAY reject such messages. 608 The metalinguistic notation used in this document corresponds to the 609 "Augmented BNF" used in other Internet mail system documents. The reader 610 who is not familiar with that syntax should consult [ABNF]. Metalanguage 611 terms used in running text are surrounded by pointed brackets (e.g., 612 ) for clarity. 614 2.4.2 Command and Reply Syntax 616 The commands consist of a command verb followed by an argument field. 617 Command verbs are four alphabetic characters and are case insensitive. 619 This also applies to any symbols representing parameter values, such as 620 "TO" or "to" for the forward-path. Command verbs and the argument fields 621 are separated by one or more spaces. However, case is important in the 622 local-part within the reverse-path and forward-path arguments. In 623 particular, for some hosts the user "smith" is different from the user 624 "Smith". 626 A few SMTP servers, in violation of this specification (and RFC 821) 627 require that command verbs and certain argument text (such as the 628 forward-path and reverse-path in RCPT and MAIL commands) be encoded by 629 clients in upper case. Implementations MAY wish to employ this encoding to 630 accommodate those servers. 632 The argument field consists of a variable length character string ending 633 with the character sequence . The receiver will take no action until 634 this sequence is received. 636 The syntax for each command is shown with the discussion of that command. 637 Common elements and parameters are shown in section 4.1.2. 639 3. The SMTP Procedures: An Overview 641 This section contains descriptions of the procedures used in SMTP: session 642 initiation, the mail transaction, forwarding mail, verifying mailbox names 643 and expanding mailing lists, and the opening and closing exchanges. 644 Comments on relaying, a note on mail domains, and a discussion of changing 645 roles are included at the end of this section. Several complete scenarios 646 are presented in appendix D. 648 3.1 Session Initiation 650 An SMTP session is initiated when a client opens a connection to a server 651 and the server responds with an opening message. 653 SMTP server implementations MAY include identification of their software 654 and version information in the connection greeting reply after the 220 655 code, a practice that permits more efficient isolation and repair of any 656 problems. Implementations MAY make provision for SMTP servers to disable 657 the software and version announcement where it causes security concerns. 658 While some systems also identify their contact point for mail problems, 659 this is not a substitute for maintaining the required "postmaster" address 660 (see [MSGFMT]). 662 The SMTP protocol allows a server to formally reject a transaction while 663 still allowing the initial connection as follows: a 554 response MAY be 664 given in the initial connection opening message instead of the 220. A 665 server taking this approach MUST still wait for the client to send a QUIT 666 (see section 4.1.1.10) before closing the connection and SHOULD respond to 667 any intervening commands with "503 bad sequence of commands". Since an 668 attempt to make an SMTP connection to such a system is probably in error, a 669 server returning a 554 response on connection opening SHOULD provide enough 670 information in the reply text to facilitate debugging of the sending 671 system. 673 3.2 Client Initiation 675 Once the server has sent the welcoming message and the client has received 676 it, the client then sends the EHLO command to the server, indicating the 677 client's identity. In addition to opening the session, use of EHLO 678 indicates that the client is able to process service extensions and 679 requests that the server provide a list of the extensions it supports. 680 Older SMTP systems, unable to support service extensions, MAY use HELO 681 instead of EHLO. Servers MUST NOT return the extended EHLO-style response 682 to a HELO command. 684 In the EHLO command the host sending the command identifies itself; the 685 command may be interpreted as saying "Hello, I am " (and, in the 686 case of EHLO, "and I support service extension requests"). 688 3.3 Mail Transactions 690 There are three steps to SMTP mail transactions. The transaction starts 691 with a MAIL command which gives the sender identification. A series of one 692 or more RCPT commands follows giving the receiver information. Then a DATA 693 command initiates transfer of the mail data and is terminated by the "end 694 of mail" data indicator, which also confirms the transaction. 696 The first step in the procedure is the MAIL command. 698 MAIL FROM: [ ] 700 This command tells the SMTP-receiver that a new mail transaction is 701 starting and to reset all its state tables and buffers, including any 702 recipients or mail data. The contains the source mailbox, 703 which can be used to report errors (see section 4.2 for a discussion of 704 error reporting). If accepted, the SMTP server returns a 250 OK reply. If 705 the mailbox specification is not acceptable for some reason, the server 706 MUST return a reply indicating whether the failure is permanent (i.e., will 707 occur again if the client tries to send the same address again) or 708 temporary (i.e., the address might be accepted if the client tries again 709 later). Despite the apparent scope of this requirement, there are 710 circumstances in which the acceptability of the reverse-path may not be 711 determined until one or more forward-paths (in RCPT commands) can be 712 examined. In those cases, the server MAY reasonably accept the 713 reverse-path (with a 250 reply) and then report problems after the 714 forward-paths are received and examined. Normally, failures produce 550 or 715 553 replies. 717 Historically, the can contain more than just a mailbox, 718 however, contemporary systems SHOULD NOT use source routing (see appendix 719 C). 721 The optional are associated with negotiated SMTP service 722 extensions (see section 2.2). 724 The second step in the procedure is the RCPT command. 726 RCPT TO: [ ] 728 This command gives a forward-path (normally a mailbox and domain) 729 identifying one recipient. If accepted, the SMTP server returns a 250 OK 730 reply and stores the forward-path. If the recipient is known not to be a 731 deliverable address, the SMTP server returns a 550 reply, typically with a 732 string such as "no such user - " and the mailbox name (other circumstances 733 and reply codes are possible). This step of the procedure can be repeated 734 any number of times. 736 The can contain more than just a mailbox. Historically, the 737 can be a source routing list of hosts and the destination 738 mailbox, however, contemporary SMTP clients SHOULD NOT utilize source 739 routes (see appendix C). Servers MUST be prepared to encounter a list of 740 source routes in the forward path, but SHOULD ignore the routes or MAY 741 decline to support the relaying they imply. Similarly, servers MAY decline 742 to accept mail that is destined for other hosts or systems. These 743 restrictions make a server useless as a relay for clients that do not 744 support full SMTP functionality. Consequently, restricted-capability 745 clients MUST NOT assume that any SMTP server on the Internet can be used as 746 their mail processing (relaying) site. If RCPT TO appears without a 747 previous MAIL FROM, the server MUST return a 503 "Bad sequence of commands" 748 response. The optional are associated with negotiated 749 SMTP service extensions (see section 2.2). 751 The third step in the procedure is the DATA command (or some alternative 752 specified in a service extension). 754 DATA 756 If accepted, the SMTP server returns a 354 Intermediate reply and considers 757 all succeeding lines up to but not including the end of mail data indicator 758 to be the message text. When the end of text is successfully received and 759 stored the SMTP-receiver sends a 250 OK reply. 761 Since the mail data is sent on the transmission channel, the end of mail 762 data must be indicated so that the command and reply dialog can be resumed. 763 SMTP indicates the end of the mail data by sending a line containing only a 764 "." (period or full stop). A transparency procedure is used to prevent 765 this from interfering with the user's text (see section 4.5.2). 767 The end of mail data indicator also confirms the mail transaction and tells 768 the SMTP server to now process the stored recipients and mail data. If 769 accepted, the SMTP server returns a 250 OK reply. The DATA command can fail 770 in only two ways: 772 - If there was no MAIL FROM, or no RCPT TO, command, or all such commands 773 were rejected, the server MAY return a "command out of sequence" (503) 774 reply. If that reply is received, the client MUST NOT send the message 775 data; more generally, message data MUST NOT be sent unless a 354 reply 776 is received. 778 - If the verb is initially accepted and the 354 reply issued, the DATA 779 command should fail only if the mail transaction was incomplete (for 780 example, no recipients), or if resources were unavailable. 782 However, in practice, some servers do not perform recipient verification 783 until after the message text is received. These servers SHOULD treat a 784 failure for one or more recipients as a "subsequent failure" and return a 785 mail message as discussed in section 6. Using a "550 mailbox not found" 786 (or equivalent) reply code after the data are accepted makes it difficult 787 or impossible for the client to determine which recipients failed. 789 When RFC 822 format is being used, the mail data include the memo header 790 items such as Date, Subject, To, Cc, From [MSGFMT]. Server SMTP systems 791 SHOULD NOT reject messages based on perceived defects in the RFC 822 or 792 MIME [RFC-MIME] message header or message body. In particular, they MUST 793 NOT reject messages in which the numbers of Resent- fields do not match or 794 Resent-to appears without Resent-from and/or Resent-date. 796 Mail transaction commands MUST be used in the order discussed above. 798 3.4 Forwarding for Address Correction or Updating 800 Forwarding support is most often required to consolidate and simplify 801 addresses within, or relative to, some enterprise and less frequently to 802 establish addresses to link a person's prior address with current one. 803 Silent forwarding of messages (without server notification to the sender), 804 for security or non-disclosure purposes, is common in the contemporary 805 Internet. 807 In both the enterprise and the "new address" cases, information 808 hiding (and sometimes security) considerations argue against exposure 809 of the "final" address through the SMTP protocol as a side-effect of 810 the forwarding activity. This may be especially important when the 811 final address may not even be reachable by the sender. Consequently, 812 the "forwarding" mechanisms described in section 3.2 of RFC 821, and 813 especially the 251 (corrected destination) reply code from RCPT TO 814 are deprecated: Servers SHOULD NOT provide that service or return 815 that code. 817 3.5 Commands for Debugging Addresses 819 3.5.1 Overview 821 SMTP provides commands to verify a user name or obtain the content of a 822 mailing list. This is done with the VRFY and EXPN commands, which have 823 character string arguments. Implementations MUST support VRFY and SHOULD 824 support EXPN (however, see section 3.5.2 and 7.3). 826 For the VRFY command, the string is a user name or a user name and domain 827 (see below). If a normal (i.e., 250) response is returned, the response MAY 828 include the full name of the user and MUST include the mailbox of the user. 829 It MUST be in either of the following forms: 831 User Name 832 local-part@domain 834 When a name that is the argument to VRFY could identify more than one 835 mailbox, the server MAY either note the ambiguity or identify the 836 alternatives. In other words, any of the following are legitimate 837 response to VRFY: 839 553 User ambiguous 841 or 843 553- Ambiguous; Possibilities are 844 553-Joe Smith 845 553-Harry Smith 846 553 Melvin Smith 848 or 850 553-Ambiguous; Possibilities 851 553- 852 553- 853 553 855 Under normal circumstances, a client receiving a 553 reply would be 856 expected to expose the result to the user. Use of exactly the forms given, 857 and the "user ambiguous" or "ambiguous" keywords, possibly supplemented by 858 extended reply codes as described in [RFC-REPLY], will facilitate automated 859 translation into other languages as needed. Of course, a client that was 860 highly automated or that was operating in another language than English, 861 might choose to try to translate the response, to return some other 862 indication to the user than the literal text of the reply, or to take some 863 automated action such as consulting a directory service for additional 864 information before reporting to the user. 866 For the EXPN command, the string identifies a mailing list, and the 867 successful (i.e., 250) multiline response MAY include the full name of the 868 users and MUST give the mailboxes on the mailing list. 870 In some hosts the distinction between a mailing list and an alias for a 871 single mailbox is a bit fuzzy, since a common data structure may hold both 872 types of entries, and it is possible to have mailing lists of one mailbox. 873 If a request is made to verify a mailing list, a positive response MAY be 874 given if a message so addressed would be delivered to everyone on the list, 875 otherwise an error SHOULD be reported (e.g., "550 That is a mailing list, 876 not a user" or "252 Unable to verify members of mailing list"). If a 877 request is made to expand a user name, the server MAY return a positive 878 response consisting of a list containing one name, or an error MAY be 879 reported (e.g., "550 That is a user name, not a mailing list"). 881 In the case of a successful multiline reply (normal for EXPN) exactly one 882 mailbox is to be specified on each line of the reply. The case of an 883 ambiguous request is discussed above. 885 "User name" is a fuzzy term and has been used deliberately. An 886 implementation of the VRFY or EXPN commands MUST include at least 887 recognition of local mailboxes as "user names". However, since current 888 Internet practice often results in a single host handling mail for multiple 889 domains, hosts, especially hosts that provide this functionality, SHOULD 890 accept the "local-part@domain" form as a "user name"; hosts MAY also choose 891 to recognize other strings as "user names". 893 The case of expanding a mailbox list requires a multiline reply, such as: 895 C: EXPN Example-People 896 S: 250-Jon Postel 897 S: 250-Fred Fonebone 898 S: 250 Sam Q. Smith 900 or 902 C EXPN Executive-Washroom-List 903 S: 550 Access Denied to You. 905 The character string arguments of the VRFY and EXPN commands cannot be 906 further restricted due to the variety of implementations of the user name 907 and mailbox list concepts. On some systems it may be appropriate for the 908 argument of the EXPN command to be a file name for a file containing a 909 mailing list, but again there are a variety of file naming conventions in 910 the Internet. Similarly, historical variations in what is returned by 911 these commands are such that the response SHOULD be interpreted very 912 carefully, if at all, and SHOULD generally only be used for diagnostic 913 purposes. 915 3.5.2 VRFY Normal Response 917 When normal (2yz or 551) responses are returned from a VRFY or EXPN 918 request, the reply MUST normally include the mailbox name. 919 "", where "domain" is a fully qualified domain name, 920 MUST appear in the syntax. In exceptional circumstances, free-form text 921 MAY be returned. In order to facilitate parsing by both computers and 922 people, addresses SHOULD appear in pointed brackets. When addresses, 923 rather than free-form debugging information, are returned, EXPN and VRFY 924 MUST return only valid domain addresses that are usable in SMTP RCPT 925 commands. Consequently, if an address implies delivery to a program or 926 other system, the mailbox name used to reach that target MUST be given. 927 Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN. 929 Server implementations MUST support VRFY and SHOULD support EXPN. For 930 security reasons, implementations MAY provide local installations a way to 931 disable either or both of these commands through configuration options or 932 the equivalent. When these commands are supported, they are not required 933 to work across relays when relaying is supported. Since they were both 934 optional in RFC 821, they MUST be listed as service extensions in an EHLO 935 response, if they are supported. 937 3.5.3 Meaning of VRFY or EXPN Success Response 939 A server MUST NOT return a 220 code in response to a VRFY or EXPN command 940 unless it has actually verified the address. In particular, a server MUST 941 NOT return 220 if all it has done is to verify that the syntax given is 942 valid. In that case, 502 (Command not implemented) or 500 (Syntax error, 943 command unrecognized) SHOULD be returned. As stated elsewhere, 944 implementation of VRFY is required and EXPN is strongly recommended. 945 Hence, implementations that return 500 or 502 for VRFY are not in 946 compliance with this specification. 948 There may be circumstances where an address appears to be valid but cannot 949 reasonably be verified in real time, particularly when a server is acting 950 as a mail exchanger for another server or domain. "Apparent validity" in 951 this case would normally involve at least syntax checking and might involve 952 verification that any domains specified were ones to which the host 953 expected to be able to relay mail. In these situations, reply code 252 954 SHOULD BE returned. These cases parallel the discussion of RCPT 955 verification discussed in section 2.1 Implementations generally SHOULD be 956 more aggressive about address verification in the case of VRFY than in the 957 case of RCPT, even if it takes a little longer to do so. 959 3.5.4 Semantics and Applications of EXPN 961 EXPN is often very useful in debugging and understanding problems with 962 mailing lists and multiple-target-address aliases. Some systems have 963 attempted to use source expansion of mailing lists as a means of 964 eliminating duplicates. The propagation of aliasing systems with mail on 965 the Internet, both for hosts (typically with MX and CNAME DNS records) and 966 for mailboxes (various types of local host aliases), has made it nearly 967 impossible for these strategies to work, and mail systems SHOULD NOT 968 attempt them. 970 3.6 Domains 972 Only resolvable, fully-qualified, domain names (FQDNs) are permitted when 973 domain names are used in SMTP. In other words, names that can be resolved 974 to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME 975 RRs whose targets can be resolved, in turn, to MX or A RRs. Local 976 nicknames or unqualified names MUST NOT be used. There are two exceptions 977 to the rule requiring FQDNs: 979 - The domain name given in the EHLO command MUST BE either a primary host 980 name (a domain name that resolves to an A RR) or, if the host has no 981 name, an address literal as described in section 4.1.1.1. 983 - The reserved mailbox name "postmaster" may be used in a RCPT TO command 984 without domain qualification (see section 4.1.1.3) and MUST be accepted 985 if so used. 987 3.7 Relaying 989 In general, the availability of Mail eXchanger records in the domain name 990 system [RFC-DNS] makes the use of explicit source routes in the Internet 991 mail system unnecessary. Many historical problems with their 992 interpretation have made their use undesirable. SMTP clients SHOULD NOT 993 generate explicit source routes except under unusual circumstances. SMTP 994 servers MAY decline to act as mail relays or to accept addresses that 995 specify source routes. When route information is encountered, they are 996 also permitted to ignore the route information and simply send to the final 997 destination specified as the last element in the route and SHOULD do so. 998 There has been an invalid practice of using names that do not appear in the 999 DNS as destination names, with the senders counting on the intermediate 1000 hosts specified in source routing to resolve any problems. If source 1001 routes are stripped, this practice will cause failures. This is one of 1002 several reasons why SMTP clients MUST NOT generate invalid source routes or 1003 depend on serial resolution of names. 1005 When source routes are not used, the process described in RFC 821 for 1006 constructing a reverse-path from the forward-path is not applicable and the 1007 reverse-path at the time of delivery will simply be the address that 1008 appeared in the MAIL command. 1010 A relay SMTP server is usually the target of a DNS MX record that 1011 designates it, rather than the final delivery system. The relay server may 1012 accept or reject the task of relaying the mail in the same way it accepts 1013 or rejects mail for a local user. If it accepts the task, it then becomes 1014 an SMTP client, establishes a transmission channel to the next SMTP server 1015 specified in the DNS (according to the rules in section 5), and sends it 1016 the mail. If it declines to relay mail to a particular address for policy 1017 reasons, a 571 response MAY be returned. 1019 If an SMTP server has accepted the task of relaying the mail and later 1020 finds that the destination is incorrect or that the mail cannot be 1021 delivered for some other reason, then it MUST construct an "undeliverable 1022 mail" notification message and send it to the originator of the 1023 undeliverable mail (as indicated by the reverse-path). Formats specified 1024 for non-delivery reports by other standards (see, for example, 1025 [RFC-NOTARY1]) SHOULD be used if possible. 1027 This notification message must be from the SMTP server at the relay host or 1028 the host that first determines that delivery cannot be accomplished. Of 1029 course, SMTP servers MUST NOT send notification messages about problems 1030 transporting notification messages. One way to prevent loops in error 1031 reporting is to specify a null reverse-path in the MAIL command of a 1032 notification message. When such a message is transmitted the reverse-path 1033 MUST be set to null. A MAIL command with a null reverse-path appears as 1034 follows: 1036 MAIL FROM:<> 1038 As discussed in section 2.4.1, a relay SMTP has no need to inspect or act 1039 upon the headers or body of the message data and MUST NOT do so except 1040 to add its own "Received:" header (section 4.4) and to perform simple 1041 counting of the number of "Received:" headers in a message (section 6.2). 1043 3.8 Mail Gatewaying 1045 While the relay function discussed above operates within the Internet SMTP 1046 transport service environment, MX records or various forms of explicit 1047 routing may require that an intermediate SMTP server perform a translation 1048 function between one transport service and another. As discussed in 1049 section 2.3.8, when such a system is at the boundary between two transport 1050 service environments, we refer to it as a "gateway" or "gateway SMTP". 1052 Gatewaying mail between different mail environments, such as different mail 1053 formats and protocols, is complex and does not easily yield to 1054 standardization. However, some general requirements may be given for a 1055 gateway between the Internet and another mail environment. 1057 3.8.1 Header Fields in Gatewaying 1059 Header fields MAY be rewritten when necessary as messages are gatewayed 1060 across mail environment boundaries. This may involve inspecting the message 1061 body or interpreting the local-part of the destination address in spite of 1062 the prohibitions in section 2.4.1 1064 Other mail systems gatewayed to the Internet often use a subset of RFC-822 1065 headers or provide similar functionality with a different syntax, but some 1066 of these mail systems do not have an equivalent to the SMTP envelope. 1067 Therefore, when a message leaves the Internet environment, it may be 1068 necessary to fold the SMTP envelope information into the message header. A 1069 possible solution would be to create new header fields to carry the 1070 envelope information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, 1071 this would require changes in mail programs in foreign environments and 1072 might risk disclosure of private information (see section 7.2). 1074 3.8.2 Received Lines in Gatewaying 1076 When forwarding a message into or out of the Internet environment, a 1077 gateway MUST prepend a Received: line, but it MUST NOT alter in any way a 1078 Received: line that is already in the header. 1080 Received: fields of messages originating from other environments may not 1081 conform exactly to this specification. However, the most important use of 1082 Received: lines is for debugging mail faults, and this debugging can be 1083 severely hampered by well-meaning gateways that try to "fix" a Received: 1084 line. As another consequence of trace fields arising in non-SMTP 1085 environments, receiving systems MUST NOT reject mail based on the format of 1086 a trace field and SHOULD be extremely robust in the light of unexpected 1087 information or formats in those fields. 1089 The gateway SHOULD indicate the environment and protocol in the "via" 1090 clauses of Received field(s) that it supplies. 1092 3.8.3 Addresses in Gatewaying 1094 >From the Internet side, the gateway SHOULD accept all valid address formats 1095 in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages. 1096 Gateways are, of course, subject to the same rules for handling source 1097 routes as those described for other SMTP systems in section 3.3. 1099 3.8.4 Other Header Fields in Gatewaying 1101 The gateway MUST ensure that all header fields of a message that it 1102 forwards into the Internet meet the requirements for Internet mail. In 1103 particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be 1104 transformed (if necessary) to satisfy RFC-822 syntax, MUST reference only 1105 fully-qualified domain names, and MUST be effective and useful for sending 1106 replies. 3.8.5 The translation algorithm used to convert mail from the 1107 Internet protocols to another environment's protocol SHOULD ensure that 1108 error messages from the foreign mail environment are delivered to the 1109 return path from the SMTP envelope, not to the sender listed in the "From:" 1110 field (or other fields) of the RFC-822 message. 1112 3.8.5 Envelopes in Gatewaying 1114 Similarly, when forwarding a message from another environment into the 1115 Internet, the gateway SHOULD set the envelope return path in accordance 1116 with an error message return address, if supplied by the foreign 1117 environment. If the foreign environment has no equivalent concept, the 1118 gateway must select and use a best approximation, with the message 1119 originator's address as the default of last resort. 1121 3.9 Terminating Sessions and Connections 1123 An SMTP connection is terminated when the client sends a QUIT command. The 1124 server responds with a positive reply code, after which it closes the 1125 connection. 1127 An SMTP server MUST NOT intentionally close the connection except: 1129 - After receiving a QUIT command and responding with a 221 reply. 1131 - After detecting the need to shutdown the SMTP service and returning a 1132 421 response code. This response code can be issued after the server 1133 receives any command or, if necessary, asynchronously from command 1134 receipt (on the assumption that the client will receive it after the 1135 next command is issued). 1137 In particular, a server that closes connections in response to commands 1138 that are not understood is in violation of this specification. Servers are 1139 expected to be tolerant of unknown commands, issuing a 500 reply and 1140 awaiting further instructions from the client. 1142 An SMTP server which is forcibly shut down via external means SHOULD 1143 attempt to send a line containing a 421 response code to the SMTP client 1144 before exiting. The SMTP client will normally read the 421 response code 1145 after sending its next command. 1147 SMTP clients that experience a connection close, reset, or other 1148 communications failure due to circumstances not under their control (in 1149 violation of the intent of this specification but sometimes unavoidable) 1150 SHOULD, to maintain the robustness of the mail system, treat the mail 1151 transaction as if a 451 response had been received and act accordingly. 1153 3.10 Mailing Lists and Aliases 1155 An SMTP-capable host SHOULD support both the alias and the list form of 1156 address expansion for multiple delivery. When a message is delivered or 1157 forwarded to each address of an expanded list form, the return address in 1158 the envelope ("MAIL FROM:") MUST be changed to be the address of a person 1159 or other entity who administers the list. However, in this case, the 1160 message header (see [MSGFMT]) MUST be left unchanged; in particular, the 1161 "From" field of the message header is unaffected. 1163 An important mail facility is a mechanism for multi-destination delivery of 1164 a single message, by transforming or "expanding" a pseudo-mailbox address 1165 into a list of destination mailbox addresses. When a message is sent to 1166 such a pseudo-mailbox (sometimes called an "exploder"), copies are 1167 forwarded or redistributed to each mailbox in the expanded list. We 1168 classify such a pseudo-mailbox as an "alias" or a "list", depending upon 1169 the expansion rules. 1171 3.10.1 Alias 1173 To expand an alias, the recipient mailer simply replaces the pseudo-mailbox 1174 address in the envelope with each of the expanded addresses in turn; the 1175 rest of the envelope and the message body are left unchanged. The message 1176 is then delivered or forwarded to each expanded address. 1178 3.10.2 List 1180 A mailing list may be said to operate by "redistribution" rather than by 1181 "forwarding". To expand a list, the recipient mailer replaces the 1182 pseudo-mailbox address in the envelope with each of the expanded addresses 1183 in turn. The return address in the envelope is changed so that all error 1184 messages generated by the final deliveries will be returned to a list 1185 administrator, not to the message originator, who generally has no control 1186 over the contents of the list and will typically find error messages 1187 annoying. 1189 4. The SMTP Specifications 1191 4.1 SMTP Commands 1193 4.1.1 Command Semantics and Syntax 1195 The SMTP commands define the mail transfer or the mail system function 1196 requested by the user. SMTP commands are character strings terminated by 1197 . The commands themselves are alphabetic characters terminated by 1198 if parameters follow and otherwise. (In the interest of 1199 improved interoperability, SMTP receivers are encouraged to tolerate 1200 trailing white space before the terminating .) The syntax of the 1201 local part of a mailbox must conform to receiver site conventions and the 1202 syntax specified in section 4.1.2. The SMTP commands are discussed below. 1203 The SMTP replies are discussed in section 4.2. 1205 A mail transaction involves several data objects which are communicated as 1206 arguments to different commands. The reverse-path is the argument of the 1207 MAIL command, the forward-path is the argument of the RCPT command, and the 1208 mail data is the argument of the DATA command. These arguments or data 1209 objects must be transmitted and held pending the confirmation communicated 1210 by the end of mail data indication which finalizes the transaction. The 1211 model for this is that distinct buffers are provided to hold the types of 1212 data objects, that is, there is a reverse-path buffer, a forward-path 1213 buffer, and a mail data buffer. Specific commands cause information to be 1214 appended to a specific buffer, or cause one or more buffers to be cleared. 1216 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) 1218 These commands are used to identify the SMTP client to the SMTP server. 1219 The argument field contains the fully-qualified domain name of the SMTP 1220 client if one is available. In situations in which the SMTP client system 1221 does not have a meaningful domain name (e.g., when its address is 1222 dynamically allocated and no reverse mapping record is available), the 1223 client SHOULD send an address literal (see section 4.1.3), optionally 1224 followed by information that will help to identify the client system. 1226 The SMTP server identifies itself to the SMTP client in the connection 1227 greeting reply and in the response to this command. 1229 A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If 1230 the SMTP server supports the SMTP service extensions it will give a 1231 successful response, a failure response, or an error response. If the SMTP 1232 server, in violation of this specification, does not support any SMTP 1233 service extensions it will generate an error response. Older client SMTP 1234 systems MAY, as discussed above, use HELO (as specified in RFC 821) instead 1235 of EHLO, and servers MUST support the HELO command and reply properly to 1236 it. In any event, a client MUST issue HELO or EHLO before starting a mail 1237 transaction. 1239 These commands, and a "250 OK" reply to one of them, confirm that both the 1240 SMTP client and the SMTP server are in the initial state, that is, there is 1241 no transaction in progress and all state tables and buffers are cleared. 1243 Normally, the response to EHLO will be a multiline reply. Each line of the 1244 response contains a keyword and, optionally, one or more parameters. The 1245 syntax for a positive response, using the ABNF notation and low-level 1246 terminals of [ABNF], is: 1248 ehlo-ok-rsp ::= "250" domain [ greeting ] 1249 / ( "250-" domain [ greeting ] 1250 *( "250-" ehlo-line ) 1251 "250" ehlo-line ) 1253 greeting ::= 1* 1255 ehlo-line ::= ehlo-keyword *( ehlo-param ) 1257 ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 1258 ; syntax and values depend on ehlo-keyword 1260 ehlo-param ::= 1* and all 1261 control characters (US-ASCII 0-31 1262 inclusive)> 1264 <> 1265 << (A through Z in upper case, and, >> 1266 << a through z in lower case) >> 1268 Although EHLO keywords may be specified in upper, lower, or mixed case, 1269 they MUST always be recognized and processed in a case-insensitive manner. 1270 This is simply an extension of practices specified in RFC 821 and section 1271 2.4.1. 1273 4.1.1.2 MAIL (MAIL) 1275 This command is used to initiate a mail transaction in which the mail data 1276 is delivered to one or more mailboxes. The argument field contains a 1277 reverse-path. 1279 The reverse-path consists of the sender mailbox or a list of hosts. In 1280 some types of reporting messages for which a reply is likely to cause a 1281 mail loop (for example, mail delivery and nondelivery notifications), the 1282 reverse-path may be null (see section 3.7). 1284 This command clears the reverse-path buffer, the forward-path buffer, and 1285 the mail data buffer; and inserts the reverse-path information from this 1286 command into the reverse-path buffer. 1288 If service extensions were negotiated, the MAIL command may also carry 1289 parameters associated with a particular service extension. 1291 Syntax: 1292 "MAIL FROM:" Reverse-path [ Mail-parameters ] 1293 or 1294 "MAIL FROM:<>" [ Mail-parameters ] 1296 4.1.1.3 RECIPIENT (RCPT) 1298 This command is used to identify an individual recipient of the mail data; 1299 multiple recipients are specified by multiple use of this command. 1301 The forward-path normally consists of the required destination mailbox or 1302 mailboxes. Sending systems SHOULD not generate the optional list of hosts 1303 known as a source route. Receiving systems MUST recognize source route 1304 syntax but SHOULD strip off the source route specification and utilize the 1305 domain name associated with the mailbox as if the source route had not been 1306 provided. 1308 Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST 1309 NOT be copied into the reverse-path. When mail reaches its ultimate 1310 destination (the forward-path contains only a destination mailbox), the 1311 SMTP server inserts it into the destination mailbox in accordance with its 1312 host mail conventions. 1314 For example, mail received at relay host xyz.com with envelope commands 1316 MAIL FROM: 1317 RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> 1319 will normally be sent directly on to host d.bar.org with envelope commands 1321 MAIL FROM: 1322 RCPT TO: 1324 As provided in appendix C, xyz.com MAY also choose to relay the message to 1325 jkl.org, using the envelope commands 1327 MAIL FROM: 1328 RCPT TO:<@jkl.org:userc@d.bar.org> 1330 Of course, since hosts are not required to relay mail at all, xyz.com may 1331 also reject the message entirely when the RCPT TO command is received, 1332 using a 550 code (since this is a "policy reason"). 1334 If service extensions were negotiated, the RCPT TO command may also carry 1335 parameters associated with a particular service extension offered by the 1336 server. The client MUST NOT transmit parameters other than those 1337 associated with a service extension offered by the server in its EHLO 1338 response. 1340 Syntax: 1341 "RCPT TO:" Forward-path [ Rcpt-parameters ] 1342 or 1343 "RCPT TO:" [ Rcpt-parameters ] 1345 4.1.1.4 DATA (DATA) 1347 The receiver treats the lines (strings ending in sequences, as 1348 described in section 2.3.7) following the command as mail data from the 1349 sender. This command causes the mail data to be appended to the mail data 1350 buffer. The mail data may contain any of the 128 ASCII character codes, 1351 although experience has indicated that use of control characters other than 1352 SP, HT, CR, and LF (especially the ASCII "Null" character) may cause 1353 problems and SHOULD be avoided when possible. 1355 The mail data is terminated by a line containing only a period, that is, 1356 the character sequence "." (see section 4.5.2). This is the 1357 end of mail data indication. Note that the first of this 1358 terminating sequence is also the that ends the final line of the 1359 data (message text) or, if there was no data, ends the DATA command itself. 1360 An extra MUST NOT be added, as that would cause an empty line to be 1361 added to the message. The only exception to this rule would arise if the 1362 message body were passed to the originating SMTP-sender with a final "line" 1363 that did not end in ; in that case, the originating SMTP system MUST 1364 either reject the message as invalid or add in order to have the 1365 receiving SMTP server recognize the "end of data" condition. 1367 The custom of accepting lines ending only in , as a concession to 1368 non-conforming behavior on the part of some UNIX systems, has proven to 1369 cause more interoperability problems than it solves, and SMTP server 1370 systems MUST NOT do this, even in the name of improved robustness. In 1371 particular, the sequence "." (bare line feeds, without carriage 1372 returns) MUST NOT be treated as equivalent to . as the end of 1373 mail data indication. 1375 Receipt of the end of mail data indication requires the server to process 1376 the stored mail transaction information. This processing consumes the 1377 information in the reverse-path buffer, the forward-path buffer, and the 1378 mail data buffer, and on the completion of this command these buffers are 1379 cleared. If the processing is successful, the receiver MUST send an OK 1380 reply. If the processing fails the receiver MUST send a failure reply. The 1381 SMTP model does not allow for partial failures at this point: either the 1382 message is accepted by the server for delivery and a positive response is 1383 returned or it is not accepted and a failure reply is returned. Errors 1384 that are diagnosed subsequently MUST be reported in a mail message, as 1385 discussed in section 4.4 In sending a positive completion reply to the end 1386 of data indication, the receiver takes full responsibility for the message 1387 (see section 6.1). 1389 When the SMTP server accepts a message either for relaying or for final 1390 delivery, it inserts a trace record (also referred to interchangeably as a 1391 "time stamp line" or "Received" line) at the top of the mail data. This 1392 trace record indicates the identity of the host that sent the message, the 1393 identity of the host that received the message (and is inserting this time 1394 stamp), and the date and time the message was received. Relayed messages 1395 will have multiple time stamp lines. Details for formation of these lines, 1396 including their syntax, is specified in section 4.4. 1398 4.1.1.5 RESET (RSET) 1400 This command specifies that the current mail transaction will be aborted. 1401 Any stored sender, recipients, and mail data MUST be discarded, and all 1402 buffers and state tables cleared. The receiver MUST send a "250 OK" reply 1403 to a RSET command with no arguments. A reset command may be issued by the 1404 client at any time. It is effectively equivalent to a NOOP if issued 1405 immediately after EHLO, before EHLO is issued in the session, after an 1406 end-of-data indicator has been sent and acknowledged, or immediately before 1407 a QUIT. In other situations, it restores the state to that immediately 1408 after the most recent EHLO. An SMTP server MUST NOT close the connection 1409 as the result of receiving a RSET; that action is reserved for QUIT (see 1410 section 4.1.1.10). 1412 Since EHLO implies some additional processing and response by the server, 1413 RSET will normally be more efficient than reissuing that command, even 1414 though the formal semantics are the same. 1416 There are circumstances, contrary to the intent of this specification, in 1417 which an SMTP server may receive an indication that the underlying TCP 1418 connection has been closed or reset. To preserve the robustness of the 1419 mail system, SMTP servers SHOULD be prepared for this condition and SHOULD 1420 treat it as if a QUIT had been received before the connection disappeared. 1422 Syntax: 1423 "RSET" 1425 4.1.1.6 VERIFY (VRFY) 1427 This command asks the receiver to confirm that the argument identifies a 1428 user or mailbox. If it is a user name, information is returned as 1429 specified in section 3.5. 1431 This command has no effect on the reverse-path buffer, the forward-path 1432 buffer, or the mail data buffer. 1434 Syntax: 1435 "VRFY" String 1437 4.1.1.7 EXPAND (EXPN) 1439 This command asks the receiver to confirm that the argument identifies a 1440 mailing list, and if so, to return the membership of that list. If the 1441 command is successful, a reply is returned containing information as 1442 described in section 3.5. This reply will have multiple lines except in 1443 the trivial case of a one-member list. 1445 This command has no effect on the reverse-path buffer, the forward-path 1446 buffer, or the mail data buffer. 1448 Syntax: 1449 "EXPN" String 1451 4.1.1.8 HELP (HELP) 1453 This command causes the server to send helpful information to the client. 1454 The command MAY take an argument (e.g., any command name) and return more 1455 specific information as a response. 1457 This command has no effect on the reverse-path buffer, the forward-path 1458 buffer, or the mail data buffer. 1460 SMTP servers SHOULD support HELP without arguments and MAY support it with 1461 arguments. 1463 Syntax: 1464 "HELP" [ String ] 1466 4.1.1.9 NOOP (NOOP) 1468 This command does not affect any parameters or previously entered commands. 1469 It specifies no action other than that the receiver send an OK reply. 1471 This command has no effect on the reverse-path buffer, the forward-path 1472 buffer, or the mail data buffer. 1474 Syntax: 1475 "NOOP" [ String ] 1477 4.1.1.10 QUIT (QUIT) 1479 This command specifies that the receiver MUST send an OK reply, and then 1480 close the transmission channel. 1482 The receiver MUST NOT intentionally close the transmission channel until it 1483 receives and replies to a QUIT command (even if there was an error). The 1484 sender MUST NOT intentionally close the transmission channel until it sends 1485 a QUIT command and receives the reply (even if there was an error response 1486 to a previous command). If the connection is closed prematurely due to 1487 violations of the above or system or network failure, the server MUST 1488 cancel any pending transaction, but not undo any previously completed 1489 transaction, and generally MUST act as if the command or transaction in 1490 progress had received a temporary error (i.e., a 4yz response). 1492 Syntax: 1493 "QUIT" 1495 4.1.2 Lower-level Syntax 1497 The syntax of the argument fields of the above commands (using the syntax 1498 specified in [ABNF] where applicable) is given below. Some of the 1499 productions given below are used only in conjunction with source routes as 1500 described in appendix C. Terminals not defined in this document, such as 1501 ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax 1502 (section 6) of [ABNF] or in the syntax of [MSGFMT]. 1504 Reverse-path = Path 1506 Forward-path = Path 1508 Path = "<" [ A-d-l ":" ] Mailbox ">" 1510 A-d-l = At-domain *( "," A-d-l ) ; Note that this form, the 1511 so-called "source route", MUST BE 1512 accepted, SHOULD NOT be generated, 1513 and SHOULD be ignored. 1515 At-domain = "@" Domain 1517 Mail-parameters = *( Keyword "=" Argument ) 1519 Rcpt-parameters = *( Keyword "=" Argument ) 1521 Keyword = Ldh-str 1522 Argument = Atom 1524 Domain = sub-domain 1*("." sub-domain) / address-literal 1526 sub-domain = let-dig *(Ldh-str) 1527 address-literal = "[" IPv4-address-literal / 1528 IPv6-address-literal / General-address-literal "]" 1529 IPv4-address-literal = snum 3*3("." snum) 1530 IPv6-address-literal = "IPv6" IPv6-addr-string 1531 IPv6-addr-string = String ; IPv6 address in standard form 1532 [IPv6AddrSpec]. Since this 1533 form uses colon characters, 1534 the String will actually need 1535 to be quoted in all cases. 1536 General-address-literal = Standardized-tag String 1537 Standardized-tag = Ldh-str ; Specified in a 1538 standards-track RFC 1539 and registered with IANA 1540 snum = 1*3Digit ; representing a decimal integer 1541 value in the range 0 through 255 1542 let-dig = Alpha / Digit 1543 ldh-str = *( Alpha / Digit / "-" ) let-dig 1545 Mailbox = Local-part "@" Domain 1547 Local-part = Dot-string / Quoted-string 1549 Dot-string = Atom [ "." Atom ] 1551 While the above definition for Local-part is relatively permissive, for 1552 maximum interoperability, a host that expects to receive mail SHOULD avoid 1553 defining mailboxes where the Local-part requires (or uses) the 1554 Quoted-string form or where the Local-part is case-sensitive. For any 1555 purposes that require generating or comparing Local-parts (e.g., to 1556 specific mailbox names), all quoted forms MUST be treated as equivalent and 1557 the sending system SHOULD transmit the form that uses the minimum quoting 1558 possible. 1560 Systems MUST NOT define mailboxes in such a way as to require the use of 1561 non-ASCII characters (octets with the high order bit set to one) or ASCII 1562 "control characters" (decimal value 0-31 and 127). These characters MUST 1563 NOT be used in MAIL FROM or RCPT TO commands or other commands that require 1564 mailbox names. 1566 String = Atom / Quoted-string 1568 special = <> / [[placeholder, see above]] 1569 the control characters (ASCII codes 0 through 31 1570 inclusive and 127) 1572 Note that the backslash, "\", is a quote character, which is used to 1573 indicate that the next character is to be used literally (instead of its 1574 normal interpretation). For example, "Joe\,Smith" indicates a single nine 1575 character user field with the comma being the fourth character of the 1576 field. 1578 Characters outside the set of alphas, digits, and hyphen MUST NOT appear in 1579 domain names. In particular, the underscore character is not permitted. 1580 SMTP servers that receive a command in which illegal character codes have 1581 been employed, and for which there are no other reasons for rejection, MUST 1582 reject that command with a 501 response. 1584 4.1.3 Address Literals 1586 Sometimes a host is not known to the domain name system and communication 1587 (and, in particular, communication to report and repair the error) is 1588 blocked. To bypass this barrier a special literal form of the address is 1589 allowed as an alternative to a domain name. For IPv4 addresses, this form 1590 uses four small decimal integers separated by dots and enclosed by brackets 1591 such as [123.255.37.2], which indicates an (IPv4) Internet Address in 1592 sequence-of-octets form. For IPv6 and other forms of addressing that might 1593 eventually be standardized, the form consists of a standardized "tag" that 1594 identifies the address syntax, a space, and the address itself, in a format 1595 specified as part of the IPv6 standards [IPv6AddrString]. 1597 4.1.4 Order of Commands 1599 There are restrictions on the order in which these commands may be used. 1601 A session that will contain mail transactions MUST first be initialized by 1602 the use of the EHLO command. An SMTP server SHOULD accept commands for 1603 non-mail transactions (e.g., VRFY or EXPN) without this initialization. 1605 An EHLO command MAY be issued by a client later in the session. If it is 1606 issued after the session begins, the SMTP server MUST clear all buffers and 1607 reset the state exactly as if a RSET command had been issued. In other 1608 words, the sequence of RSET followed immediately by EHLO is redundant, but 1609 not harmful other than in the performance cost of executing unnecessary 1610 commands. 1612 If the EHLO command is not acceptable to the SMTP server, 501, 500, or 502 1613 failure replies MUST be returned as appropriate. The SMTP server MUST stay 1614 in the same state after transmitting these replies that it was in before 1615 the EHLO was received. 1617 The SMTP client MUST ensure that the domain parameter to the EHLO command 1618 is a valid principal host name (not a CNAME or MX name) for its host. If 1619 this is not possible (e.g., when the client's address is dynamically 1620 assigned and the client does not have an obvious name), an address literal 1621 SHOULD be substituted for the domain name and supplemental information 1622 provided that will assist in identifying the client. 1624 An SMTP server MAY verify that the domain name parameter in the EHLO 1625 command actually corresponds to the IP address of the client. However, the 1626 server MUST NOT refuse to accept a message if the verification fails: the 1627 information about verification failure is for logging and tracing only. 1629 The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time 1630 during a session, or without previously initializing a session. SMTP 1631 servers SHOULD process these normally (that is, not return a 503 code) even 1632 if no EHLO command has yet been received; clients SHOULD open a session 1633 with EHLO before sending these commands. 1635 If these rules are followed, the example in RFC 821 that shows "550 access 1636 denied to you" in response to an EXPN command is incorrect unless an EHLO 1637 command precedes the EXPN or the denial of access is based on the client's 1638 IP address or other authentication or authorization-determining mechanisms. 1640 The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a 1641 mail transaction. Once started, a mail transaction consists of a 1642 transaction beginning command, one or more RCPT commands, and a DATA 1643 command, in that order. A mail transaction may be aborted by the RSET (or 1644 a new EHLO) command. There may be zero or more transactions in a session. 1646 If the transaction beginning command argument is not acceptable, a 501 1647 failure reply MUST be returned and the SMTP server MUST stay in the same 1648 state. If the commands in a transaction are out of order to the degree 1649 that they cannot be processed by the server, a 503 failure reply MUST be 1650 returned and the SMTP server MUST stay in the same state. 1652 The last command in a session MUST be the QUIT command. The QUIT command 1653 cannot be used at any other time in a session, but SHOULD be used by the 1654 client SMTP to request connection closure, even when no session opening 1655 command was sent and accepted. 1657 4.1.5 Private-use Commands 1659 As specified in section 2.2.2, commands starting in "X" may be used by 1660 bilateral agreement between the client (sending) and server (receiving) 1661 SMTP agents. An SMTP server that does not recognize such a command is 1662 expected to reply with "500 Command not recognized". An extended SMTP 1663 server MAY list the feature names associated with these private commands in 1664 the response to the EHLO command. 1666 Commands sent or accepted by SMTP systems that do not start with "X" MUST 1667 conform to the requirements of section 2.2.2. 1669 4.2 SMTP Replies 1671 Replies to SMTP commands serve to ensure the synchronization of requests 1672 and actions in the process of mail transfer and to guarantee that the SMTP 1673 client always knows the state of the SMTP server. Every command MUST 1674 generate exactly one reply. 1676 The details of the command-reply sequence are described in section 4.3. 1678 An SMTP reply consists of a three digit number (transmitted as three 1679 alphanumeric characters) followed by some text. The number is for use by 1680 automata to determine what state to enter next; the text is for the human 1681 user. The three digits contain enough encoded information that the SMTP 1682 client need not examine the text and may either discard it or pass it on to 1683 the user, as appropriate. Exceptions are as noted elsewhere in this 1684 document. In particular, the 220, 221, 251, 421, and 551 reply codes are 1685 associated with message text that must be parsed and interpreted by 1686 machines. In the general case, the text may be receiver dependent and 1687 context dependent, so there are likely to be varying texts for each reply 1688 code. A discussion of the theory of reply codes is given in section 4.2.1. 1689 Formally, a reply is defined to be the sequence: a three-digit code, , 1690 one line of text, and , or a multiline reply (as defined in section 1691 4.2.1). Only the EHLO, EXPN, and HELP commands are expected to result in 1692 multiline replies in normal circumstances, however, multiline replies are 1693 allowed for any command. 1695 In ABNF, server responses are: 1697 Greeting = "220 " Domain [ SP text ] CRLF 1698 Reply-line = Reply-code [ SP text ] CRLF 1700 where "Greeting" appears only in the 220 response that announces that the 1701 server is opening its part of the connection. 1703 An SMTP server SHOULD send only the reply codes listed in this document. 1704 An SMTP server SHOULD use the text shown in the examples whenever 1705 appropriate. 1707 An SMTP client MUST determine its actions only by the reply code, not by 1708 the text (except for 251 and 551 and, if necessary, 220, 221, and 421 1709 replies); in the general case, any text, including no text at all (although 1710 senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank) 1711 following the reply code is considered part of the text. Whenever 1712 possible, a sender-SMTP SHOULD test the first digit (severity indication) 1713 of the reply code. 1715 The list of codes that appears below must not be construed as permanent. 1716 While the addition of new codes should be a rare and significant activity, 1717 with supplemental information in the textual part of the response being 1718 preferred, new codes may be added as the result of new Standards or 1719 Standards-track specifications. Consequently, a sender-SMTP MUST be 1720 prepared to handle codes not specified in this document and MUST do so by 1721 interpreting the first digit only. 1723 4.2.1 Reply Code Severities and Theory 1725 The three digits of the reply each have a special significance. The first 1726 digit denotes whether the response is good, bad or incomplete. An 1727 unsophisticated SMTP client, or one that receives an unexpected code, will 1728 be able to determine its next action (proceed as planned, redo, retrench, 1729 etc.) by examining this first digit. An SMTP client that wants to know 1730 approximately what kind of error occurred (e.g., mail system error, command 1731 syntax error) may examine the second digit. The third digit and any 1732 supplemental information that may be present is reserved for the finest 1733 gradation of information. 1735 There are five values for the first digit of the reply code: 1737 1yz Positive Preliminary reply 1738 The command has been accepted, but the requested action is being held in 1739 abeyance, pending confirmation of the information in this reply. The 1740 SMTP client should send another command specifying whether to continue 1741 or abort the action. Note: unextended SMTP does not have any commands 1742 that allow this type of reply, and so does not have continue or abort 1743 commands. 1745 2yz Positive Completion reply 1746 The requested action has been successfully completed. A new request may 1747 be initiated. 1749 3yz Positive Intermediate reply 1750 The command has been accepted, but the requested action is being held in 1751 abeyance, pending receipt of further information. The SMTP client 1752 should send another command specifying this information. This reply is 1753 used in command sequence groups (i.e., in DATA). 1755 4yz Transient Negative Completion reply 1756 The command was not accepted, and the requested action did not occur. 1757 However, the error condition is temporary and the action may be 1758 requested again. The sender should return to the beginning of the 1759 command sequence (if any). It is difficult to assign a meaning to 1760 "transient" when two different sites (receiver- and sender- SMTP agents) 1761 must agree on the interpretation. Each reply in this category might have 1762 a different time value, but the SMTP client is encouraged to try again. 1763 A rule of thumb to determine whether a reply fits into the 4yz or the 1764 5yz category (see below) is that replies are 4yz if they can be 1765 successful if repeated without any change in command form or in 1766 properties of the sender or receiver. (that is, the command is repeated 1767 identically and the receiver does not put up a new implementation.) 1769 5yz Permanent Negative Completion reply 1770 The command was not accepted and the requested action did not occur. 1771 The SMTP client is discouraged from repeating the exact request (in the 1772 same sequence). Even some "permanent" error conditions can be 1773 corrected, so the human user may want to direct the SMTP client to 1774 reinitiate the command sequence by direct action at some point in the 1775 future (e.g., after the spelling has been changed, or the user has 1776 altered the account status). 1778 The second digit encodes responses in specific categories: 1780 x0z Syntax: These replies refer to syntax errors, syntactically correct 1781 commands that don't fit any functional category, and unimplemented or 1782 superfluous commands. 1784 x1z Information: These are replies to requests for information, such as 1785 status or help. 1787 x2z Connections: These are replies referring to the transmission channel. 1789 x3z Unspecified. 1791 x4z Unspecified. 1793 x5z Mail system: These replies indicate the status of the receiver mail 1794 system vis-a-vis the requested transfer or other mail system action. 1796 The third digit gives a finer gradation of meaning in each category 1797 specified by the second digit. The list of replies illustrates this. Each 1798 reply text is recommended rather than mandatory, and may even change 1799 according to the command with which it is associated. On the other hand, 1800 the reply codes must strictly follow the specifications in this section. 1801 Receiver implementations should not invent new codes for slightly different 1802 situations from the ones described here, but rather adapt codes already 1803 defined. 1805 For example, a command such as NOOP, whose successful execution does not 1806 offer the SMTP client any new information, will return a 250 reply. The 1807 reply is 502 when the command requests an unimplemented non-site-specific 1808 action. A refinement of that is the 504 reply for a command that is 1809 implemented, but that requests an unimplemented parameter. 1811 The reply text may be longer than a single line; in these cases the 1812 complete text must be marked so the SMTP client knows when it can stop 1813 reading the reply. This requires a special format to indicate a multiple 1814 line reply. 1816 The format for multiline replies requires that every line, except the last, 1817 begin with the reply code, followed immediately by a hyphen, "-" (also 1818 known as minus), followed by text. The last line will begin with the reply 1819 code, followed immediately by , optionally some text, and . As 1820 noted above, servers SHOULD send the if subsequent text is not sent, 1821 but clients MUST be prepared for it to be omitted. 1823 For example: 1824 123-First line 1825 123-Second line 1826 123-234 text beginning with numbers 1827 123 The last line 1829 In many cases the SMTP client then simply needs to search for the reply 1830 code followed by at the beginning of a line, and ignore all preceding 1831 lines. In a few cases, there is important data for the sender in the reply 1832 "text". The sender will be able to identify these cases from the current 1833 context. 1835 4.2.2 Reply Codes by Function Groups 1837 500 Syntax error, command unrecognized 1838 (This may include errors such as command line too long) 1839 501 Syntax error in parameters or arguments 1840 502 Command not implemented (see section 4.2.4) 1841 503 Bad sequence of commands 1842 504 Command parameter not implemented 1844 211 System status, or system help reply 1845 214 Help message 1846 (Information on how to use the receiver or the meaning of a 1847 particular non-standard command; this reply is useful only 1848 to the human user) 1850 220 Service ready 1851 221 Service closing transmission channel 1852 421 Service not available, closing transmission channel 1853 (This may be a reply to any command if the service knows it 1854 must shut down) 1856 250 Requested mail action okay, completed 1857 251 User not local; will forward to 1858 (See section 3.4) 1859 252 Cannot VRFY user, but will accept message and attempt 1860 delivery 1861 (See section 3.5.3) 1862 450 Requested mail action not taken: mailbox unavailable 1863 (e.g., mailbox busy) 1864 550 Requested action not taken: mailbox unavailable 1865 (e.g., mailbox not found, no access, or command rejected 1866 for policy reasons) 1867 451 Requested action aborted: error in processing 1868 551 User not local; please try 1869 (See section 3.4) 1870 452 Requested action not taken: insufficient system storage 1871 552 Requested mail action aborted: exceeded storage allocation 1872 553 Requested action not taken: mailbox name not allowed 1873 (e.g., mailbox syntax incorrect) 1874 571 Address not accepted for policy reasons 1875 354 Start mail input; end with . 1876 554 Transaction failed (Or, in the case of a connection-opening 1877 response, "No SMTP service here") 1879 4.2.3 Reply Codes in Numeric Order 1881 211 System status, or system help reply 1882 214 Help message 1883 (Information on how to use the receiver or the meaning of a 1884 particular non-standard command; this reply is useful only 1885 to the human user) 1886 220 Service ready 1887 221 Service closing transmission channel 1888 250 Requested mail action okay, completed 1889 251 User not local; will forward to 1890 (See section 3.4) 1891 252 Cannot VRFY user, but will accept message and attempt 1892 delivery 1893 (See section 3.5.3) 1895 354 Start mail input; end with . 1897 421 Service not available, closing transmission channel 1898 (This may be a reply to any command if the service knows it 1899 must shut down) 1900 450 Requested mail action not taken: mailbox unavailable 1901 (e.g., mailbox busy) 1902 451 Requested action aborted: local error in processing 1903 452 Requested action not taken: insufficient system storage 1905 500 Syntax error, command unrecognized 1906 (This may include errors such as command line too long) 1907 501 Syntax error in parameters or arguments 1908 502 Command not implemented (see section 4.2.4) 1909 503 Bad sequence of commands 1910 504 Command parameter not implemented 1911 550 Requested action not taken: mailbox unavailable 1912 (e.g., mailbox not found, no access, or command rejected 1913 for policy reasons) 1914 551 User not local; please try 1915 (See section 3.4) 1916 552 Requested mail action aborted: exceeded storage allocation 1917 553 Requested action not taken: mailbox name not allowed 1918 (e.g., mailbox syntax incorrect) 1919 554 Transaction failed (Or, in the case of a connection-opening 1920 response, "No SMTP service here") 1921 571 Address not accepted for policy reasons 1923 4.2.4 Reply Code 502 1925 Questions have been raised as to when reply code 502 (Command not 1926 implemented) SHOULD be returned in preference to other codes. 502 SHOULD 1927 be used when the command is actually recognized by the SMTP server, but not 1928 implemented. If the command is not recognized, code 500 SHOULD be 1929 returned. Extended SMTP systems MUST NOT list capabilities in response to 1930 EHLO for which they will return 502 (or 500) replies. 1932 4.2.5 Reply Codes After DATA and the Subsequent . 1934 When an SMTP server returns a positive completion status (2yz code) after 1935 the DATA command is completed with ., it accepts responsibility 1936 for: 1938 - delivering the message (if the recipient mailbox exists), or 1940 - if attempts to deliver the message fail due to transient conditions, 1941 retrying delivery some reasonable number of times at intervals as 1942 specified in section 4.5.4. 1944 - if attempts to deliver the message fail due to permanent conditions, or 1945 if repeated attempts to deliver the message fail due to transient 1946 conditions, returning appropriate notification to the sender of the 1947 original message (using the address in the SMTP MAIL FROM command). 1949 When an SMTP server returns a transient error completion status (4yz) code 1950 after the DATA command is completed with ., it MUST NOT make 1951 any further attempt to deliver that message. The SMTP client retains 1952 responsibility for delivery of that message and may either return it to the 1953 user or requeue it for a subsequent attempt (see section 4.5.4.1). The 1954 sending user SHOULD be able to interpret the return of a transient or 1955 permanent failure status as a non-delivery indication. 1957 4.3 Sequencing of Commands and Replies 1959 4.3.1 Sequencing Overview 1961 The communication between the sender and receiver is an alternating 1962 dialogue, controlled by the sender. As such, the sender issues a command 1963 and the receiver responds with a reply. Unless other arrangements are 1964 negotiated through service extensions, the sender MUST wait for this 1965 response before sending further commands. 1967 One important reply is the connection greeting. Normally, a receiver will 1968 send a 220 "Service ready" reply when the connection is completed. The 1969 sender SHOULD wait for this greeting message before sending any commands. 1971 Note: all the greeting-type replies have the official name (the 1972 fully-qualified primary domain name) of the server host as the first word 1973 following the reply code. Sometimes the host will have no meaningful name. 1974 See 4.1.3 for a discussion of alternatives in these situations. 1976 For example, 1977 220 ISIF.USC.EDU Service ready 1978 or 1979 220 mail.foo.com SuperSMTP v 6.1.2 Service ready 1980 or 1981 220 [10.0.0.1] Clueless host service ready 1983 The table below lists alternative success and failure replies for each 1984 command. These SHOULD be strictly adhered to: a receiver may substitute 1985 text in the replies, but the meaning and action implied by the code numbers 1986 and by the specific command reply sequence cannot be altered. 1988 4.3.2 Command-Reply Sequences 1990 Each command is listed with its usual possible replies. The prefixes used 1991 before the possible replies are "I" for intermediate, "S" for success, and 1992 "E" for error. Since some servers may generate other replies under special 1993 circumstances, and to allow for future extension, SMTP clients SHOULD, when 1994 possible, interpret only the first digit of the reply and MUST be prepared 1995 to deal with unrecognized reply codes by interpreting the first digit only. 1996 Unless extended using the mechanisms described in section 2.2, SMTP servers 1997 MUST NOT transmit reply codes to an SMTP client that are other than three 1998 digits or that do not start in a digit between 2 and 5 inclusive. 2000 These sequencing rules and, in principle, the codes themselves, can be 2001 extended or modified by SMTP extensions offered by the server and accepted 2002 (requested) by the client. 2004 In addition to the codes listed below, any SMTP command can return any of 2005 the following codes if the corresponding unusual circumstances are 2006 encountered: 2008 500 For the "command line too long" case or if the command name was not 2009 recognized. Note that producing a "command not recognized" error in 2010 response to the required subset of these commands is a violation of this 2011 specification. 2013 501 Syntax error in command or arguments. In order to provide for future 2014 extensions, commands that are specified in this document as not 2015 accepting arguments (DATA, NOOP, RSET) SHOULD return a 501 message if 2016 arguments are supplied in the absence of EHLO-advertised extensions. 2018 421 Service shutting down and closing transmission channel 2020 Specific sequences are: 2022 CONNECTION ESTABLISHMENT 2023 S: 220 2024 E: 554 2025 EHLO or HELO 2026 S: 250 2027 E: 504, 550 2028 MAIL 2029 S: 250 2030 E: 552, 451, 452, 550, 553 2031 RCPT 2032 S: 250, 251 (but see section 3.4 for discussion of 251) 2033 E: 550, 551, 552, 553, 450, 451, 452, 503, 550 2034 DATA 2035 I: 354 -> data -> S: 250 2036 E: 552, 554, 451, 452 2037 E: 451, 554, 503 2038 RSET 2039 S: 250 2040 VRFY 2041 S: 250, 251, 252 2042 E: 550, 551, 553, 502, 504 2043 EXPN 2044 S: 250, 252 2045 E: 550, 500, 502, 504 2046 HELP 2047 S: 211, 214 2048 E: 502, 504 2049 NOOP 2050 S: 250 2051 QUIT 2052 S: 221 2054 4.4 Trace Information 2056 When an SMTP server receives a message for delivery or further processing, 2057 it MUST insert trace ("time stamp" or "Received") information at the 2058 beginning of the message content, as discussed in section 4.1.1.4. 2060 This line MUST be structured as follows: 2062 - The FROM field, which MUST be supplied in an SMTP environment, SHOULD 2063 contain both (1) the name of the source host as presented in the EHLO 2064 command and (2) an address literal containing the IP address of the 2065 source, determined from the TCP connection. 2067 - The ID field MAY contain an "@" as suggested in RFC-822, but this is not 2068 required. 2070 - The FOR field MAY contain a list of entries when multiple RCPT 2071 commands have been given. This may raise some security issues and is 2072 usually not desirable; see section 7.2. 2074 An Internet mail program MUST NOT change a Received: line that was 2075 previously added to the message header. SMTP servers MUST prepend Received 2076 lines to messages; they MUST NOT change the order of existing lines or 2077 insert Received lines in any other location. 2079 As the Internet grows, comparability of Received fields is important for 2080 detecting problems, especially slow relays. SMTP servers that create 2081 Received fields SHOULD use explicit offsets in the dates (e.g., -0800), 2082 rather than time zone names of any type. Local time (with an offset) is 2083 preferred to UT when feasible. This formulation allows slightly more 2084 information about local circumstances to be specified. If UT is needed, 2085 the receiver need merely do some simple arithmetic to convert the values. 2086 Use of UT loses information about the time zone-location of the server. If 2087 a time zone name is used, it SHOULD be included in a comment. 2089 When the delivery SMTP server makes the "final delivery" of a message, it 2090 inserts a return-path line at the beginning of the mail data. This use of 2091 return-path is required; mail systems MUST support it. The return-path 2092 line preserves the information in the from the MAIL command. 2093 Here, final delivery means the message has left the SMTP world. Normally, 2094 this would mean it had been delivered to the destination user or an 2095 associated mail drop, but in some cases it may be further processed and 2096 transmitted by another mail system. 2098 It is possible for the mailbox in the return path to be different from the 2099 actual sender's mailbox, for example, if error responses are to be 2100 delivered to a special error handling mailbox rather than to the message 2101 sender. When mailing lists are involved, this arrangement is common and 2102 useful as a means of directing errors to the list maintainer rather than 2103 the message originator. 2105 The text above implies that the final mail data will begin with a return 2106 path line, followed by one or more time stamp lines. These lines will be 2107 followed by the mail data headers and body [RFC-822]. 2109 It is sometimes difficult for an SMTP server to determine whether or not it 2110 is making final delivery since forwarding or other operations may occur 2111 after the message is accepted for delivery. Consequently, any further 2112 (forwarding, gateway, or relay) systems MAY remove the return path and 2113 rebuild the MAIL FROM command as needed to ensure that exactly one such 2114 line appears in a delivered message. 2116 A message-originating SMTP system SHOULD NOT send a message that already 2117 contains a Return-path header. SMTP servers performing a relay function 2118 MUST NOT inspect the message data, and especially not to the extent needed 2119 to determine if Return-path headers are present. SMTP servers making final 2120 delivery MAY remove Return-path headers before adding their own. 2122 The primary purpose of the Return-path is to designate the address to which 2123 messages indicating non-delivery or other mail system failures are to be 2124 sent. For this to be unambiguous, exactly one return path SHOULD be 2125 present when the message is delivered. Systems using RFC 822 syntax with 2126 non-SMTP transports SHOULD designate an unambiguous address, associated 2127 with the transport envelope, to which error reports (e.g., non-delivery 2128 messages) should be sent. 2130 Historical note: Text in RFC 822 that appears to contradict the use of the 2131 Return-path header (or the envelope MAIL FROM address) as the destination 2132 for error messages is not applicable on the Internet. The MAIL FROM address 2133 (as copied into the Return-path) MUST be used as the target of any mail 2134 containing delivery error messages. 2136 In particular: 2138 - a gateway from SMTP->elsewhere SHOULD insert a return-path header, 2139 unless it is known that the "elsewhere" transport also uses Internet 2140 domain addresses and maintains the envelope sender address separately. 2142 - a gateway from elsewhere->SMTP SHOULD delete any return-path header 2143 present in the message, and either copy that information to the SMTP 2144 envelope or combine it with information present in the envelope of the 2145 other transport system to construct the MAIL FROM part of the SMTP 2146 envelope. 2148 The server must give special treatment to cases in which the processing 2149 following the end of mail data indication is only partially successful. 2150 This could happen if, after accepting several recipients and the mail data, 2151 the SMTP server finds that the mail data could be successfully delivered to 2152 some, but not all, of the recipients. In such cases, the response to the 2153 DATA command MUST be an OK reply. However, the SMTP server MUST compose 2154 and send an "undeliverable mail" notification message to the originator of 2155 the message. 2157 A single notification listing all of the failed recipients or separate 2158 notification messages MUST be sent for each failed recipient. For economy 2159 of processing by the sender, the former is preferred when possible. All 2160 undeliverable mail notification messages are sent using the MAIL command 2161 (even if they result from processing the obsolete SEND, SOML, or SAML 2162 commands) and use a null return path as discussed in section 3.7. 2164 The time stamp line and the return path line are formally defined as 2165 follows: 2167 Return-path-line = "Return-Path:" FWS Reverse-path 2169 Time-stamp-line = "Received:" FWS Stamp 2171 Stamp = From-domain By-domain Opt-info ";" FWS Daytime 2173 From-domain = "FROM" FWS Extended-Domain CFWS 2175 By-domain = "BY" FWS Extended-Domain CFWS 2177 Extended-Domain = Domain / 2178 ( Domain FWS "(" TCP-info ")" ) / 2179 ( Address-literal FWS "(" TCP-info ")" 2180 TCP-info = Address-literal / ( Domain FWS Address-literal ) 2181 ; Information derived by server from TCP connection, not client EHLO. 2183 Opt-info = [Via] [With] [ID] [For] 2185 Via = "VIA" FWS Link CFWS 2187 With = "WITH" FWS Protocol CFWS 2189 ID = "ID" FWS String / msg-id CFWS 2191 For = "FOR" FWS 1*( Path / Mailbox ) CFWS 2193 Link = <<>> / Addtl-Link 2194 Addtl-Link = Atom ; Additional standard names for links are 2195 registered with the Internet Assigned 2196 Numbers Authority (IANA). 2197 SMTP servers SHOULD NOT use unregistered 2198 names. 2199 Protocol = "ESMTP" / "SMTP" / Attdl-Protocol 2200 Attdl-Protocol = Atom ; Additional standard names for protocols 2201 are registered with the Internet Assigned 2202 Numbers Authority (IANA). SMTP servers 2203 SHOULD NOT use unregistered names. 2205 Daytime = FWS [ day-of-week "," FWS ] Date FWS Time 2207 Date = DD FWS Mon FWS YYYY 2208 ; Note that the earlier form, which permits two-digit years, has 2209 been deprecated. SMTP systems MUST use four-digit years. 2211 Time = HH ":" MM ":" SS FWS Zone 2213 DD = 1*2Digit ; the one or two digit integer day of the 2214 month in the range 1 to 31. 2216 Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | 2217 "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" 2219 YYYY = 4*4Digit ; the four decimal integer year in the range 2220 0000 to 9999. 2222 HH = 2*2Digit ; the two decimal digit hour of the day in 2223 the range 00 to 24. 2225 MM = 2*2Digit ; the two decimal digit integer minute of the hour 2226 in the range 00 to 59. 2228 SS = 2*2Digit [ "." 1*Digit ] 2229 ; the two decimal digit integer second of the 2230 minute in the range 00 to 59, with 2231 optional fractional seconds. 2233 Zone = ( "+" / "-" ) 4*4Digit [ "(" String ")" ] 2234 ; A four digit, signed time zone offset, 2235 such as -0500 for US Eastern Standard 2236 Time. This may be supplemented by a time 2237 zone name in parentheses, e.g., "-0800 2238 (PDT)". Note that there is no default; 2239 time zone information is required and 2240 MUST be supplied. 2242 4.5 Additional Implementation Issues 2244 4.5.1 Minimum Implementation 2246 In order to make SMTP workable, the following minimum implementation is 2247 required for all receivers. The following commands MUST be supported to 2248 conform to this specification: 2249 EHLO 2250 HELO 2251 VRFY 2252 MAIL 2253 RCPT 2254 DATA 2255 RSET 2256 NOOP 2257 QUIT 2259 Any system that includes an SMTP server supporting mail relaying or 2260 delivery MUST support the reserved mailbox "postmaster" as a 2261 case-insensitive local name. This postmaster address is not strictly 2262 necessary if the server always returns 554 on connection opening (as 2263 described in section 3.1). The requirement to accept mail for postmaster 2264 implies that RCPT TO commands which specify a mailbox for postmaster at any 2265 of the domains for which the SMTP server provides mail service, as well as 2266 the special case of "RCPT TO:" (with no domain specification), 2267 MUST be supported. This requirement does not imply that SMTP systems must 2268 deliver Postmaster mail in particular cases (e.g., problematic origin 2269 addresses) in which they have substantive reasons for not doing so. 2271 4.5.2 Transparency 2273 Without some provision for data transparency, the character sequence 2274 "." ends the mail text and cannot be sent by the user. In 2275 general, users are not aware of such "forbidden" sequences. To allow all 2276 user composed text to be transmitted transparently, the following 2277 procedures are used: 2279 - Before sending a line of mail text, the SMTP client checks the first 2280 character of the line. If it is a period, one additional period is 2281 inserted at the beginning of the line. 2283 - When a line of mail text is received by the SMTP server, it checks the 2284 line. If the line is composed of a single period, it is treated as the 2285 end of mail indicator. If the first character is a period and there are 2286 other characters on the line, the first character is deleted. 2288 The mail data may contain any of the 128 ASCII characters. All characters 2289 are to be delivered to the recipient's mailbox, including spaces, vertical 2290 and horizontal tabs, and other control characters. If the transmission 2291 channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes 2292 are transmitted right justified in the octets, with the high order bits 2293 cleared to zero. See 3.7 for special treatment of these conditions in SMTP 2294 systems serving a relay function. 2296 In some systems it may be necessary to transform the data as it is received 2297 and stored. This may be necessary for hosts that use a different character 2298 set than ASCII as their local character set or store data in records rather 2299 than strings. If such transformations are necessary, they MUST be 2300 reversible, especially if such transformations are applied to mail being 2301 relayed. 2303 4.5.3 Sizes and Timeouts 2305 There are several objects that have required minimum/maximum sizes. Every 2306 implementation MUST be able to receive objects of at least these sizes. 2307 Objects larger than these sizes SHOULD be avoided when possible. However, 2308 some Internet mail constructs such as encoded X.400 addresses [RFC-X400] 2309 will often require larger objects: clients MAY attempt to transmit these, 2310 but MUST be prepared for a server to reject them if they cannot be handled 2311 by it. To the maximum extent possible, implementation techniques which 2312 impose no limits on the length of these objects should be used. 2314 local-part 2315 The maximum total length of a user name or other local-part is 64 2316 characters. 2318 domain 2319 The maximum total length of a domain name or number is 255 characters. 2321 path 2322 The maximum total length of a reverse-path or forward-path is 256 2323 characters (including the punctuation and element separators). 2325 command line 2326 The maximum total length of a command line including the command word 2327 and the is 512 characters. SMTP extensions may be used to 2328 increase this limit. 2330 reply line 2331 The maximum total length of a reply line including the reply code and 2332 the is 512 characters. More information may be conveyed through 2333 multiple-line replies. 2335 text line 2336 The maximum total length of a text line including the is 1000 2337 characters (not counting the leading dot duplicated for transparency). 2338 This number may be increased by the use of SMTP Service Extensions. 2340 message content 2341 The maximum total length of a message content (including any message 2342 headers as well as the message body) MUST BE at least 64K octets. Since 2343 the introduction of multimedia mail [RFC-MIME], message lengths on the 2344 Internet have grown dramatically, and message size restrictions should 2345 be avoided if at all possible. SMTP server systems that must impose 2346 restrictions SHOULD implement the "SIZE" service extension ([RFC-SIZE]), 2347 and SMTP client systems that will send large messages SHOULD utilize it 2348 when possible. 2350 recipients buffer 2351 The minimum total number of recipients that must be buffered is 100 2352 recipients. Rejection of messages (for excessive recipients) with fewer 2353 than 100 RCPT TO commands is a violation of this specification. The 2354 general principle that relaying SMTP servers MUST NOT, and delivery SMTP 2355 servers SHOULD NOT, perform validation tests on message headers suggests 2356 that rejecting a message based on the total number of recipients shown 2357 in header fields is to be discouraged. A server which imposes a limit 2358 on the number of recipients MUST behave in an orderly fashion, such as 2359 to reject additional addresses over its limit rather than silently 2360 discarding addresses previously accepted. A client that needs to 2361 deliver a message containing over 100 RCPT TO commands SHOULD be 2362 prepared to transmit in 100-recipient "chunks" if the server declines to 2363 accept more than 100 recipients in a single message. 2365 Errors due to exceeding these limits may be reported by using the reply 2366 codes. Some examples of reply codes are: 2368 500 Line too long. 2369 or 2370 501 Path too long 2371 or 2372 452 Too many recipients (see below) 2373 or 2374 552 Too much mail data. 2376 [RFC-821] incorrectly listed the error where an SMTP server exhausts its 2377 implementation limit on the number of RCPT TO commands ("too many 2378 recipients") as having reply code 552. The correct reply code for this 2379 condition is 452. Clients SHOULD treat a 552 code in this case as a 2380 temporary, rather than permanent failure so the logic below works. 2382 When a conforming SMTP server encounters this condition, it has at least 2383 100 successful RCPT commands in its recipients buffer. If the server is 2384 able to accept the message, then at least these 100 addresses will be 2385 removed from the SMTP client's queue. When the client attempts 2386 retransmission of those addresses which received 452 responses, at least 2387 100 of these will be able to fit in the SMTP server's recipients buffer. 2388 Each retransmission attempt which is able to deliver anything will be able 2389 to dispose of at least 100 of these recipients. 2391 If an SMTP server has an implementation limit on the number of RCPT TO 2392 commands and this limit is exhausted, it MUST use a response code of 452. 2393 If the server has a configured site-policy limitation on the number of RCPT 2394 TO commands, it MAY instead use a 5XX response code. 2396 In order to interoperate with SMTP servers implementing an older version of 2397 the protocol, SMTP clients MAY treat a 552 code obtained in response to an 2398 RCPT command as if it were a 452 response code, especially after some RCPT 2399 commands have already been accepted in the same mail transaction. 2401 An SMTP client MUST provide a timeout mechanism. It MUST use per-command 2402 timeouts rather than somehow trying to time the entire mail transaction. 2403 Timeouts SHOULD be easily reconfigurable, preferably without recompiling 2404 the SMTP code. To implement this, a timer is set for each SMTP command and 2405 for each buffer of the data transfer. The latter means that the overall 2406 timeout is inherently proportional to the size of the message. 2408 Based on extensive experience with busy mail-relay hosts, the minimum 2409 per-command timeout values SHOULD be as follows: 2411 Initial 220 Message: 5 minutes 2412 An SMTP client process needs to distinguish between a failed TCP 2413 connection and a delay in receiving the initial 220 greeting message. 2414 Many SMTP servers accept a TCP connection but delay delivery of the 220 2415 message until their system load permits more mail to be processed. 2417 MAIL Command: 5 minutes 2419 RCPT Command: 5 minutes 2420 A longer timeout is required if processing of mailing lists and aliases 2421 is not deferred until after the message was accepted. 2423 DATA Initiation: 2 minutes 2424 This is while awaiting the "354 Start Input" reply to a DATA command. 2426 Data Block: 3 minutes 2427 This is while awaiting the completion of each TCP SEND call transmitting 2428 a chunk of data. 2430 DATA Termination: 10 minutes. 2431 This is while awaiting the "250 OK" reply. When the receiver gets the 2432 final period terminating the message data, it typically performs 2433 processing to deliver the message to a user mailbox. A spurious timeout 2434 at this point would be very wasteful and would typically result in 2435 delivery of multiple copies of the message, since it has been 2436 successfully sent and the server has accepted responsibility for 2437 delivery. See section 6.1 for additional discussion. 2439 An SMTP server SHOULD have a timeout of at least 5 minutes while it is 2440 awaiting the next command from the sender. 2442 4.5.4 Queuing Strategies 2444 The common structure of a host SMTP implementation includes user mailboxes, 2445 one or more areas for queuing messages in transit, and one or more daemon 2446 processes for sending and receiving mail. The exact structure will vary 2447 depending on the needs of the users on the host and the number and size of 2448 mailing lists supported by the host. We describe several optimizations that 2449 have proved helpful, particularly for mailers supporting high traffic 2450 levels. 2452 Any queuing strategy MUST include timeouts on all activities on a 2453 per-command basis. A queuing strategy MUST never send error messages in 2454 response to error messages. 2456 4.5.4.1 Sending Strategy 2458 The general model for an SMTP client is one or more processes that 2459 periodically attempt to transmit outgoing mail. In a typical system, the 2460 program that composes a message has some method for requesting immediate 2461 attention for a new piece of outgoing mail, while mail that cannot be 2462 transmitted immediately MUST be queued and periodically retried by the 2463 sender. A mail queue entry will include not only the message itself but 2464 also the envelope information. 2466 The sender MUST delay retrying a particular destination after one attempt 2467 has failed. In general, the retry interval SHOULD be at least 30 minutes; 2468 however, more sophisticated and variable strategies will be beneficial when 2469 the SMTP client can determine the reason for non-delivery. 2471 Retries continue until the message is transmitted or the sender gives up; 2472 the give-up time generally needs to be at least 4-5 days. The parameters 2473 to the retry algorithm MUST be configurable. 2475 A client SHOULD keep a list of hosts it cannot reach and corresponding 2476 connection timeouts, rather than just retrying queued mail items. 2478 Experience suggests that failures are typically transient (the target 2479 system or its connection has crashed), favoring a policy of two connection 2480 attempts in the first hour the message is in the queue, and then backing 2481 off to one every two or three hours. 2483 The SMTP client can shorten the queuing delay in cooperation with the SMTP 2484 server. For example, if mail is received from a particular address, it is 2485 likely that mail queued for that host can now be sent. Application of this 2486 principle may, in many cases, eliminate the requirement for an explicit 2487 "send queues now" function such as that discussed in [RFC-ETRN]. 2489 The strategy may be further modified as a result of multiple addresses per 2490 host (see below) to optimize delivery time vs. resource usage. 2492 An SMTP client may have a large queue of messages for each unavailable 2493 destination host. If all of these messages were retried in every retry 2494 cycle, there would be excessive Internet overhead and the sending system 2495 would be blocked for a long period. Note that an SMTP client can generally 2496 determine that a delivery attempt has failed only after a timeout of 2497 several minutes and even a one-minute timeout per connection will result in 2498 a very large delay if retries are repeated for dozens, or even hundreds, of 2499 queued messages to the same host. 2501 At the same time, SMTP clients SHOULD use great care in caching negative 2502 responses from servers. In an extreme case, if EHLO is issued multiple 2503 times during the same SMTP connection, different answers may be returned by 2504 the server. More significantly, 5yz responses to MAIL FROM MUST NOT be 2505 cached. 2507 When a mail message is to be delivered to multiple recipients, and the SMTP 2508 server to which a copy of the message is to be sent is the same for 2509 multiple recipients, then only one copy of the message SHOULD be 2510 transmitted. That is, the SMTP client SHOULD use the command sequence: 2511 MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, DATA, 2512 ..., MAIL, RCPT, DATA. However, if there are very many addresses, a limit 2513 on the number of RCPT commands per MAIL command MAY be imposed. 2514 Implementation of this efficiency feature is strongly encouraged. 2516 Similarly, to achieve timely delivery, the SMTP client MAY support multiple 2517 concurrent outgoing mail transactions. However, some limit may be 2518 appropriate to protect the host from devoting all its resources to mail. 2520 4.5.4.2 Receiving Strategy 2522 The SMTP server SHOULD attempt to keep a pending listen on the SMTP port at 2523 all times. This requires the support of multiple incoming TCP connections 2524 for SMTP. Some limit MAY be imposed. 2526 As discussed above, when the SMTP server receives mail from a particular 2527 host address, it could notify the SMTP client to retry any mail pending for 2528 that host address. 2530 5. Address Resolution and Mail Handling 2532 Once an SMTP client lexically identifies a domain to which mail will be 2533 delivered for processing (as described in sections 3.6 and 3.7), a DNS 2534 lookup is performed to resolve the domain name (see [RFC-DNS]). The names 2535 are expected to be fully-qualified domain names (FQDNs): mechanisms for 2536 inferring FQDNs from partial names or local aliases are outside of this 2537 specification and, due to a history of problems, are generally discouraged. 2538 The lookup first attempts to locate an MX record associated with the name. 2539 If a CNAME record is found instead, the resulting name is processed as if 2540 it were the initial name. If no MX records are found, but an A RR is 2541 found, the A RR is treated as if it was associated with an implicit MX RR, 2542 with a preference of 0, pointing to that host. If one or more MX RRs are 2543 found for a given name, SMTP systems MUST NOT utilize any A RRs associated 2544 with that name unless they are located using the MX RRs; the "implicit MX" 2545 rule above applies only if there are no MX records present. If MX records 2546 are present, but none of them are usable, this situation MUST be reported 2547 as an error. 2549 When the lookup succeeds, the mapping can result in a list of alternative 2550 delivery addresses rather than a single address, because of multiple MX 2551 records, multihoming, or both. To provide reliable mail transmission, the 2552 SMTP client MUST be able to try (and retry) each of the relevant addresses 2553 in this list in order, until a delivery attempt succeeds. However, there 2554 MAY also be a configurable limit on the number of alternate addresses that 2555 can be tried. In any case, a host SHOULD try at least two addresses. 2557 Two types of information is used to rank the host addresses: multiple MX 2558 records, and multihomed hosts. 2560 Multiple MX records contain a preference indication that SHOULD be used in 2561 sorting (see below). Lower numbers are more preferred than higher ones. 2562 If there are multiple destinations with the same preference and there is no 2563 clear reason to favor one (e.g., by recognition of an easily-reached 2564 address), then the sender-SMTP MUST randomize them to spread the load 2565 across multiple mail exchangers for a specific organization. 2567 The destination host (perhaps taken from the preferred MX record) may be 2568 multihomed, in which case the domain name resolver will return a list of 2569 alternative IP addresses. It is the responsibility of the domain name 2570 resolver interface to have ordered this list by decreasing preference if 2571 necessary, and SMTP MUST try them in the order presented. 2573 Although the capability to try multiple alternative addresses is required, 2574 specific installations may want to limit or disable the use of alternative 2575 addresses. The question of whether a sender should attempt retries using 2576 the different addresses of a multihomed host has been controversial. The 2577 main argument for using the multiple addresses is that it maximizes the 2578 probability of timely delivery, and indeed sometimes the probability of any 2579 delivery; the counter-argument is that it may result in unnecessary 2580 resource use. Note that resource use is also strongly determined by the 2581 sending strategy discussed in section 4.5.4.1. 2583 If a host receives a message with a destination for which it is a 2584 designated Mail eXchanger, it MAY relay the message (potentially after 2585 having rewritten the addresses), make final delivery of the message, or 2586 hand it off using some mechanism outside the SMTP-provided transport 2587 environment. 2589 If it determines that it should relay the message without rewriting the 2590 address, it MUST sort the MX records to determine candidates for delivery. 2591 The records are first ordered by preference, with the lowest-numbered 2592 records being most preferred. The relay host MUST then inspect the list 2593 for any of the names or addresses by which it might be known in mail 2594 transactions. If a matching record is found, all records at that 2595 preference level and higher-numbered ones MUST be discarded from 2596 consideration. If there are no records left at that point, it is an error 2597 condition, and the message MUST be returned as undeliverable. If records 2598 do remain, they SHOULD be tried, best preference first, as described above. 2600 6. Problem Detection and Handling 2602 6.1 Reliable Delivery and Replies by Email 2604 When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" 2605 message in response to DATA), it is accepting responsibility for delivering 2606 or relaying the message. It must take this responsibility seriously. It 2607 MUST NOT lose the message for frivolous reasons, such as because the host 2608 later crashes or because of a predictable resource shortage. 2610 If there is a delivery failure after acceptance of a message, the 2611 receiver-SMTP MUST formulate and mail a notification message. This 2612 notification MUST be sent using a null ("<>") reverse path in the envelope. 2613 The recipient of this notification SHOULD be the address from the envelope 2614 return path (or the Return-Path: line). However, if this address is null 2615 ("<>"), the receiver-SMTP MUST NOT send a notification. Obviously, nothing 2616 in this section can or should prohibit local decisions (i.e., as part of 2617 the same system environment as the receiver-SMTP) to log or otherwise 2618 transmit information about null address events locally if that is desired. 2619 If the address is an explicit source route, it MUST be stripped down to its 2620 final hop. 2622 For example, suppose that an error notification must be sent for a message 2623 that arrived with: 2624 MAIL FROM:<@a,@b:user@d> 2626 The notification message SHOULD be sent using: 2627 RCPT TO: 2629 Some delivery failures after the message is accepted by SMTP will be 2630 unavoidable. For example, it may be impossible for the receiving SMTP 2631 server to validate all the delivery addresses in RCPT command(s) due to a 2632 "soft" domain system error, because the target is a mailing list (see 2633 earlier discussion of RCPT), or because the server is acting as a relay and 2634 has no immediate access to the delivering system. 2636 To avoid receiving duplicate messages as the result of timeouts, a 2637 receiver-SMTP MUST seek to minimize the time required to respond to the 2638 final . end of data indicator. See RFC-1047 [RFC-1047] for a 2639 discussion of this problem. 2641 6.2 Loop Detection 2643 Simple counting of the number of "Received:" headers in a message has 2644 proven to be an effective, although rarely optimal, method of detecting 2645 loops in mail systems. SMTP servers using this technique SHOULD use a 2646 large rejection threshold, normally at least 100 Received entries. 2647 Whatever mechanisms are used, servers MUST contain provisions for detecting 2648 and stopping trivial loops. 2650 6.3 Compensating for Irregularities 2652 Unfortunately, variations, creative interpretations, and outright 2653 violations of Internet mail protocols do occur; some would suggest that 2654 they occur quite frequently. The debate as to whether a well-behaved SMTP 2655 receiver or relay should reject a malformed message, attempt to pass it on 2656 unchanged, or attempt to repair it to increase the odds of successful 2657 delivery (or subsequent reply) began almost with the dawn of structured 2658 network mail and shows no signs of abating. Advocates of rejection claim 2659 that attempted repairs are rarely completely adequate and that rejection of 2660 bad messages is the only way to get the offending software repaired. 2661 Advocates of "repair" or "deliver no matter what" argue that users prefer 2662 that mail go through it if at all possible and that there are significant 2663 market pressures in that direction. In practice, these market pressures 2664 may be more important to particular vendors than strict conformance to the 2665 standards, regardless of the preference of the actual developers. 2667 The problems associated with ill-formed messages were exacerbated by the 2668 introduction of the split-UA mail reading protocols [RFC-POP2, RFC-POP3, 2669 RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the use of SMTP as 2670 a posting protocol, and SMTP servers as relay systems for these client 2671 hosts (which are often only intermittently connected to the Internet). 2672 Historically, many of those client machines lacked some of the mechanisms 2673 and information assumed by SMTP (and indeed, by the mail format protocol 2674 [RFC-822]). Some could not keep adequate track of time; others had no 2675 concept of time zones; still others could not identify their own names or 2676 addresses; and, of course, none could satisfy the assumptions that underlay 2677 RFC-822's conception of authenticated addresses. 2679 In response to these weak SMTP clients, many SMTP systems now complete 2680 messages that are delivered to them in incomplete or incorrect form. This 2681 strategy is generally considered appropriate when the server can identify 2682 or authenticate the client, and there are prior agreements between them. 2683 By contrast, there is at best great concern about fixes applied by a relay 2684 or delivery SMTP server that has little or no knowledge of the user or 2685 client machine. 2687 The following changes to a message being processed MAY be applied when 2688 necessary by an originating SMTP server, or one used as the target of SMTP 2689 as an initial posting protocol: 2691 - Addition of a message-id field when none appears 2693 - Addition of a date, time or time zone when none appears 2695 - Correction of addresses to proper FQDN format 2697 The less information the server has about the client, the less likely these 2698 changes are to be correct and the more caution and conservatism should be 2699 applied when considering whether or not to perform fixes and how. These 2700 changes MUST NOT be applied by an SMTP server that provides an intermediate 2701 relay function. 2703 In all cases, properly-operating clients supplying correct information are 2704 preferred to corrections by the SMTP server. In all cases, documentation of 2705 actions performed by the servers (in trace fields and/or header comments) 2706 is strongly encouraged. 2708 7. Security Considerations 2710 7.1 Mail Security and Spoofing 2712 SMTP mail is inherently insecure in that it is feasible for even fairly 2713 casual users to negotiate directly with receiving and relaying SMTP servers 2714 and create messages that will trick a naive recipient into believing that 2715 they came from somewhere else. Constructing such a message so that the 2716 "spoofed" behavior cannot be detected by an expert is somewhat more 2717 difficult, but not sufficiently so as to be a deterrent to someone who is 2718 determined and knowledgeable. Consequently, as knowledge of Internet mail 2719 increases, so does the knowledge that SMTP mail inherently cannot be 2720 authenticated, or integrity checks provided, at the transport level. Real 2721 mail security lies only in end-to-end methods involving the message bodies, 2722 such as those that can be provided in the MOSS framework [RFC-MOSS]. 2724 Various protocol extensions and configuration options that provide 2725 authentication at the transport level (e.g., from an SMTP client to an SMTP 2726 server) improve somewhat on the traditional situation described above. 2727 However, unless they are accompanied by careful handoffs of responsibility 2728 in a carefully-designed trust environment, they remain inherently weaker 2729 than end-to-end mechanisms which use digitally signed messages rather than 2730 depending on the integrity of the transport system. 2732 Efforts to make it more difficult for users to set envelope MAIL FROM and 2733 header "From" fields to point to valid addresses other than their own are 2734 largely misguided: they frustrate legitimate applications in which mail is 2735 sent by one user on behalf of another or in which error (or normal) replies 2736 should be directed to a special address. (Systems that provide convenient 2737 ways for users to alter these fields on a per-message basis should attempt 2738 to establish a primary and permanent mailbox address for the user so that 2739 Sender fields within the message data can be generated sensibly.) 2741 This specification does not further address the authentication issues 2742 associated with SMTP other than to advocate that useful functionality not 2743 be disabled in the hope of providing some small margin of protection 2744 against an ignorant user who is trying to fake mail. 2746 7.2 "Blind" Copies 2748 Addresses that do not appear in the message headers may appear in the RCPT 2749 TO commands to an SMTP server for a number of reasons. The two most common 2750 involve the use of a mailing address as a "list exploder" (a single address 2751 that resolves into multiple addresses) and the appearance of "blind 2752 copies". Especially when more than one RCPT command is present, and in 2753 order to avoid defeating some of the purpose of these mechanisms, SMTP 2754 clients and servers SHOULD NOT copy the full set of RCPT TO command 2755 arguments into the headers, either as part of trace headers or as 2756 informational or private-extension headers. Since this rule is often 2757 violated in practice, and cannot be enforced, sending SMTP systems that are 2758 aware of "bcc" use MAY find it helpful to send each blind copy as a 2759 separate message transaction containing only a single RCPT TO command. 2761 There is no inherent relationship between either "reverse" (MAIL FROM, SAML 2762 FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP transaction 2763 ("envelope") and the addresses in the headers. Receiving systems SHOULD 2764 NOT attempt to deduce such relationships and use them to alter the headers 2765 of the message for delivery. The popular "Apparently-to" header is a 2766 violation of this principle and SHOULD NOT be used. 2768 7.3 VRFY, EXPN, and Security 2770 As discussed in section 3.5, individual sites may want to disable one or 2771 both VRFY or EXPN for security reasons. As a corollary to the above, 2772 implementations that permit this MUST NOT appear to have verified addresses 2773 that are not, in fact, verified. If a site disables these commands for 2774 security reasons, the SMTP server MUST return a 252 response, rather than a 2775 code that could be confused with successful or unsuccessful verification. 2777 Returning a 250 reply code with the address listed in the VRFY command 2778 after having checked it only for syntax violates this rule. Of course, an 2779 implementation that "supports" VRFY by always returning 550 whether or not 2780 the address is valid is equally not in conformance. 2782 Within the last few years, the contents of mailing lists have become 2783 popular as an address information source for so-called "spammers." The use 2784 of EXPN to "harvest" addresses has increased as list administrators have 2785 installed protections against inappropriate uses of the lists themselves. 2786 Implementations SHOULD still provide support for EXPN, but sites SHOULD 2787 carefully evaluate the tradeoffs. As authentication mechanisms are 2788 introduced into SMTP, some sites may choose to make EXPN available only to 2789 authenticated requestors. 2791 7.4 Information Disclosure in Announcements 2793 There has been an ongoing debate about the tradeoffs between the debugging 2794 advantages of announcing server type and version (and, sometimes, even 2795 server domain name) in the greeting response or in response to the HELP 2796 command and the disadvantages of exposing useful information to potential 2797 hostile attack. The utility of the debugging information is beyond doubt. 2798 Those who argue for making it available point out that it is far better to 2799 actually secure an SMTP server rather than hope that trying to conceal 2800 known vulnerabilities by hiding the server's precise identity will provide 2801 more protection. Sites are encouraged to evaluate the tradeoff with that 2802 issue in mind; implementations are strongly encouraged to minimally provide 2803 for making type and version information available in some way to other 2804 network hosts. 2806 7.5 Information Disclosure in Trace Fields 2808 In some circumstances, such as when mail originates from within a LAN whose 2809 hosts are not directly from the public Internet, trace ("Received") fields 2810 produced in conformance with this specification may disclose host names and 2811 similar information that would not normally be available. This ordinarily 2812 does not pose a problem, but sites with special concerns about name 2813 disclosure should be aware of it. Also, the optional FOR clause should be 2814 supplied with caution or not at all when multiple recipients are involved 2815 lest it inadvertently disclose the identities of "blind copy" recipients to 2816 others. 2818 7.6 Scope of Operation of SMTP Servers 2820 It is a well-established principle that an SMTP server may refuse to accept 2821 mail for any operational or technical reason that makes sense to the site 2822 providing the server. However, cooperation among sites and installations 2823 makes the Internet possible. If sites take excessive advantage of the 2824 right to reject traffic, the ubiquity of email availability (one of the 2825 strengths of the Internet) will be threatened; considerable care should be 2826 taken and balance maintained if a site decides to be selective about the 2827 traffic it will accept and process. 2829 In recent years, use of the relay function through arbitrary sites has been 2830 used as part of hostile efforts to hide the actual origins of mail. Some 2831 sites have decided to limit the use of the relay function to known or 2832 identifiable sources, and implementations SHOULD provide the capability to 2833 perform this type of filtering. When mail is rejected for these or other 2834 policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL FROM, 2835 or RCPT TO as appropriate. 2837 8. IANA Considerations 2839 IANA is <> to set up three registries. The first consists of 2840 SMTP service extensions with the associated keywords, and, as needed, 2841 parameters and verbs. As specified in section 2.2.2, no entry may be made 2842 in this registry that starts in an "X". Entries may be made only for 2843 service extensions (and associated keywords, parameters, or verbs) that are 2844 defined in standards-track or experimental RFCs specifically approved by 2845 the IESG for this purpose. 2847 The second registry consists of "tags" that identify forms of domain 2848 literals other than those for IPv4 addresses (specified in RFC 821 and in 2849 this document) and IPv6 addresses (specified in this document). Additional 2850 literal types require standardization before being used; none are 2851 anticipated at this time. 2853 The third, established by RFC 821 and renewed by this specification, is a 2854 registry of link and protocol identifiers to be used with the "via" and 2855 "with" subclauses of the time stamp ("Received: header") described in 2856 section 4.4. Link and protocol identifiers in addition to those specified 2857 in this document may be registered only by standardization or by way of an 2858 RFC-documented, IESG-approved, Experimental protocol extension. 2860 9. References 2862 [8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP 2863 Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994. 2865 [ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax 2866 Specifications: ABNF", RFC 2234, November 1997. 2868 [IPv6AddrString] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing 2869 Architecture", RFC 1884, December 1995. 2871 [MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt, 2872 August, 1998 2874 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 2875 Messages", RFC 822, Department of Electrical Engineering, University of 2876 Delaware, August 1982. 2878 [RFC-974] C. Partridge, "Mail routing and the domain system", RFC 974, 2879 01/01/1986 2881 [RFC-1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047, 2882 02/01/1988. 2884 [RFC-1123] R. Braden, "Requirements for Internet hosts - application and 2885 support", 10/01/1989 2887 [RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large 2888 and Binary MIME Messages", RFC 1830, 08/16/1995. 2890 [RFC-DNS] P. Mockapetris, "Domain names - implementation and 2891 specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and 2892 facilities", RFC 1034. (STD 13) 2894 [RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue 2895 Starting", RFC 1985, 08/14/1996. 2897 [RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version 2", RFC 2898 1176, 08/20/1990. 2900 [RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - Version 4", RFC 2901 2060, 12/04/1996. 2903 [RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part 2904 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996. 2906 [RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions 2907 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996. 2909 [RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object 2910 Security Services", RFC 1848, 10/03/1995. 2912 [RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status 2913 Notifications", RFC 1891, 01/15/1996. 2915 [RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for 2916 Delivery Status Notifications", RFC 1894, 01/15/1996. 2918 [RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal 2919 computers", RFC 1056, 06/01/1988. 2921 [RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command 2922 Pipelining", RFC 1854, 10/04/1995. 2924 [RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds, 2925 "Post Office Protocol - version 2", RFC 937, 02/01/1985 2927 [RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930, 2928 5/14/96 (Std 53). 2930 [RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893, 2931 01/15/1996. 2933 [RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for 2934 Message Size Declaration", RFC 1870, 11/06/1995. (STD 10) 2936 [RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 2937 and RFC 822", RFC 1327, 05/18/1992. 2939 [SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP 2940 Service Extensions", RFC-1869, 11/06/1995. (STD 10) 2942 [TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet 2943 Program Protocol Specification", RFC 793, USC/Information Sciences 2944 Institute, NTIS AD Number A111091, September 1981. 2946 [US-ASCII] United States of America Standards Institute (now American 2947 National Standards Institute), X3.4, 1968, "USA Code for Information 2948 Interchange". ANSI X3.4-1968 has been replaced by newer versions with 2949 slight modifications, but the 1968 version remains definitive for the 2950 Internet. 2952 10. Editor's Address 2954 John C. Klensin 2955 MCI Communications 2956 800 Boylston St., 7th floor 2957 Boston, MA 02199 2958 USA 2959 Email: Klensin@mci.net 2960 Phone: +1 617 960 1011 2961 Fax: +1 617 960 1009 2963 11. Acknowledgments 2965 Many people worked long and hard on the many iterations of this document. 2966 There was wide-ranging debate on the mailing list about many technical 2967 issues, and many contributors helped form the wording in this 2968 specification. The hundreds of participants in the many discussions since 2969 RFC 821 was produced are too numerous to mention, but they all helped this 2970 document become what it is. 2972 A. TCP Transport Service 2974 The TCP connection supports the transmission of 8-bit bytes. The SMTP data 2975 is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte 2976 with the high-order bit cleared to zero. Service extensions may modify 2977 this rule to permit transmission of full 8-bit data bytes as part of the 2978 message body, but not in SMTP commands or responses. 2980 B. Generating SMTP Commands from RFC 822 Headers 2982 Some systems use RFC 822 headers (only) in a mail submission protocol, or 2983 otherwise generate SMTP commands from RFC 822 headers when such a message 2984 is handed to an MTA from a UA. While the MTA-UA protocol is a private 2985 matter, not covered by any Internet Standard, there are problems with this 2986 approach. For example, there have been repeated problems with proper 2987 handling of "bcc" copies and redistribution lists when information that 2988 conceptually belongs to a mail envelopes is not separated early in 2989 processing from header information (and kept separate). 2991 It is recommended that the UA provide its initial MTA with an envelope 2992 separate from the message itself. However, if the envelope is not 2993 supplied, SMTP commands SHOULD be generated as follows: 2995 1. Each recipient address from a TO, CC, or BCC header field SHOULD be 2996 copied to a RCPT command (generating multiple message copies if that is 2997 required for queuing or delivery). This includes any addresses listed 2998 in a RFC 822 "group". Any BCC fields SHOULD then be removed from the 2999 headers. Once this process is completed, the remaining headers SHOULD 3000 be checked to verify that at least one To:, Cc:, or Bcc: header remains. 3001 If none do, then a bcc: header with no additional information SHOULD be 3002 inserted as specified in [MSGFMT]. 3004 2. The return address in the MAIL command SHOULD, if possible, be derived 3005 from the system's identity for the submitting (local) user. And the From 3006 header field otherwise. If there is a system identity available, it 3007 SHOULD also be copied to the Sender header field if it is different from 3008 the address in the From header field. (Any Sender field that was 3009 already there SHOULD be removed.) Systems may provide a way for 3010 submitters to override the envelope return address, but may want to 3011 restrict its use to privileged users. This will not prevent mail 3012 forgery, but may lessen its incidence; see section 7.1. 3014 When an MTA is being used in this way, it bears responsibility for ensuring 3015 that the message being transmitted is valid. The mechanisms for checking 3016 that validity, and for handling (or returning) messages that are not valid 3017 at the time of arrival, are part of the MUA-MTA interface and not covered 3018 by this specification. 3020 A submission protocol based on Standard RFC 822 information alone MUST NOT 3021 be used to gateway a message from a foreign (non-SMTP) mail system into an 3022 SMTP environment. Additional information to construct an envelope must 3023 come from some source in the other environment, whether supplemental 3024 headers or the foreign system's envelope. 3026 Attempts to gateway messages using only their header "to" and "cc" fields, 3027 have repeatedly caused mail loops and other behavior adverse to the proper 3028 functioning of the Internet mail environment. These problems have been 3029 especially common when the message originates from an Internet mailing list 3030 and is distributed into the foreign environment using envelope information. 3031 When these messages are then processed by a header-only remailer, loops 3032 back to the Internet environment (and the mailing list) are almost 3033 inevitable. 3035 C. Source Routes 3037 The is a reverse source routing list of hosts and a source 3038 mailbox. The first host in the SHOULD be the host sending 3039 the MAIL FROM command. Similarly, the may be a source 3040 routing lists of hosts and a destination mailbox. However, in general, the 3041 SHOULD contain only a mailbox and domain name, relying on 3042 the domain name system to supply routing information if required. The use 3043 of source routes is deprecated; while servers MUST be prepared to receive 3044 and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT 3045 transmit them. 3047 For relay purposes, the forward-path may be a source route of the form 3048 "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified 3049 domain names. This form is used to emphasize the distinction between an 3050 address and a route. The mailbox is an absolute address, and the route is 3051 information about how to get there. The two concepts should not be 3052 confused. 3054 If source routes are used, RFC 821 and the text below should be consulted 3055 for the mechanisms for constructing and updating the forward- and 3056 reverse-paths. 3058 The SMTP server transforms the command arguments by moving its own 3059 identifier (its domain name or that of any domain for which it is acting as 3060 a mail exchanger), if it appears, from the forward-path to the beginning of 3061 the reverse-path. 3063 Notice that the forward-path and reverse-path appear in the SMTP commands 3064 and replies, but not necessarily in the message. That is, there is no need 3065 for these paths and especially this syntax to appear in the "To:" , 3066 "From:", "CC:", etc. fields of the message header. Conversely, SMTP servers 3067 MUST NOT derive final message delivery information from message header 3068 fields. 3070 When the list of hosts is present, it is a "reverse" source route and 3071 indicates that the mail was relayed through each host on the list (the 3072 first host in the list was the most recent relay). This list is used as a 3073 source route to return non-delivery notices to the sender. As each relay 3074 host adds itself to the beginning of the list, it MUST use its name as 3075 known in the transport environment to which it is relaying the mail rather 3076 than that of the transport environment from which the mail came (if they 3077 are different). 3079 D. Scenarios 3081 This section presents complete scenarios of several types of SMTP sessions. 3082 In the examples, "C:" indicates what is said by the SMTP client, and "S:" 3083 indicates what is said by the SMTP server. 3085 D.1 A Typical SMTP Transaction Scenario 3087 This SMTP example shows mail sent by Smith at host bar.com, to Jones, 3088 Green, and Brown at host foo.com. Here we assume that host bar.com 3089 contacts host foo.com directly. The mail is accepted for Jones and Brown. 3090 Green does not have a mailbox at host foo.com. 3092 S: 220 foo.com Simple Mail Transfer Service Ready 3093 C: EHLO bar.com 3094 S: 250-foo.com greets bar.com 3095 S: 250-8BITMIME 3096 S: 250-SIZE 3097 S: 250-DSN 3098 S: 250 HELP 3099 C: MAIL FROM: 3100 S: 250 OK 3101 C: RCPT TO: 3102 S: 250 OK 3103 C: RCPT TO: 3104 S: 550 No such user here 3105 C: RCPT TO: 3106 S: 250 OK 3107 C: DATA 3108 S: 354 Start mail input; end with . 3109 C: Blah blah blah... 3110 C: ...etc. etc. etc. 3111 C: . 3112 S: 250 OK 3113 C: QUIT 3114 S: 221 foo.com Service closing transmission channel 3116 D.2 Aborted SMTP Transaction Scenario 3118 S: 220 foo.com Simple Mail Transfer Service Ready 3119 C: EHLO bar.com 3120 S: 250-foo.com greets bar.com 3121 S: 250-8BITMIME 3122 S: 250-SIZE 3123 S: 250-DSN 3124 S: 250 HELP 3125 C: MAIL FROM: 3126 S: 250 OK 3127 C: RCPT TO: 3128 S: 250 OK 3129 C: RCPT TO: 3130 S: 550 No such user here 3131 C: RSET 3132 S: 250 OK 3133 C: QUIT 3134 S: 221 foo.com Service closing transmission channel 3136 D.3 Relayed Mail Scenario 3138 Step 1 -- Source Host to Relay Host 3140 S: 220 foo.com Simple Mail Transfer Service Ready 3141 C: EHLO bar.com 3142 S: 250-foo.com greets bar.com 3143 S: 250-8BITMIME 3144 S: 250-SIZE 3145 S: 250-DSN 3146 S: 250 HELP 3147 C: MAIL FROM: 3148 S: 250 OK 3149 C: RCPT TO:<@foo.com:Jones@XYZ.COM> 3150 S: 250 OK 3151 C: DATA 3152 S: 354 Start mail input; end with . 3153 C: Date: Thu, 21 May 1998 05:33:29 -0700 3154 C: From: John Q. Public 3155 C: Subject: The Next Meeting of the Board 3156 C: To: Jones@xyz.com 3157 C: 3158 C: Bill: 3159 C: The next meeting of the board of directors will be 3160 C: on Tuesday. 3161 C: John. 3162 C: . 3163 S: 250 OK 3164 C: QUIT 3165 S: 221 foo.com Service closing transmission channel 3167 Step 2 -- Relay Host to Destination Host 3169 S: 220 xyz.com Simple Mail Transfer Service Ready 3170 C: EHLO foo.com 3171 S: 250 xyz.com is on the air 3172 C: MAIL FROM:<@foo.com:JQP@bar.com> 3173 S: 250 OK 3174 C: RCPT TO: 3175 S: 250 OK 3176 C: DATA 3177 S: 354 Start mail input; end with . 3178 C: Received: from bar.com by foo.com ; Thu, 21 May 1998 05:33:29 -0700 3179 C: Date: Thu, 21 May 1998 05:33:22 -0700 3180 C: From: John Q. Public 3181 C: Subject: The Next Meeting of the Board 3182 C: To: Jones@xyz.com 3183 C: 3184 C: Bill: 3185 C: The next meeting of the board of directors will be 3186 C: on Tuesday. 3187 C: John. 3188 C: . 3189 S: 250 OK 3191 C: QUIT 3192 S: 221 foo.com Service closing transmission channel 3194 D.4 Verifying and Sending Scenario 3196 S: 220 foo.com Simple Mail Transfer Service Ready 3197 C: EHLO bar.com 3198 S: 250-foo.com greets bar.com 3199 S: 250-8BITMIME 3200 S: 250-SIZE 3201 S: 250-DSN 3202 S: 250 HELP 3203 C: VRFY Crispin 3204 S: 250 Mark Crispin 3205 C: SEND FROM: 3206 S: 250 OK 3207 C: RCPT TO: 3208 S: 250 OK 3209 C: DATA 3210 S: 354 Start mail input; end with . 3211 C: Blah blah blah... 3212 C: ...etc. etc. etc. 3213 C: . 3214 S: 250 OK 3215 C: QUIT 3216 S: 221 foo.com Service closing transmission channel 3218 E. Other Gateway Issues 3220 In general, gateways between the Internet and other mail systems SHOULD 3221 attempt to preserve any layering semantics across the boundaries between 3222 the two mail systems involved. Gateway- translation approaches that 3223 attempt to take shortcuts by mapping, (such as envelope information from 3224 one system to the message headers or body of another) have generally proven 3225 to be inadequate in important ways. Systems translating between 3226 environments that do not support both envelopes and headers and Internet 3227 mail must be written with the understanding that some information loss is 3228 almost inevitable. 3230 F. Deprecated Features of RFC 821 3232 A few features of RFC 821 have proven to be problematic and SHOULD NOT be 3233 used in Internet mail. 3235 F.1 TURN 3237 This command, described in RFC 821, raises important security issues since, 3238 in the absence of strong authentication of the host requesting that the 3239 client and server switch roles, it can easily be used to divert mail from 3240 its correct destination. Its use is deprecated; SMTP systems SHOULD NOT 3241 use it unless the server can authenticate the client. 3243 F.2 Source Routing 3245 RFC 821 utilized the concept of explicit source routing to get mail from 3246 one host to another via a series of relays. The requirement to utilize 3247 source routes in regular mail traffic was eliminated by the introduction of 3248 the domain name system "MX" record and the last significant justification 3249 for them was eliminated by the introduction, in RFC 1123, of a clear 3250 requirement that addresses following an "@" must all be fully-qualified 3251 domain names. Consequently, the only remaining justifications for the use 3252 of source routes are support for very old SMTP clients or MUAs and in mail 3253 system debugging. They can, however, still be useful in the latter 3254 circumstance and for routing mail around serious, but temporary, problems 3255 such as problems with the relevant DNS records. 3257 SMTP servers MUST continue to accept source route syntax as specified in 3258 the main body of this document and in RFC 1123. They MAY, if necessary, 3259 ignore the routes and utilize only the target domain in the address. If 3260 they do utilize the source route, the message MUST be sent to the first 3261 domain shown in the address. In particular, a server MUST NOT guess at 3262 shortcuts within the source route. 3264 Clients SHOULD NOT utilize explicit source routing except under unusual 3265 circumstances, such as debugging or potentially relaying around firewall or 3266 mail system configuration errors. 3268 F.3 HELO 3270 As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO 3271 when the server will accept the former. Servers must continue to accept 3272 and process HELO in order to support older clients. 3274 F.4 #-literals 3276 RFC 821 provided for specifying an Internet address as a decimal integer 3277 host number prefixed by a pound sign, "#". In practice, that form has been 3278 obsolete since the introduction of TCP/IP. It is deprecated and MUST NOT 3279 be used. 3281 F.5 Dates and Years 3283 When dates are inserted into messages by SMTP clients or servers (e.g., in 3284 trace fields), four-digit years MUST BE used. Two-digit years are 3285 deprecated; three-digit years were never permitted in the Internet mail 3286 system. 3288 F.6 Sending versus Mailing 3290 In addition to specifying a mechanism for delivering messages to user's 3291 mailboxes, RFC 821 provided additional, optional, commands to deliver 3292 messages directly to the user's terminal screen. These commands (SEND, 3293 SAML, SOML) were rarely implemented, and changes in workstation technology 3294 and the introduction of other protocols may have rendered them obsolete 3295 even where they are implemented. 3297 Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers MAY 3298 implement them. If they are implemented by servers, the implementation 3299 model specified in RFC 821 MUST be used and the command names MUST be 3300 published in the response to the EHLO command. 3302 X. Change Summary and Loose Ends (Temporary) 3304 X.1 Change summary 3306 X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and 3307 draft-ietf-drums-smtpupd-01.txt 3309 (i) Slightly clarified the discussions of rejection and failure of VRFY 3310 requests and the associated response codes. 3312 (ii) Slightly clarified the discussion of deferred address validation. 3314 (iii) Removed the IPCE terminology and modified the text in section 4.1.1.2 3315 to explicitly introduce the "mail gateway" terminology and to begin to 3316 distinguish a mail gateway from a conventional relay. 3318 (iv) Explicitly noted that SMTP clients for things like POP and IMAP may 3319 send everything to a single relay for further processing, rather than 3320 resolving final domain names. 3322 (v) Tightened the RSET discussion. 3324 (vi) Deprecation of 251 only for RCPT (still ok for VRFY) 3326 X.1.2. Substantive changes between draft-ietf-drums-smtpupd-01.txt and 3327 draft-ietf-drums-smtpupd-02.txt. 3329 Incorporated additional RFC 1123 material; reorganized several sections for 3330 clarity. Added definitions and other previous "loose end" material. 3332 X.1.3. Substantive changes between draft-ietf-drums-smtpupd-02.txt and 3333 draft-ietf-drums-smtpupd-03.txt. 3335 (i) Eliminated a number of placeholders and tightened some of the 3336 definitions in section 2. Added a few new placeholders for consistency 3337 checking against other documents. 3339 (ii) Removed the state diagrams, per direction at IETF Montreal. 3341 (iii) Added new section 6.3, an attempt to summarize WG discussions on the 3342 "posting" versus "delivery" versus "relay" functions of SMTP and on whether 3343 "fixups" are appropriate in different cases. 3345 (iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123. 3347 (v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship. 3349 (vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat. 3351 (v) The remaining miscellaneous changes agreed to in Montreal have been 3352 incorporated except as noted below. 3354 X.1.4. Substantive changes between draft-ietf-drums-smtpupd-03.txt and 3355 draft-ietf-drums-smtpupd-04.txt. 3357 Many small changes have been made between these two versions; the list that 3358 follows is not exhaustive. 3360 (i) To clarify some of the text, definitions have been introduced to 3361 distinguish among originating, delivery, relay, and gateway SMTP systems. 3363 (ii) The role of LF-terminated lines has been clarified. 3365 (iii) Several changes have been made to clarify the principle that, no 3366 matter what originating and final delivery systems might do, relay systems 3367 are not permitted to tamper with message content, even to "fix" headers 3368 that are determined to be invalid. If they deem message content to be 3369 seriously unacceptable, they are encouraged to reject the messages in 3370 preference to trying to fix them up, but, in general, the theme is "don't 3371 look/ don't tell". 3373 (iv) A few more definitions have been added to the terminology section, and 3374 the separate glossary has been eliminated. 3376 (v) I have taken a shot at text to address some of the controversies that 3377 have raged on the WG mailing list (e.g., sections 7.4 and 7.5). Since there 3378 was no consensus on most of those topics, I expect that the inserted text 3379 will satisfy no one except, perhaps, for agreement that saying nothing 3380 would have been worse. As a mechanism for moving forward, the text in 3381 these controversial areas that now appears will be considered "base"; 3382 alterations will be made only if clear consensus emerges. 3384 (vi) Per discussion in Los Angeles, source routes have been further 3385 deprecated. 3387 (vii) Some of the VRFY/EXPN materials have been moved to "security 3388 considerations", where they appear to belong, some text has been added, and 3389 the conformance statements adjusted to reflect what I perceive to be WG 3390 consensus. 3392 (viii) New MX resolution material has been added to section 5. While most 3393 of this material is from RFC974, the rules have been further tightened to 3394 reflect current practice and experience (974 is written in a somewhat 3395 speculative fashion for a standard). In particular, the behavior of trying 3396 the target host's A RR when MXs existed but all of them were eliminated is 3397 now prohibited, which seems necessary if another of other ideas being 3398 recommended or considered are to be feasible. 3400 X.1.5. Substantive changes between draft-ietf-drums-smtpupd-04.txt and 3401 draft-ietf-drums-smtpupd-05.txt. 3403 (i) All normative references to RFC 1123 have been removed from the main 3404 body of the text (some still appear in the appendices where they will 3405 remain). 3407 (ii) Section 3.5 has been renamed slightly to distinguish between 3408 "debugging of SMTP implementations" and "debugging of addresses". Better 3409 terminology would be welcome. 3411 (iii) Error conditions resulting from the DATA command have been clarified. 3413 (iv) Section 4.2 (SMTP replies) has been revised and tightened to reflect 3414 reality and recent discussion on the list. 3416 (v) Appendix E has been revised a bit and moved into section 4.2.1. Given 3417 the importance of the "check only first digit" rule, it has to be there. 3419 (vi) Added new text for "no SMTP service supported" to sections 3.1, 4.2.2, 3420 4.2.3, and 4.3.2. As noted in 3.1, I'd rather add 521 (which would work 3421 perfectly with the model) rather than overloading 554. 3423 (vii) The Return-path language in section 4.4 has been cleaned up a bit. 3425 (viii) Tightened the "postmaster" language in 4.5.1, requiring a small 3426 change to 4.1.1.3. 3428 (ix) I have unilaterally (with a little help from my friends), increased 3429 some of the size limits. 64 was much too short for a domain name, and the 3430 DNS limit of 255 (?) has now been inserted. That leaves the return path 3431 much too short, but I haven't fixed it (maybe that will cause us to get rid 3432 of them). We still have a 64 character limit on the local-part, which is 3433 also *much* too short. Votes for 128 or longer limits accepted. See 3434 X.1.6(I) 3436 (x) The text on the "recipients buffer" has been rewritten so that (I hope) 3437 it makes sense and gives some explicit guidance for how clients and servers 3438 should proceed if limits are imposed. 3440 X.1.6. Substantive changes between draft-ietf-drums-smtpupd-05.txt and 3441 draft-ietf-drums-smtpupd-06.txt. 3443 Most of the changes in this revision have been editorial rather than 3444 substantive. Major substantive changes include: 3446 (i) The language about maximum sizes of SMTP command lines has been 3447 reworked, per WG mailing list discussion. 3449 (ii) Several instances of "Should" have been promoted to "Must" when the 3450 reasons for the weaker rule seemed to have disappeared. In particular, the 3451 requirement that an SMTP implementation support timeouts has become a MUST. 3452 Also, conformance to this specification requires support of EHLO. Older 3453 systems should claim conformance to the [to-be-historical] 821, not this 3454 specification. 3456 X.1.7. Substantive changes between draft-ietf-drums-smtpupd-06.txt and 3457 draft-ietf-drums-smtpupd-07.txt. 3459 (i) Removed "implied RSET" text associated with QUIT, as specified at the 3460 December 1997 IETF 3462 (ii) Required that servers support EHLO, as specified at the December 1997 3463 IETF 3465 X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and 3466 draft-ietf-drums-smtpupd-08.txt. 3468 This version involves mostly editorial work and cleanup of loose ends. 3470 (iii) Error code presentation has been restructured. 3472 (iv) ABNF conversion done 3474 (v) IPv6 address format inserted per RFC 1884, since we could not get clear 3475 agreement on an alternative. 3477 (vi) Trivial, silly, examples removed. Others not yet renumbered. 3479 (vii) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes. Eric may 3480 not like the way I've done either of these change very much: the first now 3481 makes the distinction between returning an address and returning other 3482 stuff (which was permitted by -06, but the text wasn't as clear as it 3483 should have been): if it looks like an address, it needs to be an address. 3484 Similarly, with 4.1.1, Eric wanted to explicitly permit/legitimize "DATA 3485 ". I see several disadvantages to doing that, so have inserted 3486 language that encourages receivers to tolerate trailing white space, which 3487 may have the same practical effect. 3489 X.1.8. Substantive changes between draft-ietf-drums-smtpupd-04.txt and 3490 draft-ietf-drums-smtpupd-05.txt. 3492 This version is substantially a cleanup, with several clarifications. In 3493 addition 3495 (i) New 7.5 added (old one renumbered) to discuss info disclosure through 3496 Received fields. 3498 (ii) Some character set and minor syntax issues clarified. 3500 (iii) Material on code 571 added (thought this had been done long ago; 3501 slipped through the cracks) 3503 (iv) Many clarifications added as the result of list discussions and 3504 suggestions. (v) First serious attempt at putting the syntax into ABNF 3505 form. Still not complete. 3507 X.2 Loose ends 3509 << All issues in this section are still open.>> 3511 (i) The 821 BNF -> ABNF transition needs careful checking. 3513 (ii) Trace field discussion should be checked carefully, particularly since 3514 the syntax given is slightly different from 821. Provision has been made, 3515 reflecting some current practice, for (optional) fractional seconds in time 3516 stamps. 3518 (iii) Remaining syntax differences and redundancies with respect to 822bis 3519 (see note on section 4.1.2). Note that the use of "Atom" for extension 3520 parameter keywords is slightly different from the specification in RFC 3521 1869. 3523 (vi) We don't have a satisfactory definition for "link" as in "Received:.. 3524 via " and, if there is a registry, I can't find it. Needs to be 3525 fixed somehow. 3527 Z. Full Copyright Statement 3529 Copyright (C) The Internet Society (1998). All Rights Reserved. 3531 This document and translations of it may be copied and furnished to others, 3532 and derivative works that comment on or otherwise explain it or assist in 3533 its implementation may be prepared, copied, published and distributed, in 3534 whole or in part, without restriction of any kind, provided that the above 3535 copyright notice and this paragraph are included on all such copies and 3536 derivative works. However, this document itself may not be modified in any 3537 way, such as by removing the copyright notice or references to the Internet 3538 Society or other Internet organizations, except as needed for the purpose 3539 of developing Internet standards in which case the procedures for 3540 copyrights defined in the Internet Standards process must be followed, or 3541 as required to translate it into languages other than English. 3543 The limited permissions granted above are perpetual and will not be revoked 3544 by the Internet Society or its successors or assigns. 3546 This document and the information contained herein is provided on an "AS 3547 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 3548 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 3549 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 3550 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 3551 PARTICULAR PURPOSE.