]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group J. Klensin, Editor | |
8 | Request for Comments: 2821 AT&T Laboratories | |
9 | Obsoletes: 821, 974, 1869 April 2001 | |
10 | Updates: 1123 | |
11 | Category: Standards Track | |
12 | ||
13 | ||
14 | Simple Mail Transfer Protocol | |
15 | ||
16 | Status of this Memo | |
17 | ||
18 | This document specifies an Internet standards track protocol for the | |
19 | Internet community, and requests discussion and suggestions for | |
20 | improvements. Please refer to the current edition of the "Internet | |
21 | Official Protocol Standards" (STD 1) for the standardization state | |
22 | and status of this protocol. Distribution of this memo is unlimited. | |
23 | ||
24 | Copyright Notice | |
25 | ||
26 | Copyright (C) The Internet Society (2001). All Rights Reserved. | |
27 | ||
28 | Abstract | |
29 | ||
30 | This document is a self-contained specification of the basic protocol | |
31 | for the Internet electronic mail transport. It consolidates, updates | |
32 | and clarifies, but doesn't add new or change existing functionality | |
33 | of the following: | |
34 | ||
35 | - the original SMTP (Simple Mail Transfer Protocol) specification of | |
36 | RFC 821 [30], | |
37 | ||
38 | - domain name system requirements and implications for mail | |
39 | transport from RFC 1035 [22] and RFC 974 [27], | |
40 | ||
41 | - the clarifications and applicability statements in RFC 1123 [2], | |
42 | and | |
43 | ||
44 | - material drawn from the SMTP Extension mechanisms [19]. | |
45 | ||
46 | It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the | |
47 | mail transport materials of RFC 1123). However, RFC 821 specifies | |
48 | some features that were not in significant use in the Internet by the | |
49 | mid-1990s and (in appendices) some additional transport models. | |
50 | Those sections are omitted here in the interest of clarity and | |
51 | brevity; readers needing them should refer to RFC 821. | |
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | Klensin Standards Track [Page 1] | |
59 | \f | |
60 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
61 | ||
62 | ||
63 | It also includes some additional material from RFC 1123 that required | |
64 | amplification. This material has been identified in multiple ways, | |
65 | mostly by tracking flaming on various lists and newsgroups and | |
66 | problems of unusual readings or interpretations that have appeared as | |
67 | the SMTP extensions have been deployed. Where this specification | |
68 | moves beyond consolidation and actually differs from earlier | |
69 | documents, it supersedes them technically as well as textually. | |
70 | ||
71 | Although SMTP was designed as a mail transport and delivery protocol, | |
72 | this specification also contains information that is important to its | |
73 | use as a 'mail submission' protocol, as recommended for POP [3, 26] | |
74 | and IMAP [6]. Additional submission issues are discussed in RFC 2476 | |
75 | [15]. | |
76 | ||
77 | Section 2.3 provides definitions of terms specific to this document. | |
78 | Except when the historical terminology is necessary for clarity, this | |
79 | document uses the current 'client' and 'server' terminology to | |
80 | identify the sending and receiving SMTP processes, respectively. | |
81 | ||
82 | A companion document [32] discusses message headers, message bodies | |
83 | and formats and structures for them, and their relationship. | |
84 | ||
85 | Table of Contents | |
86 | ||
87 | 1. Introduction .................................................. 4 | |
88 | 2. The SMTP Model ................................................ 5 | |
89 | 2.1 Basic Structure .............................................. 5 | |
90 | 2.2 The Extension Model .......................................... 7 | |
91 | 2.2.1 Background ................................................. 7 | |
92 | 2.2.2 Definition and Registration of Extensions .................. 8 | |
93 | 2.3 Terminology .................................................. 9 | |
94 | 2.3.1 Mail Objects ............................................... 10 | |
95 | 2.3.2 Senders and Receivers ...................................... 10 | |
96 | 2.3.3 Mail Agents and Message Stores ............................. 10 | |
97 | 2.3.4 Host ....................................................... 11 | |
98 | 2.3.5 Domain ..................................................... 11 | |
99 | 2.3.6 Buffer and State Table ..................................... 11 | |
100 | 2.3.7 Lines ...................................................... 12 | |
101 | 2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12 | |
102 | 2.3.9 Message Content and Mail Data .............................. 13 | |
103 | 2.3.10 Mailbox and Address ....................................... 13 | |
104 | 2.3.11 Reply ..................................................... 13 | |
105 | 2.4 General Syntax Principles and Transaction Model .............. 13 | |
106 | 3. The SMTP Procedures: An Overview .............................. 15 | |
107 | 3.1 Session Initiation ........................................... 15 | |
108 | 3.2 Client Initiation ............................................ 16 | |
109 | 3.3 Mail Transactions ............................................ 16 | |
110 | 3.4 Forwarding for Address Correction or Updating ................ 19 | |
111 | ||
112 | ||
113 | ||
114 | Klensin Standards Track [Page 2] | |
115 | \f | |
116 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
117 | ||
118 | ||
119 | 3.5 Commands for Debugging Addresses ............................. 20 | |
120 | 3.5.1 Overview ................................................... 20 | |
121 | 3.5.2 VRFY Normal Response ....................................... 22 | |
122 | 3.5.3 Meaning of VRFY or EXPN Success Response ................... 22 | |
123 | 3.5.4 Semantics and Applications of EXPN ......................... 23 | |
124 | 3.6 Domains ...................................................... 23 | |
125 | 3.7 Relaying ..................................................... 24 | |
126 | 3.8 Mail Gatewaying .............................................. 25 | |
127 | 3.8.1 Header Fields in Gatewaying ................................ 26 | |
128 | 3.8.2 Received Lines in Gatewaying ............................... 26 | |
129 | 3.8.3 Addresses in Gatewaying .................................... 26 | |
130 | 3.8.4 Other Header Fields in Gatewaying .......................... 27 | |
131 | 3.8.5 Envelopes in Gatewaying .................................... 27 | |
132 | 3.9 Terminating Sessions and Connections ......................... 27 | |
133 | 3.10 Mailing Lists and Aliases ................................... 28 | |
134 | 3.10.1 Alias ..................................................... 28 | |
135 | 3.10.2 List ...................................................... 28 | |
136 | 4. The SMTP Specifications ....................................... 29 | |
137 | 4.1 SMTP Commands ................................................ 29 | |
138 | 4.1.1 Command Semantics and Syntax ............................... 29 | |
139 | 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29 | |
140 | 4.1.1.2 MAIL (MAIL) .............................................. 31 | |
141 | 4.1.1.3 RECIPIENT (RCPT) ......................................... 31 | |
142 | 4.1.1.4 DATA (DATA) .............................................. 33 | |
143 | 4.1.1.5 RESET (RSET) ............................................. 34 | |
144 | 4.1.1.6 VERIFY (VRFY) ............................................ 35 | |
145 | 4.1.1.7 EXPAND (EXPN) ............................................ 35 | |
146 | 4.1.1.8 HELP (HELP) .............................................. 35 | |
147 | 4.1.1.9 NOOP (NOOP) .............................................. 35 | |
148 | 4.1.1.10 QUIT (QUIT) ............................................. 36 | |
149 | 4.1.2 Command Argument Syntax .................................... 36 | |
150 | 4.1.3 Address Literals ........................................... 38 | |
151 | 4.1.4 Order of Commands .......................................... 39 | |
152 | 4.1.5 Private-use Commands ....................................... 40 | |
153 | 4.2 SMTP Replies ................................................ 40 | |
154 | 4.2.1 Reply Code Severities and Theory ........................... 42 | |
155 | 4.2.2 Reply Codes by Function Groups ............................. 44 | |
156 | 4.2.3 Reply Codes in Numeric Order .............................. 45 | |
157 | 4.2.4 Reply Code 502 ............................................. 46 | |
158 | 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46 | |
159 | 4.3 Sequencing of Commands and Replies ........................... 47 | |
160 | 4.3.1 Sequencing Overview ........................................ 47 | |
161 | 4.3.2 Command-Reply Sequences .................................... 48 | |
162 | 4.4 Trace Information ............................................ 49 | |
163 | 4.5 Additional Implementation Issues ............................. 53 | |
164 | 4.5.1 Minimum Implementation ..................................... 53 | |
165 | 4.5.2 Transparency ............................................... 53 | |
166 | 4.5.3 Sizes and Timeouts ......................................... 54 | |
167 | ||
168 | ||
169 | ||
170 | Klensin Standards Track [Page 3] | |
171 | \f | |
172 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
173 | ||
174 | ||
175 | 4.5.3.1 Size limits and minimums ................................. 54 | |
176 | 4.5.3.2 Timeouts ................................................. 56 | |
177 | 4.5.4 Retry Strategies ........................................... 57 | |
178 | 4.5.4.1 Sending Strategy ......................................... 58 | |
179 | 4.5.4.2 Receiving Strategy ....................................... 59 | |
180 | 4.5.5 Messages with a null reverse-path .......................... 59 | |
181 | 5. Address Resolution and Mail Handling .......................... 60 | |
182 | 6. Problem Detection and Handling ................................ 62 | |
183 | 6.1 Reliable Delivery and Replies by Email ....................... 62 | |
184 | 6.2 Loop Detection ............................................... 63 | |
185 | 6.3 Compensating for Irregularities .............................. 63 | |
186 | 7. Security Considerations ....................................... 64 | |
187 | 7.1 Mail Security and Spoofing ................................... 64 | |
188 | 7.2 "Blind" Copies ............................................... 65 | |
189 | 7.3 VRFY, EXPN, and Security ..................................... 65 | |
190 | 7.4 Information Disclosure in Announcements ...................... 66 | |
191 | 7.5 Information Disclosure in Trace Fields ....................... 66 | |
192 | 7.6 Information Disclosure in Message Forwarding ................. 67 | |
193 | 7.7 Scope of Operation of SMTP Servers ........................... 67 | |
194 | 8. IANA Considerations ........................................... 67 | |
195 | 9. References .................................................... 68 | |
196 | 10. Editor's Address ............................................. 70 | |
197 | 11. Acknowledgments .............................................. 70 | |
198 | Appendices ....................................................... 71 | |
199 | A. TCP Transport Service ......................................... 71 | |
200 | B. Generating SMTP Commands from RFC 822 Headers ................. 71 | |
201 | C. Source Routes ................................................. 72 | |
202 | D. Scenarios ..................................................... 73 | |
203 | E. Other Gateway Issues .......................................... 76 | |
204 | F. Deprecated Features of RFC 821 ................................ 76 | |
205 | Full Copyright Statement ......................................... 79 | |
206 | ||
207 | 1. Introduction | |
208 | ||
209 | The objective of the Simple Mail Transfer Protocol (SMTP) is to | |
210 | transfer mail reliably and efficiently. | |
211 | ||
212 | SMTP is independent of the particular transmission subsystem and | |
213 | requires only a reliable ordered data stream channel. While this | |
214 | document specifically discusses transport over TCP, other transports | |
215 | are possible. Appendices to RFC 821 describe some of them. | |
216 | ||
217 | An important feature of SMTP is its capability to transport mail | |
218 | across networks, usually referred to as "SMTP mail relaying" (see | |
219 | section 3.8). A network consists of the mutually-TCP-accessible | |
220 | hosts on the public Internet, the mutually-TCP-accessible hosts on a | |
221 | firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN | |
222 | environment utilizing a non-TCP transport-level protocol. Using | |
223 | ||
224 | ||
225 | ||
226 | Klensin Standards Track [Page 4] | |
227 | \f | |
228 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
229 | ||
230 | ||
231 | SMTP, a process can transfer mail to another process on the same | |
232 | network or to some other network via a relay or gateway process | |
233 | accessible to both networks. | |
234 | ||
235 | In this way, a mail message may pass through a number of intermediate | |
236 | relay or gateway hosts on its path from sender to ultimate recipient. | |
237 | The Mail eXchanger mechanisms of the domain name system [22, 27] (and | |
238 | section 5 of this document) are used to identify the appropriate | |
239 | next-hop destination for a message being transported. | |
240 | ||
241 | 2. The SMTP Model | |
242 | ||
243 | 2.1 Basic Structure | |
244 | ||
245 | The SMTP design can be pictured as: | |
246 | ||
247 | +----------+ +----------+ | |
248 | +------+ | | | | | |
249 | | User |<-->| | SMTP | | | |
250 | +------+ | Client- |Commands/Replies| Server- | | |
251 | +------+ | SMTP |<-------------->| SMTP | +------+ | |
252 | | File |<-->| | and Mail | |<-->| File | | |
253 | |System| | | | | |System| | |
254 | +------+ +----------+ +----------+ +------+ | |
255 | SMTP client SMTP server | |
256 | ||
257 | When an SMTP client has a message to transmit, it establishes a two- | |
258 | way transmission channel to an SMTP server. The responsibility of an | |
259 | SMTP client is to transfer mail messages to one or more SMTP servers, | |
260 | or report its failure to do so. | |
261 | ||
262 | The means by which a mail message is presented to an SMTP client, and | |
263 | how that client determines the domain name(s) to which mail messages | |
264 | are to be transferred is a local matter, and is not addressed by this | |
265 | document. In some cases, the domain name(s) transferred to, or | |
266 | determined by, an SMTP client will identify the final destination(s) | |
267 | of the mail message. In other cases, common with SMTP clients | |
268 | associated with implementations of the POP [3, 26] or IMAP [6] | |
269 | protocols, or when the SMTP client is inside an isolated transport | |
270 | service environment, the domain name determined will identify an | |
271 | intermediate destination through which all mail messages are to be | |
272 | relayed. SMTP clients that transfer all traffic, regardless of the | |
273 | target domain names associated with the individual messages, or that | |
274 | do not maintain queues for retrying message transmissions that | |
275 | initially cannot be completed, may otherwise conform to this | |
276 | specification but are not considered fully-capable. Fully-capable | |
277 | SMTP implementations, including the relays used by these less capable | |
278 | ||
279 | ||
280 | ||
281 | ||
282 | Klensin Standards Track [Page 5] | |
283 | \f | |
284 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
285 | ||
286 | ||
287 | ones, and their destinations, are expected to support all of the | |
288 | queuing, retrying, and alternate address functions discussed in this | |
289 | specification. | |
290 | ||
291 | The means by which an SMTP client, once it has determined a target | |
292 | domain name, determines the identity of an SMTP server to which a | |
293 | copy of a message is to be transferred, and then performs that | |
294 | transfer, is covered by this document. To effect a mail transfer to | |
295 | an SMTP server, an SMTP client establishes a two-way transmission | |
296 | channel to that SMTP server. An SMTP client determines the address | |
297 | of an appropriate host running an SMTP server by resolving a | |
298 | destination domain name to either an intermediate Mail eXchanger host | |
299 | or a final target host. | |
300 | ||
301 | An SMTP server may be either the ultimate destination or an | |
302 | intermediate "relay" (that is, it may assume the role of an SMTP | |
303 | client after receiving the message) or "gateway" (that is, it may | |
304 | transport the message further using some protocol other than SMTP). | |
305 | SMTP commands are generated by the SMTP client and sent to the SMTP | |
306 | server. SMTP replies are sent from the SMTP server to the SMTP | |
307 | client in response to the commands. | |
308 | ||
309 | In other words, message transfer can occur in a single connection | |
310 | between the original SMTP-sender and the final SMTP-recipient, or can | |
311 | occur in a series of hops through intermediary systems. In either | |
312 | case, a formal handoff of responsibility for the message occurs: the | |
313 | protocol requires that a server accept responsibility for either | |
314 | delivering a message or properly reporting the failure to do so. | |
315 | ||
316 | Once the transmission channel is established and initial handshaking | |
317 | completed, the SMTP client normally initiates a mail transaction. | |
318 | Such a transaction consists of a series of commands to specify the | |
319 | originator and destination of the mail and transmission of the | |
320 | message content (including any headers or other structure) itself. | |
321 | When the same message is sent to multiple recipients, this protocol | |
322 | encourages the transmission of only one copy of the data for all | |
323 | recipients at the same destination (or intermediate relay) host. | |
324 | ||
325 | The server responds to each command with a reply; replies may | |
326 | indicate that the command was accepted, that additional commands are | |
327 | expected, or that a temporary or permanent error condition exists. | |
328 | Commands specifying the sender or recipients may include server- | |
329 | permitted SMTP service extension requests as discussed in section | |
330 | 2.2. The dialog is purposely lock-step, one-at-a-time, although this | |
331 | can be modified by mutually-agreed extension requests such as command | |
332 | pipelining [13]. | |
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Klensin Standards Track [Page 6] | |
339 | \f | |
340 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
341 | ||
342 | ||
343 | Once a given mail message has been transmitted, the client may either | |
344 | request that the connection be shut down or may initiate other mail | |
345 | transactions. In addition, an SMTP client may use a connection to an | |
346 | SMTP server for ancillary services such as verification of email | |
347 | addresses or retrieval of mailing list subscriber addresses. | |
348 | ||
349 | As suggested above, this protocol provides mechanisms for the | |
350 | transmission of mail. This transmission normally occurs directly | |
351 | from the sending user's host to the receiving user's host when the | |
352 | two hosts are connected to the same transport service. When they are | |
353 | not connected to the same transport service, transmission occurs via | |
354 | one or more relay SMTP servers. An intermediate host that acts as | |
355 | either an SMTP relay or as a gateway into some other transmission | |
356 | environment is usually selected through the use of the domain name | |
357 | service (DNS) Mail eXchanger mechanism. | |
358 | ||
359 | Usually, intermediate hosts are determined via the DNS MX record, not | |
360 | by explicit "source" routing (see section 5 and appendices C and | |
361 | F.2). | |
362 | ||
363 | 2.2 The Extension Model | |
364 | ||
365 | 2.2.1 Background | |
366 | ||
367 | In an effort that started in 1990, approximately a decade after RFC | |
368 | 821 was completed, the protocol was modified with a "service | |
369 | extensions" model that permits the client and server to agree to | |
370 | utilize shared functionality beyond the original SMTP requirements. | |
371 | The SMTP extension mechanism defines a means whereby an extended SMTP | |
372 | client and server may recognize each other, and the server can inform | |
373 | the client as to the service extensions that it supports. | |
374 | ||
375 | Contemporary SMTP implementations MUST support the basic extension | |
376 | mechanisms. For instance, servers MUST support the EHLO command even | |
377 | if they do not implement any specific extensions and clients SHOULD | |
378 | preferentially utilize EHLO rather than HELO. (However, for | |
379 | compatibility with older conforming implementations, SMTP clients and | |
380 | servers MUST support the original HELO mechanisms as a fallback.) | |
381 | Unless the different characteristics of HELO must be identified for | |
382 | interoperability purposes, this document discusses only EHLO. | |
383 | ||
384 | SMTP is widely deployed and high-quality implementations have proven | |
385 | to be very robust. However, the Internet community now considers | |
386 | some services to be important that were not anticipated when the | |
387 | protocol was first designed. If support for those services is to be | |
388 | added, it must be done in a way that permits older implementations to | |
389 | continue working acceptably. The extension framework consists of: | |
390 | ||
391 | ||
392 | ||
393 | ||
394 | Klensin Standards Track [Page 7] | |
395 | \f | |
396 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
397 | ||
398 | ||
399 | - The SMTP command EHLO, superseding the earlier HELO, | |
400 | ||
401 | - a registry of SMTP service extensions, | |
402 | ||
403 | - additional parameters to the SMTP MAIL and RCPT commands, and | |
404 | ||
405 | - optional replacements for commands defined in this protocol, such | |
406 | as for DATA in non-ASCII transmissions [33]. | |
407 | ||
408 | SMTP's strength comes primarily from its simplicity. Experience with | |
409 | many protocols has shown that protocols with few options tend towards | |
410 | ubiquity, whereas protocols with many options tend towards obscurity. | |
411 | ||
412 | Each and every extension, regardless of its benefits, must be | |
413 | carefully scrutinized with respect to its implementation, deployment, | |
414 | and interoperability costs. In many cases, the cost of extending the | |
415 | SMTP service will likely outweigh the benefit. | |
416 | ||
417 | 2.2.2 Definition and Registration of Extensions | |
418 | ||
419 | The IANA maintains a registry of SMTP service extensions. A | |
420 | corresponding EHLO keyword value is associated with each extension. | |
421 | Each service extension registered with the IANA must be defined in a | |
422 | formal standards-track or IESG-approved experimental protocol | |
423 | document. The definition must include: | |
424 | ||
425 | - the textual name of the SMTP service extension; | |
426 | ||
427 | - the EHLO keyword value associated with the extension; | |
428 | ||
429 | - the syntax and possible values of parameters associated with the | |
430 | EHLO keyword value; | |
431 | ||
432 | - any additional SMTP verbs associated with the extension | |
433 | (additional verbs will usually be, but are not required to be, the | |
434 | same as the EHLO keyword value); | |
435 | ||
436 | - any new parameters the extension associates with the MAIL or RCPT | |
437 | verbs; | |
438 | ||
439 | - a description of how support for the extension affects the | |
440 | behavior of a server and client SMTP; and, | |
441 | ||
442 | - the increment by which the extension is increasing the maximum | |
443 | length of the commands MAIL and/or RCPT, over that specified in | |
444 | this standard. | |
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | Klensin Standards Track [Page 8] | |
451 | \f | |
452 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
453 | ||
454 | ||
455 | In addition, any EHLO keyword value starting with an upper or lower | |
456 | case "X" refers to a local SMTP service extension used exclusively | |
457 | through bilateral agreement. Keywords beginning with "X" MUST NOT be | |
458 | used in a registered service extension. Conversely, keyword values | |
459 | presented in the EHLO response that do not begin with "X" MUST | |
460 | correspond to a standard, standards-track, or IESG-approved | |
461 | experimental SMTP service extension registered with IANA. A | |
462 | conforming server MUST NOT offer non-"X"-prefixed keyword values that | |
463 | are not described in a registered extension. | |
464 | ||
465 | Additional verbs and parameter names are bound by the same rules as | |
466 | EHLO keywords; specifically, verbs beginning with "X" are local | |
467 | extensions that may not be registered or standardized. Conversely, | |
468 | verbs not beginning with "X" must always be registered. | |
469 | ||
470 | 2.3 Terminology | |
471 | ||
472 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
473 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
474 | document are to be interpreted as described below. | |
475 | ||
476 | 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that | |
477 | the definition is an absolute requirement of the specification. | |
478 | ||
479 | 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the | |
480 | definition is an absolute prohibition of the specification. | |
481 | ||
482 | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that | |
483 | there may exist valid reasons in particular circumstances to | |
484 | ignore a particular item, but the full implications must be | |
485 | understood and carefully weighed before choosing a different | |
486 | course. | |
487 | ||
488 | 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean | |
489 | that there may exist valid reasons in particular circumstances | |
490 | when the particular behavior is acceptable or even useful, but the | |
491 | full implications should be understood and the case carefully | |
492 | weighed before implementing any behavior described with this | |
493 | label. | |
494 | ||
495 | 5. MAY This word, or the adjective "OPTIONAL", mean that an item is | |
496 | truly optional. One vendor may choose to include the item because | |
497 | a particular marketplace requires it or because the vendor feels | |
498 | that it enhances the product while another vendor may omit the | |
499 | same item. An implementation which does not include a particular | |
500 | option MUST be prepared to interoperate with another | |
501 | implementation which does include the option, though perhaps with | |
502 | reduced functionality. In the same vein an implementation which | |
503 | ||
504 | ||
505 | ||
506 | Klensin Standards Track [Page 9] | |
507 | \f | |
508 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
509 | ||
510 | ||
511 | does include a particular option MUST be prepared to interoperate | |
512 | with another implementation which does not include the option | |
513 | (except, of course, for the feature the option provides.) | |
514 | ||
515 | 2.3.1 Mail Objects | |
516 | ||
517 | SMTP transports a mail object. A mail object contains an envelope | |
518 | and content. | |
519 | ||
520 | The SMTP envelope is sent as a series of SMTP protocol units | |
521 | (described in section 3). It consists of an originator address (to | |
522 | which error reports should be directed); one or more recipient | |
523 | addresses; and optional protocol extension material. Historically, | |
524 | variations on the recipient address specification command (RCPT TO) | |
525 | could be used to specify alternate delivery modes, such as immediate | |
526 | display; those variations have now been deprecated (see appendix F, | |
527 | section F.6). | |
528 | ||
529 | The SMTP content is sent in the SMTP DATA protocol unit and has two | |
530 | parts: the headers and the body. If the content conforms to other | |
531 | contemporary standards, the headers form a collection of field/value | |
532 | pairs structured as in the message format specification [32]; the | |
533 | body, if structured, is defined according to MIME [12]. The content | |
534 | is textual in nature, expressed using the US-ASCII repertoire [1]. | |
535 | Although SMTP extensions (such as "8BITMIME" [20]) may relax this | |
536 | restriction for the content body, the content headers are always | |
537 | encoded using the US-ASCII repertoire. A MIME extension [23] defines | |
538 | an algorithm for representing header values outside the US-ASCII | |
539 | repertoire, while still encoding them using the US-ASCII repertoire. | |
540 | ||
541 | 2.3.2 Senders and Receivers | |
542 | ||
543 | In RFC 821, the two hosts participating in an SMTP transaction were | |
544 | described as the "SMTP-sender" and "SMTP-receiver". This document | |
545 | has been changed to reflect current industry terminology and hence | |
546 | refers to them as the "SMTP client" (or sometimes just "the client") | |
547 | and "SMTP server" (or just "the server"), respectively. Since a | |
548 | given host may act both as server and client in a relay situation, | |
549 | "receiver" and "sender" terminology is still used where needed for | |
550 | clarity. | |
551 | ||
552 | 2.3.3 Mail Agents and Message Stores | |
553 | ||
554 | Additional mail system terminology became common after RFC 821 was | |
555 | published and, where convenient, is used in this specification. In | |
556 | particular, SMTP servers and clients provide a mail transport service | |
557 | and therefore act as "Mail Transfer Agents" (MTAs). "Mail User | |
558 | Agents" (MUAs or UAs) are normally thought of as the sources and | |
559 | ||
560 | ||
561 | ||
562 | Klensin Standards Track [Page 10] | |
563 | \f | |
564 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
565 | ||
566 | ||
567 | targets of mail. At the source, an MUA might collect mail to be | |
568 | transmitted from a user and hand it off to an MTA; the final | |
569 | ("delivery") MTA would be thought of as handing the mail off to an | |
570 | MUA (or at least transferring responsibility to it, e.g., by | |
571 | depositing the message in a "message store"). However, while these | |
572 | terms are used with at least the appearance of great precision in | |
573 | other environments, the implied boundaries between MUAs and MTAs | |
574 | often do not accurately match common, and conforming, practices with | |
575 | Internet mail. Hence, the reader should be cautious about inferring | |
576 | the strong relationships and responsibilities that might be implied | |
577 | if these terms were used elsewhere. | |
578 | ||
579 | 2.3.4 Host | |
580 | ||
581 | For the purposes of this specification, a host is a computer system | |
582 | attached to the Internet (or, in some cases, to a private TCP/IP | |
583 | network) and supporting the SMTP protocol. Hosts are known by names | |
584 | (see "domain"); identifying them by numerical address is discouraged. | |
585 | ||
586 | 2.3.5 Domain | |
587 | ||
588 | A domain (or domain name) consists of one or more dot-separated | |
589 | components. These components ("labels" in DNS terminology [22]) are | |
590 | restricted for SMTP purposes to consist of a sequence of letters, | |
591 | digits, and hyphens drawn from the ASCII character set [1]. Domain | |
592 | names are used as names of hosts and of other entities in the domain | |
593 | name hierarchy. For example, a domain may refer to an alias (label | |
594 | of a CNAME RR) or the label of Mail eXchanger records to be used to | |
595 | deliver mail instead of representing a host name. See [22] and | |
596 | section 5 of this specification. | |
597 | ||
598 | The domain name, as described in this document and in [22], is the | |
599 | entire, fully-qualified name (often referred to as an "FQDN"). A | |
600 | domain name that is not in FQDN form is no more than a local alias. | |
601 | Local aliases MUST NOT appear in any SMTP transaction. | |
602 | ||
603 | 2.3.6 Buffer and State Table | |
604 | ||
605 | SMTP sessions are stateful, with both parties carefully maintaining a | |
606 | common view of the current state. In this document we model this | |
607 | state by a virtual "buffer" and a "state table" on the server which | |
608 | may be used by the client to, for example, "clear the buffer" or | |
609 | "reset the state table," causing the information in the buffer to be | |
610 | discarded and the state to be returned to some previous state. | |
611 | ||
612 | ||
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | Klensin Standards Track [Page 11] | |
619 | \f | |
620 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
621 | ||
622 | ||
623 | 2.3.7 Lines | |
624 | ||
625 | SMTP commands and, unless altered by a service extension, message | |
626 | data, are transmitted in "lines". Lines consist of zero or more data | |
627 | characters terminated by the sequence ASCII character "CR" (hex value | |
628 | 0D) followed immediately by ASCII character "LF" (hex value 0A). | |
629 | This termination sequence is denoted as <CRLF> in this document. | |
630 | Conforming implementations MUST NOT recognize or generate any other | |
631 | character or character sequence as a line terminator. Limits MAY be | |
632 | imposed on line lengths by servers (see section 4.5.3). | |
633 | ||
634 | In addition, the appearance of "bare" "CR" or "LF" characters in text | |
635 | (i.e., either without the other) has a long history of causing | |
636 | problems in mail implementations and applications that use the mail | |
637 | system as a tool. SMTP client implementations MUST NOT transmit | |
638 | these characters except when they are intended as line terminators | |
639 | and then MUST, as indicated above, transmit them only as a <CRLF> | |
640 | sequence. | |
641 | ||
642 | 2.3.8 Originator, Delivery, Relay, and Gateway Systems | |
643 | ||
644 | This specification makes a distinction among four types of SMTP | |
645 | systems, based on the role those systems play in transmitting | |
646 | electronic mail. An "originating" system (sometimes called an SMTP | |
647 | originator) introduces mail into the Internet or, more generally, | |
648 | into a transport service environment. A "delivery" SMTP system is | |
649 | one that receives mail from a transport service environment and | |
650 | passes it to a mail user agent or deposits it in a message store | |
651 | which a mail user agent is expected to subsequently access. A | |
652 | "relay" SMTP system (usually referred to just as a "relay") receives | |
653 | mail from an SMTP client and transmits it, without modification to | |
654 | the message data other than adding trace information, to another SMTP | |
655 | server for further relaying or for delivery. | |
656 | ||
657 | A "gateway" SMTP system (usually referred to just as a "gateway") | |
658 | receives mail from a client system in one transport environment and | |
659 | transmits it to a server system in another transport environment. | |
660 | Differences in protocols or message semantics between the transport | |
661 | environments on either side of a gateway may require that the gateway | |
662 | system perform transformations to the message that are not permitted | |
663 | to SMTP relay systems. For the purposes of this specification, | |
664 | firewalls that rewrite addresses should be considered as gateways, | |
665 | even if SMTP is used on both sides of them (see [11]). | |
666 | ||
667 | ||
668 | ||
669 | ||
670 | ||
671 | ||
672 | ||
673 | ||
674 | Klensin Standards Track [Page 12] | |
675 | \f | |
676 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
677 | ||
678 | ||
679 | 2.3.9 Message Content and Mail Data | |
680 | ||
681 | The terms "message content" and "mail data" are used interchangeably | |
682 | in this document to describe the material transmitted after the DATA | |
683 | command is accepted and before the end of data indication is | |
684 | transmitted. Message content includes message headers and the | |
685 | possibly-structured message body. The MIME specification [12] | |
686 | provides the standard mechanisms for structured message bodies. | |
687 | ||
688 | 2.3.10 Mailbox and Address | |
689 | ||
690 | As used in this specification, an "address" is a character string | |
691 | that identifies a user to whom mail will be sent or a location into | |
692 | which mail will be deposited. The term "mailbox" refers to that | |
693 | depository. The two terms are typically used interchangeably unless | |
694 | the distinction between the location in which mail is placed (the | |
695 | mailbox) and a reference to it (the address) is important. An | |
696 | address normally consists of user and domain specifications. The | |
697 | standard mailbox naming convention is defined to be "local- | |
698 | part@domain": contemporary usage permits a much broader set of | |
699 | applications than simple "user names". Consequently, and due to a | |
700 | long history of problems when intermediate hosts have attempted to | |
701 | optimize transport by modifying them, the local-part MUST be | |
702 | interpreted and assigned semantics only by the host specified in the | |
703 | domain part of the address. | |
704 | ||
705 | 2.3.11 Reply | |
706 | ||
707 | An SMTP reply is an acknowledgment (positive or negative) sent from | |
708 | receiver to sender via the transmission channel in response to a | |
709 | command. The general form of a reply is a numeric completion code | |
710 | (indicating failure or success) usually followed by a text string. | |
711 | The codes are for use by programs and the text is usually intended | |
712 | for human users. Recent work [34] has specified further structuring | |
713 | of the reply strings, including the use of supplemental and more | |
714 | specific completion codes. | |
715 | ||
716 | 2.4 General Syntax Principles and Transaction Model | |
717 | ||
718 | SMTP commands and replies have a rigid syntax. All commands begin | |
719 | with a command verb. All Replies begin with a three digit numeric | |
720 | code. In some commands and replies, arguments MUST follow the verb | |
721 | or reply code. Some commands do not accept arguments (after the | |
722 | verb), and some reply codes are followed, sometimes optionally, by | |
723 | free form text. In both cases, where text appears, it is separated | |
724 | from the verb or reply code by a space character. Complete | |
725 | definitions of commands and replies appear in section 4. | |
726 | ||
727 | ||
728 | ||
729 | ||
730 | Klensin Standards Track [Page 13] | |
731 | \f | |
732 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
733 | ||
734 | ||
735 | Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command | |
736 | and extension name keywords) are not case sensitive, with the sole | |
737 | exception in this specification of a mailbox local-part (SMTP | |
738 | Extensions may explicitly specify case-sensitive elements). That is, | |
739 | a command verb, an argument value other than a mailbox local-part, | |
740 | and free form text MAY be encoded in upper case, lower case, or any | |
741 | mixture of upper and lower case with no impact on its meaning. This | |
742 | is NOT true of a mailbox local-part. The local-part of a mailbox | |
743 | MUST BE treated as case sensitive. Therefore, SMTP implementations | |
744 | MUST take care to preserve the case of mailbox local-parts. Mailbox | |
745 | domains are not case sensitive. In particular, for some hosts the | |
746 | user "smith" is different from the user "Smith". However, exploiting | |
747 | the case sensitivity of mailbox local-parts impedes interoperability | |
748 | and is discouraged. | |
749 | ||
750 | A few SMTP servers, in violation of this specification (and RFC 821) | |
751 | require that command verbs be encoded by clients in upper case. | |
752 | Implementations MAY wish to employ this encoding to accommodate those | |
753 | servers. | |
754 | ||
755 | The argument field consists of a variable length character string | |
756 | ending with the end of the line, i.e., with the character sequence | |
757 | <CRLF>. The receiver will take no action until this sequence is | |
758 | received. | |
759 | ||
760 | The syntax for each command is shown with the discussion of that | |
761 | command. Common elements and parameters are shown in section 4.1.2. | |
762 | ||
763 | Commands and replies are composed of characters from the ASCII | |
764 | character set [1]. When the transport service provides an 8-bit byte | |
765 | (octet) transmission channel, each 7-bit character is transmitted | |
766 | right justified in an octet with the high order bit cleared to zero. | |
767 | More specifically, the unextended SMTP service provides seven bit | |
768 | transport only. An originating SMTP client which has not | |
769 | successfully negotiated an appropriate extension with a particular | |
770 | server MUST NOT transmit messages with information in the high-order | |
771 | bit of octets. If such messages are transmitted in violation of this | |
772 | rule, receiving SMTP servers MAY clear the high-order bit or reject | |
773 | the message as invalid. In general, a relay SMTP SHOULD assume that | |
774 | the message content it has received is valid and, assuming that the | |
775 | envelope permits doing so, relay it without inspecting that content. | |
776 | Of course, if the content is mislabeled and the data path cannot | |
777 | accept the actual content, this may result in ultimate delivery of a | |
778 | severely garbled message to the recipient. Delivery SMTP systems MAY | |
779 | reject ("bounce") such messages rather than deliver them. No sending | |
780 | SMTP system is permitted to send envelope commands in any character | |
781 | ||
782 | ||
783 | ||
784 | ||
785 | ||
786 | Klensin Standards Track [Page 14] | |
787 | \f | |
788 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
789 | ||
790 | ||
791 | set other than US-ASCII; receiving systems SHOULD reject such | |
792 | commands, normally using "500 syntax error - invalid character" | |
793 | replies. | |
794 | ||
795 | Eight-bit message content transmission MAY be requested of the server | |
796 | by a client using extended SMTP facilities, notably the "8BITMIME" | |
797 | extension [20]. 8BITMIME SHOULD be supported by SMTP servers. | |
798 | However, it MUST not be construed as authorization to transmit | |
799 | unrestricted eight bit material. 8BITMIME MUST NOT be requested by | |
800 | senders for material with the high bit on that is not in MIME format | |
801 | with an appropriate content-transfer encoding; servers MAY reject | |
802 | such messages. | |
803 | ||
804 | The metalinguistic notation used in this document corresponds to the | |
805 | "Augmented BNF" used in other Internet mail system documents. The | |
806 | reader who is not familiar with that syntax should consult the ABNF | |
807 | specification [8]. Metalanguage terms used in running text are | |
808 | surrounded by pointed brackets (e.g., <CRLF>) for clarity. | |
809 | ||
810 | 3. The SMTP Procedures: An Overview | |
811 | ||
812 | This section contains descriptions of the procedures used in SMTP: | |
813 | session initiation, the mail transaction, forwarding mail, verifying | |
814 | mailbox names and expanding mailing lists, and the opening and | |
815 | closing exchanges. Comments on relaying, a note on mail domains, and | |
816 | a discussion of changing roles are included at the end of this | |
817 | section. Several complete scenarios are presented in appendix D. | |
818 | ||
819 | 3.1 Session Initiation | |
820 | ||
821 | An SMTP session is initiated when a client opens a connection to a | |
822 | server and the server responds with an opening message. | |
823 | ||
824 | SMTP server implementations MAY include identification of their | |
825 | software and version information in the connection greeting reply | |
826 | after the 220 code, a practice that permits more efficient isolation | |
827 | and repair of any problems. Implementations MAY make provision for | |
828 | SMTP servers to disable the software and version announcement where | |
829 | it causes security concerns. While some systems also identify their | |
830 | contact point for mail problems, this is not a substitute for | |
831 | maintaining the required "postmaster" address (see section 4.5.1). | |
832 | ||
833 | The SMTP protocol allows a server to formally reject a transaction | |
834 | while still allowing the initial connection as follows: a 554 | |
835 | response MAY be given in the initial connection opening message | |
836 | instead of the 220. A server taking this approach MUST still wait | |
837 | for the client to send a QUIT (see section 4.1.1.10) before closing | |
838 | the connection and SHOULD respond to any intervening commands with | |
839 | ||
840 | ||
841 | ||
842 | Klensin Standards Track [Page 15] | |
843 | \f | |
844 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
845 | ||
846 | ||
847 | "503 bad sequence of commands". Since an attempt to make an SMTP | |
848 | connection to such a system is probably in error, a server returning | |
849 | a 554 response on connection opening SHOULD provide enough | |
850 | information in the reply text to facilitate debugging of the sending | |
851 | system. | |
852 | ||
853 | 3.2 Client Initiation | |
854 | ||
855 | Once the server has sent the welcoming message and the client has | |
856 | received it, the client normally sends the EHLO command to the | |
857 | server, indicating the client's identity. In addition to opening the | |
858 | session, use of EHLO indicates that the client is able to process | |
859 | service extensions and requests that the server provide a list of the | |
860 | extensions it supports. Older SMTP systems which are unable to | |
861 | support service extensions and contemporary clients which do not | |
862 | require service extensions in the mail session being initiated, MAY | |
863 | use HELO instead of EHLO. Servers MUST NOT return the extended | |
864 | EHLO-style response to a HELO command. For a particular connection | |
865 | attempt, if the server returns a "command not recognized" response to | |
866 | EHLO, the client SHOULD be able to fall back and send HELO. | |
867 | ||
868 | In the EHLO command the host sending the command identifies itself; | |
869 | the command may be interpreted as saying "Hello, I am <domain>" (and, | |
870 | in the case of EHLO, "and I support service extension requests"). | |
871 | ||
872 | 3.3 Mail Transactions | |
873 | ||
874 | There are three steps to SMTP mail transactions. The transaction | |
875 | starts with a MAIL command which gives the sender identification. | |
876 | (In general, the MAIL command may be sent only when no mail | |
877 | transaction is in progress; see section 4.1.4.) A series of one or | |
878 | more RCPT commands follows giving the receiver information. Then a | |
879 | DATA command initiates transfer of the mail data and is terminated by | |
880 | the "end of mail" data indicator, which also confirms the | |
881 | transaction. | |
882 | ||
883 | The first step in the procedure is the MAIL command. | |
884 | ||
885 | MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF> | |
886 | ||
887 | This command tells the SMTP-receiver that a new mail transaction is | |
888 | starting and to reset all its state tables and buffers, including any | |
889 | recipients or mail data. The <reverse-path> portion of the first or | |
890 | only argument contains the source mailbox (between "<" and ">" | |
891 | brackets), which can be used to report errors (see section 4.2 for a | |
892 | discussion of error reporting). If accepted, the SMTP server returns | |
893 | a 250 OK reply. If the mailbox specification is not acceptable for | |
894 | some reason, the server MUST return a reply indicating whether the | |
895 | ||
896 | ||
897 | ||
898 | Klensin Standards Track [Page 16] | |
899 | \f | |
900 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
901 | ||
902 | ||
903 | failure is permanent (i.e., will occur again if the client tries to | |
904 | send the same address again) or temporary (i.e., the address might be | |
905 | accepted if the client tries again later). Despite the apparent | |
906 | scope of this requirement, there are circumstances in which the | |
907 | acceptability of the reverse-path may not be determined until one or | |
908 | more forward-paths (in RCPT commands) can be examined. In those | |
909 | cases, the server MAY reasonably accept the reverse-path (with a 250 | |
910 | reply) and then report problems after the forward-paths are received | |
911 | and examined. Normally, failures produce 550 or 553 replies. | |
912 | ||
913 | Historically, the <reverse-path> can contain more than just a | |
914 | mailbox, however, contemporary systems SHOULD NOT use source routing | |
915 | (see appendix C). | |
916 | ||
917 | The optional <mail-parameters> are associated with negotiated SMTP | |
918 | service extensions (see section 2.2). | |
919 | ||
920 | The second step in the procedure is the RCPT command. | |
921 | ||
922 | RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF> | |
923 | ||
924 | The first or only argument to this command includes a forward-path | |
925 | (normally a mailbox and domain, always surrounded by "<" and ">" | |
926 | brackets) identifying one recipient. If accepted, the SMTP server | |
927 | returns a 250 OK reply and stores the forward-path. If the recipient | |
928 | is known not to be a deliverable address, the SMTP server returns a | |
929 | 550 reply, typically with a string such as "no such user - " and the | |
930 | mailbox name (other circumstances and reply codes are possible). | |
931 | This step of the procedure can be repeated any number of times. | |
932 | ||
933 | The <forward-path> can contain more than just a mailbox. | |
934 | Historically, the <forward-path> can be a source routing list of | |
935 | hosts and the destination mailbox, however, contemporary SMTP clients | |
936 | SHOULD NOT utilize source routes (see appendix C). Servers MUST be | |
937 | prepared to encounter a list of source routes in the forward path, | |
938 | but SHOULD ignore the routes or MAY decline to support the relaying | |
939 | they imply. Similarly, servers MAY decline to accept mail that is | |
940 | destined for other hosts or systems. These restrictions make a | |
941 | server useless as a relay for clients that do not support full SMTP | |
942 | functionality. Consequently, restricted-capability clients MUST NOT | |
943 | assume that any SMTP server on the Internet can be used as their mail | |
944 | processing (relaying) site. If a RCPT command appears without a | |
945 | previous MAIL command, the server MUST return a 503 "Bad sequence of | |
946 | commands" response. The optional <rcpt-parameters> are associated | |
947 | with negotiated SMTP service extensions (see section 2.2). | |
948 | ||
949 | The third step in the procedure is the DATA command (or some | |
950 | alternative specified in a service extension). | |
951 | ||
952 | ||
953 | ||
954 | Klensin Standards Track [Page 17] | |
955 | \f | |
956 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
957 | ||
958 | ||
959 | DATA <CRLF> | |
960 | ||
961 | If accepted, the SMTP server returns a 354 Intermediate reply and | |
962 | considers all succeeding lines up to but not including the end of | |
963 | mail data indicator to be the message text. When the end of text is | |
964 | successfully received and stored the SMTP-receiver sends a 250 OK | |
965 | reply. | |
966 | ||
967 | Since the mail data is sent on the transmission channel, the end of | |
968 | mail data must be indicated so that the command and reply dialog can | |
969 | be resumed. SMTP indicates the end of the mail data by sending a | |
970 | line containing only a "." (period or full stop). A transparency | |
971 | procedure is used to prevent this from interfering with the user's | |
972 | text (see section 4.5.2). | |
973 | ||
974 | The end of mail data indicator also confirms the mail transaction and | |
975 | tells the SMTP server to now process the stored recipients and mail | |
976 | data. If accepted, the SMTP server returns a 250 OK reply. The DATA | |
977 | command can fail at only two points in the protocol exchange: | |
978 | ||
979 | - If there was no MAIL, or no RCPT, command, or all such commands | |
980 | were rejected, the server MAY return a "command out of sequence" | |
981 | (503) or "no valid recipients" (554) reply in response to the DATA | |
982 | command. If one of those replies (or any other 5yz reply) is | |
983 | received, the client MUST NOT send the message data; more | |
984 | generally, message data MUST NOT be sent unless a 354 reply is | |
985 | received. | |
986 | ||
987 | - If the verb is initially accepted and the 354 reply issued, the | |
988 | DATA command should fail only if the mail transaction was | |
989 | incomplete (for example, no recipients), or if resources were | |
990 | unavailable (including, of course, the server unexpectedly | |
991 | becoming unavailable), or if the server determines that the | |
992 | message should be rejected for policy or other reasons. | |
993 | ||
994 | However, in practice, some servers do not perform recipient | |
995 | verification until after the message text is received. These servers | |
996 | SHOULD treat a failure for one or more recipients as a "subsequent | |
997 | failure" and return a mail message as discussed in section 6. Using | |
998 | a "550 mailbox not found" (or equivalent) reply code after the data | |
999 | are accepted makes it difficult or impossible for the client to | |
1000 | determine which recipients failed. | |
1001 | ||
1002 | When RFC 822 format [7, 32] is being used, the mail data include the | |
1003 | memo header items such as Date, Subject, To, Cc, From. Server SMTP | |
1004 | systems SHOULD NOT reject messages based on perceived defects in the | |
1005 | RFC 822 or MIME [12] message header or message body. In particular, | |
1006 | ||
1007 | ||
1008 | ||
1009 | ||
1010 | Klensin Standards Track [Page 18] | |
1011 | \f | |
1012 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1013 | ||
1014 | ||
1015 | they MUST NOT reject messages in which the numbers of Resent-fields | |
1016 | do not match or Resent-to appears without Resent-from and/or Resent- | |
1017 | date. | |
1018 | ||
1019 | Mail transaction commands MUST be used in the order discussed above. | |
1020 | ||
1021 | 3.4 Forwarding for Address Correction or Updating | |
1022 | ||
1023 | Forwarding support is most often required to consolidate and simplify | |
1024 | addresses within, or relative to, some enterprise and less frequently | |
1025 | to establish addresses to link a person's prior address with current | |
1026 | one. Silent forwarding of messages (without server notification to | |
1027 | the sender), for security or non-disclosure purposes, is common in | |
1028 | the contemporary Internet. | |
1029 | ||
1030 | In both the enterprise and the "new address" cases, information | |
1031 | hiding (and sometimes security) considerations argue against exposure | |
1032 | of the "final" address through the SMTP protocol as a side-effect of | |
1033 | the forwarding activity. This may be especially important when the | |
1034 | final address may not even be reachable by the sender. Consequently, | |
1035 | the "forwarding" mechanisms described in section 3.2 of RFC 821, and | |
1036 | especially the 251 (corrected destination) and 551 reply codes from | |
1037 | RCPT must be evaluated carefully by implementers and, when they are | |
1038 | available, by those configuring systems. | |
1039 | ||
1040 | In particular: | |
1041 | ||
1042 | * Servers MAY forward messages when they are aware of an address | |
1043 | change. When they do so, they MAY either provide address-updating | |
1044 | information with a 251 code, or may forward "silently" and return | |
1045 | a 250 code. But, if a 251 code is used, they MUST NOT assume that | |
1046 | the client will actually update address information or even return | |
1047 | that information to the user. | |
1048 | ||
1049 | Alternately, | |
1050 | ||
1051 | * Servers MAY reject or bounce messages when they are not | |
1052 | deliverable when addressed. When they do so, they MAY either | |
1053 | provide address-updating information with a 551 code, or may | |
1054 | reject the message as undeliverable with a 550 code and no | |
1055 | address-specific information. But, if a 551 code is used, they | |
1056 | MUST NOT assume that the client will actually update address | |
1057 | information or even return that information to the user. | |
1058 | ||
1059 | SMTP server implementations that support the 251 and/or 551 reply | |
1060 | codes are strongly encouraged to provide configuration mechanisms so | |
1061 | that sites which conclude that they would undesirably disclose | |
1062 | information can disable or restrict their use. | |
1063 | ||
1064 | ||
1065 | ||
1066 | Klensin Standards Track [Page 19] | |
1067 | \f | |
1068 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1069 | ||
1070 | ||
1071 | 3.5 Commands for Debugging Addresses | |
1072 | ||
1073 | 3.5.1 Overview | |
1074 | ||
1075 | SMTP provides commands to verify a user name or obtain the content of | |
1076 | a mailing list. This is done with the VRFY and EXPN commands, which | |
1077 | have character string arguments. Implementations SHOULD support VRFY | |
1078 | and EXPN (however, see section 3.5.2 and 7.3). | |
1079 | ||
1080 | For the VRFY command, the string is a user name or a user name and | |
1081 | domain (see below). If a normal (i.e., 250) response is returned, | |
1082 | the response MAY include the full name of the user and MUST include | |
1083 | the mailbox of the user. It MUST be in either of the following | |
1084 | forms: | |
1085 | ||
1086 | User Name <local-part@domain> | |
1087 | local-part@domain | |
1088 | ||
1089 | When a name that is the argument to VRFY could identify more than one | |
1090 | mailbox, the server MAY either note the ambiguity or identify the | |
1091 | alternatives. In other words, any of the following are legitimate | |
1092 | response to VRFY: | |
1093 | ||
1094 | 553 User ambiguous | |
1095 | ||
1096 | or | |
1097 | ||
1098 | 553- Ambiguous; Possibilities are | |
1099 | 553-Joe Smith <jsmith@foo.com> | |
1100 | 553-Harry Smith <hsmith@foo.com> | |
1101 | 553 Melvin Smith <dweep@foo.com> | |
1102 | ||
1103 | or | |
1104 | ||
1105 | 553-Ambiguous; Possibilities | |
1106 | 553- <jsmith@foo.com> | |
1107 | 553- <hsmith@foo.com> | |
1108 | 553 <dweep@foo.com> | |
1109 | ||
1110 | Under normal circumstances, a client receiving a 553 reply would be | |
1111 | expected to expose the result to the user. Use of exactly the forms | |
1112 | given, and the "user ambiguous" or "ambiguous" keywords, possibly | |
1113 | supplemented by extended reply codes such as those described in [34], | |
1114 | will facilitate automated translation into other languages as needed. | |
1115 | Of course, a client that was highly automated or that was operating | |
1116 | in another language than English, might choose to try to translate | |
1117 | the response, to return some other indication to the user than the | |
1118 | ||
1119 | ||
1120 | ||
1121 | ||
1122 | Klensin Standards Track [Page 20] | |
1123 | \f | |
1124 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1125 | ||
1126 | ||
1127 | literal text of the reply, or to take some automated action such as | |
1128 | consulting a directory service for additional information before | |
1129 | reporting to the user. | |
1130 | ||
1131 | For the EXPN command, the string identifies a mailing list, and the | |
1132 | successful (i.e., 250) multiline response MAY include the full name | |
1133 | of the users and MUST give the mailboxes on the mailing list. | |
1134 | ||
1135 | In some hosts the distinction between a mailing list and an alias for | |
1136 | a single mailbox is a bit fuzzy, since a common data structure may | |
1137 | hold both types of entries, and it is possible to have mailing lists | |
1138 | containing only one mailbox. If a request is made to apply VRFY to a | |
1139 | mailing list, a positive response MAY be given if a message so | |
1140 | addressed would be delivered to everyone on the list, otherwise an | |
1141 | error SHOULD be reported (e.g., "550 That is a mailing list, not a | |
1142 | user" or "252 Unable to verify members of mailing list"). If a | |
1143 | request is made to expand a user name, the server MAY return a | |
1144 | positive response consisting of a list containing one name, or an | |
1145 | error MAY be reported (e.g., "550 That is a user name, not a mailing | |
1146 | list"). | |
1147 | ||
1148 | In the case of a successful multiline reply (normal for EXPN) exactly | |
1149 | one mailbox is to be specified on each line of the reply. The case | |
1150 | of an ambiguous request is discussed above. | |
1151 | ||
1152 | "User name" is a fuzzy term and has been used deliberately. An | |
1153 | implementation of the VRFY or EXPN commands MUST include at least | |
1154 | recognition of local mailboxes as "user names". However, since | |
1155 | current Internet practice often results in a single host handling | |
1156 | mail for multiple domains, hosts, especially hosts that provide this | |
1157 | functionality, SHOULD accept the "local-part@domain" form as a "user | |
1158 | name"; hosts MAY also choose to recognize other strings as "user | |
1159 | names". | |
1160 | ||
1161 | The case of expanding a mailbox list requires a multiline reply, such | |
1162 | as: | |
1163 | ||
1164 | C: EXPN Example-People | |
1165 | S: 250-Jon Postel <Postel@isi.edu> | |
1166 | S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> | |
1167 | S: 250 Sam Q. Smith <SQSmith@specific.generic.com> | |
1168 | ||
1169 | or | |
1170 | ||
1171 | C: EXPN Executive-Washroom-List | |
1172 | S: 550 Access Denied to You. | |
1173 | ||
1174 | ||
1175 | ||
1176 | ||
1177 | ||
1178 | Klensin Standards Track [Page 21] | |
1179 | \f | |
1180 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1181 | ||
1182 | ||
1183 | The character string arguments of the VRFY and EXPN commands cannot | |
1184 | be further restricted due to the variety of implementations of the | |
1185 | user name and mailbox list concepts. On some systems it may be | |
1186 | appropriate for the argument of the EXPN command to be a file name | |
1187 | for a file containing a mailing list, but again there are a variety | |
1188 | of file naming conventions in the Internet. Similarly, historical | |
1189 | variations in what is returned by these commands are such that the | |
1190 | response SHOULD be interpreted very carefully, if at all, and SHOULD | |
1191 | generally only be used for diagnostic purposes. | |
1192 | ||
1193 | 3.5.2 VRFY Normal Response | |
1194 | ||
1195 | When normal (2yz or 551) responses are returned from a VRFY or EXPN | |
1196 | request, the reply normally includes the mailbox name, i.e., | |
1197 | "<local-part@domain>", where "domain" is a fully qualified domain | |
1198 | name, MUST appear in the syntax. In circumstances exceptional enough | |
1199 | to justify violating the intent of this specification, free-form text | |
1200 | MAY be returned. In order to facilitate parsing by both computers | |
1201 | and people, addresses SHOULD appear in pointed brackets. When | |
1202 | addresses, rather than free-form debugging information, are returned, | |
1203 | EXPN and VRFY MUST return only valid domain addresses that are usable | |
1204 | in SMTP RCPT commands. Consequently, if an address implies delivery | |
1205 | to a program or other system, the mailbox name used to reach that | |
1206 | target MUST be given. Paths (explicit source routes) MUST NOT be | |
1207 | returned by VRFY or EXPN. | |
1208 | ||
1209 | Server implementations SHOULD support both VRFY and EXPN. For | |
1210 | security reasons, implementations MAY provide local installations a | |
1211 | way to disable either or both of these commands through configuration | |
1212 | options or the equivalent. When these commands are supported, they | |
1213 | are not required to work across relays when relaying is supported. | |
1214 | Since they were both optional in RFC 821, they MUST be listed as | |
1215 | service extensions in an EHLO response, if they are supported. | |
1216 | ||
1217 | 3.5.3 Meaning of VRFY or EXPN Success Response | |
1218 | ||
1219 | A server MUST NOT return a 250 code in response to a VRFY or EXPN | |
1220 | command unless it has actually verified the address. In particular, | |
1221 | a server MUST NOT return 250 if all it has done is to verify that the | |
1222 | syntax given is valid. In that case, 502 (Command not implemented) | |
1223 | or 500 (Syntax error, command unrecognized) SHOULD be returned. As | |
1224 | stated elsewhere, implementation (in the sense of actually validating | |
1225 | addresses and returning information) of VRFY and EXPN are strongly | |
1226 | recommended. Hence, implementations that return 500 or 502 for VRFY | |
1227 | are not in full compliance with this specification. | |
1228 | ||
1229 | ||
1230 | ||
1231 | ||
1232 | ||
1233 | ||
1234 | Klensin Standards Track [Page 22] | |
1235 | \f | |
1236 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1237 | ||
1238 | ||
1239 | There may be circumstances where an address appears to be valid but | |
1240 | cannot reasonably be verified in real time, particularly when a | |
1241 | server is acting as a mail exchanger for another server or domain. | |
1242 | "Apparent validity" in this case would normally involve at least | |
1243 | syntax checking and might involve verification that any domains | |
1244 | specified were ones to which the host expected to be able to relay | |
1245 | mail. In these situations, reply code 252 SHOULD be returned. These | |
1246 | cases parallel the discussion of RCPT verification discussed in | |
1247 | section 2.1. Similarly, the discussion in section 3.4 applies to the | |
1248 | use of reply codes 251 and 551 with VRFY (and EXPN) to indicate | |
1249 | addresses that are recognized but that would be forwarded or bounced | |
1250 | were mail received for them. Implementations generally SHOULD be | |
1251 | more aggressive about address verification in the case of VRFY than | |
1252 | in the case of RCPT, even if it takes a little longer to do so. | |
1253 | ||
1254 | 3.5.4 Semantics and Applications of EXPN | |
1255 | ||
1256 | EXPN is often very useful in debugging and understanding problems | |
1257 | with mailing lists and multiple-target-address aliases. Some systems | |
1258 | have attempted to use source expansion of mailing lists as a means of | |
1259 | eliminating duplicates. The propagation of aliasing systems with | |
1260 | mail on the Internet, for hosts (typically with MX and CNAME DNS | |
1261 | records), for mailboxes (various types of local host aliases), and in | |
1262 | various proxying arrangements, has made it nearly impossible for | |
1263 | these strategies to work consistently, and mail systems SHOULD NOT | |
1264 | attempt them. | |
1265 | ||
1266 | 3.6 Domains | |
1267 | ||
1268 | Only resolvable, fully-qualified, domain names (FQDNs) are permitted | |
1269 | when domain names are used in SMTP. In other words, names that can | |
1270 | be resolved to MX RRs or A RRs (as discussed in section 5) are | |
1271 | permitted, as are CNAME RRs whose targets can be resolved, in turn, | |
1272 | to MX or A RRs. Local nicknames or unqualified names MUST NOT be | |
1273 | used. There are two exceptions to the rule requiring FQDNs: | |
1274 | ||
1275 | - The domain name given in the EHLO command MUST BE either a primary | |
1276 | host name (a domain name that resolves to an A RR) or, if the host | |
1277 | has no name, an address literal as described in section 4.1.1.1. | |
1278 | ||
1279 | - The reserved mailbox name "postmaster" may be used in a RCPT | |
1280 | command without domain qualification (see section 4.1.1.3) and | |
1281 | MUST be accepted if so used. | |
1282 | ||
1283 | ||
1284 | ||
1285 | ||
1286 | ||
1287 | ||
1288 | ||
1289 | ||
1290 | Klensin Standards Track [Page 23] | |
1291 | \f | |
1292 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1293 | ||
1294 | ||
1295 | 3.7 Relaying | |
1296 | ||
1297 | In general, the availability of Mail eXchanger records in the domain | |
1298 | name system [22, 27] makes the use of explicit source routes in the | |
1299 | Internet mail system unnecessary. Many historical problems with | |
1300 | their interpretation have made their use undesirable. SMTP clients | |
1301 | SHOULD NOT generate explicit source routes except under unusual | |
1302 | circumstances. SMTP servers MAY decline to act as mail relays or to | |
1303 | accept addresses that specify source routes. When route information | |
1304 | is encountered, SMTP servers are also permitted to ignore the route | |
1305 | information and simply send to the final destination specified as the | |
1306 | last element in the route and SHOULD do so. There has been an | |
1307 | invalid practice of using names that do not appear in the DNS as | |
1308 | destination names, with the senders counting on the intermediate | |
1309 | hosts specified in source routing to resolve any problems. If source | |
1310 | routes are stripped, this practice will cause failures. This is one | |
1311 | of several reasons why SMTP clients MUST NOT generate invalid source | |
1312 | routes or depend on serial resolution of names. | |
1313 | ||
1314 | When source routes are not used, the process described in RFC 821 for | |
1315 | constructing a reverse-path from the forward-path is not applicable | |
1316 | and the reverse-path at the time of delivery will simply be the | |
1317 | address that appeared in the MAIL command. | |
1318 | ||
1319 | A relay SMTP server is usually the target of a DNS MX record that | |
1320 | designates it, rather than the final delivery system. The relay | |
1321 | server may accept or reject the task of relaying the mail in the same | |
1322 | way it accepts or rejects mail for a local user. If it accepts the | |
1323 | task, it then becomes an SMTP client, establishes a transmission | |
1324 | channel to the next SMTP server specified in the DNS (according to | |
1325 | the rules in section 5), and sends it the mail. If it declines to | |
1326 | relay mail to a particular address for policy reasons, a 550 response | |
1327 | SHOULD be returned. | |
1328 | ||
1329 | Many mail-sending clients exist, especially in conjunction with | |
1330 | facilities that receive mail via POP3 or IMAP, that have limited | |
1331 | capability to support some of the requirements of this specification, | |
1332 | such as the ability to queue messages for subsequent delivery | |
1333 | attempts. For these clients, it is common practice to make private | |
1334 | arrangements to send all messages to a single server for processing | |
1335 | and subsequent distribution. SMTP, as specified here, is not ideally | |
1336 | suited for this role, and work is underway on standardized mail | |
1337 | submission protocols that might eventually supercede the current | |
1338 | practices. In any event, because these arrangements are private and | |
1339 | fall outside the scope of this specification, they are not described | |
1340 | here. | |
1341 | ||
1342 | ||
1343 | ||
1344 | ||
1345 | ||
1346 | Klensin Standards Track [Page 24] | |
1347 | \f | |
1348 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1349 | ||
1350 | ||
1351 | It is important to note that MX records can point to SMTP servers | |
1352 | which act as gateways into other environments, not just SMTP relays | |
1353 | and final delivery systems; see sections 3.8 and 5. | |
1354 | ||
1355 | If an SMTP server has accepted the task of relaying the mail and | |
1356 | later finds that the destination is incorrect or that the mail cannot | |
1357 | be delivered for some other reason, then it MUST construct an | |
1358 | "undeliverable mail" notification message and send it to the | |
1359 | originator of the undeliverable mail (as indicated by the reverse- | |
1360 | path). Formats specified for non-delivery reports by other standards | |
1361 | (see, for example, [24, 25]) SHOULD be used if possible. | |
1362 | ||
1363 | This notification message must be from the SMTP server at the relay | |
1364 | host or the host that first determines that delivery cannot be | |
1365 | accomplished. Of course, SMTP servers MUST NOT send notification | |
1366 | messages about problems transporting notification messages. One way | |
1367 | to prevent loops in error reporting is to specify a null reverse-path | |
1368 | in the MAIL command of a notification message. When such a message | |
1369 | is transmitted the reverse-path MUST be set to null (see section | |
1370 | 4.5.5 for additional discussion). A MAIL command with a null | |
1371 | reverse-path appears as follows: | |
1372 | ||
1373 | MAIL FROM:<> | |
1374 | ||
1375 | As discussed in section 2.4.1, a relay SMTP has no need to inspect or | |
1376 | act upon the headers or body of the message data and MUST NOT do so | |
1377 | except to add its own "Received:" header (section 4.4) and, | |
1378 | optionally, to attempt to detect looping in the mail system (see | |
1379 | section 6.2). | |
1380 | ||
1381 | 3.8 Mail Gatewaying | |
1382 | ||
1383 | While the relay function discussed above operates within the Internet | |
1384 | SMTP transport service environment, MX records or various forms of | |
1385 | explicit routing may require that an intermediate SMTP server perform | |
1386 | a translation function between one transport service and another. As | |
1387 | discussed in section 2.3.8, when such a system is at the boundary | |
1388 | between two transport service environments, we refer to it as a | |
1389 | "gateway" or "gateway SMTP". | |
1390 | ||
1391 | Gatewaying mail between different mail environments, such as | |
1392 | different mail formats and protocols, is complex and does not easily | |
1393 | yield to standardization. However, some general requirements may be | |
1394 | given for a gateway between the Internet and another mail | |
1395 | environment. | |
1396 | ||
1397 | ||
1398 | ||
1399 | ||
1400 | ||
1401 | ||
1402 | Klensin Standards Track [Page 25] | |
1403 | \f | |
1404 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1405 | ||
1406 | ||
1407 | 3.8.1 Header Fields in Gatewaying | |
1408 | ||
1409 | Header fields MAY be rewritten when necessary as messages are | |
1410 | gatewayed across mail environment boundaries. This may involve | |
1411 | inspecting the message body or interpreting the local-part of the | |
1412 | destination address in spite of the prohibitions in section 2.4.1. | |
1413 | ||
1414 | Other mail systems gatewayed to the Internet often use a subset of | |
1415 | RFC 822 headers or provide similar functionality with a different | |
1416 | syntax, but some of these mail systems do not have an equivalent to | |
1417 | the SMTP envelope. Therefore, when a message leaves the Internet | |
1418 | environment, it may be necessary to fold the SMTP envelope | |
1419 | information into the message header. A possible solution would be to | |
1420 | create new header fields to carry the envelope information (e.g., | |
1421 | "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would require | |
1422 | changes in mail programs in foreign environments and might risk | |
1423 | disclosure of private information (see section 7.2). | |
1424 | ||
1425 | 3.8.2 Received Lines in Gatewaying | |
1426 | ||
1427 | When forwarding a message into or out of the Internet environment, a | |
1428 | gateway MUST prepend a Received: line, but it MUST NOT alter in any | |
1429 | way a Received: line that is already in the header. | |
1430 | ||
1431 | "Received:" fields of messages originating from other environments | |
1432 | may not conform exactly to this specification. However, the most | |
1433 | important use of Received: lines is for debugging mail faults, and | |
1434 | this debugging can be severely hampered by well-meaning gateways that | |
1435 | try to "fix" a Received: line. As another consequence of trace | |
1436 | fields arising in non-SMTP environments, receiving systems MUST NOT | |
1437 | reject mail based on the format of a trace field and SHOULD be | |
1438 | extremely robust in the light of unexpected information or formats in | |
1439 | those fields. | |
1440 | ||
1441 | The gateway SHOULD indicate the environment and protocol in the "via" | |
1442 | clauses of Received field(s) that it supplies. | |
1443 | ||
1444 | 3.8.3 Addresses in Gatewaying | |
1445 | ||
1446 | From the Internet side, the gateway SHOULD accept all valid address | |
1447 | formats in SMTP commands and in RFC 822 headers, and all valid RFC | |
1448 | 822 messages. Addresses and headers generated by gateways MUST | |
1449 | conform to applicable Internet standards (including this one and RFC | |
1450 | 822). Gateways are, of course, subject to the same rules for | |
1451 | handling source routes as those described for other SMTP systems in | |
1452 | section 3.3. | |
1453 | ||
1454 | ||
1455 | ||
1456 | ||
1457 | ||
1458 | Klensin Standards Track [Page 26] | |
1459 | \f | |
1460 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1461 | ||
1462 | ||
1463 | 3.8.4 Other Header Fields in Gatewaying | |
1464 | ||
1465 | The gateway MUST ensure that all header fields of a message that it | |
1466 | forwards into the Internet mail environment meet the requirements for | |
1467 | Internet mail. In particular, all addresses in "From:", "To:", | |
1468 | "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC | |
1469 | 822 syntax, MUST reference only fully-qualified domain names, and | |
1470 | MUST be effective and useful for sending replies. The translation | |
1471 | algorithm used to convert mail from the Internet protocols to another | |
1472 | environment's protocol SHOULD ensure that error messages from the | |
1473 | foreign mail environment are delivered to the return path from the | |
1474 | SMTP envelope, not to the sender listed in the "From:" field (or | |
1475 | other fields) of the RFC 822 message. | |
1476 | ||
1477 | 3.8.5 Envelopes in Gatewaying | |
1478 | ||
1479 | Similarly, when forwarding a message from another environment into | |
1480 | the Internet, the gateway SHOULD set the envelope return path in | |
1481 | accordance with an error message return address, if supplied by the | |
1482 | foreign environment. If the foreign environment has no equivalent | |
1483 | concept, the gateway must select and use a best approximation, with | |
1484 | the message originator's address as the default of last resort. | |
1485 | ||
1486 | 3.9 Terminating Sessions and Connections | |
1487 | ||
1488 | An SMTP connection is terminated when the client sends a QUIT | |
1489 | command. The server responds with a positive reply code, after which | |
1490 | it closes the connection. | |
1491 | ||
1492 | An SMTP server MUST NOT intentionally close the connection except: | |
1493 | ||
1494 | - After receiving a QUIT command and responding with a 221 reply. | |
1495 | ||
1496 | - After detecting the need to shut down the SMTP service and | |
1497 | returning a 421 response code. This response code can be issued | |
1498 | after the server receives any command or, if necessary, | |
1499 | asynchronously from command receipt (on the assumption that the | |
1500 | client will receive it after the next command is issued). | |
1501 | ||
1502 | In particular, a server that closes connections in response to | |
1503 | commands that are not understood is in violation of this | |
1504 | specification. Servers are expected to be tolerant of unknown | |
1505 | commands, issuing a 500 reply and awaiting further instructions from | |
1506 | the client. | |
1507 | ||
1508 | ||
1509 | ||
1510 | ||
1511 | ||
1512 | ||
1513 | ||
1514 | Klensin Standards Track [Page 27] | |
1515 | \f | |
1516 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1517 | ||
1518 | ||
1519 | An SMTP server which is forcibly shut down via external means SHOULD | |
1520 | attempt to send a line containing a 421 response code to the SMTP | |
1521 | client before exiting. The SMTP client will normally read the 421 | |
1522 | response code after sending its next command. | |
1523 | ||
1524 | SMTP clients that experience a connection close, reset, or other | |
1525 | communications failure due to circumstances not under their control | |
1526 | (in violation of the intent of this specification but sometimes | |
1527 | unavoidable) SHOULD, to maintain the robustness of the mail system, | |
1528 | treat the mail transaction as if a 451 response had been received and | |
1529 | act accordingly. | |
1530 | ||
1531 | 3.10 Mailing Lists and Aliases | |
1532 | ||
1533 | An SMTP-capable host SHOULD support both the alias and the list | |
1534 | models of address expansion for multiple delivery. When a message is | |
1535 | delivered or forwarded to each address of an expanded list form, the | |
1536 | return address in the envelope ("MAIL FROM:") MUST be changed to be | |
1537 | the address of a person or other entity who administers the list. | |
1538 | However, in this case, the message header [32] MUST be left | |
1539 | unchanged; in particular, the "From" field of the message header is | |
1540 | unaffected. | |
1541 | ||
1542 | An important mail facility is a mechanism for multi-destination | |
1543 | delivery of a single message, by transforming (or "expanding" or | |
1544 | "exploding") a pseudo-mailbox address into a list of destination | |
1545 | mailbox addresses. When a message is sent to such a pseudo-mailbox | |
1546 | (sometimes called an "exploder"), copies are forwarded or | |
1547 | redistributed to each mailbox in the expanded list. Servers SHOULD | |
1548 | simply utilize the addresses on the list; application of heuristics | |
1549 | or other matching rules to eliminate some addresses, such as that of | |
1550 | the originator, is strongly discouraged. We classify such a pseudo- | |
1551 | mailbox as an "alias" or a "list", depending upon the expansion | |
1552 | rules. | |
1553 | ||
1554 | 3.10.1 Alias | |
1555 | ||
1556 | To expand an alias, the recipient mailer simply replaces the pseudo- | |
1557 | mailbox address in the envelope with each of the expanded addresses | |
1558 | in turn; the rest of the envelope and the message body are left | |
1559 | unchanged. The message is then delivered or forwarded to each | |
1560 | expanded address. | |
1561 | ||
1562 | 3.10.2 List | |
1563 | ||
1564 | A mailing list may be said to operate by "redistribution" rather than | |
1565 | by "forwarding". To expand a list, the recipient mailer replaces the | |
1566 | pseudo-mailbox address in the envelope with all of the expanded | |
1567 | ||
1568 | ||
1569 | ||
1570 | Klensin Standards Track [Page 28] | |
1571 | \f | |
1572 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1573 | ||
1574 | ||
1575 | addresses. The return address in the envelope is changed so that all | |
1576 | error messages generated by the final deliveries will be returned to | |
1577 | a list administrator, not to the message originator, who generally | |
1578 | has no control over the contents of the list and will typically find | |
1579 | error messages annoying. | |
1580 | ||
1581 | 4. The SMTP Specifications | |
1582 | ||
1583 | 4.1 SMTP Commands | |
1584 | ||
1585 | 4.1.1 Command Semantics and Syntax | |
1586 | ||
1587 | The SMTP commands define the mail transfer or the mail system | |
1588 | function requested by the user. SMTP commands are character strings | |
1589 | terminated by <CRLF>. The commands themselves are alphabetic | |
1590 | characters terminated by <SP> if parameters follow and <CRLF> | |
1591 | otherwise. (In the interest of improved interoperability, SMTP | |
1592 | receivers are encouraged to tolerate trailing white space before the | |
1593 | terminating <CRLF>.) The syntax of the local part of a mailbox must | |
1594 | conform to receiver site conventions and the syntax specified in | |
1595 | section 4.1.2. The SMTP commands are discussed below. The SMTP | |
1596 | replies are discussed in section 4.2. | |
1597 | ||
1598 | A mail transaction involves several data objects which are | |
1599 | communicated as arguments to different commands. The reverse-path is | |
1600 | the argument of the MAIL command, the forward-path is the argument of | |
1601 | the RCPT command, and the mail data is the argument of the DATA | |
1602 | command. These arguments or data objects must be transmitted and | |
1603 | held pending the confirmation communicated by the end of mail data | |
1604 | indication which finalizes the transaction. The model for this is | |
1605 | that distinct buffers are provided to hold the types of data objects, | |
1606 | that is, there is a reverse-path buffer, a forward-path buffer, and a | |
1607 | mail data buffer. Specific commands cause information to be appended | |
1608 | to a specific buffer, or cause one or more buffers to be cleared. | |
1609 | ||
1610 | Several commands (RSET, DATA, QUIT) are specified as not permitting | |
1611 | parameters. In the absence of specific extensions offered by the | |
1612 | server and accepted by the client, clients MUST NOT send such | |
1613 | parameters and servers SHOULD reject commands containing them as | |
1614 | having invalid syntax. | |
1615 | ||
1616 | 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) | |
1617 | ||
1618 | These commands are used to identify the SMTP client to the SMTP | |
1619 | server. The argument field contains the fully-qualified domain name | |
1620 | of the SMTP client if one is available. In situations in which the | |
1621 | SMTP client system does not have a meaningful domain name (e.g., when | |
1622 | its address is dynamically allocated and no reverse mapping record is | |
1623 | ||
1624 | ||
1625 | ||
1626 | Klensin Standards Track [Page 29] | |
1627 | \f | |
1628 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1629 | ||
1630 | ||
1631 | available), the client SHOULD send an address literal (see section | |
1632 | 4.1.3), optionally followed by information that will help to identify | |
1633 | the client system. y The SMTP server identifies itself to the SMTP | |
1634 | client in the connection greeting reply and in the response to this | |
1635 | command. | |
1636 | ||
1637 | A client SMTP SHOULD start an SMTP session by issuing the EHLO | |
1638 | command. If the SMTP server supports the SMTP service extensions it | |
1639 | will give a successful response, a failure response, or an error | |
1640 | response. If the SMTP server, in violation of this specification, | |
1641 | does not support any SMTP service extensions it will generate an | |
1642 | error response. Older client SMTP systems MAY, as discussed above, | |
1643 | use HELO (as specified in RFC 821) instead of EHLO, and servers MUST | |
1644 | support the HELO command and reply properly to it. In any event, a | |
1645 | client MUST issue HELO or EHLO before starting a mail transaction. | |
1646 | ||
1647 | These commands, and a "250 OK" reply to one of them, confirm that | |
1648 | both the SMTP client and the SMTP server are in the initial state, | |
1649 | that is, there is no transaction in progress and all state tables and | |
1650 | buffers are cleared. | |
1651 | ||
1652 | Syntax: | |
1653 | ||
1654 | ehlo = "EHLO" SP Domain CRLF | |
1655 | helo = "HELO" SP Domain CRLF | |
1656 | ||
1657 | Normally, the response to EHLO will be a multiline reply. Each line | |
1658 | of the response contains a keyword and, optionally, one or more | |
1659 | parameters. Following the normal syntax for multiline replies, these | |
1660 | keyworks follow the code (250) and a hyphen for all but the last | |
1661 | line, and the code and a space for the last line. The syntax for a | |
1662 | positive response, using the ABNF notation and terminal symbols of | |
1663 | [8], is: | |
1664 | ||
1665 | ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF ) | |
1666 | / ( "250-" domain [ SP ehlo-greet ] CRLF | |
1667 | *( "250-" ehlo-line CRLF ) | |
1668 | "250" SP ehlo-line CRLF ) | |
1669 | ||
1670 | ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) | |
1671 | ; string of any characters other than CR or LF | |
1672 | ||
1673 | ehlo-line = ehlo-keyword *( SP ehlo-param ) | |
1674 | ||
1675 | ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") | |
1676 | ; additional syntax of ehlo-params depends on | |
1677 | ; ehlo-keyword | |
1678 | ||
1679 | ||
1680 | ||
1681 | ||
1682 | Klensin Standards Track [Page 30] | |
1683 | \f | |
1684 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1685 | ||
1686 | ||
1687 | ehlo-param = 1*(%d33-127) | |
1688 | ; any CHAR excluding <SP> and all | |
1689 | ; control characters (US-ASCII 0-31 inclusive) | |
1690 | ||
1691 | Although EHLO keywords may be specified in upper, lower, or mixed | |
1692 | case, they MUST always be recognized and processed in a case- | |
1693 | insensitive manner. This is simply an extension of practices | |
1694 | specified in RFC 821 and section 2.4.1. | |
1695 | ||
1696 | 4.1.1.2 MAIL (MAIL) | |
1697 | ||
1698 | This command is used to initiate a mail transaction in which the mail | |
1699 | data is delivered to an SMTP server which may, in turn, deliver it to | |
1700 | one or more mailboxes or pass it on to another system (possibly using | |
1701 | SMTP). The argument field contains a reverse-path and may contain | |
1702 | optional parameters. In general, the MAIL command may be sent only | |
1703 | when no mail transaction is in progress, see section 4.1.4. | |
1704 | ||
1705 | The reverse-path consists of the sender mailbox. Historically, that | |
1706 | mailbox might optionally have been preceded by a list of hosts, but | |
1707 | that behavior is now deprecated (see appendix C). In some types of | |
1708 | reporting messages for which a reply is likely to cause a mail loop | |
1709 | (for example, mail delivery and nondelivery notifications), the | |
1710 | reverse-path may be null (see section 3.7). | |
1711 | ||
1712 | This command clears the reverse-path buffer, the forward-path buffer, | |
1713 | and the mail data buffer; and inserts the reverse-path information | |
1714 | from this command into the reverse-path buffer. | |
1715 | ||
1716 | If service extensions were negotiated, the MAIL command may also | |
1717 | carry parameters associated with a particular service extension. | |
1718 | ||
1719 | Syntax: | |
1720 | ||
1721 | "MAIL FROM:" ("<>" / Reverse-Path) | |
1722 | [SP Mail-parameters] CRLF | |
1723 | ||
1724 | 4.1.1.3 RECIPIENT (RCPT) | |
1725 | ||
1726 | This command is used to identify an individual recipient of the mail | |
1727 | data; multiple recipients are specified by multiple use of this | |
1728 | command. The argument field contains a forward-path and may contain | |
1729 | optional parameters. | |
1730 | ||
1731 | The forward-path normally consists of the required destination | |
1732 | mailbox. Sending systems SHOULD not generate the optional list of | |
1733 | hosts known as a source route. Receiving systems MUST recognize | |
1734 | ||
1735 | ||
1736 | ||
1737 | ||
1738 | Klensin Standards Track [Page 31] | |
1739 | \f | |
1740 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1741 | ||
1742 | ||
1743 | source route syntax but SHOULD strip off the source route | |
1744 | specification and utilize the domain name associated with the mailbox | |
1745 | as if the source route had not been provided. | |
1746 | ||
1747 | Similarly, relay hosts SHOULD strip or ignore source routes, and | |
1748 | names MUST NOT be copied into the reverse-path. When mail reaches | |
1749 | its ultimate destination (the forward-path contains only a | |
1750 | destination mailbox), the SMTP server inserts it into the destination | |
1751 | mailbox in accordance with its host mail conventions. | |
1752 | ||
1753 | For example, mail received at relay host xyz.com with envelope | |
1754 | commands | |
1755 | ||
1756 | MAIL FROM:<userx@y.foo.org> | |
1757 | RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> | |
1758 | ||
1759 | will normally be sent directly on to host d.bar.org with envelope | |
1760 | commands | |
1761 | ||
1762 | MAIL FROM:<userx@y.foo.org> | |
1763 | RCPT TO:<userc@d.bar.org> | |
1764 | ||
1765 | As provided in appendix C, xyz.com MAY also choose to relay the | |
1766 | message to hosta.int, using the envelope commands | |
1767 | ||
1768 | MAIL FROM:<userx@y.foo.org> | |
1769 | RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> | |
1770 | ||
1771 | or to jkl.org, using the envelope commands | |
1772 | ||
1773 | MAIL FROM:<userx@y.foo.org> | |
1774 | RCPT TO:<@jkl.org:userc@d.bar.org> | |
1775 | ||
1776 | Of course, since hosts are not required to relay mail at all, xyz.com | |
1777 | may also reject the message entirely when the RCPT command is | |
1778 | received, using a 550 code (since this is a "policy reason"). | |
1779 | ||
1780 | If service extensions were negotiated, the RCPT command may also | |
1781 | carry parameters associated with a particular service extension | |
1782 | offered by the server. The client MUST NOT transmit parameters other | |
1783 | than those associated with a service extension offered by the server | |
1784 | in its EHLO response. | |
1785 | ||
1786 | Syntax: | |
1787 | "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path) | |
1788 | [SP Rcpt-parameters] CRLF | |
1789 | ||
1790 | ||
1791 | ||
1792 | ||
1793 | ||
1794 | Klensin Standards Track [Page 32] | |
1795 | \f | |
1796 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1797 | ||
1798 | ||
1799 | 4.1.1.4 DATA (DATA) | |
1800 | ||
1801 | The receiver normally sends a 354 response to DATA, and then treats | |
1802 | the lines (strings ending in <CRLF> sequences, as described in | |
1803 | section 2.3.7) following the command as mail data from the sender. | |
1804 | This command causes the mail data to be appended to the mail data | |
1805 | buffer. The mail data may contain any of the 128 ASCII character | |
1806 | codes, although experience has indicated that use of control | |
1807 | characters other than SP, HT, CR, and LF may cause problems and | |
1808 | SHOULD be avoided when possible. | |
1809 | ||
1810 | The mail data is terminated by a line containing only a period, that | |
1811 | is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This | |
1812 | is the end of mail data indication. Note that the first <CRLF> of | |
1813 | this terminating sequence is also the <CRLF> that ends the final line | |
1814 | of the data (message text) or, if there was no data, ends the DATA | |
1815 | command itself. An extra <CRLF> MUST NOT be added, as that would | |
1816 | cause an empty line to be added to the message. The only exception | |
1817 | to this rule would arise if the message body were passed to the | |
1818 | originating SMTP-sender with a final "line" that did not end in | |
1819 | <CRLF>; in that case, the originating SMTP system MUST either reject | |
1820 | the message as invalid or add <CRLF> in order to have the receiving | |
1821 | SMTP server recognize the "end of data" condition. | |
1822 | ||
1823 | The custom of accepting lines ending only in <LF>, as a concession to | |
1824 | non-conforming behavior on the part of some UNIX systems, has proven | |
1825 | to cause more interoperability problems than it solves, and SMTP | |
1826 | server systems MUST NOT do this, even in the name of improved | |
1827 | robustness. In particular, the sequence "<LF>.<LF>" (bare line | |
1828 | feeds, without carriage returns) MUST NOT be treated as equivalent to | |
1829 | <CRLF>.<CRLF> as the end of mail data indication. | |
1830 | ||
1831 | Receipt of the end of mail data indication requires the server to | |
1832 | process the stored mail transaction information. This processing | |
1833 | consumes the information in the reverse-path buffer, the forward-path | |
1834 | buffer, and the mail data buffer, and on the completion of this | |
1835 | command these buffers are cleared. If the processing is successful, | |
1836 | the receiver MUST send an OK reply. If the processing fails the | |
1837 | receiver MUST send a failure reply. The SMTP model does not allow | |
1838 | for partial failures at this point: either the message is accepted by | |
1839 | the server for delivery and a positive response is returned or it is | |
1840 | not accepted and a failure reply is returned. In sending a positive | |
1841 | completion reply to the end of data indication, the receiver takes | |
1842 | full responsibility for the message (see section 6.1). Errors that | |
1843 | are diagnosed subsequently MUST be reported in a mail message, as | |
1844 | discussed in section 4.4. | |
1845 | ||
1846 | ||
1847 | ||
1848 | ||
1849 | ||
1850 | Klensin Standards Track [Page 33] | |
1851 | \f | |
1852 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1853 | ||
1854 | ||
1855 | When the SMTP server accepts a message either for relaying or for | |
1856 | final delivery, it inserts a trace record (also referred to | |
1857 | interchangeably as a "time stamp line" or "Received" line) at the top | |
1858 | of the mail data. This trace record indicates the identity of the | |
1859 | host that sent the message, the identity of the host that received | |
1860 | the message (and is inserting this time stamp), and the date and time | |
1861 | the message was received. Relayed messages will have multiple time | |
1862 | stamp lines. Details for formation of these lines, including their | |
1863 | syntax, is specified in section 4.4. | |
1864 | ||
1865 | Additional discussion about the operation of the DATA command appears | |
1866 | in section 3.3. | |
1867 | ||
1868 | Syntax: | |
1869 | "DATA" CRLF | |
1870 | ||
1871 | 4.1.1.5 RESET (RSET) | |
1872 | ||
1873 | This command specifies that the current mail transaction will be | |
1874 | aborted. Any stored sender, recipients, and mail data MUST be | |
1875 | discarded, and all buffers and state tables cleared. The receiver | |
1876 | MUST send a "250 OK" reply to a RSET command with no arguments. A | |
1877 | reset command may be issued by the client at any time. It is | |
1878 | effectively equivalent to a NOOP (i.e., if has no effect) if issued | |
1879 | immediately after EHLO, before EHLO is issued in the session, after | |
1880 | an end-of-data indicator has been sent and acknowledged, or | |
1881 | immediately before a QUIT. An SMTP server MUST NOT close the | |
1882 | connection as the result of receiving a RSET; that action is reserved | |
1883 | for QUIT (see section 4.1.1.10). | |
1884 | ||
1885 | Since EHLO implies some additional processing and response by the | |
1886 | server, RSET will normally be more efficient than reissuing that | |
1887 | command, even though the formal semantics are the same. | |
1888 | ||
1889 | There are circumstances, contrary to the intent of this | |
1890 | specification, in which an SMTP server may receive an indication that | |
1891 | the underlying TCP connection has been closed or reset. To preserve | |
1892 | the robustness of the mail system, SMTP servers SHOULD be prepared | |
1893 | for this condition and SHOULD treat it as if a QUIT had been received | |
1894 | before the connection disappeared. | |
1895 | ||
1896 | Syntax: | |
1897 | "RSET" CRLF | |
1898 | ||
1899 | ||
1900 | ||
1901 | ||
1902 | ||
1903 | ||
1904 | ||
1905 | ||
1906 | Klensin Standards Track [Page 34] | |
1907 | \f | |
1908 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1909 | ||
1910 | ||
1911 | 4.1.1.6 VERIFY (VRFY) | |
1912 | ||
1913 | This command asks the receiver to confirm that the argument | |
1914 | identifies a user or mailbox. If it is a user name, information is | |
1915 | returned as specified in section 3.5. | |
1916 | ||
1917 | This command has no effect on the reverse-path buffer, the forward- | |
1918 | path buffer, or the mail data buffer. | |
1919 | ||
1920 | Syntax: | |
1921 | "VRFY" SP String CRLF | |
1922 | ||
1923 | 4.1.1.7 EXPAND (EXPN) | |
1924 | ||
1925 | This command asks the receiver to confirm that the argument | |
1926 | identifies a mailing list, and if so, to return the membership of | |
1927 | that list. If the command is successful, a reply is returned | |
1928 | containing information as described in section 3.5. This reply will | |
1929 | have multiple lines except in the trivial case of a one-member list. | |
1930 | ||
1931 | This command has no effect on the reverse-path buffer, the forward- | |
1932 | path buffer, or the mail data buffer and may be issued at any time. | |
1933 | ||
1934 | Syntax: | |
1935 | "EXPN" SP String CRLF | |
1936 | ||
1937 | 4.1.1.8 HELP (HELP) | |
1938 | ||
1939 | This command causes the server to send helpful information to the | |
1940 | client. The command MAY take an argument (e.g., any command name) | |
1941 | and return more specific information as a response. | |
1942 | ||
1943 | This command has no effect on the reverse-path buffer, the forward- | |
1944 | path buffer, or the mail data buffer and may be issued at any time. | |
1945 | ||
1946 | SMTP servers SHOULD support HELP without arguments and MAY support it | |
1947 | with arguments. | |
1948 | ||
1949 | Syntax: | |
1950 | "HELP" [ SP String ] CRLF | |
1951 | ||
1952 | 4.1.1.9 NOOP (NOOP) | |
1953 | ||
1954 | This command does not affect any parameters or previously entered | |
1955 | commands. It specifies no action other than that the receiver send | |
1956 | an OK reply. | |
1957 | ||
1958 | ||
1959 | ||
1960 | ||
1961 | ||
1962 | Klensin Standards Track [Page 35] | |
1963 | \f | |
1964 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
1965 | ||
1966 | ||
1967 | This command has no effect on the reverse-path buffer, the forward- | |
1968 | path buffer, or the mail data buffer and may be issued at any time. | |
1969 | If a parameter string is specified, servers SHOULD ignore it. | |
1970 | ||
1971 | Syntax: | |
1972 | "NOOP" [ SP String ] CRLF | |
1973 | ||
1974 | 4.1.1.10 QUIT (QUIT) | |
1975 | ||
1976 | This command specifies that the receiver MUST send an OK reply, and | |
1977 | then close the transmission channel. | |
1978 | ||
1979 | The receiver MUST NOT intentionally close the transmission channel | |
1980 | until it receives and replies to a QUIT command (even if there was an | |
1981 | error). The sender MUST NOT intentionally close the transmission | |
1982 | channel until it sends a QUIT command and SHOULD wait until it | |
1983 | receives the reply (even if there was an error response to a previous | |
1984 | command). If the connection is closed prematurely due to violations | |
1985 | of the above or system or network failure, the server MUST cancel any | |
1986 | pending transaction, but not undo any previously completed | |
1987 | transaction, and generally MUST act as if the command or transaction | |
1988 | in progress had received a temporary error (i.e., a 4yz response). | |
1989 | ||
1990 | The QUIT command may be issued at any time. | |
1991 | ||
1992 | Syntax: | |
1993 | "QUIT" CRLF | |
1994 | ||
1995 | 4.1.2 Command Argument Syntax | |
1996 | ||
1997 | The syntax of the argument fields of the above commands (using the | |
1998 | syntax specified in [8] where applicable) is given below. Some of | |
1999 | the productions given below are used only in conjunction with source | |
2000 | routes as described in appendix C. Terminals not defined in this | |
2001 | document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in | |
2002 | the "core" syntax [8 (section 6)] or in the message format syntax | |
2003 | [32]. | |
2004 | ||
2005 | Reverse-path = Path | |
2006 | Forward-path = Path | |
2007 | Path = "<" [ A-d-l ":" ] Mailbox ">" | |
2008 | A-d-l = At-domain *( "," A-d-l ) | |
2009 | ; Note that this form, the so-called "source route", | |
2010 | ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be | |
2011 | ; ignored. | |
2012 | At-domain = "@" domain | |
2013 | Mail-parameters = esmtp-param *(SP esmtp-param) | |
2014 | Rcpt-parameters = esmtp-param *(SP esmtp-param) | |
2015 | ||
2016 | ||
2017 | ||
2018 | Klensin Standards Track [Page 36] | |
2019 | \f | |
2020 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2021 | ||
2022 | ||
2023 | esmtp-param = esmtp-keyword ["=" esmtp-value] | |
2024 | esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") | |
2025 | esmtp-value = 1*(%d33-60 / %d62-127) | |
2026 | ; any CHAR excluding "=", SP, and control characters | |
2027 | Keyword = Ldh-str | |
2028 | Argument = Atom | |
2029 | Domain = (sub-domain 1*("." sub-domain)) / address-literal | |
2030 | sub-domain = Let-dig [Ldh-str] | |
2031 | ||
2032 | address-literal = "[" IPv4-address-literal / | |
2033 | IPv6-address-literal / | |
2034 | General-address-literal "]" | |
2035 | ; See section 4.1.3 | |
2036 | ||
2037 | Mailbox = Local-part "@" Domain | |
2038 | ||
2039 | Local-part = Dot-string / Quoted-string | |
2040 | ; MAY be case-sensitive | |
2041 | ||
2042 | Dot-string = Atom *("." Atom) | |
2043 | ||
2044 | Atom = 1*atext | |
2045 | ||
2046 | Quoted-string = DQUOTE *qcontent DQUOTE | |
2047 | ||
2048 | String = Atom / Quoted-string | |
2049 | ||
2050 | While the above definition for Local-part is relatively permissive, | |
2051 | for maximum interoperability, a host that expects to receive mail | |
2052 | SHOULD avoid defining mailboxes where the Local-part requires (or | |
2053 | uses) the Quoted-string form or where the Local-part is case- | |
2054 | sensitive. For any purposes that require generating or comparing | |
2055 | Local-parts (e.g., to specific mailbox names), all quoted forms MUST | |
2056 | be treated as equivalent and the sending system SHOULD transmit the | |
2057 | form that uses the minimum quoting possible. | |
2058 | ||
2059 | Systems MUST NOT define mailboxes in such a way as to require the use | |
2060 | in SMTP of non-ASCII characters (octets with the high order bit set | |
2061 | to one) or ASCII "control characters" (decimal value 0-31 and 127). | |
2062 | These characters MUST NOT be used in MAIL or RCPT commands or other | |
2063 | commands that require mailbox names. | |
2064 | ||
2065 | Note that the backslash, "\", is a quote character, which is used to | |
2066 | indicate that the next character is to be used literally (instead of | |
2067 | its normal interpretation). For example, "Joe\,Smith" indicates a | |
2068 | single nine character user field with the comma being the fourth | |
2069 | character of the field. | |
2070 | ||
2071 | ||
2072 | ||
2073 | ||
2074 | Klensin Standards Track [Page 37] | |
2075 | \f | |
2076 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2077 | ||
2078 | ||
2079 | To promote interoperability and consistent with long-standing | |
2080 | guidance about conservative use of the DNS in naming and applications | |
2081 | (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]), | |
2082 | characters outside the set of alphas, digits, and hyphen MUST NOT | |
2083 | appear in domain name labels for SMTP clients or servers. In | |
2084 | particular, the underscore character is not permitted. SMTP servers | |
2085 | that receive a command in which invalid character codes have been | |
2086 | employed, and for which there are no other reasons for rejection, | |
2087 | MUST reject that command with a 501 response. | |
2088 | ||
2089 | 4.1.3 Address Literals | |
2090 | ||
2091 | Sometimes a host is not known to the domain name system and | |
2092 | communication (and, in particular, communication to report and repair | |
2093 | the error) is blocked. To bypass this barrier a special literal form | |
2094 | of the address is allowed as an alternative to a domain name. For | |
2095 | IPv4 addresses, this form uses four small decimal integers separated | |
2096 | by dots and enclosed by brackets such as [123.255.37.2], which | |
2097 | indicates an (IPv4) Internet Address in sequence-of-octets form. For | |
2098 | IPv6 and other forms of addressing that might eventually be | |
2099 | standardized, the form consists of a standardized "tag" that | |
2100 | identifies the address syntax, a colon, and the address itself, in a | |
2101 | format specified as part of the IPv6 standards [17]. | |
2102 | ||
2103 | Specifically: | |
2104 | ||
2105 | IPv4-address-literal = Snum 3("." Snum) | |
2106 | IPv6-address-literal = "IPv6:" IPv6-addr | |
2107 | General-address-literal = Standardized-tag ":" 1*dcontent | |
2108 | Standardized-tag = Ldh-str | |
2109 | ; MUST be specified in a standards-track RFC | |
2110 | ; and registered with IANA | |
2111 | ||
2112 | Snum = 1*3DIGIT ; representing a decimal integer | |
2113 | ; value in the range 0 through 255 | |
2114 | Let-dig = ALPHA / DIGIT | |
2115 | Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig | |
2116 | ||
2117 | IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp | |
2118 | IPv6-hex = 1*4HEXDIG | |
2119 | IPv6-full = IPv6-hex 7(":" IPv6-hex) | |
2120 | IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" | |
2121 | IPv6-hex)] | |
2122 | ; The "::" represents at least 2 16-bit groups of zeros | |
2123 | ; No more than 6 groups in addition to the "::" may be | |
2124 | ; present | |
2125 | IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal | |
2126 | IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" | |
2127 | ||
2128 | ||
2129 | ||
2130 | Klensin Standards Track [Page 38] | |
2131 | \f | |
2132 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2133 | ||
2134 | ||
2135 | [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal | |
2136 | ; The "::" represents at least 2 16-bit groups of zeros | |
2137 | ; No more than 4 groups in addition to the "::" and | |
2138 | ; IPv4-address-literal may be present | |
2139 | ||
2140 | 4.1.4 Order of Commands | |
2141 | ||
2142 | There are restrictions on the order in which these commands may be | |
2143 | used. | |
2144 | ||
2145 | A session that will contain mail transactions MUST first be | |
2146 | initialized by the use of the EHLO command. An SMTP server SHOULD | |
2147 | accept commands for non-mail transactions (e.g., VRFY or EXPN) | |
2148 | without this initialization. | |
2149 | ||
2150 | An EHLO command MAY be issued by a client later in the session. If | |
2151 | it is issued after the session begins, the SMTP server MUST clear all | |
2152 | buffers and reset the state exactly as if a RSET command had been | |
2153 | issued. In other words, the sequence of RSET followed immediately by | |
2154 | EHLO is redundant, but not harmful other than in the performance cost | |
2155 | of executing unnecessary commands. | |
2156 | ||
2157 | If the EHLO command is not acceptable to the SMTP server, 501, 500, | |
2158 | or 502 failure replies MUST be returned as appropriate. The SMTP | |
2159 | server MUST stay in the same state after transmitting these replies | |
2160 | that it was in before the EHLO was received. | |
2161 | ||
2162 | The SMTP client MUST, if possible, ensure that the domain parameter | |
2163 | to the EHLO command is a valid principal host name (not a CNAME or MX | |
2164 | name) for its host. If this is not possible (e.g., when the client's | |
2165 | address is dynamically assigned and the client does not have an | |
2166 | obvious name), an address literal SHOULD be substituted for the | |
2167 | domain name and supplemental information provided that will assist in | |
2168 | identifying the client. | |
2169 | ||
2170 | An SMTP server MAY verify that the domain name parameter in the EHLO | |
2171 | command actually corresponds to the IP address of the client. | |
2172 | However, the server MUST NOT refuse to accept a message for this | |
2173 | reason if the verification fails: the information about verification | |
2174 | failure is for logging and tracing only. | |
2175 | ||
2176 | The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time | |
2177 | during a session, or without previously initializing a session. SMTP | |
2178 | servers SHOULD process these normally (that is, not return a 503 | |
2179 | code) even if no EHLO command has yet been received; clients SHOULD | |
2180 | open a session with EHLO before sending these commands. | |
2181 | ||
2182 | ||
2183 | ||
2184 | ||
2185 | ||
2186 | Klensin Standards Track [Page 39] | |
2187 | \f | |
2188 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2189 | ||
2190 | ||
2191 | If these rules are followed, the example in RFC 821 that shows "550 | |
2192 | access denied to you" in response to an EXPN command is incorrect | |
2193 | unless an EHLO command precedes the EXPN or the denial of access is | |
2194 | based on the client's IP address or other authentication or | |
2195 | authorization-determining mechanisms. | |
2196 | ||
2197 | The MAIL command (or the obsolete SEND, SOML, or SAML commands) | |
2198 | begins a mail transaction. Once started, a mail transaction consists | |
2199 | of a transaction beginning command, one or more RCPT commands, and a | |
2200 | DATA command, in that order. A mail transaction may be aborted by | |
2201 | the RSET (or a new EHLO) command. There may be zero or more | |
2202 | transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be | |
2203 | sent if a mail transaction is already open, i.e., it should be sent | |
2204 | only if no mail transaction had been started in the session, or it | |
2205 | the previous one successfully concluded with a successful DATA | |
2206 | command, or if the previous one was aborted with a RSET. | |
2207 | ||
2208 | If the transaction beginning command argument is not acceptable, a | |
2209 | 501 failure reply MUST be returned and the SMTP server MUST stay in | |
2210 | the same state. If the commands in a transaction are out of order to | |
2211 | the degree that they cannot be processed by the server, a 503 failure | |
2212 | reply MUST be returned and the SMTP server MUST stay in the same | |
2213 | state. | |
2214 | ||
2215 | The last command in a session MUST be the QUIT command. The QUIT | |
2216 | command cannot be used at any other time in a session, but SHOULD be | |
2217 | used by the client SMTP to request connection closure, even when no | |
2218 | session opening command was sent and accepted. | |
2219 | ||
2220 | 4.1.5 Private-use Commands | |
2221 | ||
2222 | As specified in section 2.2.2, commands starting in "X" may be used | |
2223 | by bilateral agreement between the client (sending) and server | |
2224 | (receiving) SMTP agents. An SMTP server that does not recognize such | |
2225 | a command is expected to reply with "500 Command not recognized". An | |
2226 | extended SMTP server MAY list the feature names associated with these | |
2227 | private commands in the response to the EHLO command. | |
2228 | ||
2229 | Commands sent or accepted by SMTP systems that do not start with "X" | |
2230 | MUST conform to the requirements of section 2.2.2. | |
2231 | ||
2232 | 4.2 SMTP Replies | |
2233 | ||
2234 | Replies to SMTP commands serve to ensure the synchronization of | |
2235 | requests and actions in the process of mail transfer and to guarantee | |
2236 | that the SMTP client always knows the state of the SMTP server. | |
2237 | Every command MUST generate exactly one reply. | |
2238 | ||
2239 | ||
2240 | ||
2241 | ||
2242 | Klensin Standards Track [Page 40] | |
2243 | \f | |
2244 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2245 | ||
2246 | ||
2247 | The details of the command-reply sequence are described in section | |
2248 | 4.3. | |
2249 | ||
2250 | An SMTP reply consists of a three digit number (transmitted as three | |
2251 | numeric characters) followed by some text unless specified otherwise | |
2252 | in this document. The number is for use by automata to determine | |
2253 | what state to enter next; the text is for the human user. The three | |
2254 | digits contain enough encoded information that the SMTP client need | |
2255 | not examine the text and may either discard it or pass it on to the | |
2256 | user, as appropriate. Exceptions are as noted elsewhere in this | |
2257 | document. In particular, the 220, 221, 251, 421, and 551 reply codes | |
2258 | are associated with message text that must be parsed and interpreted | |
2259 | by machines. In the general case, the text may be receiver dependent | |
2260 | and context dependent, so there are likely to be varying texts for | |
2261 | each reply code. A discussion of the theory of reply codes is given | |
2262 | in section 4.2.1. Formally, a reply is defined to be the sequence: a | |
2263 | three-digit code, <SP>, one line of text, and <CRLF>, or a multiline | |
2264 | reply (as defined in section 4.2.1). Since, in violation of this | |
2265 | specification, the text is sometimes not sent, clients which do not | |
2266 | receive it SHOULD be prepared to process the code alone (with or | |
2267 | without a trailing space character). Only the EHLO, EXPN, and HELP | |
2268 | commands are expected to result in multiline replies in normal | |
2269 | circumstances, however, multiline replies are allowed for any | |
2270 | command. | |
2271 | ||
2272 | In ABNF, server responses are: | |
2273 | ||
2274 | Greeting = "220 " Domain [ SP text ] CRLF | |
2275 | Reply-line = Reply-code [ SP text ] CRLF | |
2276 | ||
2277 | where "Greeting" appears only in the 220 response that announces that | |
2278 | the server is opening its part of the connection. | |
2279 | ||
2280 | An SMTP server SHOULD send only the reply codes listed in this | |
2281 | document. An SMTP server SHOULD use the text shown in the examples | |
2282 | whenever appropriate. | |
2283 | ||
2284 | An SMTP client MUST determine its actions only by the reply code, not | |
2285 | by the text (except for the "change of address" 251 and 551 and, if | |
2286 | necessary, 220, 221, and 421 replies); in the general case, any text, | |
2287 | including no text at all (although senders SHOULD NOT send bare | |
2288 | codes), MUST be acceptable. The space (blank) following the reply | |
2289 | code is considered part of the text. Whenever possible, a receiver- | |
2290 | SMTP SHOULD test the first digit (severity indication) of the reply | |
2291 | code. | |
2292 | ||
2293 | ||
2294 | ||
2295 | ||
2296 | ||
2297 | ||
2298 | Klensin Standards Track [Page 41] | |
2299 | \f | |
2300 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2301 | ||
2302 | ||
2303 | The list of codes that appears below MUST NOT be construed as | |
2304 | permanent. While the addition of new codes should be a rare and | |
2305 | significant activity, with supplemental information in the textual | |
2306 | part of the response being preferred, new codes may be added as the | |
2307 | result of new Standards or Standards-track specifications. | |
2308 | Consequently, a sender-SMTP MUST be prepared to handle codes not | |
2309 | specified in this document and MUST do so by interpreting the first | |
2310 | digit only. | |
2311 | ||
2312 | 4.2.1 Reply Code Severities and Theory | |
2313 | ||
2314 | The three digits of the reply each have a special significance. The | |
2315 | first digit denotes whether the response is good, bad or incomplete. | |
2316 | An unsophisticated SMTP client, or one that receives an unexpected | |
2317 | code, will be able to determine its next action (proceed as planned, | |
2318 | redo, retrench, etc.) by examining this first digit. An SMTP client | |
2319 | that wants to know approximately what kind of error occurred (e.g., | |
2320 | mail system error, command syntax error) may examine the second | |
2321 | digit. The third digit and any supplemental information that may be | |
2322 | present is reserved for the finest gradation of information. | |
2323 | ||
2324 | There are five values for the first digit of the reply code: | |
2325 | ||
2326 | 1yz Positive Preliminary reply | |
2327 | The command has been accepted, but the requested action is being | |
2328 | held in abeyance, pending confirmation of the information in this | |
2329 | reply. The SMTP client should send another command specifying | |
2330 | whether to continue or abort the action. Note: unextended SMTP | |
2331 | does not have any commands that allow this type of reply, and so | |
2332 | does not have continue or abort commands. | |
2333 | ||
2334 | 2yz Positive Completion reply | |
2335 | The requested action has been successfully completed. A new | |
2336 | request may be initiated. | |
2337 | ||
2338 | 3yz Positive Intermediate reply | |
2339 | The command has been accepted, but the requested action is being | |
2340 | held in abeyance, pending receipt of further information. The | |
2341 | SMTP client should send another command specifying this | |
2342 | information. This reply is used in command sequence groups (i.e., | |
2343 | in DATA). | |
2344 | ||
2345 | 4yz Transient Negative Completion reply | |
2346 | The command was not accepted, and the requested action did not | |
2347 | occur. However, the error condition is temporary and the action | |
2348 | may be requested again. The sender should return to the beginning | |
2349 | of the command sequence (if any). It is difficult to assign a | |
2350 | meaning to "transient" when two different sites (receiver- and | |
2351 | ||
2352 | ||
2353 | ||
2354 | Klensin Standards Track [Page 42] | |
2355 | \f | |
2356 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2357 | ||
2358 | ||
2359 | sender-SMTP agents) must agree on the interpretation. Each reply | |
2360 | in this category might have a different time value, but the SMTP | |
2361 | client is encouraged to try again. A rule of thumb to determine | |
2362 | whether a reply fits into the 4yz or the 5yz category (see below) | |
2363 | is that replies are 4yz if they can be successful if repeated | |
2364 | without any change in command form or in properties of the sender | |
2365 | or receiver (that is, the command is repeated identically and the | |
2366 | receiver does not put up a new implementation.) | |
2367 | ||
2368 | 5yz Permanent Negative Completion reply | |
2369 | The command was not accepted and the requested action did not | |
2370 | occur. The SMTP client is discouraged from repeating the exact | |
2371 | request (in the same sequence). Even some "permanent" error | |
2372 | conditions can be corrected, so the human user may want to direct | |
2373 | the SMTP client to reinitiate the command sequence by direct | |
2374 | action at some point in the future (e.g., after the spelling has | |
2375 | been changed, or the user has altered the account status). | |
2376 | ||
2377 | The second digit encodes responses in specific categories: | |
2378 | ||
2379 | x0z Syntax: These replies refer to syntax errors, syntactically | |
2380 | correct commands that do not fit any functional category, and | |
2381 | unimplemented or superfluous commands. | |
2382 | ||
2383 | x1z Information: These are replies to requests for information, | |
2384 | such as status or help. | |
2385 | ||
2386 | x2z Connections: These are replies referring to the transmission | |
2387 | channel. | |
2388 | ||
2389 | x3z Unspecified. | |
2390 | ||
2391 | x4z Unspecified. | |
2392 | ||
2393 | x5z Mail system: These replies indicate the status of the receiver | |
2394 | mail system vis-a-vis the requested transfer or other mail system | |
2395 | action. | |
2396 | ||
2397 | The third digit gives a finer gradation of meaning in each category | |
2398 | specified by the second digit. The list of replies illustrates this. | |
2399 | Each reply text is recommended rather than mandatory, and may even | |
2400 | change according to the command with which it is associated. On the | |
2401 | other hand, the reply codes must strictly follow the specifications | |
2402 | in this section. Receiver implementations should not invent new | |
2403 | codes for slightly different situations from the ones described here, | |
2404 | but rather adapt codes already defined. | |
2405 | ||
2406 | ||
2407 | ||
2408 | ||
2409 | ||
2410 | Klensin Standards Track [Page 43] | |
2411 | \f | |
2412 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2413 | ||
2414 | ||
2415 | For example, a command such as NOOP, whose successful execution does | |
2416 | not offer the SMTP client any new information, will return a 250 | |
2417 | reply. The reply is 502 when the command requests an unimplemented | |
2418 | non-site-specific action. A refinement of that is the 504 reply for | |
2419 | a command that is implemented, but that requests an unimplemented | |
2420 | parameter. | |
2421 | ||
2422 | The reply text may be longer than a single line; in these cases the | |
2423 | complete text must be marked so the SMTP client knows when it can | |
2424 | stop reading the reply. This requires a special format to indicate a | |
2425 | multiple line reply. | |
2426 | ||
2427 | The format for multiline replies requires that every line, except the | |
2428 | last, begin with the reply code, followed immediately by a hyphen, | |
2429 | "-" (also known as minus), followed by text. The last line will | |
2430 | begin with the reply code, followed immediately by <SP>, optionally | |
2431 | some text, and <CRLF>. As noted above, servers SHOULD send the <SP> | |
2432 | if subsequent text is not sent, but clients MUST be prepared for it | |
2433 | to be omitted. | |
2434 | ||
2435 | For example: | |
2436 | ||
2437 | 123-First line | |
2438 | 123-Second line | |
2439 | 123-234 text beginning with numbers | |
2440 | 123 The last line | |
2441 | ||
2442 | In many cases the SMTP client then simply needs to search for a line | |
2443 | beginning with the reply code followed by <SP> or <CRLF> and ignore | |
2444 | all preceding lines. In a few cases, there is important data for the | |
2445 | client in the reply "text". The client will be able to identify | |
2446 | these cases from the current context. | |
2447 | ||
2448 | 4.2.2 Reply Codes by Function Groups | |
2449 | ||
2450 | 500 Syntax error, command unrecognized | |
2451 | (This may include errors such as command line too long) | |
2452 | 501 Syntax error in parameters or arguments | |
2453 | 502 Command not implemented (see section 4.2.4) | |
2454 | 503 Bad sequence of commands | |
2455 | 504 Command parameter not implemented | |
2456 | ||
2457 | 211 System status, or system help reply | |
2458 | 214 Help message | |
2459 | (Information on how to use the receiver or the meaning of a | |
2460 | particular non-standard command; this reply is useful only | |
2461 | to the human user) | |
2462 | ||
2463 | ||
2464 | ||
2465 | ||
2466 | Klensin Standards Track [Page 44] | |
2467 | \f | |
2468 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2469 | ||
2470 | ||
2471 | 220 <domain> Service ready | |
2472 | 221 <domain> Service closing transmission channel | |
2473 | 421 <domain> Service not available, closing transmission channel | |
2474 | (This may be a reply to any command if the service knows it | |
2475 | must shut down) | |
2476 | ||
2477 | 250 Requested mail action okay, completed | |
2478 | 251 User not local; will forward to <forward-path> | |
2479 | (See section 3.4) | |
2480 | 252 Cannot VRFY user, but will accept message and attempt | |
2481 | delivery | |
2482 | (See section 3.5.3) | |
2483 | 450 Requested mail action not taken: mailbox unavailable | |
2484 | (e.g., mailbox busy) | |
2485 | 550 Requested action not taken: mailbox unavailable | |
2486 | (e.g., mailbox not found, no access, or command rejected | |
2487 | for policy reasons) | |
2488 | 451 Requested action aborted: error in processing | |
2489 | 551 User not local; please try <forward-path> | |
2490 | (See section 3.4) | |
2491 | 452 Requested action not taken: insufficient system storage | |
2492 | 552 Requested mail action aborted: exceeded storage allocation | |
2493 | 553 Requested action not taken: mailbox name not allowed | |
2494 | (e.g., mailbox syntax incorrect) | |
2495 | 354 Start mail input; end with <CRLF>.<CRLF> | |
2496 | 554 Transaction failed (Or, in the case of a connection-opening | |
2497 | response, "No SMTP service here") | |
2498 | ||
2499 | 4.2.3 Reply Codes in Numeric Order | |
2500 | ||
2501 | 211 System status, or system help reply | |
2502 | 214 Help message | |
2503 | (Information on how to use the receiver or the meaning of a | |
2504 | particular non-standard command; this reply is useful only | |
2505 | to the human user) | |
2506 | 220 <domain> Service ready | |
2507 | 221 <domain> Service closing transmission channel | |
2508 | 250 Requested mail action okay, completed | |
2509 | 251 User not local; will forward to <forward-path> | |
2510 | (See section 3.4) | |
2511 | 252 Cannot VRFY user, but will accept message and attempt | |
2512 | delivery | |
2513 | (See section 3.5.3) | |
2514 | ||
2515 | 354 Start mail input; end with <CRLF>.<CRLF> | |
2516 | ||
2517 | ||
2518 | ||
2519 | ||
2520 | ||
2521 | ||
2522 | Klensin Standards Track [Page 45] | |
2523 | \f | |
2524 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2525 | ||
2526 | ||
2527 | 421 <domain> Service not available, closing transmission channel | |
2528 | (This may be a reply to any command if the service knows it | |
2529 | must shut down) | |
2530 | 450 Requested mail action not taken: mailbox unavailable | |
2531 | (e.g., mailbox busy) | |
2532 | 451 Requested action aborted: local error in processing | |
2533 | 452 Requested action not taken: insufficient system storage | |
2534 | 500 Syntax error, command unrecognized | |
2535 | (This may include errors such as command line too long) | |
2536 | 501 Syntax error in parameters or arguments | |
2537 | 502 Command not implemented (see section 4.2.4) | |
2538 | 503 Bad sequence of commands | |
2539 | 504 Command parameter not implemented | |
2540 | 550 Requested action not taken: mailbox unavailable | |
2541 | (e.g., mailbox not found, no access, or command rejected | |
2542 | for policy reasons) | |
2543 | 551 User not local; please try <forward-path> | |
2544 | (See section 3.4) | |
2545 | 552 Requested mail action aborted: exceeded storage allocation | |
2546 | 553 Requested action not taken: mailbox name not allowed | |
2547 | (e.g., mailbox syntax incorrect) | |
2548 | 554 Transaction failed (Or, in the case of a connection-opening | |
2549 | response, "No SMTP service here") | |
2550 | ||
2551 | 4.2.4 Reply Code 502 | |
2552 | ||
2553 | Questions have been raised as to when reply code 502 (Command not | |
2554 | implemented) SHOULD be returned in preference to other codes. 502 | |
2555 | SHOULD be used when the command is actually recognized by the SMTP | |
2556 | server, but not implemented. If the command is not recognized, code | |
2557 | 500 SHOULD be returned. Extended SMTP systems MUST NOT list | |
2558 | capabilities in response to EHLO for which they will return 502 (or | |
2559 | 500) replies. | |
2560 | ||
2561 | 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> | |
2562 | ||
2563 | When an SMTP server returns a positive completion status (2yz code) | |
2564 | after the DATA command is completed with <CRLF>.<CRLF>, it accepts | |
2565 | responsibility for: | |
2566 | ||
2567 | - delivering the message (if the recipient mailbox exists), or | |
2568 | ||
2569 | - if attempts to deliver the message fail due to transient | |
2570 | conditions, retrying delivery some reasonable number of times at | |
2571 | intervals as specified in section 4.5.4. | |
2572 | ||
2573 | ||
2574 | ||
2575 | ||
2576 | ||
2577 | ||
2578 | Klensin Standards Track [Page 46] | |
2579 | \f | |
2580 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2581 | ||
2582 | ||
2583 | - if attempts to deliver the message fail due to permanent | |
2584 | conditions, or if repeated attempts to deliver the message fail | |
2585 | due to transient conditions, returning appropriate notification to | |
2586 | the sender of the original message (using the address in the SMTP | |
2587 | MAIL command). | |
2588 | ||
2589 | When an SMTP server returns a permanent error status (5yz) code after | |
2590 | the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make | |
2591 | any subsequent attempt to deliver that message. The SMTP client | |
2592 | retains responsibility for delivery of that message and may either | |
2593 | return it to the user or requeue it for a subsequent attempt (see | |
2594 | section 4.5.4.1). | |
2595 | ||
2596 | The user who originated the message SHOULD be able to interpret the | |
2597 | return of a transient failure status (by mail message or otherwise) | |
2598 | as a non-delivery indication, just as a permanent failure would be | |
2599 | interpreted. I.e., if the client SMTP successfully handles these | |
2600 | conditions, the user will not receive such a reply. | |
2601 | ||
2602 | When an SMTP server returns a permanent error status (5yz) code after | |
2603 | the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make | |
2604 | any subsequent attempt to deliver the message. As with temporary | |
2605 | error status codes, the SMTP client retains responsibility for the | |
2606 | message, but SHOULD not again attempt delivery to the same server | |
2607 | without user review and intervention of the message. | |
2608 | ||
2609 | 4.3 Sequencing of Commands and Replies | |
2610 | ||
2611 | 4.3.1 Sequencing Overview | |
2612 | ||
2613 | The communication between the sender and receiver is an alternating | |
2614 | dialogue, controlled by the sender. As such, the sender issues a | |
2615 | command and the receiver responds with a reply. Unless other | |
2616 | arrangements are negotiated through service extensions, the sender | |
2617 | MUST wait for this response before sending further commands. | |
2618 | ||
2619 | One important reply is the connection greeting. Normally, a receiver | |
2620 | will send a 220 "Service ready" reply when the connection is | |
2621 | completed. The sender SHOULD wait for this greeting message before | |
2622 | sending any commands. | |
2623 | ||
2624 | Note: all the greeting-type replies have the official name (the | |
2625 | fully-qualified primary domain name) of the server host as the first | |
2626 | word following the reply code. Sometimes the host will have no | |
2627 | meaningful name. See 4.1.3 for a discussion of alternatives in these | |
2628 | situations. | |
2629 | ||
2630 | ||
2631 | ||
2632 | ||
2633 | ||
2634 | Klensin Standards Track [Page 47] | |
2635 | \f | |
2636 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2637 | ||
2638 | ||
2639 | For example, | |
2640 | ||
2641 | 220 ISIF.USC.EDU Service ready | |
2642 | or | |
2643 | 220 mail.foo.com SuperSMTP v 6.1.2 Service ready | |
2644 | or | |
2645 | 220 [10.0.0.1] Clueless host service ready | |
2646 | ||
2647 | The table below lists alternative success and failure replies for | |
2648 | each command. These SHOULD be strictly adhered to: a receiver may | |
2649 | substitute text in the replies, but the meaning and action implied by | |
2650 | the code numbers and by the specific command reply sequence cannot be | |
2651 | altered. | |
2652 | ||
2653 | 4.3.2 Command-Reply Sequences | |
2654 | ||
2655 | Each command is listed with its usual possible replies. The prefixes | |
2656 | used before the possible replies are "I" for intermediate, "S" for | |
2657 | success, and "E" for error. Since some servers may generate other | |
2658 | replies under special circumstances, and to allow for future | |
2659 | extension, SMTP clients SHOULD, when possible, interpret only the | |
2660 | first digit of the reply and MUST be prepared to deal with | |
2661 | unrecognized reply codes by interpreting the first digit only. | |
2662 | Unless extended using the mechanisms described in section 2.2, SMTP | |
2663 | servers MUST NOT transmit reply codes to an SMTP client that are | |
2664 | other than three digits or that do not start in a digit between 2 and | |
2665 | 5 inclusive. | |
2666 | ||
2667 | These sequencing rules and, in principle, the codes themselves, can | |
2668 | be extended or modified by SMTP extensions offered by the server and | |
2669 | accepted (requested) by the client. | |
2670 | ||
2671 | In addition to the codes listed below, any SMTP command can return | |
2672 | any of the following codes if the corresponding unusual circumstances | |
2673 | are encountered: | |
2674 | ||
2675 | 500 For the "command line too long" case or if the command name was | |
2676 | not recognized. Note that producing a "command not recognized" | |
2677 | error in response to the required subset of these commands is a | |
2678 | violation of this specification. | |
2679 | ||
2680 | 501 Syntax error in command or arguments. In order to provide for | |
2681 | future extensions, commands that are specified in this document as | |
2682 | not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 | |
2683 | message if arguments are supplied in the absence of EHLO- | |
2684 | advertised extensions. | |
2685 | ||
2686 | 421 Service shutting down and closing transmission channel | |
2687 | ||
2688 | ||
2689 | ||
2690 | Klensin Standards Track [Page 48] | |
2691 | \f | |
2692 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2693 | ||
2694 | ||
2695 | Specific sequences are: | |
2696 | ||
2697 | CONNECTION ESTABLISHMENT | |
2698 | S: 220 | |
2699 | E: 554 | |
2700 | EHLO or HELO | |
2701 | S: 250 | |
2702 | E: 504, 550 | |
2703 | ||
2704 | S: 250 | |
2705 | E: 552, 451, 452, 550, 553, 503 | |
2706 | RCPT | |
2707 | S: 250, 251 (but see section 3.4 for discussion of 251 and 551) | |
2708 | E: 550, 551, 552, 553, 450, 451, 452, 503, 550 | |
2709 | DATA | |
2710 | I: 354 -> data -> S: 250 | |
2711 | E: 552, 554, 451, 452 | |
2712 | E: 451, 554, 503 | |
2713 | RSET | |
2714 | S: 250 | |
2715 | VRFY | |
2716 | S: 250, 251, 252 | |
2717 | E: 550, 551, 553, 502, 504 | |
2718 | EXPN | |
2719 | S: 250, 252 | |
2720 | E: 550, 500, 502, 504 | |
2721 | HELP | |
2722 | S: 211, 214 | |
2723 | E: 502, 504 | |
2724 | NOOP | |
2725 | S: 250 | |
2726 | QUIT | |
2727 | S: 221 | |
2728 | ||
2729 | 4.4 Trace Information | |
2730 | ||
2731 | When an SMTP server receives a message for delivery or further | |
2732 | processing, it MUST insert trace ("time stamp" or "Received") | |
2733 | information at the beginning of the message content, as discussed in | |
2734 | section 4.1.1.4. | |
2735 | ||
2736 | This line MUST be structured as follows: | |
2737 | ||
2738 | - The FROM field, which MUST be supplied in an SMTP environment, | |
2739 | SHOULD contain both (1) the name of the source host as presented | |
2740 | in the EHLO command and (2) an address literal containing the IP | |
2741 | address of the source, determined from the TCP connection. | |
2742 | ||
2743 | ||
2744 | ||
2745 | ||
2746 | Klensin Standards Track [Page 49] | |
2747 | \f | |
2748 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2749 | ||
2750 | ||
2751 | - The ID field MAY contain an "@" as suggested in RFC 822, but this | |
2752 | is not required. | |
2753 | ||
2754 | - The FOR field MAY contain a list of <path> entries when multiple | |
2755 | RCPT commands have been given. This may raise some security | |
2756 | issues and is usually not desirable; see section 7.2. | |
2757 | ||
2758 | An Internet mail program MUST NOT change a Received: line that was | |
2759 | previously added to the message header. SMTP servers MUST prepend | |
2760 | Received lines to messages; they MUST NOT change the order of | |
2761 | existing lines or insert Received lines in any other location. | |
2762 | ||
2763 | As the Internet grows, comparability of Received fields is important | |
2764 | for detecting problems, especially slow relays. SMTP servers that | |
2765 | create Received fields SHOULD use explicit offsets in the dates | |
2766 | (e.g., -0800), rather than time zone names of any type. Local time | |
2767 | (with an offset) is preferred to UT when feasible. This formulation | |
2768 | allows slightly more information about local circumstances to be | |
2769 | specified. If UT is needed, the receiver need merely do some simple | |
2770 | arithmetic to convert the values. Use of UT loses information about | |
2771 | the time zone-location of the server. If it is desired to supply a | |
2772 | time zone name, it SHOULD be included in a comment. | |
2773 | ||
2774 | When the delivery SMTP server makes the "final delivery" of a | |
2775 | message, it inserts a return-path line at the beginning of the mail | |
2776 | data. This use of return-path is required; mail systems MUST support | |
2777 | it. The return-path line preserves the information in the <reverse- | |
2778 | path> from the MAIL command. Here, final delivery means the message | |
2779 | has left the SMTP environment. Normally, this would mean it had been | |
2780 | delivered to the destination user or an associated mail drop, but in | |
2781 | some cases it may be further processed and transmitted by another | |
2782 | mail system. | |
2783 | ||
2784 | It is possible for the mailbox in the return path to be different | |
2785 | from the actual sender's mailbox, for example, if error responses are | |
2786 | to be delivered to a special error handling mailbox rather than to | |
2787 | the message sender. When mailing lists are involved, this | |
2788 | arrangement is common and useful as a means of directing errors to | |
2789 | the list maintainer rather than the message originator. | |
2790 | ||
2791 | The text above implies that the final mail data will begin with a | |
2792 | return path line, followed by one or more time stamp lines. These | |
2793 | lines will be followed by the mail data headers and body [32]. | |
2794 | ||
2795 | It is sometimes difficult for an SMTP server to determine whether or | |
2796 | not it is making final delivery since forwarding or other operations | |
2797 | may occur after the message is accepted for delivery. Consequently, | |
2798 | ||
2799 | ||
2800 | ||
2801 | ||
2802 | Klensin Standards Track [Page 50] | |
2803 | \f | |
2804 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2805 | ||
2806 | ||
2807 | any further (forwarding, gateway, or relay) systems MAY remove the | |
2808 | return path and rebuild the MAIL command as needed to ensure that | |
2809 | exactly one such line appears in a delivered message. | |
2810 | ||
2811 | A message-originating SMTP system SHOULD NOT send a message that | |
2812 | already contains a Return-path header. SMTP servers performing a | |
2813 | relay function MUST NOT inspect the message data, and especially not | |
2814 | to the extent needed to determine if Return-path headers are present. | |
2815 | SMTP servers making final delivery MAY remove Return-path headers | |
2816 | before adding their own. | |
2817 | ||
2818 | The primary purpose of the Return-path is to designate the address to | |
2819 | which messages indicating non-delivery or other mail system failures | |
2820 | are to be sent. For this to be unambiguous, exactly one return path | |
2821 | SHOULD be present when the message is delivered. Systems using RFC | |
2822 | 822 syntax with non-SMTP transports SHOULD designate an unambiguous | |
2823 | address, associated with the transport envelope, to which error | |
2824 | reports (e.g., non-delivery messages) should be sent. | |
2825 | ||
2826 | Historical note: Text in RFC 822 that appears to contradict the use | |
2827 | of the Return-path header (or the envelope reverse path address from | |
2828 | the MAIL command) as the destination for error messages is not | |
2829 | applicable on the Internet. The reverse path address (as copied into | |
2830 | the Return-path) MUST be used as the target of any mail containing | |
2831 | delivery error messages. | |
2832 | ||
2833 | In particular: | |
2834 | ||
2835 | - a gateway from SMTP->elsewhere SHOULD insert a return-path header, | |
2836 | unless it is known that the "elsewhere" transport also uses | |
2837 | Internet domain addresses and maintains the envelope sender | |
2838 | address separately. | |
2839 | ||
2840 | - a gateway from elsewhere->SMTP SHOULD delete any return-path | |
2841 | header present in the message, and either copy that information to | |
2842 | the SMTP envelope or combine it with information present in the | |
2843 | envelope of the other transport system to construct the reverse | |
2844 | path argument to the MAIL command in the SMTP envelope. | |
2845 | ||
2846 | The server must give special treatment to cases in which the | |
2847 | processing following the end of mail data indication is only | |
2848 | partially successful. This could happen if, after accepting several | |
2849 | recipients and the mail data, the SMTP server finds that the mail | |
2850 | data could be successfully delivered to some, but not all, of the | |
2851 | recipients. In such cases, the response to the DATA command MUST be | |
2852 | an OK reply. However, the SMTP server MUST compose and send an | |
2853 | "undeliverable mail" notification message to the originator of the | |
2854 | message. | |
2855 | ||
2856 | ||
2857 | ||
2858 | Klensin Standards Track [Page 51] | |
2859 | \f | |
2860 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2861 | ||
2862 | ||
2863 | A single notification listing all of the failed recipients or | |
2864 | separate notification messages MUST be sent for each failed | |
2865 | recipient. For economy of processing by the sender, the former is | |
2866 | preferred when possible. All undeliverable mail notification | |
2867 | messages are sent using the MAIL command (even if they result from | |
2868 | processing the obsolete SEND, SOML, or SAML commands) and use a null | |
2869 | return path as discussed in section 3.7. | |
2870 | ||
2871 | The time stamp line and the return path line are formally defined as | |
2872 | follows: | |
2873 | ||
2874 | Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> | |
2875 | ||
2876 | Time-stamp-line = "Received:" FWS Stamp <CRLF> | |
2877 | ||
2878 | Stamp = From-domain By-domain Opt-info ";" FWS date-time | |
2879 | ||
2880 | ; where "date-time" is as defined in [32] | |
2881 | ; but the "obs-" forms, especially two-digit | |
2882 | ; years, are prohibited in SMTP and MUST NOT be used. | |
2883 | ||
2884 | From-domain = "FROM" FWS Extended-Domain CFWS | |
2885 | ||
2886 | By-domain = "BY" FWS Extended-Domain CFWS | |
2887 | ||
2888 | Extended-Domain = Domain / | |
2889 | ( Domain FWS "(" TCP-info ")" ) / | |
2890 | ( Address-literal FWS "(" TCP-info ")" ) | |
2891 | ||
2892 | TCP-info = Address-literal / ( Domain FWS Address-literal ) | |
2893 | ; Information derived by server from TCP connection | |
2894 | ; not client EHLO. | |
2895 | ||
2896 | Opt-info = [Via] [With] [ID] [For] | |
2897 | ||
2898 | Via = "VIA" FWS Link CFWS | |
2899 | ||
2900 | With = "WITH" FWS Protocol CFWS | |
2901 | ||
2902 | ID = "ID" FWS String / msg-id CFWS | |
2903 | ||
2904 | For = "FOR" FWS 1*( Path / Mailbox ) CFWS | |
2905 | ||
2906 | Link = "TCP" / Addtl-Link | |
2907 | Addtl-Link = Atom | |
2908 | ; Additional standard names for links are registered with the | |
2909 | ; Internet Assigned Numbers Authority (IANA). "Via" is | |
2910 | ; primarily of value with non-Internet transports. SMTP | |
2911 | ||
2912 | ||
2913 | ||
2914 | Klensin Standards Track [Page 52] | |
2915 | \f | |
2916 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2917 | ||
2918 | ||
2919 | ; servers SHOULD NOT use unregistered names. | |
2920 | Protocol = "ESMTP" / "SMTP" / Attdl-Protocol | |
2921 | Attdl-Protocol = Atom | |
2922 | ; Additional standard names for protocols are registered with the | |
2923 | ; Internet Assigned Numbers Authority (IANA). SMTP servers | |
2924 | ; SHOULD NOT use unregistered names. | |
2925 | ||
2926 | 4.5 Additional Implementation Issues | |
2927 | ||
2928 | 4.5.1 Minimum Implementation | |
2929 | ||
2930 | In order to make SMTP workable, the following minimum implementation | |
2931 | is required for all receivers. The following commands MUST be | |
2932 | supported to conform to this specification: | |
2933 | ||
2934 | EHLO | |
2935 | HELO | |
2936 | ||
2937 | RCPT | |
2938 | DATA | |
2939 | RSET | |
2940 | NOOP | |
2941 | QUIT | |
2942 | VRFY | |
2943 | ||
2944 | Any system that includes an SMTP server supporting mail relaying or | |
2945 | delivery MUST support the reserved mailbox "postmaster" as a case- | |
2946 | insensitive local name. This postmaster address is not strictly | |
2947 | necessary if the server always returns 554 on connection opening (as | |
2948 | described in section 3.1). The requirement to accept mail for | |
2949 | postmaster implies that RCPT commands which specify a mailbox for | |
2950 | postmaster at any of the domains for which the SMTP server provides | |
2951 | mail service, as well as the special case of "RCPT TO:<Postmaster>" | |
2952 | (with no domain specification), MUST be supported. | |
2953 | ||
2954 | SMTP systems are expected to make every reasonable effort to accept | |
2955 | mail directed to Postmaster from any other system on the Internet. | |
2956 | In extreme cases --such as to contain a denial of service attack or | |
2957 | other breach of security-- an SMTP server may block mail directed to | |
2958 | Postmaster. However, such arrangements SHOULD be narrowly tailored | |
2959 | so as to avoid blocking messages which are not part of such attacks. | |
2960 | ||
2961 | 4.5.2 Transparency | |
2962 | ||
2963 | Without some provision for data transparency, the character sequence | |
2964 | "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. | |
2965 | In general, users are not aware of such "forbidden" sequences. To | |
2966 | ||
2967 | ||
2968 | ||
2969 | ||
2970 | Klensin Standards Track [Page 53] | |
2971 | \f | |
2972 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
2973 | ||
2974 | ||
2975 | allow all user composed text to be transmitted transparently, the | |
2976 | following procedures are used: | |
2977 | ||
2978 | - Before sending a line of mail text, the SMTP client checks the | |
2979 | first character of the line. If it is a period, one additional | |
2980 | period is inserted at the beginning of the line. | |
2981 | ||
2982 | - When a line of mail text is received by the SMTP server, it checks | |
2983 | the line. If the line is composed of a single period, it is | |
2984 | treated as the end of mail indicator. If the first character is a | |
2985 | period and there are other characters on the line, the first | |
2986 | character is deleted. | |
2987 | ||
2988 | The mail data may contain any of the 128 ASCII characters. All | |
2989 | characters are to be delivered to the recipient's mailbox, including | |
2990 | spaces, vertical and horizontal tabs, and other control characters. | |
2991 | If the transmission channel provides an 8-bit byte (octet) data | |
2992 | stream, the 7-bit ASCII codes are transmitted right justified in the | |
2993 | octets, with the high order bits cleared to zero. See 3.7 for | |
2994 | special treatment of these conditions in SMTP systems serving a relay | |
2995 | function. | |
2996 | ||
2997 | In some systems it may be necessary to transform the data as it is | |
2998 | received and stored. This may be necessary for hosts that use a | |
2999 | different character set than ASCII as their local character set, that | |
3000 | store data in records rather than strings, or which use special | |
3001 | character sequences as delimiters inside mailboxes. If such | |
3002 | transformations are necessary, they MUST be reversible, especially if | |
3003 | they are applied to mail being relayed. | |
3004 | ||
3005 | 4.5.3 Sizes and Timeouts | |
3006 | ||
3007 | 4.5.3.1 Size limits and minimums | |
3008 | ||
3009 | There are several objects that have required minimum/maximum sizes. | |
3010 | Every implementation MUST be able to receive objects of at least | |
3011 | these sizes. Objects larger than these sizes SHOULD be avoided when | |
3012 | possible. However, some Internet mail constructs such as encoded | |
3013 | X.400 addresses [16] will often require larger objects: clients MAY | |
3014 | attempt to transmit these, but MUST be prepared for a server to | |
3015 | reject them if they cannot be handled by it. To the maximum extent | |
3016 | possible, implementation techniques which impose no limits on the | |
3017 | length of these objects should be used. | |
3018 | ||
3019 | local-part | |
3020 | The maximum total length of a user name or other local-part is 64 | |
3021 | characters. | |
3022 | ||
3023 | ||
3024 | ||
3025 | ||
3026 | Klensin Standards Track [Page 54] | |
3027 | \f | |
3028 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3029 | ||
3030 | ||
3031 | domain | |
3032 | The maximum total length of a domain name or number is 255 | |
3033 | characters. | |
3034 | ||
3035 | path | |
3036 | The maximum total length of a reverse-path or forward-path is 256 | |
3037 | characters (including the punctuation and element separators). | |
3038 | ||
3039 | command line | |
3040 | The maximum total length of a command line including the command | |
3041 | word and the <CRLF> is 512 characters. SMTP extensions may be | |
3042 | used to increase this limit. | |
3043 | ||
3044 | reply line | |
3045 | The maximum total length of a reply line including the reply code | |
3046 | and the <CRLF> is 512 characters. More information may be | |
3047 | conveyed through multiple-line replies. | |
3048 | ||
3049 | text line | |
3050 | The maximum total length of a text line including the <CRLF> is | |
3051 | 1000 characters (not counting the leading dot duplicated for | |
3052 | transparency). This number may be increased by the use of SMTP | |
3053 | Service Extensions. | |
3054 | ||
3055 | message content | |
3056 | The maximum total length of a message content (including any | |
3057 | message headers as well as the message body) MUST BE at least 64K | |
3058 | octets. Since the introduction of Internet standards for | |
3059 | multimedia mail [12], message lengths on the Internet have grown | |
3060 | dramatically, and message size restrictions should be avoided if | |
3061 | at all possible. SMTP server systems that must impose | |
3062 | restrictions SHOULD implement the "SIZE" service extension [18], | |
3063 | and SMTP client systems that will send large messages SHOULD | |
3064 | utilize it when possible. | |
3065 | ||
3066 | recipients buffer | |
3067 | The minimum total number of recipients that must be buffered is | |
3068 | 100 recipients. Rejection of messages (for excessive recipients) | |
3069 | with fewer than 100 RCPT commands is a violation of this | |
3070 | specification. The general principle that relaying SMTP servers | |
3071 | MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation | |
3072 | tests on message headers suggests that rejecting a message based | |
3073 | on the total number of recipients shown in header fields is to be | |
3074 | discouraged. A server which imposes a limit on the number of | |
3075 | recipients MUST behave in an orderly fashion, such as to reject | |
3076 | additional addresses over its limit rather than silently | |
3077 | discarding addresses previously accepted. A client that needs to | |
3078 | ||
3079 | ||
3080 | ||
3081 | ||
3082 | Klensin Standards Track [Page 55] | |
3083 | \f | |
3084 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3085 | ||
3086 | ||
3087 | deliver a message containing over 100 RCPT commands SHOULD be | |
3088 | prepared to transmit in 100-recipient "chunks" if the server | |
3089 | declines to accept more than 100 recipients in a single message. | |
3090 | ||
3091 | Errors due to exceeding these limits may be reported by using the | |
3092 | reply codes. Some examples of reply codes are: | |
3093 | ||
3094 | 500 Line too long. | |
3095 | or | |
3096 | 501 Path too long | |
3097 | or | |
3098 | 452 Too many recipients (see below) | |
3099 | or | |
3100 | 552 Too much mail data. | |
3101 | ||
3102 | RFC 821 [30] incorrectly listed the error where an SMTP server | |
3103 | exhausts its implementation limit on the number of RCPT commands | |
3104 | ("too many recipients") as having reply code 552. The correct reply | |
3105 | code for this condition is 452. Clients SHOULD treat a 552 code in | |
3106 | this case as a temporary, rather than permanent, failure so the logic | |
3107 | below works. | |
3108 | ||
3109 | When a conforming SMTP server encounters this condition, it has at | |
3110 | least 100 successful RCPT commands in its recipients buffer. If the | |
3111 | server is able to accept the message, then at least these 100 | |
3112 | addresses will be removed from the SMTP client's queue. When the | |
3113 | client attempts retransmission of those addresses which received 452 | |
3114 | responses, at least 100 of these will be able to fit in the SMTP | |
3115 | server's recipients buffer. Each retransmission attempt which is | |
3116 | able to deliver anything will be able to dispose of at least 100 of | |
3117 | these recipients. | |
3118 | ||
3119 | If an SMTP server has an implementation limit on the number of RCPT | |
3120 | commands and this limit is exhausted, it MUST use a response code of | |
3121 | 452 (but the client SHOULD also be prepared for a 552, as noted | |
3122 | above). If the server has a configured site-policy limitation on the | |
3123 | number of RCPT commands, it MAY instead use a 5XX response code. | |
3124 | This would be most appropriate if the policy limitation was intended | |
3125 | to apply if the total recipient count for a particular message body | |
3126 | were enforced even if that message body was sent in multiple mail | |
3127 | transactions. | |
3128 | ||
3129 | 4.5.3.2 Timeouts | |
3130 | ||
3131 | An SMTP client MUST provide a timeout mechanism. It MUST use per- | |
3132 | command timeouts rather than somehow trying to time the entire mail | |
3133 | transaction. Timeouts SHOULD be easily reconfigurable, preferably | |
3134 | without recompiling the SMTP code. To implement this, a timer is set | |
3135 | ||
3136 | ||
3137 | ||
3138 | Klensin Standards Track [Page 56] | |
3139 | \f | |
3140 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3141 | ||
3142 | ||
3143 | for each SMTP command and for each buffer of the data transfer. The | |
3144 | latter means that the overall timeout is inherently proportional to | |
3145 | the size of the message. | |
3146 | ||
3147 | Based on extensive experience with busy mail-relay hosts, the minimum | |
3148 | per-command timeout values SHOULD be as follows: | |
3149 | ||
3150 | Initial 220 Message: 5 minutes | |
3151 | An SMTP client process needs to distinguish between a failed TCP | |
3152 | connection and a delay in receiving the initial 220 greeting | |
3153 | message. Many SMTP servers accept a TCP connection but delay | |
3154 | delivery of the 220 message until their system load permits more | |
3155 | mail to be processed. | |
3156 | ||
3157 | MAIL Command: 5 minutes | |
3158 | ||
3159 | RCPT Command: 5 minutes | |
3160 | A longer timeout is required if processing of mailing lists and | |
3161 | aliases is not deferred until after the message was accepted. | |
3162 | ||
3163 | DATA Initiation: 2 minutes | |
3164 | This is while awaiting the "354 Start Input" reply to a DATA | |
3165 | command. | |
3166 | ||
3167 | Data Block: 3 minutes | |
3168 | This is while awaiting the completion of each TCP SEND call | |
3169 | transmitting a chunk of data. | |
3170 | ||
3171 | DATA Termination: 10 minutes. | |
3172 | This is while awaiting the "250 OK" reply. When the receiver gets | |
3173 | the final period terminating the message data, it typically | |
3174 | performs processing to deliver the message to a user mailbox. A | |
3175 | spurious timeout at this point would be very wasteful and would | |
3176 | typically result in delivery of multiple copies of the message, | |
3177 | since it has been successfully sent and the server has accepted | |
3178 | responsibility for delivery. See section 6.1 for additional | |
3179 | discussion. | |
3180 | ||
3181 | An SMTP server SHOULD have a timeout of at least 5 minutes while it | |
3182 | is awaiting the next command from the sender. | |
3183 | ||
3184 | 4.5.4 Retry Strategies | |
3185 | ||
3186 | The common structure of a host SMTP implementation includes user | |
3187 | mailboxes, one or more areas for queuing messages in transit, and one | |
3188 | or more daemon processes for sending and receiving mail. The exact | |
3189 | structure will vary depending on the needs of the users on the host | |
3190 | ||
3191 | ||
3192 | ||
3193 | ||
3194 | Klensin Standards Track [Page 57] | |
3195 | \f | |
3196 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3197 | ||
3198 | ||
3199 | and the number and size of mailing lists supported by the host. We | |
3200 | describe several optimizations that have proved helpful, particularly | |
3201 | for mailers supporting high traffic levels. | |
3202 | ||
3203 | Any queuing strategy MUST include timeouts on all activities on a | |
3204 | per-command basis. A queuing strategy MUST NOT send error messages | |
3205 | in response to error messages under any circumstances. | |
3206 | ||
3207 | 4.5.4.1 Sending Strategy | |
3208 | ||
3209 | The general model for an SMTP client is one or more processes that | |
3210 | periodically attempt to transmit outgoing mail. In a typical system, | |
3211 | the program that composes a message has some method for requesting | |
3212 | immediate attention for a new piece of outgoing mail, while mail that | |
3213 | cannot be transmitted immediately MUST be queued and periodically | |
3214 | retried by the sender. A mail queue entry will include not only the | |
3215 | message itself but also the envelope information. | |
3216 | ||
3217 | The sender MUST delay retrying a particular destination after one | |
3218 | attempt has failed. In general, the retry interval SHOULD be at | |
3219 | least 30 minutes; however, more sophisticated and variable strategies | |
3220 | will be beneficial when the SMTP client can determine the reason for | |
3221 | non-delivery. | |
3222 | ||
3223 | Retries continue until the message is transmitted or the sender gives | |
3224 | up; the give-up time generally needs to be at least 4-5 days. The | |
3225 | parameters to the retry algorithm MUST be configurable. | |
3226 | ||
3227 | A client SHOULD keep a list of hosts it cannot reach and | |
3228 | corresponding connection timeouts, rather than just retrying queued | |
3229 | mail items. | |
3230 | ||
3231 | Experience suggests that failures are typically transient (the target | |
3232 | system or its connection has crashed), favoring a policy of two | |
3233 | connection attempts in the first hour the message is in the queue, | |
3234 | and then backing off to one every two or three hours. | |
3235 | ||
3236 | The SMTP client can shorten the queuing delay in cooperation with the | |
3237 | SMTP server. For example, if mail is received from a particular | |
3238 | address, it is likely that mail queued for that host can now be sent. | |
3239 | Application of this principle may, in many cases, eliminate the | |
3240 | requirement for an explicit "send queues now" function such as ETRN | |
3241 | [9]. | |
3242 | ||
3243 | The strategy may be further modified as a result of multiple | |
3244 | addresses per host (see below) to optimize delivery time vs. resource | |
3245 | usage. | |
3246 | ||
3247 | ||
3248 | ||
3249 | ||
3250 | Klensin Standards Track [Page 58] | |
3251 | \f | |
3252 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3253 | ||
3254 | ||
3255 | An SMTP client may have a large queue of messages for each | |
3256 | unavailable destination host. If all of these messages were retried | |
3257 | in every retry cycle, there would be excessive Internet overhead and | |
3258 | the sending system would be blocked for a long period. Note that an | |
3259 | SMTP client can generally determine that a delivery attempt has | |
3260 | failed only after a timeout of several minutes and even a one-minute | |
3261 | timeout per connection will result in a very large delay if retries | |
3262 | are repeated for dozens, or even hundreds, of queued messages to the | |
3263 | same host. | |
3264 | ||
3265 | At the same time, SMTP clients SHOULD use great care in caching | |
3266 | negative responses from servers. In an extreme case, if EHLO is | |
3267 | issued multiple times during the same SMTP connection, different | |
3268 | answers may be returned by the server. More significantly, 5yz | |
3269 | responses to the MAIL command MUST NOT be cached. | |
3270 | ||
3271 | When a mail message is to be delivered to multiple recipients, and | |
3272 | the SMTP server to which a copy of the message is to be sent is the | |
3273 | same for multiple recipients, then only one copy of the message | |
3274 | SHOULD be transmitted. That is, the SMTP client SHOULD use the | |
3275 | command sequence: MAIL, RCPT, RCPT,... RCPT, DATA instead of the | |
3276 | sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there | |
3277 | are very many addresses, a limit on the number of RCPT commands per | |
3278 | MAIL command MAY be imposed. Implementation of this efficiency | |
3279 | feature is strongly encouraged. | |
3280 | ||
3281 | Similarly, to achieve timely delivery, the SMTP client MAY support | |
3282 | multiple concurrent outgoing mail transactions. However, some limit | |
3283 | may be appropriate to protect the host from devoting all its | |
3284 | resources to mail. | |
3285 | ||
3286 | 4.5.4.2 Receiving Strategy | |
3287 | ||
3288 | The SMTP server SHOULD attempt to keep a pending listen on the SMTP | |
3289 | port at all times. This requires the support of multiple incoming | |
3290 | TCP connections for SMTP. Some limit MAY be imposed but servers that | |
3291 | cannot handle more than one SMTP transaction at a time are not in | |
3292 | conformance with the intent of this specification. | |
3293 | ||
3294 | As discussed above, when the SMTP server receives mail from a | |
3295 | particular host address, it could activate its own SMTP queuing | |
3296 | mechanisms to retry any mail pending for that host address. | |
3297 | ||
3298 | 4.5.5 Messages with a null reverse-path | |
3299 | ||
3300 | There are several types of notification messages which are required | |
3301 | by existing and proposed standards to be sent with a null reverse | |
3302 | path, namely non-delivery notifications as discussed in section 3.7, | |
3303 | ||
3304 | ||
3305 | ||
3306 | Klensin Standards Track [Page 59] | |
3307 | \f | |
3308 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3309 | ||
3310 | ||
3311 | other kinds of Delivery Status Notifications (DSNs) [24], and also | |
3312 | Message Disposition Notifications (MDNs) [10]. All of these kinds of | |
3313 | messages are notifications about a previous message, and they are | |
3314 | sent to the reverse-path of the previous mail message. (If the | |
3315 | delivery of such a notification message fails, that usually indicates | |
3316 | a problem with the mail system of the host to which the notification | |
3317 | message is addressed. For this reason, at some hosts the MTA is set | |
3318 | up to forward such failed notification messages to someone who is | |
3319 | able to fix problems with the mail system, e.g., via the postmaster | |
3320 | alias.) | |
3321 | ||
3322 | All other types of messages (i.e., any message which is not required | |
3323 | by a standards-track RFC to have a null reverse-path) SHOULD be sent | |
3324 | with with a valid, non-null reverse-path. | |
3325 | ||
3326 | Implementors of automated email processors should be careful to make | |
3327 | sure that the various kinds of messages with null reverse-path are | |
3328 | handled correctly, in particular such systems SHOULD NOT reply to | |
3329 | messages with null reverse-path. | |
3330 | ||
3331 | 5. Address Resolution and Mail Handling | |
3332 | ||
3333 | Once an SMTP client lexically identifies a domain to which mail will | |
3334 | be delivered for processing (as described in sections 3.6 and 3.7), a | |
3335 | DNS lookup MUST be performed to resolve the domain name [22]. The | |
3336 | names are expected to be fully-qualified domain names (FQDNs): | |
3337 | mechanisms for inferring FQDNs from partial names or local aliases | |
3338 | are outside of this specification and, due to a history of problems, | |
3339 | are generally discouraged. The lookup first attempts to locate an MX | |
3340 | record associated with the name. If a CNAME record is found instead, | |
3341 | the resulting name is processed as if it were the initial name. If | |
3342 | no MX records are found, but an A RR is found, the A RR is treated as | |
3343 | if it was associated with an implicit MX RR, with a preference of 0, | |
3344 | pointing to that host. If one or more MX RRs are found for a given | |
3345 | name, SMTP systems MUST NOT utilize any A RRs associated with that | |
3346 | name unless they are located using the MX RRs; the "implicit MX" rule | |
3347 | above applies only if there are no MX records present. If MX records | |
3348 | are present, but none of them are usable, this situation MUST be | |
3349 | reported as an error. | |
3350 | ||
3351 | When the lookup succeeds, the mapping can result in a list of | |
3352 | alternative delivery addresses rather than a single address, because | |
3353 | of multiple MX records, multihoming, or both. To provide reliable | |
3354 | mail transmission, the SMTP client MUST be able to try (and retry) | |
3355 | each of the relevant addresses in this list in order, until a | |
3356 | delivery attempt succeeds. However, there MAY also be a configurable | |
3357 | limit on the number of alternate addresses that can be tried. In any | |
3358 | case, the SMTP client SHOULD try at least two addresses. | |
3359 | ||
3360 | ||
3361 | ||
3362 | Klensin Standards Track [Page 60] | |
3363 | \f | |
3364 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3365 | ||
3366 | ||
3367 | Two types of information is used to rank the host addresses: multiple | |
3368 | MX records, and multihomed hosts. | |
3369 | ||
3370 | Multiple MX records contain a preference indication that MUST be used | |
3371 | in sorting (see below). Lower numbers are more preferred than higher | |
3372 | ones. If there are multiple destinations with the same preference | |
3373 | and there is no clear reason to favor one (e.g., by recognition of an | |
3374 | easily-reached address), then the sender-SMTP MUST randomize them to | |
3375 | spread the load across multiple mail exchangers for a specific | |
3376 | organization. | |
3377 | ||
3378 | The destination host (perhaps taken from the preferred MX record) may | |
3379 | be multihomed, in which case the domain name resolver will return a | |
3380 | list of alternative IP addresses. It is the responsibility of the | |
3381 | domain name resolver interface to have ordered this list by | |
3382 | decreasing preference if necessary, and SMTP MUST try them in the | |
3383 | order presented. | |
3384 | ||
3385 | Although the capability to try multiple alternative addresses is | |
3386 | required, specific installations may want to limit or disable the use | |
3387 | of alternative addresses. The question of whether a sender should | |
3388 | attempt retries using the different addresses of a multihomed host | |
3389 | has been controversial. The main argument for using the multiple | |
3390 | addresses is that it maximizes the probability of timely delivery, | |
3391 | and indeed sometimes the probability of any delivery; the counter- | |
3392 | argument is that it may result in unnecessary resource use. Note | |
3393 | that resource use is also strongly determined by the sending strategy | |
3394 | discussed in section 4.5.4.1. | |
3395 | ||
3396 | If an SMTP server receives a message with a destination for which it | |
3397 | is a designated Mail eXchanger, it MAY relay the message (potentially | |
3398 | after having rewritten the MAIL FROM and/or RCPT TO addresses), make | |
3399 | final delivery of the message, or hand it off using some mechanism | |
3400 | outside the SMTP-provided transport environment. Of course, neither | |
3401 | of the latter require that the list of MX records be examined | |
3402 | further. | |
3403 | ||
3404 | If it determines that it should relay the message without rewriting | |
3405 | the address, it MUST sort the MX records to determine candidates for | |
3406 | delivery. The records are first ordered by preference, with the | |
3407 | lowest-numbered records being most preferred. The relay host MUST | |
3408 | then inspect the list for any of the names or addresses by which it | |
3409 | might be known in mail transactions. If a matching record is found, | |
3410 | all records at that preference level and higher-numbered ones MUST be | |
3411 | discarded from consideration. If there are no records left at that | |
3412 | point, it is an error condition, and the message MUST be returned as | |
3413 | undeliverable. If records do remain, they SHOULD be tried, best | |
3414 | preference first, as described above. | |
3415 | ||
3416 | ||
3417 | ||
3418 | Klensin Standards Track [Page 61] | |
3419 | \f | |
3420 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3421 | ||
3422 | ||
3423 | 6. Problem Detection and Handling | |
3424 | ||
3425 | 6.1 Reliable Delivery and Replies by Email | |
3426 | ||
3427 | When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" | |
3428 | message in response to DATA), it is accepting responsibility for | |
3429 | delivering or relaying the message. It must take this responsibility | |
3430 | seriously. It MUST NOT lose the message for frivolous reasons, such | |
3431 | as because the host later crashes or because of a predictable | |
3432 | resource shortage. | |
3433 | ||
3434 | If there is a delivery failure after acceptance of a message, the | |
3435 | receiver-SMTP MUST formulate and mail a notification message. This | |
3436 | notification MUST be sent using a null ("<>") reverse path in the | |
3437 | envelope. The recipient of this notification MUST be the address | |
3438 | from the envelope return path (or the Return-Path: line). However, | |
3439 | if this address is null ("<>"), the receiver-SMTP MUST NOT send a | |
3440 | notification. Obviously, nothing in this section can or should | |
3441 | prohibit local decisions (i.e., as part of the same system | |
3442 | environment as the receiver-SMTP) to log or otherwise transmit | |
3443 | information about null address events locally if that is desired. If | |
3444 | the address is an explicit source route, it MUST be stripped down to | |
3445 | its final hop. | |
3446 | ||
3447 | For example, suppose that an error notification must be sent for a | |
3448 | message that arrived with: | |
3449 | ||
3450 | MAIL FROM:<@a,@b:user@d> | |
3451 | ||
3452 | The notification message MUST be sent using: | |
3453 | ||
3454 | RCPT TO:<user@d> | |
3455 | ||
3456 | Some delivery failures after the message is accepted by SMTP will be | |
3457 | unavoidable. For example, it may be impossible for the receiving | |
3458 | SMTP server to validate all the delivery addresses in RCPT command(s) | |
3459 | due to a "soft" domain system error, because the target is a mailing | |
3460 | list (see earlier discussion of RCPT), or because the server is | |
3461 | acting as a relay and has no immediate access to the delivering | |
3462 | system. | |
3463 | ||
3464 | To avoid receiving duplicate messages as the result of timeouts, a | |
3465 | receiver-SMTP MUST seek to minimize the time required to respond to | |
3466 | the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [28] for | |
3467 | a discussion of this problem. | |
3468 | ||
3469 | ||
3470 | ||
3471 | ||
3472 | ||
3473 | ||
3474 | Klensin Standards Track [Page 62] | |
3475 | \f | |
3476 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3477 | ||
3478 | ||
3479 | 6.2 Loop Detection | |
3480 | ||
3481 | Simple counting of the number of "Received:" headers in a message has | |
3482 | proven to be an effective, although rarely optimal, method of | |
3483 | detecting loops in mail systems. SMTP servers using this technique | |
3484 | SHOULD use a large rejection threshold, normally at least 100 | |
3485 | Received entries. Whatever mechanisms are used, servers MUST contain | |
3486 | provisions for detecting and stopping trivial loops. | |
3487 | ||
3488 | 6.3 Compensating for Irregularities | |
3489 | ||
3490 | Unfortunately, variations, creative interpretations, and outright | |
3491 | violations of Internet mail protocols do occur; some would suggest | |
3492 | that they occur quite frequently. The debate as to whether a well- | |
3493 | behaved SMTP receiver or relay should reject a malformed message, | |
3494 | attempt to pass it on unchanged, or attempt to repair it to increase | |
3495 | the odds of successful delivery (or subsequent reply) began almost | |
3496 | with the dawn of structured network mail and shows no signs of | |
3497 | abating. Advocates of rejection claim that attempted repairs are | |
3498 | rarely completely adequate and that rejection of bad messages is the | |
3499 | only way to get the offending software repaired. Advocates of | |
3500 | "repair" or "deliver no matter what" argue that users prefer that | |
3501 | mail go through it if at all possible and that there are significant | |
3502 | market pressures in that direction. In practice, these market | |
3503 | pressures may be more important to particular vendors than strict | |
3504 | conformance to the standards, regardless of the preference of the | |
3505 | actual developers. | |
3506 | ||
3507 | The problems associated with ill-formed messages were exacerbated by | |
3508 | the introduction of the split-UA mail reading protocols [3, 26, 5, | |
3509 | 21]. These protocols have encouraged the use of SMTP as a posting | |
3510 | protocol, and SMTP servers as relay systems for these client hosts | |
3511 | (which are often only intermittently connected to the Internet). | |
3512 | Historically, many of those client machines lacked some of the | |
3513 | mechanisms and information assumed by SMTP (and indeed, by the mail | |
3514 | format protocol [7]). Some could not keep adequate track of time; | |
3515 | others had no concept of time zones; still others could not identify | |
3516 | their own names or addresses; and, of course, none could satisfy the | |
3517 | assumptions that underlay RFC 822's conception of authenticated | |
3518 | addresses. | |
3519 | ||
3520 | In response to these weak SMTP clients, many SMTP systems now | |
3521 | complete messages that are delivered to them in incomplete or | |
3522 | incorrect form. This strategy is generally considered appropriate | |
3523 | when the server can identify or authenticate the client, and there | |
3524 | are prior agreements between them. By contrast, there is at best | |
3525 | great concern about fixes applied by a relay or delivery SMTP server | |
3526 | that has little or no knowledge of the user or client machine. | |
3527 | ||
3528 | ||
3529 | ||
3530 | Klensin Standards Track [Page 63] | |
3531 | \f | |
3532 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3533 | ||
3534 | ||
3535 | The following changes to a message being processed MAY be applied | |
3536 | when necessary by an originating SMTP server, or one used as the | |
3537 | target of SMTP as an initial posting protocol: | |
3538 | ||
3539 | - Addition of a message-id field when none appears | |
3540 | ||
3541 | - Addition of a date, time or time zone when none appears | |
3542 | ||
3543 | - Correction of addresses to proper FQDN format | |
3544 | ||
3545 | The less information the server has about the client, the less likely | |
3546 | these changes are to be correct and the more caution and conservatism | |
3547 | should be applied when considering whether or not to perform fixes | |
3548 | and how. These changes MUST NOT be applied by an SMTP server that | |
3549 | provides an intermediate relay function. | |
3550 | ||
3551 | In all cases, properly-operating clients supplying correct | |
3552 | information are preferred to corrections by the SMTP server. In all | |
3553 | cases, documentation of actions performed by the servers (in trace | |
3554 | fields and/or header comments) is strongly encouraged. | |
3555 | ||
3556 | 7. Security Considerations | |
3557 | ||
3558 | 7.1 Mail Security and Spoofing | |
3559 | ||
3560 | SMTP mail is inherently insecure in that it is feasible for even | |
3561 | fairly casual users to negotiate directly with receiving and relaying | |
3562 | SMTP servers and create messages that will trick a naive recipient | |
3563 | into believing that they came from somewhere else. Constructing such | |
3564 | a message so that the "spoofed" behavior cannot be detected by an | |
3565 | expert is somewhat more difficult, but not sufficiently so as to be a | |
3566 | deterrent to someone who is determined and knowledgeable. | |
3567 | Consequently, as knowledge of Internet mail increases, so does the | |
3568 | knowledge that SMTP mail inherently cannot be authenticated, or | |
3569 | integrity checks provided, at the transport level. Real mail | |
3570 | security lies only in end-to-end methods involving the message | |
3571 | bodies, such as those which use digital signatures (see [14] and, | |
3572 | e.g., PGP [4] or S/MIME [31]). | |
3573 | ||
3574 | Various protocol extensions and configuration options that provide | |
3575 | authentication at the transport level (e.g., from an SMTP client to | |
3576 | an SMTP server) improve somewhat on the traditional situation | |
3577 | described above. However, unless they are accompanied by careful | |
3578 | handoffs of responsibility in a carefully-designed trust environment, | |
3579 | they remain inherently weaker than end-to-end mechanisms which use | |
3580 | digitally signed messages rather than depending on the integrity of | |
3581 | the transport system. | |
3582 | ||
3583 | ||
3584 | ||
3585 | ||
3586 | Klensin Standards Track [Page 64] | |
3587 | \f | |
3588 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3589 | ||
3590 | ||
3591 | Efforts to make it more difficult for users to set envelope return | |
3592 | path and header "From" fields to point to valid addresses other than | |
3593 | their own are largely misguided: they frustrate legitimate | |
3594 | applications in which mail is sent by one user on behalf of another | |
3595 | or in which error (or normal) replies should be directed to a special | |
3596 | address. (Systems that provide convenient ways for users to alter | |
3597 | these fields on a per-message basis should attempt to establish a | |
3598 | primary and permanent mailbox address for the user so that Sender | |
3599 | fields within the message data can be generated sensibly.) | |
3600 | ||
3601 | This specification does not further address the authentication issues | |
3602 | associated with SMTP other than to advocate that useful functionality | |
3603 | not be disabled in the hope of providing some small margin of | |
3604 | protection against an ignorant user who is trying to fake mail. | |
3605 | ||
3606 | 7.2 "Blind" Copies | |
3607 | ||
3608 | Addresses that do not appear in the message headers may appear in the | |
3609 | RCPT commands to an SMTP server for a number of reasons. The two | |
3610 | most common involve the use of a mailing address as a "list exploder" | |
3611 | (a single address that resolves into multiple addresses) and the | |
3612 | appearance of "blind copies". Especially when more than one RCPT | |
3613 | command is present, and in order to avoid defeating some of the | |
3614 | purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy | |
3615 | the full set of RCPT command arguments into the headers, either as | |
3616 | part of trace headers or as informational or private-extension | |
3617 | headers. Since this rule is often violated in practice, and cannot | |
3618 | be enforced, sending SMTP systems that are aware of "bcc" use MAY | |
3619 | find it helpful to send each blind copy as a separate message | |
3620 | transaction containing only a single RCPT command. | |
3621 | ||
3622 | There is no inherent relationship between either "reverse" (from | |
3623 | MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP | |
3624 | transaction ("envelope") and the addresses in the headers. Receiving | |
3625 | systems SHOULD NOT attempt to deduce such relationships and use them | |
3626 | to alter the headers of the message for delivery. The popular | |
3627 | "Apparently-to" header is a violation of this principle as well as a | |
3628 | common source of unintended information disclosure and SHOULD NOT be | |
3629 | used. | |
3630 | ||
3631 | 7.3 VRFY, EXPN, and Security | |
3632 | ||
3633 | As discussed in section 3.5, individual sites may want to disable | |
3634 | either or both of VRFY or EXPN for security reasons. As a corollary | |
3635 | to the above, implementations that permit this MUST NOT appear to | |
3636 | have verified addresses that are not, in fact, verified. If a site | |
3637 | ||
3638 | ||
3639 | ||
3640 | ||
3641 | ||
3642 | Klensin Standards Track [Page 65] | |
3643 | \f | |
3644 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3645 | ||
3646 | ||
3647 | disables these commands for security reasons, the SMTP server MUST | |
3648 | return a 252 response, rather than a code that could be confused with | |
3649 | successful or unsuccessful verification. | |
3650 | ||
3651 | Returning a 250 reply code with the address listed in the VRFY | |
3652 | command after having checked it only for syntax violates this rule. | |
3653 | Of course, an implementation that "supports" VRFY by always returning | |
3654 | 550 whether or not the address is valid is equally not in | |
3655 | conformance. | |
3656 | ||
3657 | Within the last few years, the contents of mailing lists have become | |
3658 | popular as an address information source for so-called "spammers." | |
3659 | The use of EXPN to "harvest" addresses has increased as list | |
3660 | administrators have installed protections against inappropriate uses | |
3661 | of the lists themselves. Implementations SHOULD still provide | |
3662 | support for EXPN, but sites SHOULD carefully evaluate the tradeoffs. | |
3663 | As authentication mechanisms are introduced into SMTP, some sites may | |
3664 | choose to make EXPN available only to authenticated requestors. | |
3665 | ||
3666 | 7.4 Information Disclosure in Announcements | |
3667 | ||
3668 | There has been an ongoing debate about the tradeoffs between the | |
3669 | debugging advantages of announcing server type and version (and, | |
3670 | sometimes, even server domain name) in the greeting response or in | |
3671 | response to the HELP command and the disadvantages of exposing | |
3672 | information that might be useful in a potential hostile attack. The | |
3673 | utility of the debugging information is beyond doubt. Those who | |
3674 | argue for making it available point out that it is far better to | |
3675 | actually secure an SMTP server rather than hope that trying to | |
3676 | conceal known vulnerabilities by hiding the server's precise identity | |
3677 | will provide more protection. Sites are encouraged to evaluate the | |
3678 | tradeoff with that issue in mind; implementations are strongly | |
3679 | encouraged to minimally provide for making type and version | |
3680 | information available in some way to other network hosts. | |
3681 | ||
3682 | 7.5 Information Disclosure in Trace Fields | |
3683 | ||
3684 | In some circumstances, such as when mail originates from within a LAN | |
3685 | whose hosts are not directly on the public Internet, trace | |
3686 | ("Received") fields produced in conformance with this specification | |
3687 | may disclose host names and similar information that would not | |
3688 | normally be available. This ordinarily does not pose a problem, but | |
3689 | sites with special concerns about name disclosure should be aware of | |
3690 | it. Also, the optional FOR clause should be supplied with caution or | |
3691 | not at all when multiple recipients are involved lest it | |
3692 | inadvertently disclose the identities of "blind copy" recipients to | |
3693 | others. | |
3694 | ||
3695 | ||
3696 | ||
3697 | ||
3698 | Klensin Standards Track [Page 66] | |
3699 | \f | |
3700 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3701 | ||
3702 | ||
3703 | 7.6 Information Disclosure in Message Forwarding | |
3704 | ||
3705 | As discussed in section 3.4, use of the 251 or 551 reply codes to | |
3706 | identify the replacement address associated with a mailbox may | |
3707 | inadvertently disclose sensitive information. Sites that are | |
3708 | concerned about those issues should ensure that they select and | |
3709 | configure servers appropriately. | |
3710 | ||
3711 | 7.7 Scope of Operation of SMTP Servers | |
3712 | ||
3713 | It is a well-established principle that an SMTP server may refuse to | |
3714 | accept mail for any operational or technical reason that makes sense | |
3715 | to the site providing the server. However, cooperation among sites | |
3716 | and installations makes the Internet possible. If sites take | |
3717 | excessive advantage of the right to reject traffic, the ubiquity of | |
3718 | email availability (one of the strengths of the Internet) will be | |
3719 | threatened; considerable care should be taken and balance maintained | |
3720 | if a site decides to be selective about the traffic it will accept | |
3721 | and process. | |
3722 | ||
3723 | In recent years, use of the relay function through arbitrary sites | |
3724 | has been used as part of hostile efforts to hide the actual origins | |
3725 | of mail. Some sites have decided to limit the use of the relay | |
3726 | function to known or identifiable sources, and implementations SHOULD | |
3727 | provide the capability to perform this type of filtering. When mail | |
3728 | is rejected for these or other policy reasons, a 550 code SHOULD be | |
3729 | used in response to EHLO, MAIL, or RCPT as appropriate. | |
3730 | ||
3731 | 8. IANA Considerations | |
3732 | ||
3733 | IANA will maintain three registries in support of this specification. | |
3734 | The first consists of SMTP service extensions with the associated | |
3735 | keywords, and, as needed, parameters and verbs. As specified in | |
3736 | section 2.2.2, no entry may be made in this registry that starts in | |
3737 | an "X". Entries may be made only for service extensions (and | |
3738 | associated keywords, parameters, or verbs) that are defined in | |
3739 | standards-track or experimental RFCs specifically approved by the | |
3740 | IESG for this purpose. | |
3741 | ||
3742 | The second registry consists of "tags" that identify forms of domain | |
3743 | literals other than those for IPv4 addresses (specified in RFC 821 | |
3744 | and in this document) and IPv6 addresses (specified in this | |
3745 | document). Additional literal types require standardization before | |
3746 | being used; none are anticipated at this time. | |
3747 | ||
3748 | The third, established by RFC 821 and renewed by this specification, | |
3749 | is a registry of link and protocol identifiers to be used with the | |
3750 | "via" and "with" subclauses of the time stamp ("Received: header") | |
3751 | ||
3752 | ||
3753 | ||
3754 | Klensin Standards Track [Page 67] | |
3755 | \f | |
3756 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3757 | ||
3758 | ||
3759 | described in section 4.4. Link and protocol identifiers in addition | |
3760 | to those specified in this document may be registered only by | |
3761 | standardization or by way of an RFC-documented, IESG-approved, | |
3762 | Experimental protocol extension. | |
3763 | ||
3764 | 9. References | |
3765 | ||
3766 | [1] American National Standards Institute (formerly United States of | |
3767 | America Standards Institute), X3.4, 1968, "USA Code for | |
3768 | Information Interchange". ANSI X3.4-1968 has been replaced by | |
3769 | newer versions with slight modifications, but the 1968 version | |
3770 | remains definitive for the Internet. | |
3771 | ||
3772 | [2] Braden, R., "Requirements for Internet hosts - application and | |
3773 | support", STD 3, RFC 1123, October 1989. | |
3774 | ||
3775 | [3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J. | |
3776 | Reynolds, "Post Office Protocol - version 2", RFC 937, February | |
3777 | 1985. | |
3778 | ||
3779 | [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP | |
3780 | Message Format", RFC 2440, November 1998. | |
3781 | ||
3782 | [5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC | |
3783 | 1176, August 1990. | |
3784 | ||
3785 | [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC | |
3786 | 2060, December 1996. | |
3787 | ||
3788 | [7] Crocker, D., "Standard for the Format of ARPA Internet Text | |
3789 | Messages", RFC 822, August 1982. | |
3790 | ||
3791 | [8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax | |
3792 | Specifications: ABNF", RFC 2234, November 1997. | |
3793 | ||
3794 | [9] De Winter, J., "SMTP Service Extension for Remote Message Queue | |
3795 | Starting", RFC 1985, August 1996. | |
3796 | ||
3797 | [10] Fajman, R., "An Extensible Message Format for Message | |
3798 | Disposition Notifications", RFC 2298, March 1998. | |
3799 | ||
3800 | [11] Freed, N, "Behavior of and Requirements for Internet Firewalls", | |
3801 | RFC 2979, October 2000. | |
3802 | ||
3803 | [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |
3804 | Extensions (MIME) Part One: Format of Internet Message Bodies", | |
3805 | RFC 2045, December 1996. | |
3806 | ||
3807 | ||
3808 | ||
3809 | ||
3810 | Klensin Standards Track [Page 68] | |
3811 | \f | |
3812 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3813 | ||
3814 | ||
3815 | [13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC | |
3816 | 2920, September 2000. | |
3817 | ||
3818 | [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security | |
3819 | Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", | |
3820 | RFC 1847, October 1995. | |
3821 | ||
3822 | [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, | |
3823 | December 1998. | |
3824 | ||
3825 | [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156, | |
3826 | January 1998. | |
3827 | ||
3828 | [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing | |
3829 | Architecture", RFC 2373, July 1998. | |
3830 | ||
3831 | [18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for | |
3832 | Message Size Declaration", STD 10, RFC 1870, November 1995. | |
3833 | ||
3834 | [19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, | |
3835 | "SMTP Service Extensions", STD 10, RFC 1869, November 1995. | |
3836 | ||
3837 | [20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, | |
3838 | "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July | |
3839 | 1994. | |
3840 | ||
3841 | [21] Lambert, M., "PCMAIL: A distributed mail system for personal | |
3842 | computers", RFC 1056, July 1988. | |
3843 | ||
3844 | [22] Mockapetris, P., "Domain names - implementation and | |
3845 | specification", STD 13, RFC 1035, November 1987. | |
3846 | ||
3847 | Mockapetris, P., "Domain names - concepts and facilities", STD | |
3848 | 13, RFC 1034, November 1987. | |
3849 | ||
3850 | [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part | |
3851 | Three: Message Header Extensions for Non-ASCII Text", RFC 2047, | |
3852 | December 1996. | |
3853 | ||
3854 | [24] Moore, K., "SMTP Service Extension for Delivery Status | |
3855 | Notifications", RFC 1891, January 1996. | |
3856 | ||
3857 | [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for | |
3858 | Delivery Status Notifications", RFC 1894, January 1996. | |
3859 | ||
3860 | [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD | |
3861 | 53, RFC 1939, May 1996. | |
3862 | ||
3863 | ||
3864 | ||
3865 | ||
3866 | Klensin Standards Track [Page 69] | |
3867 | \f | |
3868 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3869 | ||
3870 | ||
3871 | [27] Partridge, C., "Mail routing and the domain system", RFC 974, | |
3872 | January 1986. | |
3873 | ||
3874 | [28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February | |
3875 | 1988. | |
3876 | ||
3877 | [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet | |
3878 | Program Protocol Specification", STD 7, RFC 793, September 1981. | |
3879 | ||
3880 | [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August | |
3881 | 1982. | |
3882 | ||
3883 | [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC | |
3884 | 2633, June 1999. | |
3885 | ||
3886 | [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April | |
3887 | 2001. | |
3888 | ||
3889 | [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of | |
3890 | Large and Binary MIME Messages", RFC 1830, August 1995. | |
3891 | ||
3892 | [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, | |
3893 | January 1996. | |
3894 | ||
3895 | 10. Editor's Address | |
3896 | ||
3897 | John C. Klensin | |
3898 | AT&T Laboratories | |
3899 | 99 Bedford St | |
3900 | Boston, MA 02111 USA | |
3901 | ||
3902 | Phone: 617-574-3076 | |
3903 | EMail: klensin@research.att.com | |
3904 | ||
3905 | 11. Acknowledgments | |
3906 | ||
3907 | Many people worked long and hard on the many iterations of this | |
3908 | document. There was wide-ranging debate in the IETF DRUMS Working | |
3909 | Group, both on its mailing list and in face to face discussions, | |
3910 | about many technical issues and the role of a revised standard for | |
3911 | Internet mail transport, and many contributors helped form the | |
3912 | wording in this specification. The hundreds of participants in the | |
3913 | many discussions since RFC 821 was produced are too numerous to | |
3914 | mention, but they all helped this document become what it is. | |
3915 | ||
3916 | ||
3917 | ||
3918 | ||
3919 | ||
3920 | ||
3921 | ||
3922 | Klensin Standards Track [Page 70] | |
3923 | \f | |
3924 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3925 | ||
3926 | ||
3927 | APPENDICES | |
3928 | ||
3929 | A. TCP Transport Service | |
3930 | ||
3931 | The TCP connection supports the transmission of 8-bit bytes. The | |
3932 | SMTP data is 7-bit ASCII characters. Each character is transmitted | |
3933 | as an 8-bit byte with the high-order bit cleared to zero. Service | |
3934 | extensions may modify this rule to permit transmission of full 8-bit | |
3935 | data bytes as part of the message body, but not in SMTP commands or | |
3936 | responses. | |
3937 | ||
3938 | B. Generating SMTP Commands from RFC 822 Headers | |
3939 | ||
3940 | Some systems use RFC 822 headers (only) in a mail submission | |
3941 | protocol, or otherwise generate SMTP commands from RFC 822 headers | |
3942 | when such a message is handed to an MTA from a UA. While the MTA-UA | |
3943 | protocol is a private matter, not covered by any Internet Standard, | |
3944 | there are problems with this approach. For example, there have been | |
3945 | repeated problems with proper handling of "bcc" copies and | |
3946 | redistribution lists when information that conceptually belongs to a | |
3947 | mail envelopes is not separated early in processing from header | |
3948 | information (and kept separate). | |
3949 | ||
3950 | It is recommended that the UA provide its initial ("submission | |
3951 | client") MTA with an envelope separate from the message itself. | |
3952 | However, if the envelope is not supplied, SMTP commands SHOULD be | |
3953 | generated as follows: | |
3954 | ||
3955 | 1. Each recipient address from a TO, CC, or BCC header field SHOULD | |
3956 | be copied to a RCPT command (generating multiple message copies if | |
3957 | that is required for queuing or delivery). This includes any | |
3958 | addresses listed in a RFC 822 "group". Any BCC fields SHOULD then | |
3959 | be removed from the headers. Once this process is completed, the | |
3960 | remaining headers SHOULD be checked to verify that at least one | |
3961 | To:, Cc:, or Bcc: header remains. If none do, then a bcc: header | |
3962 | with no additional information SHOULD be inserted as specified in | |
3963 | [32]. | |
3964 | ||
3965 | 2. The return address in the MAIL command SHOULD, if possible, be | |
3966 | derived from the system's identity for the submitting (local) | |
3967 | user, and the "From:" header field otherwise. If there is a | |
3968 | system identity available, it SHOULD also be copied to the Sender | |
3969 | header field if it is different from the address in the From | |
3970 | header field. (Any Sender field that was already there SHOULD be | |
3971 | removed.) Systems may provide a way for submitters to override | |
3972 | the envelope return address, but may want to restrict its use to | |
3973 | privileged users. This will not prevent mail forgery, but may | |
3974 | lessen its incidence; see section 7.1. | |
3975 | ||
3976 | ||
3977 | ||
3978 | Klensin Standards Track [Page 71] | |
3979 | \f | |
3980 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
3981 | ||
3982 | ||
3983 | When an MTA is being used in this way, it bears responsibility for | |
3984 | ensuring that the message being transmitted is valid. The mechanisms | |
3985 | for checking that validity, and for handling (or returning) messages | |
3986 | that are not valid at the time of arrival, are part of the MUA-MTA | |
3987 | interface and not covered by this specification. | |
3988 | ||
3989 | A submission protocol based on Standard RFC 822 information alone | |
3990 | MUST NOT be used to gateway a message from a foreign (non-SMTP) mail | |
3991 | system into an SMTP environment. Additional information to construct | |
3992 | an envelope must come from some source in the other environment, | |
3993 | whether supplemental headers or the foreign system's envelope. | |
3994 | ||
3995 | Attempts to gateway messages using only their header "to" and "cc" | |
3996 | fields have repeatedly caused mail loops and other behavior adverse | |
3997 | to the proper functioning of the Internet mail environment. These | |
3998 | problems have been especially common when the message originates from | |
3999 | an Internet mailing list and is distributed into the foreign | |
4000 | environment using envelope information. When these messages are then | |
4001 | processed by a header-only remailer, loops back to the Internet | |
4002 | environment (and the mailing list) are almost inevitable. | |
4003 | ||
4004 | C. Source Routes | |
4005 | ||
4006 | Historically, the <reverse-path> was a reverse source routing list of | |
4007 | hosts and a source mailbox. The first host in the <reverse-path> | |
4008 | SHOULD be the host sending the MAIL command. Similarly, the | |
4009 | <forward-path> may be a source routing lists of hosts and a | |
4010 | destination mailbox. However, in general, the <forward-path> SHOULD | |
4011 | contain only a mailbox and domain name, relying on the domain name | |
4012 | system to supply routing information if required. The use of source | |
4013 | routes is deprecated; while servers MUST be prepared to receive and | |
4014 | handle them as discussed in section 3.3 and F.2, clients SHOULD NOT | |
4015 | transmit them and this section was included only to provide context. | |
4016 | ||
4017 | For relay purposes, the forward-path may be a source route of the | |
4018 | form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully- | |
4019 | qualified domain names. This form is used to emphasize the | |
4020 | distinction between an address and a route. The mailbox is an | |
4021 | absolute address, and the route is information about how to get | |
4022 | there. The two concepts should not be confused. | |
4023 | ||
4024 | If source routes are used, RFC 821 and the text below should be | |
4025 | consulted for the mechanisms for constructing and updating the | |
4026 | forward- and reverse-paths. | |
4027 | ||
4028 | ||
4029 | ||
4030 | ||
4031 | ||
4032 | ||
4033 | ||
4034 | Klensin Standards Track [Page 72] | |
4035 | \f | |
4036 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
4037 | ||
4038 | ||
4039 | The SMTP server transforms the command arguments by moving its own | |
4040 | identifier (its domain name or that of any domain for which it is | |
4041 | acting as a mail exchanger), if it appears, from the forward-path to | |
4042 | the beginning of the reverse-path. | |
4043 | ||
4044 | Notice that the forward-path and reverse-path appear in the SMTP | |
4045 | commands and replies, but not necessarily in the message. That is, | |
4046 | there is no need for these paths and especially this syntax to appear | |
4047 | in the "To:" , "From:", "CC:", etc. fields of the message header. | |
4048 | Conversely, SMTP servers MUST NOT derive final message delivery | |
4049 | information from message header fields. | |
4050 | ||
4051 | When the list of hosts is present, it is a "reverse" source route and | |
4052 | indicates that the mail was relayed through each host on the list | |
4053 | (the first host in the list was the most recent relay). This list is | |
4054 | used as a source route to return non-delivery notices to the sender. | |
4055 | As each relay host adds itself to the beginning of the list, it MUST | |
4056 | use its name as known in the transport environment to which it is | |
4057 | relaying the mail rather than that of the transport environment from | |
4058 | which the mail came (if they are different). | |
4059 | ||
4060 | D. Scenarios | |
4061 | ||
4062 | This section presents complete scenarios of several types of SMTP | |
4063 | sessions. In the examples, "C:" indicates what is said by the SMTP | |
4064 | client, and "S:" indicates what is said by the SMTP server. | |
4065 | ||
4066 | D.1 A Typical SMTP Transaction Scenario | |
4067 | ||
4068 | This SMTP example shows mail sent by Smith at host bar.com, to Jones, | |
4069 | Green, and Brown at host foo.com. Here we assume that host bar.com | |
4070 | contacts host foo.com directly. The mail is accepted for Jones and | |
4071 | Brown. Green does not have a mailbox at host foo.com. | |
4072 | ||
4073 | S: 220 foo.com Simple Mail Transfer Service Ready | |
4074 | C: EHLO bar.com | |
4075 | S: 250-foo.com greets bar.com | |
4076 | S: 250-8BITMIME | |
4077 | S: 250-SIZE | |
4078 | S: 250-DSN | |
4079 | S: 250 HELP | |
4080 | C: MAIL FROM:<Smith@bar.com> | |
4081 | S: 250 OK | |
4082 | C: RCPT TO:<Jones@foo.com> | |
4083 | S: 250 OK | |
4084 | C: RCPT TO:<Green@foo.com> | |
4085 | S: 550 No such user here | |
4086 | C: RCPT TO:<Brown@foo.com> | |
4087 | ||
4088 | ||
4089 | ||
4090 | Klensin Standards Track [Page 73] | |
4091 | \f | |
4092 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
4093 | ||
4094 | ||
4095 | S: 250 OK | |
4096 | C: DATA | |
4097 | S: 354 Start mail input; end with <CRLF>.<CRLF> | |
4098 | C: Blah blah blah... | |
4099 | C: ...etc. etc. etc. | |
4100 | C: . | |
4101 | S: 250 OK | |
4102 | C: QUIT | |
4103 | S: 221 foo.com Service closing transmission channel | |
4104 | ||
4105 | D.2 Aborted SMTP Transaction Scenario | |
4106 | ||
4107 | S: 220 foo.com Simple Mail Transfer Service Ready | |
4108 | C: EHLO bar.com | |
4109 | S: 250-foo.com greets bar.com | |
4110 | S: 250-8BITMIME | |
4111 | S: 250-SIZE | |
4112 | S: 250-DSN | |
4113 | S: 250 HELP | |
4114 | C: MAIL FROM:<Smith@bar.com> | |
4115 | S: 250 OK | |
4116 | C: RCPT TO:<Jones@foo.com> | |
4117 | S: 250 OK | |
4118 | C: RCPT TO:<Green@foo.com> | |
4119 | S: 550 No such user here | |
4120 | C: RSET | |
4121 | S: 250 OK | |
4122 | C: QUIT | |
4123 | S: 221 foo.com Service closing transmission channel | |
4124 | ||
4125 | D.3 Relayed Mail Scenario | |
4126 | ||
4127 | Step 1 -- Source Host to Relay Host | |
4128 | ||
4129 | S: 220 foo.com Simple Mail Transfer Service Ready | |
4130 | C: EHLO bar.com | |
4131 | S: 250-foo.com greets bar.com | |
4132 | S: 250-8BITMIME | |
4133 | S: 250-SIZE | |
4134 | S: 250-DSN | |
4135 | S: 250 HELP | |
4136 | C: MAIL FROM:<JQP@bar.com> | |
4137 | S: 250 OK | |
4138 | C: RCPT TO:<@foo.com:Jones@XYZ.COM> | |
4139 | S: 250 OK | |
4140 | C: DATA | |
4141 | S: 354 Start mail input; end with <CRLF>.<CRLF> | |
4142 | C: Date: Thu, 21 May 1998 05:33:29 -0700 | |
4143 | ||
4144 | ||
4145 | ||
4146 | Klensin Standards Track [Page 74] | |
4147 | \f | |
4148 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
4149 | ||
4150 | ||
4151 | C: From: John Q. Public <JQP@bar.com> | |
4152 | C: Subject: The Next Meeting of the Board | |
4153 | C: To: Jones@xyz.com | |
4154 | C: | |
4155 | C: Bill: | |
4156 | C: The next meeting of the board of directors will be | |
4157 | C: on Tuesday. | |
4158 | C: John. | |
4159 | C: . | |
4160 | S: 250 OK | |
4161 | C: QUIT | |
4162 | S: 221 foo.com Service closing transmission channel | |
4163 | ||
4164 | Step 2 -- Relay Host to Destination Host | |
4165 | ||
4166 | S: 220 xyz.com Simple Mail Transfer Service Ready | |
4167 | C: EHLO foo.com | |
4168 | S: 250 xyz.com is on the air | |
4169 | C: MAIL FROM:<@foo.com:JQP@bar.com> | |
4170 | S: 250 OK | |
4171 | C: RCPT TO:<Jones@XYZ.COM> | |
4172 | S: 250 OK | |
4173 | C: DATA | |
4174 | S: 354 Start mail input; end with <CRLF>.<CRLF> | |
4175 | C: Received: from bar.com by foo.com ; Thu, 21 May 1998 | |
4176 | C: 05:33:29 -0700 | |
4177 | C: Date: Thu, 21 May 1998 05:33:22 -0700 | |
4178 | C: From: John Q. Public <JQP@bar.com> | |
4179 | C: Subject: The Next Meeting of the Board | |
4180 | C: To: Jones@xyz.com | |
4181 | C: | |
4182 | C: Bill: | |
4183 | C: The next meeting of the board of directors will be | |
4184 | C: on Tuesday. | |
4185 | C: John. | |
4186 | C: . | |
4187 | S: 250 OK | |
4188 | C: QUIT | |
4189 | S: 221 foo.com Service closing transmission channel | |
4190 | ||
4191 | D.4 Verifying and Sending Scenario | |
4192 | ||
4193 | S: 220 foo.com Simple Mail Transfer Service Ready | |
4194 | C: EHLO bar.com | |
4195 | S: 250-foo.com greets bar.com | |
4196 | S: 250-8BITMIME | |
4197 | S: 250-SIZE | |
4198 | S: 250-DSN | |
4199 | ||
4200 | ||
4201 | ||
4202 | Klensin Standards Track [Page 75] | |
4203 | \f | |
4204 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
4205 | ||
4206 | ||
4207 | S: 250-VRFY | |
4208 | S: 250 HELP | |
4209 | C: VRFY Crispin | |
4210 | S: 250 Mark Crispin <Admin.MRC@foo.com> | |
4211 | C: SEND FROM:<EAK@bar.com> | |
4212 | S: 250 OK | |
4213 | C: RCPT TO:<Admin.MRC@foo.com> | |
4214 | S: 250 OK | |
4215 | C: DATA | |
4216 | S: 354 Start mail input; end with <CRLF>.<CRLF> | |
4217 | C: Blah blah blah... | |
4218 | C: ...etc. etc. etc. | |
4219 | C: . | |
4220 | S: 250 OK | |
4221 | C: QUIT | |
4222 | S: 221 foo.com Service closing transmission channel | |
4223 | ||
4224 | E. Other Gateway Issues | |
4225 | ||
4226 | In general, gateways between the Internet and other mail systems | |
4227 | SHOULD attempt to preserve any layering semantics across the | |
4228 | boundaries between the two mail systems involved. Gateway- | |
4229 | translation approaches that attempt to take shortcuts by mapping, | |
4230 | (such as envelope information from one system to the message headers | |
4231 | or body of another) have generally proven to be inadequate in | |
4232 | important ways. Systems translating between environments that do not | |
4233 | support both envelopes and headers and Internet mail must be written | |
4234 | with the understanding that some information loss is almost | |
4235 | inevitable. | |
4236 | ||
4237 | F. Deprecated Features of RFC 821 | |
4238 | ||
4239 | A few features of RFC 821 have proven to be problematic and SHOULD | |
4240 | NOT be used in Internet mail. | |
4241 | ||
4242 | F.1 TURN | |
4243 | ||
4244 | This command, described in RFC 821, raises important security issues | |
4245 | since, in the absence of strong authentication of the host requesting | |
4246 | that the client and server switch roles, it can easily be used to | |
4247 | divert mail from its correct destination. Its use is deprecated; | |
4248 | SMTP systems SHOULD NOT use it unless the server can authenticate the | |
4249 | client. | |
4250 | ||
4251 | ||
4252 | ||
4253 | ||
4254 | ||
4255 | ||
4256 | ||
4257 | ||
4258 | Klensin Standards Track [Page 76] | |
4259 | \f | |
4260 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
4261 | ||
4262 | ||
4263 | F.2 Source Routing | |
4264 | ||
4265 | RFC 821 utilized the concept of explicit source routing to get mail | |
4266 | from one host to another via a series of relays. The requirement to | |
4267 | utilize source routes in regular mail traffic was eliminated by the | |
4268 | introduction of the domain name system "MX" record and the last | |
4269 | significant justification for them was eliminated by the | |
4270 | introduction, in RFC 1123, of a clear requirement that addresses | |
4271 | following an "@" must all be fully-qualified domain names. | |
4272 | Consequently, the only remaining justifications for the use of source | |
4273 | routes are support for very old SMTP clients or MUAs and in mail | |
4274 | system debugging. They can, however, still be useful in the latter | |
4275 | circumstance and for routing mail around serious, but temporary, | |
4276 | problems such as problems with the relevant DNS records. | |
4277 | ||
4278 | SMTP servers MUST continue to accept source route syntax as specified | |
4279 | in the main body of this document and in RFC 1123. They MAY, if | |
4280 | necessary, ignore the routes and utilize only the target domain in | |
4281 | the address. If they do utilize the source route, the message MUST | |
4282 | be sent to the first domain shown in the address. In particular, a | |
4283 | server MUST NOT guess at shortcuts within the source route. | |
4284 | ||
4285 | Clients SHOULD NOT utilize explicit source routing except under | |
4286 | unusual circumstances, such as debugging or potentially relaying | |
4287 | around firewall or mail system configuration errors. | |
4288 | ||
4289 | F.3 HELO | |
4290 | ||
4291 | As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to | |
4292 | HELO when the server will accept the former. Servers must continue | |
4293 | to accept and process HELO in order to support older clients. | |
4294 | ||
4295 | F.4 #-literals | |
4296 | ||
4297 | RFC 821 provided for specifying an Internet address as a decimal | |
4298 | integer host number prefixed by a pound sign, "#". In practice, that | |
4299 | form has been obsolete since the introduction of TCP/IP. It is | |
4300 | deprecated and MUST NOT be used. | |
4301 | ||
4302 | F.5 Dates and Years | |
4303 | ||
4304 | When dates are inserted into messages by SMTP clients or servers | |
4305 | (e.g., in trace fields), four-digit years MUST BE used. Two-digit | |
4306 | years are deprecated; three-digit years were never permitted in the | |
4307 | Internet mail system. | |
4308 | ||
4309 | ||
4310 | ||
4311 | ||
4312 | ||
4313 | ||
4314 | Klensin Standards Track [Page 77] | |
4315 | \f | |
4316 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
4317 | ||
4318 | ||
4319 | F.6 Sending versus Mailing | |
4320 | ||
4321 | In addition to specifying a mechanism for delivering messages to | |
4322 | user's mailboxes, RFC 821 provided additional, optional, commands to | |
4323 | deliver messages directly to the user's terminal screen. These | |
4324 | commands (SEND, SAML, SOML) were rarely implemented, and changes in | |
4325 | workstation technology and the introduction of other protocols may | |
4326 | have rendered them obsolete even where they are implemented. | |
4327 | ||
4328 | Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers | |
4329 | MAY implement them. If they are implemented by servers, the | |
4330 | implementation model specified in RFC 821 MUST be used and the | |
4331 | command names MUST be published in the response to the EHLO command. | |
4332 | ||
4333 | ||
4334 | ||
4335 | ||
4336 | ||
4337 | ||
4338 | ||
4339 | ||
4340 | ||
4341 | ||
4342 | ||
4343 | ||
4344 | ||
4345 | ||
4346 | ||
4347 | ||
4348 | ||
4349 | ||
4350 | ||
4351 | ||
4352 | ||
4353 | ||
4354 | ||
4355 | ||
4356 | ||
4357 | ||
4358 | ||
4359 | ||
4360 | ||
4361 | ||
4362 | ||
4363 | ||
4364 | ||
4365 | ||
4366 | ||
4367 | ||
4368 | ||
4369 | ||
4370 | Klensin Standards Track [Page 78] | |
4371 | \f | |
4372 | RFC 2821 Simple Mail Transfer Protocol April 2001 | |
4373 | ||
4374 | ||
4375 | Full Copyright Statement | |
4376 | ||
4377 | Copyright (C) The Internet Society (2001). All Rights Reserved. | |
4378 | ||
4379 | This document and translations of it may be copied and furnished to | |
4380 | others, and derivative works that comment on or otherwise explain it | |
4381 | or assist in its implementation may be prepared, copied, published | |
4382 | and distributed, in whole or in part, without restriction of any | |
4383 | kind, provided that the above copyright notice and this paragraph are | |
4384 | included on all such copies and derivative works. However, this | |
4385 | document itself may not be modified in any way, such as by removing | |
4386 | the copyright notice or references to the Internet Society or other | |
4387 | Internet organizations, except as needed for the purpose of | |
4388 | developing Internet standards in which case the procedures for | |
4389 | copyrights defined in the Internet Standards process must be | |
4390 | followed, or as required to translate it into languages other than | |
4391 | English. | |
4392 | ||
4393 | The limited permissions granted above are perpetual and will not be | |
4394 | revoked by the Internet Society or its successors or assigns. | |
4395 | ||
4396 | This document and the information contained herein is provided on an | |
4397 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
4398 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
4399 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
4400 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
4401 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
4402 | ||
4403 | Acknowledgement | |
4404 | ||
4405 | Funding for the RFC Editor function is currently provided by the | |
4406 | Internet Society. | |
4407 | ||
4408 | ||
4409 | ||
4410 | ||
4411 | ||
4412 | ||
4413 | ||
4414 | ||
4415 | ||
4416 | ||
4417 | ||
4418 | ||
4419 | ||
4420 | ||
4421 | ||
4422 | ||
4423 | ||
4424 | ||
4425 | ||
4426 | Klensin Standards Track [Page 79] | |
4427 | \f |