Commit

Author:

Hash:

Timestamp:

+4069 -0 +/-7 browse

Kevin Schoon [me@kevinschoon.com]

3c2c8486b5c09b9698d7be5528e8e80d6f32c196

Tue, 30 Jul 2024 15:32:20 +0000 (1.3 years ago)

update documentation and add more rfcs
1diff --git a/README.md b/README.md
2index a3a1312..8f35111 100644
3--- a/README.md
4+++ b/README.md
5 @@ -2,3 +2,78 @@
6
7 Lightweight embeddable SMTP [RFC5321](https://www.rfc-editor.org/rfc/rfc5321.html)
8 server for use in applications that need to receive e-mail.
9+
10+ ## Use Case
11+
12+ The original goal of this library is to have a usable SMTP server that can be
13+ embedded in mailing list software, particularly for use in
14+ [Ayllu](https://ayllu-forge.org) and
15+ [Mailpot](https://git.meli-email.org/meli/mailpot). After considering all of
16+ the existing SMTP servers there was no Rust library that could be easily
17+ embedded in an application and general purpose SMTP servers like Postfix are
18+ too complex to be reasonably packaged.
19+
20+ ## Security
21+
22+ Due to the common abuse of the SMTP protocol by nefarious internet actors the
23+ default behavior of this package must _never_ allow open relaying without
24+ explicit and conscious configuration from the user. Additionally the SMTP
25+ server must never expose the e-mail addresses or other user data contained
26+ within.
27+
28+ ## Alpha Status
29+
30+ NOTE: This library is at best in an "alpha" state currently and should be used
31+ for _absolutely nothing_ that is important.
32+
33+ ## Protocol Status
34+
35+ ### SMTP Base server and Commands [RFC5321](rfcs/rfc5321.txt)
36+
37+ | Name | Status | Notes |
38+ |----------|--------|----------|
39+ | HELO | ✅ | |
40+ |----------|--------|----------|
41+ | EHLO | ✅ | |
42+ |----------|--------|----------|
43+ | MAIL | ✅ | |
44+ |----------|--------|----------|
45+ | RCPT | ✅ | |
46+ |----------|--------|----------|
47+ | BDAT | ✅ | |
48+ |----------|--------|----------|
49+ | DATA | ✅ | |
50+ |----------|--------|----------|
51+ | AUTH | ❌ | No authentication currently supported |
52+ |----------|--------|----------|
53+ | VRFY | ❌ | |
54+ |----------|--------|----------|
55+ | EXPN | ❌ | |
56+ |----------|--------|----------|
57+ | STARTTLS | ❌ | For the moment there is no plan to implement STARTTLS |
58+ |----------|--------|----------|
59+
60+
61+ ### ESMTP Extensions
62+
63+ | Name | Status | RFC |
64+ |-----------------------|----------|-------------------------------|
65+ | SIZE | TODO | [RFC1870](rfcs/rfc1870.txt) |
66+ |-----------------------|----------|-------------------------------|
67+ | PIPELINING | TODO | [RFC2920](rfcs/rc2920.txt) |
68+ |-----------------------|----------|-------------------------------|
69+ | 8BITMIME | TODO | [RFC6152](rfcs/rfc6152.txt) |
70+ |-----------------------|----------|-------------------------------|
71+ | ENHANCED STATUS CODES | TODO | [RFC2920](rfcs/rfc3463.txt) |
72+ |-----------------------|----------|-------------------------------|
73+ | SMTPUTF8 | TODO | [RFC6531](rfcs/rfc6531.txt) |
74+ |-----------------------|----------|-------------------------------|
75+ | CHUNKING | TODO | [RFC3030](rfcs/rfc3030.txt) |
76+ |-----------------------|----------|-------------------------------|
77+ | DSN | TODO | [RFC3461](rfcs/rfc3461.txt) |
78+ |-----------------------|----------|-------------------------------|
79+
80+ ## Attributions
81+
82+ Several of the free software libraries released by
83+ [stalwart](https://github.com/stalwartlabs/mail-server) are in use here.
84 diff --git a/rfcs/rfc1870.txt b/rfcs/rfc1870.txt
85new file mode 100644
86index 0000000..edf3c98
87--- /dev/null
88+++ b/rfcs/rfc1870.txt
89 @@ -0,0 +1,507 @@
90+
91+
92+
93+
94+
95+
96+ Network Working Group J. Klensin, WG Chair
97+ Request For Comments: 1870 MCI
98+ STD: 10 N. Freed, Editor
99+ Obsoletes: 1653 Innosoft International, Inc.
100+ Category: Standards Track K. Moore
101+ University of Tennessee
102+ November 1995
103+
104+
105+ SMTP Service Extension
106+ for Message Size Declaration
107+
108+ Status of this Memo
109+
110+ This document specifies an Internet standards track protocol for the
111+ Internet community, and requests discussion and suggestions for
112+ improvements. Please refer to the current edition of the "Internet
113+ Official Protocol Standards" (STD 1) for the standardization state
114+ and status of this protocol. Distribution of this memo is unlimited.
115+
116+ 1. Abstract
117+
118+ This memo defines an extension to the SMTP service whereby an SMTP
119+ client and server may interact to give the server an opportunity to
120+ decline to accept a message (perhaps temporarily) based on the
121+ client's estimate of the message size.
122+
123+ 2. Introduction
124+
125+ The MIME extensions to the Internet message protocol provide for the
126+ transmission of many kinds of data which were previously unsupported
127+ in Internet mail. One expected result of the use of MIME is that
128+ SMTP will be expected to carry a much wider range of message sizes
129+ than was previously the case. This has an impact on the amount of
130+ resources (e.g. disk space) required by a system acting as a server.
131+
132+ This memo uses the mechanism defined in [5] to define extensions to
133+ the SMTP service whereby a client ("sender-SMTP") may declare the
134+ size of a particular message to a server ("receiver-SMTP"), after
135+ which the server may indicate to the client that it is or is not
136+ willing to accept the message based on the declared message size and
137+ whereby a server ("receiver-SMTP") may declare the maximum message
138+ size it is willing to accept to a client ("sender-SMTP").
139+
140+
141+
142+
143+
144+
145+
146+
147+ Klensin, et al Standards Track [Page 1]
148+
149+ RFC 1870 SMTP Size Declaration November 1995
150+
151+
152+ 3. Framework for the Size Declaration Extension
153+
154+ The following service extension is therefore defined:
155+
156+ (1) the name of the SMTP service extension is "Message Size
157+ Declaration";
158+
159+ (2) the EHLO keyword value associated with this extension is "SIZE";
160+
161+ (3) one optional parameter is allowed with this EHLO keyword value, a
162+ decimal number indicating the fixed maximum message size in bytes
163+ that the server will accept. The syntax of the parameter is as
164+ follows, using the augmented BNF notation of [2]:
165+
166+ size-param ::= [1*DIGIT]
167+
168+ A parameter value of 0 (zero) indicates that no fixed maximum
169+ message size is in force. If the parameter is omitted no
170+ information is conveyed about the server's fixed maximum message
171+ size;
172+
173+ (4) one optional parameter using the keyword "SIZE" is added to the
174+ MAIL FROM command. The value associated with this parameter is a
175+ decimal number indicating the size of the message that is to be
176+ transmitted. The syntax of the value is as follows, using the
177+ augmented BNF notation of [2]:
178+
179+ size-value ::= 1*20DIGIT
180+
181+ (5) the maximum length of a MAIL FROM command line is increased by 26
182+ characters by the possible addition of the SIZE keyword and
183+ value;
184+
185+ (6) no additional SMTP verbs are defined by this extension.
186+
187+ The remainder of this memo specifies how support for the extension
188+ affects the behavior of an SMTP client and server.
189+
190+ 4. The Message Size Declaration service extension
191+
192+ An SMTP server may have a fixed upper limit on message size. Any
193+ attempt by a client to transfer a message which is larger than this
194+ fixed upper limit will fail. In addition, a server normally has
195+ limited space with which to store incoming messages. Transfer of a
196+ message may therefore also fail due to a lack of storage space, but
197+ might succeed at a later time.
198+
199+
200+
201+
202+
203+ Klensin, et al Standards Track [Page 2]
204+
205+ RFC 1870 SMTP Size Declaration November 1995
206+
207+
208+ A client using the unextended SMTP protocol defined in [1], can only
209+ be informed of such failures after transmitting the entire message to
210+ the server (which discards the transferred message). If, however,
211+ both client and server support the Message Size Declaration service
212+ extension, such conditions may be detected before any transfer is
213+ attempted.
214+
215+ An SMTP client wishing to relay a large content may issue the EHLO
216+ command to start an SMTP session, to determine if the server supports
217+ any of several service extensions. If the server responds with code
218+ 250 to the EHLO command, and the response includes the EHLO keyword
219+ value SIZE, then the Message Size Declaration extension is supported.
220+
221+ If a numeric parameter follows the SIZE keyword value of the EHLO
222+ response, it indicates the size of the largest message that the
223+ server is willing to accept. Any attempt by a client to transfer a
224+ message which is larger than this limit will be rejected with a
225+ permanent failure (552) reply code.
226+
227+ A server that supports the Message Size Declaration extension will
228+ accept the extended version of the MAIL command described below.
229+ When supported by the server, a client may use the extended MAIL
230+ command (instead of the MAIL command as defined in [1]) to declare an
231+ estimate of the size of a message it wishes to transfer. The server
232+ may then return an appropriate error code if it determines that an
233+ attempt to transfer a message of that size would fail.
234+
235+ 5. Definitions
236+
237+ The message size is defined as the number of octets, including CR-LF
238+ pairs, but not the SMTP DATA command's terminating dot or doubled
239+ quoting dots, to be transmitted by the SMTP client after receiving
240+ reply code 354 to the DATA command.
241+
242+ The fixed maximum message size is defined as the message size of the
243+ largest message that a server is ever willing to accept. An attempt
244+ to transfer any message larger than the fixed maximum message size
245+ will always fail. The fixed maximum message size may be an
246+ implementation artifact of the SMTP server, or it may be chosen by
247+ the administrator of the server.
248+
249+ The declared message size is defined as a client's estimate of the
250+ message size for a particular message.
251+
252+
253+
254+
255+
256+
257+
258+
259+ Klensin, et al Standards Track [Page 3]
260+
261+ RFC 1870 SMTP Size Declaration November 1995
262+
263+
264+ 6. The extended MAIL command
265+
266+ The extended MAIL command is issued by a client when it wishes to
267+ inform a server of the size of the message to be sent. The extended
268+ MAIL command is identical to the MAIL command as defined in [1],
269+ except that a SIZE parameter appears after the address.
270+
271+ The complete syntax of this extended command is defined in [5]. The
272+ esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by
273+ the syntax for size-value shown above.
274+
275+ The value associated with the SIZE parameter is a decimal
276+ representation of the declared message size in octets. This number
277+ should include the message header, body, and the CR-LF sequences
278+ between lines, but not the SMTP DATA command's terminating dot or
279+ doubled quoting dots. Only one SIZE parameter may be specified in a
280+ single MAIL command.
281+
282+ Ideally, the declared message size is equal to the true message size.
283+ However, since exact computation of the message size may be
284+ infeasable, the client may use a heuristically-derived estimate.
285+ Such heuristics should be chosen so that the declared message size is
286+ usually larger than the actual message size. (This has the effect of
287+ making the counting or non-counting of SMTP DATA dots largely an
288+ academic point.)
289+
290+ NOTE: Servers MUST NOT use the SIZE parameter to determine end of
291+ content in the DATA command.
292+
293+ 6.1 Server action on receipt of the extended MAIL command
294+
295+ Upon receipt of an extended MAIL command containing a SIZE parameter,
296+ a server should determine whether the declared message size exceeds
297+ its fixed maximum message size. If the declared message size is
298+ smaller than the fixed maximum message size, the server may also wish
299+ to determine whether sufficient resources are available to buffer a
300+ message of the declared message size and to maintain it in stable
301+ storage, until the message can be delivered or relayed to each of its
302+ recipients.
303+
304+ A server may respond to the extended MAIL command with any of the
305+ error codes defined in [1] for the MAIL command. In addition, one of
306+ the following error codes may be returned:
307+
308+ (1) If the server currently lacks sufficient resources to accept a
309+ message of the indicated size, but may be able to accept the
310+ message at a later time, it responds with code "452 insufficient
311+ system storage".
312+
313+
314+
315+ Klensin, et al Standards Track [Page 4]
316+
317+ RFC 1870 SMTP Size Declaration November 1995
318+
319+
320+ (2) If the indicated size is larger than the server's fixed maximum
321+ message size, the server responds with code "552 message size
322+ exceeds fixed maximium message size".
323+
324+ A server is permitted, but not required, to accept a message which
325+ is, in fact, larger than declared in the extended MAIL command, such
326+ as might occur if the client employed a size-estimation heuristic
327+ which was inaccurate.
328+
329+ 6.2 Client action on receiving response to extended MAIL command
330+
331+ The client, upon receiving the server's response to the extended MAIL
332+ command, acts as follows:
333+
334+ (1) If the code "452 insufficient system storage" is returned, the
335+ client should next send either a RSET command (if it wishes to
336+ attempt to send other messages) or a QUIT command. The client
337+ should then repeat the attempt to send the message to the server
338+ at a later time.
339+
340+ (2) If the code "552 message exceeds fixed maximum message size" is
341+ received, the client should immediately send either a RSET command
342+ (if it wishes to attempt to send additional messages), or a QUIT
343+ command. The client should then declare the message undeliverable
344+ and return appropriate notification to the sender (if a sender
345+ address was present in the MAIL command).
346+
347+ A successful (250) reply code in response to the extended MAIL
348+ command does not constitute an absolute guarantee that the message
349+ transfer will succeed. SMTP clients using the extended MAIL command
350+ must still be prepared to handle both temporary and permanent error
351+ reply codes (including codes 452 and 552), either immediately after
352+ issuing the DATA command, or after transfer of the message.
353+
354+ 6.3 Messages larger than the declared size.
355+
356+ Once a server has agreed (via the extended MAIL command) to accept a
357+ message of a particular size, it should not return a 552 reply code
358+ after the transfer phase of the DATA command, unless the actual size
359+ of the message transferred is greater than the declared message size.
360+ A server may also choose to accept a message which is somewhat larger
361+ than the declared message size.
362+
363+ A client is permitted to declare a message to be smaller than its
364+ actual size. However, in this case, a successful (250) reply code is
365+ no assurance that the server will accept the message or has
366+ sufficient resources to do so. The server may reject such a message
367+ after its DATA transfer.
368+
369+
370+
371+ Klensin, et al Standards Track [Page 5]
372+
373+ RFC 1870 SMTP Size Declaration November 1995
374+
375+
376+ 6.4 Per-recipient rejection based on message size.
377+
378+ A server that implements this extension may return a 452 or 552 reply
379+ code in response to a RCPT command, based on its unwillingness to
380+ accept a message of the declared size for a particular recipient.
381+
382+ (1) If a 452 code is returned, the client may requeue the message for
383+ later delivery to the same recipient.
384+
385+ (2) If a 552 code is returned, the client may not requeue the message
386+ for later delivery to the same recipient.
387+
388+ 7. Minimal usage
389+
390+ A "minimal" client may use this extension to simply compare its
391+ (perhaps estimated) size of the message that it wishes to relay, with
392+ the server's fixed maximum message size (from the parameter to the
393+ SIZE keyword in the EHLO response), to determine whether the server
394+ will ever accept the message. Such an implementation need not
395+ declare message sizes via the extended MAIL command. However,
396+ neither will it be able to discover temporary limits on message size
397+ due to server resource limitations, nor per-recipient limitations on
398+ message size.
399+
400+ A minimal server that employs this service extension may simply use
401+ the SIZE keyword value to inform the client of the size of the
402+ largest message it will accept, or to inform the client that there is
403+ no fixed limit on message size. Such a server must accept the
404+ extended MAIL command and return a 552 reply code if the client's
405+ declared size exceeds its fixed size limit (if any), but it need not
406+ detect "temporary" limitations on message size.
407+
408+ The numeric parameter to the EHLO SIZE keyword is optional. If the
409+ parameter is omitted entirely it indicates that the server does not
410+ advertise a fixed maximum message size. A server that returns the
411+ SIZE keyword with no parameter in response to the EHLO command may
412+ not issue a positive (250) response to an extended MAIL command
413+ containing a SIZE specification without first checking to see if
414+ sufficient resources are available to transfer a message of the
415+ declared size, and to retain it in stable storage until it can be
416+ relayed or delivered to its recipients. If possible, the server
417+ should actually reserve sufficient storage space to transfer the
418+ message.
419+
420+
421+
422+
423+
424+
425+
426+
427+ Klensin, et al Standards Track [Page 6]
428+
429+ RFC 1870 SMTP Size Declaration November 1995
430+
431+
432+ 8. Example
433+
434+ The following example illustrates the use of size declaration with
435+ some permanent and temporary failures.
436+
437+ S: <wait for connection on TCP port 25>
438+ C: <open connection to server>
439+ S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
440+ C: EHLO ymir.claremont.edu
441+ S: 250-sigurd.innosoft.com
442+ S: 250-EXPN
443+ S: 250-HELP
444+ S: 250 SIZE 1000000
445+ C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
446+ S: 250 Address Ok.
447+ C: RCPT TO:<ned@innosoft.com>
448+ S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
449+ C: RCPT TO:<ned@ymir.claremont.edu>
450+ S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
451+ C: RCPT TO:<ned@hmcvax.claremont.edu>
452+ S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
453+ C: DATA
454+ S: 354 Send message, ending in CRLF.CRLF.
455+ ...
456+ C: .
457+ S: 250 Some recipients OK
458+ C: QUIT
459+ S: 221 Goodbye
460+
461+ 9. Security Considerations
462+
463+ The size declaration extensions described in this memo can
464+ conceivably be used to facilitate crude service denial attacks.
465+ Specifically, both the information contained in the SIZE parameter
466+ and use of the extended MAIL command make it somewhat quicker and
467+ easier to devise an efficacious service denial attack. However,
468+ unless implementations are very weak, these extensions do not create
469+ any vulnerability that has not always existed with SMTP. In addition,
470+ no issues are addressed involving trusted systems and possible
471+ release of information via the mechanisms described in this RFC.
472+
473+ 10. Acknowledgements
474+
475+ This document was derived from an earlier Working Group work in
476+ progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot
477+ Lear, Marshall T. Rose, and Einar Stefferud provided extensive
478+ comments in response to earlier works in progress of both this and
479+ the previous memo.
480+
481+
482+
483+ Klensin, et al Standards Track [Page 7]
484+
485+ RFC 1870 SMTP Size Declaration November 1995
486+
487+
488+ 11. References
489+
490+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
491+ USC/Information Sciences Institute, August 1982.
492+
493+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
494+ Messages", STD 11, RFC 822, UDEL, August 1982.
495+
496+ [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
497+ Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
498+
499+ [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
500+ Headers", RFC 1522, University of Tennessee, September 1993.
501+
502+ [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
503+ "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
504+ International, Inc., Dover Beach Consulting, Inc., Network
505+ Management Associates, Inc., Brandenburg Consulting, November
506+ 1995.
507+
508+ [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
509+ 974, BBN, January 1986.
510+
511+
512+
513+
514+
515+
516+
517+
518+
519+
520+
521+
522+
523+
524+
525+
526+
527+
528+
529+
530+
531+
532+
533+
534+
535+
536+
537+
538+
539+ Klensin, et al Standards Track [Page 8]
540+
541+ RFC 1870 SMTP Size Declaration November 1995
542+
543+
544+ 12. Chair, Editor, and Author Addresses
545+
546+ John Klensin, WG Chair
547+ MCI
548+ 2100 Reston Parkway
549+ Reston, VA 22091
550+
551+ Phone: +1 703 715-7361
552+ Fax: +1 703 715-7436
553+ EMail: klensin@mci.net
554+
555+
556+ Ned Freed, Editor
557+ Innosoft International, Inc.
558+ 1050 East Garvey Avenue South
559+ West Covina, CA 91790
560+ USA
561+
562+ Phone: +1 818 919 3600
563+ Fax: +1 818 919 3614
564+ EMail: ned@innosoft.com
565+
566+
567+ Keith Moore
568+ Computer Science Dept.
569+ University of Tennessee
570+ 107 Ayres Hall
571+ Knoxville, TN 37996-1301
572+ USA
573+
574+ EMail: moore@cs.utk.edu
575+
576+
577+
578+
579+
580+
581+
582+
583+
584+
585+
586+
587+
588+
589+
590+
591+
592+
593+
594+
595+ Klensin, et al Standards Track [Page 9]
596+
597 diff --git a/rfcs/rfc1985.txt b/rfcs/rfc1985.txt
598new file mode 100644
599index 0000000..f49afd7
600--- /dev/null
601+++ b/rfcs/rfc1985.txt
602 @@ -0,0 +1,395 @@
603+
604+
605+
606+
607+
608+
609+ Network Working Group J. De Winter
610+ Request for Comments: 1985 Wildbear Consulting, Inc.
611+ Category: Standards Track August 1996
612+
613+
614+ SMTP Service Extension
615+ for Remote Message Queue Starting
616+
617+ Status of this Memo
618+
619+ This document specifies an Internet standards track protocol for the
620+ Internet community, and requests discussion and suggestions for
621+ improvements. Please refer to the current edition of the "Internet
622+ Official Protocol Standards" (STD 1) for the standardization state
623+ and status of this protocol. Distribution of this memo is unlimited.
624+
625+ Abstract
626+
627+ This memo defines an extension to the SMTP service whereby an SMTP
628+ client and server may interact to give the server an opportunity to
629+ start the processing of its queues for messages to go to a given
630+ host. This extension is meant to be used in startup conditions as
631+ well as for mail nodes that have transient connections to their
632+ service providers.
633+
634+ 1. Introduction
635+
636+ The TURN command was a valid attempt to address the problem of having
637+ to start the processing for the mail queue on a remote machine.
638+ However, the TURN command presents a large security loophole. As
639+ there is no verification of the remote host name, the TURN command
640+ could be used by a rogue system to download the mail for a site other
641+ than itself.
642+
643+ Therefore, this memo introduces the ETRN command. This command uses
644+ the mechanism defined in [4] to define extensions to the SMTP service
645+ whereby a client ("sender-SMTP") may request that the server
646+ ("receiver-SMTP") start the processing of its mail queues for
647+ messages that are waiting at the server for the client machine. If
648+ any messages are at the server for the client, then the server should
649+ create a new SMTP session and send the messages at that time.
650+
651+
652+
653+
654+
655+
656+
657+
658+
659+
660+ De Winter Standards Track [Page 1]
661+
662+ RFC 1985 SMTP Service Extension - ETRN August 1996
663+
664+
665+ 2. Framework for the ETRN Extension
666+
667+ The following service extension is therefore defined:
668+
669+ (1) the name of the SMTP service extension is "Remote Queue
670+ Processing Declaration";
671+
672+ (2) the EHLO keyword value associated with this extension is "ETRN",
673+ with no associated parameters;
674+
675+ (3) one additional verb, ETRN, with a single parameter that
676+ specifies the name of the client(s) to start processing for;
677+
678+ (4) no additional SMTP verbs are defined by this extension.
679+
680+ The remainder of this memo specifies how support for the extension
681+ affects the behavior of an SMTP client and server.
682+
683+ 3. The Remote Queue Processing Declaration service extension
684+
685+ To save money, many small companies want to only maintain transient
686+ connections to their service providers. In addition, there are some
687+ situations where the client sites depend on their mail arriving
688+ quickly, so forcing the queues on the server belonging to their
689+ service provider may be more desirable than waiting for the retry
690+ timeout to occur.
691+
692+ Both of these situations could currently be fixed using the TURN
693+ command defined in [1], if it were not for a large security loophole
694+ in the TURN command. As it stands, the TURN command will reverse the
695+ direction of the SMTP connection and assume that the remote host is
696+ being honest about what its name is. The security loophole is that
697+ there is no documented stipulation for checking the authenticity of
698+ the remote host name, as given in the HELO or EHLO command. As such,
699+ most SMTP and ESMTP implementations do not implement the TURN command
700+ to avoid this security loophole.
701+
702+ This has been addressed in the design of the ETRN command. This
703+ extended turn command was written with the points in the first
704+ paragraph in mind, yet paying attention to the problems that
705+ currently exist with the TURN command. The security loophole is
706+ avoided by asking the server to start a new connection aimed at the
707+ specified client.
708+
709+ In this manner, the server has a lot more certainty that it is
710+ talking to the correct SMTP client. This mechanism can just be seen
711+ as a more immediate version of the retry queues that appear in most
712+ SMTP implementations. In addition, as this command will take a
713+
714+
715+
716+ De Winter Standards Track [Page 2]
717+
718+ RFC 1985 SMTP Service Extension - ETRN August 1996
719+
720+
721+ single parameter, the name of the remote host(s) to start the queues
722+ for, the server can decide whether it wishes to respect the request
723+ or deny it for any local administrative reasons.
724+
725+ 4. Definitions
726+
727+ Remote queue processing means that using an SMTP or ESMTP connection,
728+ the client may request that the server start to process parts of its
729+ messaging queue. This processing is performed using the existing
730+ SMTP infrastructure and will occur at some point after the processing
731+ is initiated.
732+
733+ The server host is the node that is responding to the ETRN
734+ command.
735+
736+ The client host is the node that is initiating the ETRN command.
737+
738+ The remote host name is defined to be a plain-text field that
739+ specifies a name for the remote host(s). This remote host name may
740+ also include an alias for the specified remote host or special
741+ commands to identify other types of queues.
742+
743+ 5. The extended ETRN command
744+
745+ The extended ETRN command is issued by the client host when it wishes
746+ to start the SMTP queue processing of a given server host. The
747+ syntax of this command is as follows:
748+
749+ ETRN [<option character>]<node name><CR><LF>
750+
751+ This command may be issued at any time once a session is established,
752+ as long as there is not a transaction occuring. Thus, this command
753+ is illegal between a MAIL FROM: command and the end of the DATA
754+ commands and responses.
755+
756+ The specified node name must be a fully qualified domain name for the
757+ node, which may refer to a CNAME or MX pointer in the DNS. If an
758+ alias is used for the node, multiple ETRN commands may be needed to
759+ start the processing for the node as it may be listed at the remote
760+ site under multiple names. This can also be addressed using the
761+ options discussed in section 5.3.
762+
763+ The option character under normal circumstances is not used.
764+
765+
766+
767+
768+
769+
770+
771+
772+ De Winter Standards Track [Page 3]
773+
774+ RFC 1985 SMTP Service Extension - ETRN August 1996
775+
776+
777+ 5.1 Server action on receipt of the extended ETRN command
778+
779+ When the server host receives the ETRN command, it should have a look
780+ at the node name that is specified in the command and make a local
781+ decision if it should honour the request. If not, the appropriate
782+ error codes should be returned to the client.
783+
784+ Otherwise, the server host should force its retry queues to start
785+ sending messages to that remote site, using another SMTP connection.
786+ At the moment, there is no requirement that a connection must occur,
787+ or that the connection must occur within a given time frame. This
788+ should be noted in the case where there are no messages for the
789+ client host at the server host and only the 250 response is used.
790+
791+ Since the processing of the queues may take an indeterminate amount
792+ of time, this command should return immediately with a response to
793+ the client host. The valid return codes for this command are:
794+
795+ 250 OK, queuing for node <x> started
796+ 251 OK, no messages waiting for node <x>
797+ 252 OK, pending messages for node <x> started
798+ 253 OK, <n> pending messages for node <x> started
799+ 458 Unable to queue messages for node <x>
800+ 459 Node <x> not allowed: <reason>
801+ 500 Syntax Error
802+ 501 Syntax Error in Parameters
803+
804+ The 250 response code does not indicate that messages will be sent to
805+ the system in question, just that the queue has been started and some
806+ action will occur. If the server is capable of supporting it, the
807+ 251, 252 or 253 response codes should be used to give more
808+ information to the client side. In this case, if there are messages
809+ waiting for the client side node, a check can be performed using
810+ these responses codes as an indication of when there are no more
811+ pending messages in the queue for that node.
812+
813+ The 458 and 459 result codes should be used to give more information
814+ back to the client host as to why the action was not performed. If
815+ the syntax of the request is not correct, then the 500 and 501 result
816+ codes should be used.
817+
818+ 5.2 Client action on receiving response to extended ETRN command
819+
820+ If one of the 500 level error codes (550 or 551) are sent, the client
821+ should assume that the protocol is not supported in the remote host
822+ or that the protocol has not been implemented correctly on either the
823+ client or server host. In this case, multiple ETRN commands (dealing
824+ with the aliases for the system) should not be sent.
825+
826+
827+
828+ De Winter Standards Track [Page 4]
829+
830+ RFC 1985 SMTP Service Extension - ETRN August 1996
831+
832+
833+ If the 250 response is received, then the client host can assume that
834+ the server host found its request to be satisfactory and it will send
835+ any queued messages. This process may involve going through a very
836+ large retry queue, and may take some time.
837+
838+ If the 400 level response is received, then the client can assume
839+ that the server supports the command, but for some local reason does
840+ not want to accept the ETRN command as is. In most cases, it will
841+ mean that there is a list of nodes that it will accept the command
842+ from and the current client is not on that list. The 459 response
843+ code is presented to allow for a more in-depth reason as to why the
844+ remote queuing cannot be started.
845+
846+ 5.3 Use Of ETRN to release mail for a subdomain or queue
847+
848+ If the requesting server wishes to release all of the mail for a
849+ given subdomain, a variation on the ETRN command can be used. To
850+ perform this request, the option character '@' should be used in
851+ front of the node name. In this manner, any domain names that are
852+ formed with a suffix of the specified node name are released.
853+
854+ For example, if the command ETRN @foo.com was issued, then any
855+ accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com
856+ may be released. It should be noted that the receiving side of the
857+ ETRN command should make a decision based on the client in question
858+ and only allow certain combinations for each of the nodes. This is
859+ more of a security issue than anything else.
860+
861+ In a similar vein, it might be necessary under some circumstances to
862+ release a certain queue, where that queue does not correspond to a
863+ given domain name. To this end, the option character '#' can be used
864+ to force the processing of a given queue. In this case, the node
865+ name would be used as a queue name instead, and its syntactical
866+ structure would be dependant on the receiving server. An example of
867+ this would be using the command ETRN #uucp to force the flush of a
868+ UUCP queue. Note that the use of this option is entirely a local
869+ matter and there is no way for a client to find a list of any such
870+ queues that exist.
871+
872+ 6. Minimal usage
873+
874+ A "minimal" client may use this extension with its host name to start
875+ the queues on the server host. This minimal usage will not handle
876+ cases where mail for 'x.y' is sent to 's.x.y'.
877+
878+ A minimal server may use this extensions to start the processing of
879+ the queues for all remote sites. In this case, the 458 error
880+ response will not be seen, and it should always return the 250
881+
882+
883+
884+ De Winter Standards Track [Page 5]
885+
886+ RFC 1985 SMTP Service Extension - ETRN August 1996
887+
888+
889+ response as it will always try and start the processing for any
890+ request.
891+
892+ 7. Example
893+
894+ The following example illustrates the use of remote queue processing
895+ with some permanent and temporary failures.
896+
897+ S: <wait for connection on TCP port 25>
898+ C: <open connection to server>
899+ S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
900+ C: EHLO ymir.claremont.edu
901+ S: 250-sigurd.innosoft.com
902+ S: 250-EXPN
903+ S: 250-HELP
904+ S: 250 ETRN
905+ C: ETRN
906+ S: 500 Syntax Error
907+ C: ETRN localname
908+ S: 501 Syntax Error in Parameters
909+ C: ETRN uu.net
910+ S: 458 Unable to queue messages for node uu.net
911+ ...
912+
913+ C: ETRN sigurd.innosoft.com
914+ S: 250 OK, queuing for node sigurd.innosoft.com started
915+ C: ETRN innosoft.com
916+ S: 250 OK, queuing for node innosoft.com started
917+
918+ OR
919+
920+ C: ETRN sigurd.innosoft.com
921+ S: 251 OK, no messages waiting for node sigurd.innosoft.com
922+ C: ETRN innosoft.com
923+ S: 252 OK, pending messages for node innosoft.com started
924+ C: ETRN mysoft.com
925+ S: 253 OK, 14 pending messages for node mysoft.com started
926+
927+ ...
928+ C: ETRN foo.bar
929+ S: 459 Node foo.bar not allowed: Unable to resolve name.
930+ ...
931+ C: QUIT
932+ S: 250 Goodbye
933+
934+
935+
936+
937+
938+
939+
940+ De Winter Standards Track [Page 6]
941+
942+ RFC 1985 SMTP Service Extension - ETRN August 1996
943+
944+
945+ 8. Security Considerations
946+
947+ This command does not compromise any security considerations of any
948+ existing SMTP or ESMTP protocols as it merely shortens the time that
949+ a client needs to wait before their messages are retried.
950+
951+ Precautions should be taken to make sure that any client server can
952+ only use the @ and # option characters for systems that make sense.
953+ Failure to implement some kind of sanity checking on the parameters
954+ could lead to congestion. This would be evident if a person asking
955+ to release @com, which would release mail for any address that ended
956+ with com.
957+
958+ 9. Acknowledgements
959+
960+ This document was created with lots of support from the users of our
961+ products, who have given some input to the functionality that they
962+ would like to see in the software that they bought.
963+
964+ 10. References
965+
966+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
967+ 821, August 1982.
968+
969+ [2] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
970+ E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
971+ Nations University, Innosoft International, Inc., Dover Beach
972+ Consulting, Inc., Network Management Associates, Inc., The Branch
973+ Office, February 1993.
974+
975+ 11. Author's Address
976+
977+ Jack De Winter
978+ Wildbear Consulting, Inc.
979+ 17 Brock Street
980+ Kitchener, Ontario, Canada
981+ N2M 1X2
982+
983+ Phone: +1 519 576 3873
984+ EMail: jack@wildbear.on.ca
985+
986+
987+
988+
989+
990+
991+
992+
993+
994+
995+
996+ De Winter Standards Track [Page 7]
997+
998 diff --git a/rfcs/rfc2920.txt b/rfcs/rfc2920.txt
999new file mode 100644
1000index 0000000..833bd8f
1001--- /dev/null
1002+++ b/rfcs/rfc2920.txt
1003 @@ -0,0 +1,507 @@
1004+
1005+
1006+
1007+
1008+
1009+
1010+ Network Working Group N. Freed
1011+ Request for Comments: 2920 Innosoft
1012+ STD: 60 September 2000
1013+ Obsoletes: 2197
1014+ Category: Standards Track
1015+
1016+
1017+ SMTP Service Extension for Command Pipelining
1018+
1019+ Status of this Memo
1020+
1021+ This document specifies an Internet standards track protocol for the
1022+ Internet community, and requests discussion and suggestions for
1023+ improvements. Please refer to the current edition of the "Internet
1024+ Official Protocol Standards" (STD 1) for the standardization state
1025+ and status of this protocol. Distribution of this memo is unlimited.
1026+
1027+ Copyright Notice
1028+
1029+ Copyright (C) The Internet Society (2000). All Rights Reserved.
1030+
1031+ Abstract
1032+
1033+ This memo defines an extension to the Simple Mail Transfer Protocol
1034+ (SMTP) service whereby a server can indicate the extent of its
1035+ ability to accept multiple commands in a single Transmission Control
1036+ Protocol (TCP) send operation. Using a single TCP send operation for
1037+ multiple commands can improve SMTP performance significantly.
1038+
1039+ 1. Introduction
1040+
1041+ Although SMTP is widely and robustly deployed, certain extensions may
1042+ nevertheless prove useful. In particular, many parts of the Internet
1043+ make use of high latency network links. SMTP's intrinsic one
1044+ command-one response structure is significantly penalized by high
1045+ latency links, often to the point where the factors contributing to
1046+ overall connection time are dominated by the time spent waiting for
1047+ responses to individual commands (turnaround time).
1048+
1049+ In the best of all worlds it would be possible to simply deploy SMTP
1050+ client software that makes use of command pipelining: batching up
1051+ multiple commands into single TCP send operations. Unfortunately, the
1052+ original SMTP specification [RFC-821] did not explicitly state that
1053+ SMTP servers must support this. As a result a non-trivial number of
1054+ Internet SMTP servers cannot adequately handle command pipelining.
1055+ Flaws known to exist in deployed servers include:
1056+
1057+
1058+
1059+
1060+
1061+ Freed Standards Track [Page 1]
1062+
1063+ RFC 2920 SMTP for Command Pipelining September 2000
1064+
1065+
1066+ (1) Connection handoff and buffer flushes in the middle of the
1067+ SMTP dialogue. Creation of server processes for incoming SMTP
1068+ connections is a useful, obvious, and harmless implementation
1069+ technique. However, some SMTP servers defer process forking
1070+ and connection handoff until some intermediate point in the
1071+ SMTP dialogue. When this is done material read from the TCP
1072+ connection and kept in process buffers can be lost.
1073+
1074+ (2) Flushing the TCP input buffer when an SMTP command fails. SMTP
1075+ commands often fail but there is no reason to flush the TCP
1076+ input buffer when this happens. Nevertheless, some SMTP
1077+ servers do this.
1078+
1079+ (3) Improper processing and promulgation of SMTP command failures.
1080+ For example, some SMTP servers will refuse to accept a DATA
1081+ command if the last RCPT TO command fails, paying no attention
1082+ to the success or failure of prior RCPT TO command results.
1083+ Other servers will accept a DATA command even when all
1084+ previous RCPT TO commands have failed. Although it is possible
1085+ to accommodate this sort of behavior in a client that employs
1086+ command pipelining, it does complicate the construction of the
1087+ client unnecessarily.
1088+
1089+ This memo uses the mechanism described in [RFC-1869] to define an
1090+ extension to the SMTP service whereby an SMTP server can declare that
1091+ it is capable of handling pipelined commands. The SMTP client can
1092+ then check for this declaration and use pipelining only when the
1093+ server declares itself capable of handling it.
1094+
1095+ 1.1. Requirements Notation
1096+
1097+ This document occasionally uses terms that appear in capital letters.
1098+ When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
1099+ appear capitalized, they are being used to indicate particular
1100+ requirements of this specification. A discussion of the meanings of
1101+ the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the
1102+ terms "MUST NOT" and "SHOULD NOT" are logical extensions of this
1103+ usage.
1104+
1105+ 2. Framework for the Command Pipelining Extension
1106+
1107+ The Command Pipelining extension is defined as follows:
1108+
1109+ (1) the name of the SMTP service extension is Pipelining;
1110+
1111+ (2) the EHLO keyword value associated with the extension is
1112+ PIPELINING;
1113+
1114+
1115+
1116+
1117+ Freed Standards Track [Page 2]
1118+
1119+ RFC 2920 SMTP for Command Pipelining September 2000
1120+
1121+
1122+ (3) no parameter is used with the PIPELINING EHLO keyword;
1123+
1124+ (4) no additional parameters are added to either the MAIL FROM or
1125+ RCPT TO commands.
1126+
1127+ (5) no additional SMTP verbs are defined by this extension; and,
1128+
1129+ (6) the next section specifies how support for the extension
1130+ affects the behavior of a server and client SMTP.
1131+
1132+ 3. The Pipelining Service Extension
1133+
1134+ When a client SMTP wishes to employ command pipelining, it first
1135+ issues the EHLO command to the server SMTP. If the server SMTP
1136+ responds with code 250 to the EHLO command, and the response includes
1137+ the EHLO keyword value PIPELINING, then the server SMTP has indicated
1138+ that it can accommodate SMTP command pipelining.
1139+
1140+ 3.1. Client use of pipelining
1141+
1142+ Once the client SMTP has confirmed that support exists for the
1143+ pipelining extension, the client SMTP may then elect to transmit
1144+ groups of SMTP commands in batches without waiting for a response to
1145+ each individual command. In particular, the commands RSET, MAIL FROM,
1146+ SEND FROM, SOML FROM, SAML FROM, and RCPT TO can all appear anywhere
1147+ in a pipelined command group. The EHLO, DATA, VRFY, EXPN, TURN,
1148+ QUIT, and NOOP commands can only appear as the last command in a
1149+ group since their success or failure produces a change of state which
1150+ the client SMTP must accommodate. (NOOP is included in this group so
1151+ it can be used as a synchronization point.)
1152+
1153+ Additional commands added by other SMTP extensions may only appear as
1154+ the last command in a group unless otherwise specified by the
1155+ extensions that define the commands.
1156+
1157+ The actual transfer of message content is explicitly allowed to be
1158+ the first "command" in a group. That is, a RSET/MAIL FROM sequence
1159+ used to initiate a new message transaction can be placed in the same
1160+ group as the final transfer of the headers and body of the previous
1161+ message.
1162+
1163+ Client SMTP implementations that employ pipelining MUST check ALL
1164+ statuses associated with each command in a group. For example, if
1165+ none of the RCPT TO recipient addresses were accepted the client must
1166+ then check the response to the DATA command -- the client cannot
1167+ assume that the DATA command will be rejected just because none of
1168+ the RCPT TO commands worked. If the DATA command was properly
1169+ rejected the client SMTP can just issue RSET, but if the DATA command
1170+
1171+
1172+
1173+ Freed Standards Track [Page 3]
1174+
1175+ RFC 2920 SMTP for Command Pipelining September 2000
1176+
1177+
1178+ was accepted the client SMTP should send a single dot.
1179+
1180+ Command statuses MUST be coordinated with responses by counting each
1181+ separate response and correlating that count with the number of
1182+ commands known to have been issued. Multiline responses MUST be
1183+ supported. Matching on the basis of either the error code value or
1184+ associated text is expressly forbidden.
1185+
1186+ Client SMTP implementations MAY elect to operate in a nonblocking
1187+ fashion, processing server responses immediately upon receipt, even
1188+ if there is still data pending transmission from the client's
1189+ previous TCP send operation. If nonblocking operation is not
1190+ supported, however, client SMTP implementations MUST also check the
1191+ TCP window size and make sure that each group of commands fits
1192+ entirely within the window. The window size is usually, but not
1193+ always, 4K octets. Failure to perform this check can lead to
1194+ deadlock conditions.
1195+
1196+ Clients MUST NOT confuse responses to multiple commands with
1197+ multiline responses. Each command requires one or more lines of
1198+ response, the last line not containing a dash between the response
1199+ code and the response string.
1200+
1201+ 3.2. Server support of pipelining
1202+
1203+ A server SMTP implementation that offers the pipelining extension:
1204+
1205+ (1) MUST respond to commands in the order they are received from
1206+ the client.
1207+
1208+ (2) SHOULD elect to store responses to grouped RSET, MAIL FROM,
1209+ SEND FROM, SOML FROM, SAML FROM, and RCPT TO commands in an
1210+ internal buffer so they can sent as a unit.
1211+
1212+ (3) SHOULD issue a positive response to the DATA command if and
1213+ only if one or more valid RCPT TO addresses have been
1214+ previously received.
1215+
1216+ (4) MUST NOT, after issuing a positive response to a DATA command
1217+ with no valid recipients and subsequently receiving an empty
1218+ message, send any message whatsoever to anybody.
1219+
1220+ (5) MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, TURN,
1221+ QUIT, and NOOP.
1222+
1223+ (6) MUST NOT buffer responses to unrecognized commands.
1224+
1225+
1226+
1227+
1228+
1229+ Freed Standards Track [Page 4]
1230+
1231+ RFC 2920 SMTP for Command Pipelining September 2000
1232+
1233+
1234+ (7) MUST send all pending responses immediately whenever the local
1235+ TCP input buffer is emptied.
1236+
1237+ (8) MUST NOT make assumptions about commands that are yet to be
1238+ received.
1239+
1240+ (9) MUST NOT flush or otherwise lose the contents of the TCP input
1241+ buffer under any circumstances whatsoever.
1242+
1243+ (10) SHOULD issue response text that indicates, either implicitly
1244+ or explicitly, what command the response matches.
1245+
1246+ The overriding intent of these server requirements is to make it as
1247+ easy as possible for servers to conform to these pipelining
1248+ extensions.
1249+
1250+ 4. Examples
1251+
1252+ Consider the following SMTP dialogue that does not use pipelining:
1253+
1254+ S: <wait for open connection>
1255+ C: <open connection to server>
1256+ S: 220 Innosoft.com SMTP service ready
1257+ C: HELO dbc.mtview.ca.us
1258+ S: 250 Innosoft.com
1259+ C: MAIL FROM:<mrose@dbc.mtview.ca.us>
1260+ S: 250 sender <mrose@dbc.mtview.ca.us> OK
1261+ C: RCPT TO:<ned@innosoft.com>
1262+ S: 250 recipient <ned@innosoft.com> OK
1263+ C: RCPT TO:<dan@innosoft.com>
1264+ S: 250 recipient <dan@innosoft.com> OK
1265+ C: RCPT TO:<kvc@innosoft.com>
1266+ S: 250 recipient <kvc@innosoft.com> OK
1267+ C: DATA
1268+ S: 354 enter mail, end with line containing only "."
1269+ ...
1270+ C: .
1271+ S: 250 message sent
1272+ C: QUIT
1273+ S: 221 goodbye
1274+
1275+ The client waits for a server response a total of 9 times in this
1276+ simple example. But if pipelining is employed the following dialogue
1277+ is possible:
1278+
1279+ S: <wait for open connection>
1280+ C: <open connection to server>
1281+ S: 220 innosoft.com SMTP service ready
1282+
1283+
1284+
1285+ Freed Standards Track [Page 5]
1286+
1287+ RFC 2920 SMTP for Command Pipelining September 2000
1288+
1289+
1290+ C: EHLO dbc.mtview.ca.us
1291+ S: 250-innosoft.com
1292+ S: 250 PIPELINING
1293+ C: MAIL FROM:<mrose@dbc.mtview.ca.us>
1294+ C: RCPT TO:<ned@innosoft.com>
1295+ C: RCPT TO:<dan@innosoft.com>
1296+ C: RCPT TO:<kvc@innosoft.com>
1297+ C: DATA
1298+ S: 250 sender <mrose@dbc.mtview.ca.us> OK
1299+ S: 250 recipient <ned@innosoft.com> OK
1300+ S: 250 recipient <dan@innosoft.com> OK
1301+ S: 250 recipient <kvc@innosoft.com> OK
1302+ S: 354 enter mail, end with line containing only "."
1303+ ...
1304+ C: .
1305+ C: QUIT
1306+ S: 250 message sent
1307+ S: 221 goodbye
1308+
1309+ The total number of turnarounds has been reduced from 9 to 4.
1310+
1311+ The next example illustrates one possible form of behavior when
1312+ pipelining is used and all recipients are rejected:
1313+
1314+ S: <wait for open connection>
1315+ C: <open connection to server>
1316+ S: 220 innosoft.com SMTP service ready
1317+ C: EHLO dbc.mtview.ca.us
1318+ S: 250-innosoft.com
1319+ S: 250 PIPELINING
1320+ C: MAIL FROM:<mrose@dbc.mtview.ca.us>
1321+ C: RCPT TO:<nsb@thumper.bellcore.com>
1322+ C: RCPT TO:<galvin@tis.com>
1323+ C: DATA
1324+ S: 250 sender <mrose@dbc.mtview.ca.us> OK
1325+ S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
1326+ S: 550 remote mail to <galvin@tis.com> not allowed
1327+ S: 554 no valid recipients given
1328+ C: QUIT
1329+ S: 221 goodbye
1330+
1331+ The client SMTP waits for the server 4 times here as well. If the
1332+ server SMTP does not check for at least one valid recipient prior to
1333+ accepting the DATA command, the following dialogue would result:
1334+
1335+ S: <wait for open connection>
1336+ C: <open connection to server>
1337+ S: 220 innosoft.com SMTP service ready
1338+
1339+
1340+
1341+ Freed Standards Track [Page 6]
1342+
1343+ RFC 2920 SMTP for Command Pipelining September 2000
1344+
1345+
1346+ C: EHLO dbc.mtview.ca.us
1347+ S: 250-innosoft.com
1348+ S: 250 PIPELINING
1349+ C: MAIL FROM:<mrose@dbc.mtview.ca.us>
1350+ C: RCPT TO:<nsb@thumper.bellcore.com>
1351+ C: RCPT TO:<galvin@tis.com>
1352+ C: DATA
1353+ S: 250 sender <mrose@dbc.mtview.ca.us> OK
1354+ S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
1355+ S: 550 remote mail to <galvin@tis.com> not allowed
1356+ S: 354 enter mail, end with line containing only "."
1357+ C: .
1358+ C: QUIT
1359+ S: 554 no valid recipients
1360+ S: 221 goodbye
1361+
1362+ 5. Security Considerations
1363+
1364+ This RFC does not discuss security issues and is not believed
1365+ to raise any security issues not endemic in electronic mail
1366+ and present in fully conforming implementations of [RFC-821].
1367+
1368+ 6. Acknowledgements
1369+
1370+ This document is based on the SMTP service extension model
1371+ presented in RFC 1425. Marshall Rose's description of SMTP
1372+ command pipelining in his book "The Internet Message" also
1373+ served as a source of inspiration for this extension.
1374+
1375+ 7. References
1376+
1377+ [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
1378+ 821, August 1982.
1379+
1380+ [RFC-1123] Braden, R., "Requirements for Internet Hosts --
1381+ Application and Support", STD 3, RFC 1123, October, 1989.
1382+
1383+ [RFC-1854] Freed, N., "SMTP Service Extension for Command
1384+ Pipelining", RFC 1854, October 1995.
1385+
1386+ [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
1387+ Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
1388+ November 1995.
1389+
1390+ [RFC-2197] Freed, N., "SMTP Service Extension for Command
1391+ Pipelining", RFC 2197, September 1997.
1392+
1393+
1394+
1395+
1396+
1397+ Freed Standards Track [Page 7]
1398+
1399+ RFC 2920 SMTP for Command Pipelining September 2000
1400+
1401+
1402+ 8. Author's Address
1403+
1404+ Ned Freed
1405+ Innosoft International, Inc.
1406+ 1050 Lakes Drive
1407+ West Covina, CA 91790
1408+ USA
1409+
1410+ Phone: +1 626 919 3600
1411+ Fax: +1 626 919 361
1412+ EMail: ned.freed@innosoft.com
1413+
1414+ This document is a product of work done by the Internet Engineering
1415+ Task Force Working Group on Messaging Extensions, Alan Cargille,
1416+ chair.
1417+
1418+
1419+
1420+
1421+
1422+
1423+
1424+
1425+
1426+
1427+
1428+
1429+
1430+
1431+
1432+
1433+
1434+
1435+
1436+
1437+
1438+
1439+
1440+
1441+
1442+
1443+
1444+
1445+
1446+
1447+
1448+
1449+
1450+
1451+
1452+
1453+ Freed Standards Track [Page 8]
1454+
1455+ RFC 2920 SMTP for Command Pipelining September 2000
1456+
1457+
1458+ 9. Full Copyright Statement
1459+
1460+ Copyright (C) The Internet Society (2000). All Rights Reserved.
1461+
1462+ This document and translations of it may be copied and furnished to
1463+ others, and derivative works that comment on or otherwise explain it
1464+ or assist in its implementation may be prepared, copied, published
1465+ and distributed, in whole or in part, without restriction of any
1466+ kind, provided that the above copyright notice and this paragraph are
1467+ included on all such copies and derivative works. However, this
1468+ document itself may not be modified in any way, such as by removing
1469+ the copyright notice or references to the Internet Society or other
1470+ Internet organizations, except as needed for the purpose of
1471+ developing Internet standards in which case the procedures for
1472+ copyrights defined in the Internet Standards process must be
1473+ followed, or as required to translate it into languages other than
1474+ English.
1475+
1476+ The limited permissions granted above are perpetual and will not be
1477+ revoked by the Internet Society or its successors or assigns.
1478+
1479+ This document and the information contained herein is provided on an
1480+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1481+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1482+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1483+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1484+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1485+
1486+
1487+
1488+ Acknowledgement
1489+
1490+ Funding for the RFC Editor function is currently provided by the
1491+ Internet Society.
1492+
1493+
1494+
1495+
1496+
1497+
1498+
1499+
1500+
1501+
1502+
1503+
1504+
1505+
1506+
1507+
1508+
1509+ Freed Standards Track [Page 9]
1510+
1511 diff --git a/rfcs/rfc3030.txt b/rfcs/rfc3030.txt
1512new file mode 100644
1513index 0000000..821b675
1514--- /dev/null
1515+++ b/rfcs/rfc3030.txt
1516 @@ -0,0 +1,675 @@
1517+
1518+
1519+
1520+
1521+
1522+
1523+ Network Working Group G. Vaudreuil
1524+ Request for Comments: 3030 Lucent Technologies
1525+ Obsolete: 1830 December 2000
1526+ Category: Standards Track
1527+
1528+
1529+ SMTP Service Extensions
1530+ for Transmission of Large
1531+ and Binary MIME Messages
1532+
1533+ Status of this Memo
1534+
1535+ This document specifies an Internet standards track protocol for the
1536+ Internet community, and requests discussion and suggestions for
1537+ improvements. Please refer to the current edition of the "Internet
1538+ Official Protocol Standards" (STD 1) for the standardization state
1539+ and status of this protocol. Distribution of this memo is unlimited.
1540+
1541+ Copyright Notice
1542+
1543+ Copyright (C) The Internet Society (2000). All Rights Reserved.
1544+
1545+ Abstract
1546+
1547+ This memo defines two extensions to the SMTP (Simple Mail Transfer
1548+ Protocol) service. The first extension enables a SMTP client and
1549+ server to negotiate the use of an alternative to the DATA command,
1550+ called "BDAT", for efficiently sending large MIME (Multipurpose
1551+ Internet Mail Extensions) messages. The second extension takes
1552+ advantage of the BDAT command to permit the negotiated sending of
1553+ MIME messages that employ the binary transfer encoding. This
1554+ document is intended to update and obsolete RFC 1830.
1555+
1556+ Working Group Summary
1557+
1558+ This protocol is not the product of an IETF working group, however
1559+ the specification resulted from discussions within the ESMTP working
1560+ group. The resulting protocol documented in RFC 1830 was classified
1561+ as experimental at that time due to questions about the robustness of
1562+ the Binary Content-Transfer-Encoding deployed in then existent MIME
1563+ implementations. As MIME has matured and other uses of the Binary
1564+ Content-Transfer-Encoding have been deployed, these concerns have
1565+ been allayed. With this document, Binary ESMTP is expected to become
1566+ standards-track.
1567+
1568+
1569+
1570+
1571+
1572+
1573+
1574+ Vaudreuil Standards Track [Page 1]
1575+
1576+ RFC 3030 Binary ESMTP December 2000
1577+
1578+
1579+ Document Conventions
1580+
1581+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
1582+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
1583+ document are to be interpreted as described in RFC 2119 [RFC2119].
1584+
1585+ Table of Contents
1586+
1587+ 1. Overview ................................................... 2
1588+ 2. Framework for the Large Message Extensions ................. 3
1589+ 3. Framework for the Binary Service Extension ................. 5
1590+ 4. Examples ................................................... 8
1591+ 4.1 Simple Chunking .......................................... 8
1592+ 4.2 Pipelining BINARYMIME .................................... 8
1593+ 5. Security Considerations .................................... 9
1594+ 6. References ................................................. 9
1595+ 7. Author's Address ........................................... 10
1596+ 8. Appendix A - Changes from RFC 1830 ......................... 11
1597+ 9. Full Copyright Statement ................................... 12
1598+
1599+ 1. Overview
1600+
1601+ The MIME extensions to the Internet message format provides for the
1602+ transmission of many kinds of data that were previously unsupported
1603+ in Internet mail. Anticipating the need to transport the new media
1604+ more efficiently, the SMTP protocol has been extended to provide
1605+ transport for new message types. RFC 1652 defines one such extension
1606+ for the transmission of unencoded 8-bit MIME messages [8BIT]. This
1607+ service extension permits the receiver SMTP to declare support for
1608+ 8-bit body parts and the sender to request 8-bit transmission of a
1609+ particular message.
1610+
1611+ One expected result of the use of MIME is that the Internet mail
1612+ system will be expected to carry very large mail messages. In such
1613+ transactions, there is a performance-based desire to eliminate the
1614+ requirement that the message be scanned for "CR LF . CR LF" sequences
1615+ upon sending and receiving to detect the end of message.
1616+
1617+ Independent of the need to send large messages, Internet mail is
1618+ increasingly multimedia. There is a need to avoid the overhead of
1619+ base64 and quoted-printable encoding of binary objects sent using the
1620+ MIME message format over SMTP between hosts that support binary
1621+ message processing.
1622+
1623+
1624+
1625+
1626+
1627+
1628+
1629+
1630+ Vaudreuil Standards Track [Page 2]
1631+
1632+ RFC 3030 Binary ESMTP December 2000
1633+
1634+
1635+ This memo uses the mechanism defined in [ESMTP] to define two
1636+ extensions to the SMTP service whereby an SMTP server ("receiver-
1637+ SMTP") may declare support for the message chunking transmission mode
1638+ and support for the reception of Binary messages, which the SMTP
1639+ client ("sender-SMTP") is then free to use.
1640+
1641+ 2. Framework for the Large Message Extensions
1642+
1643+ The following service extension is hereby defined:
1644+
1645+ 1) The name of the data chunking service extension is "CHUNKING".
1646+
1647+ 2) The EHLO keyword value associated with this extension is
1648+ "CHUNKING".
1649+
1650+ 3) A new SMTP verb, BDAT, is defined as an alternative to the "DATA"
1651+ command of [RFC821]. The BDAT verb takes two arguments. The
1652+ first argument indicates the length, in octets, of the binary data
1653+ chunk. The second optional argument indicates that the data chunk
1654+ is the last.
1655+
1656+ bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
1657+ chunk-size ::= 1*DIGIT
1658+ end-marker ::= "LAST"
1659+
1660+ 4) This extension may be used for SMTP message submission. [Submit]
1661+
1662+ 5) Servers that offer the BDAT extension MUST continue to support the
1663+ regular SMTP DATA command. Clients are free to use DATA to
1664+ transfer appropriately encoded to servers that support the
1665+ CHUNKING extension if they wish to do so.
1666+
1667+ The CHUNKING service extension enables the use of the BDAT
1668+ alternative to the DATA command. This extension can be used for any
1669+ message, whether 7-bit, 8BITMIME or BINARYMIME.
1670+
1671+ When a sender-SMTP wishes to send (using the MAIL command) a large
1672+ message using the CHUNKING extension, it first issues the EHLO
1673+ command to the receiver-SMTP. If the receiver-SMTP responds with
1674+ code 250 to the EHLO command and the response includes the EHLO
1675+ keyword value CHUNKING, then the receiver-SMTP is indicating that it
1676+ supports the BDAT command and will accept the sending of messages in
1677+ chunks.
1678+
1679+ After all MAIL and RCPT responses are collected and processed, the
1680+ message is sent using a series of BDAT commands. The BDAT command
1681+ takes one required argument, the exact length of the data segment in
1682+
1683+
1684+
1685+
1686+ Vaudreuil Standards Track [Page 3]
1687+
1688+ RFC 3030 Binary ESMTP December 2000
1689+
1690+
1691+ octets. The message data is sent immediately after the trailing <CR>
1692+ <LF> of the BDAT command line. Once the receiver-SMTP receives the
1693+ specified number of octets, it will return a 250 reply code.
1694+
1695+ The optional LAST parameter on the BDAT command indicates that this
1696+ is the last chunk of message data to be sent. The last BDAT command
1697+ MAY have a byte-count of zero indicating there is no additional data
1698+ to be sent. Any BDAT command sent after the BDAT LAST is illegal and
1699+ MUST be replied to with a 503 "Bad sequence of commands" reply code.
1700+ The state resulting from this error is indeterminate. A RSET command
1701+ MUST be sent to clear the transaction before continuing.
1702+
1703+ A 250 response MUST be sent to each successful BDAT data block within
1704+ a mail transaction. If a failure occurs after a BDAT command is
1705+ received, the receiver-SMTP MUST accept and discard the associated
1706+ message data before sending the appropriate 5XX or 4XX code. If a
1707+ 5XX or 4XX code is received by the sender-SMTP in response to a BDAT
1708+ chunk, the transaction should be considered failed and the sender-
1709+ SMTP MUST NOT send any additional BDAT segments. If the receiver-
1710+ SMTP has declared support for command pipelining [PIPE], the receiver
1711+ SMTP MUST be prepared to accept and discard additional BDAT chunks
1712+ already in the pipeline after the failed BDAT.
1713+
1714+ Note: An error on the receiver-SMTP such as disk full or imminent
1715+ shutdown can only be reported after the BDAT segment has been
1716+ received. It is therefore important to choose a reasonable chunk
1717+ size given the expected end-to-end bandwidth.
1718+
1719+ Note: Because the receiver-SMTP does not acknowledge the BDAT
1720+ command before the message data is sent, it is important to send
1721+ the BDAT only to systems that have declared their capability to
1722+ accept BDAT commands. Illegally sending a BDAT command and
1723+ associated message data to a non-CHUNKING capable system will
1724+ result in the receiver-SMTP parsing the associated message data as
1725+ if it were a potentially very long, ESMTP command line containing
1726+ binary data.
1727+
1728+ The resulting state from a failed BDAT command is indeterminate. A
1729+ RSET command MUST be issued to clear the transaction before
1730+ additional commands may be sent. The RSET command, when issued after
1731+ the first BDAT and before the BDAT LAST, clears all segments sent
1732+ during that transaction and resets the session.
1733+
1734+ DATA and BDAT commands cannot be used in the same transaction. If a
1735+ DATA statement is issued after a BDAT for the current transaction, a
1736+ 503 "Bad sequence of commands" MUST be issued. The state resulting
1737+ from this error is indeterminate. A RSET command MUST be sent to
1738+
1739+
1740+
1741+
1742+ Vaudreuil Standards Track [Page 4]
1743+
1744+ RFC 3030 Binary ESMTP December 2000
1745+
1746+
1747+ clear the transaction before continuing. There is no prohibition on
1748+ using DATA and BDAT in the same session, so long as they are not
1749+ mixed in the same transaction.
1750+
1751+ The local storage size of a message may not accurately reflect the
1752+ actual size of the message sent due to local storage conventions. In
1753+ particular, text messages sent with the BDAT command MUST be sent in
1754+ the canonical MIME format with lines delimited with a <CR><LF>. It
1755+ may not be possible to convert the entire message to the canonical
1756+ format at once. CHUNKING provides a mechanism to convert the message
1757+ to canonical form, accurately count the bytes, and send the message a
1758+ single chunk at a time.
1759+
1760+ Note: Correct byte counting is essential. If the sender-SMTP
1761+ indicates a chunk-size larger than the actual chunk-size, the
1762+ receiver-SMTP will continue to wait for the remainder of the data
1763+ or when using streaming, will read the subsequent command as
1764+ additional message data. In the case where a portion of the
1765+ previous command was read as data, the parser will return a syntax
1766+ error when the incomplete command is read.
1767+
1768+ If the sender-SMTP indicates a chunk-size smaller than the actual
1769+ chunk-size, the receiver-SMTP will interpret the remainder of the
1770+ message data as invalid commands. Note that the remainder of the
1771+ message data may be binary and as such lexicographical parsers
1772+ MUST be prepared to receive, process, and reject lines of
1773+ arbitrary octets.
1774+
1775+ 3. Framework for the Binary Service Extension
1776+
1777+ The following service extension is hereby defined:
1778+
1779+ 1) The name of the binary service extension is "BINARYMIME".
1780+
1781+ 2) The EHLO keyword value associated with this extension is
1782+ "BINARYMIME".
1783+
1784+ 3) The BINARYMIME service extension can only be used with the
1785+ "CHUNKING" service extension.
1786+
1787+ 4) No parameter is used with the BINARYMIME keyword.
1788+
1789+ 5) [8BIT] defines the BODY parameter for the MAIL command. This
1790+ extension defines an additional value for the BODY parameter,
1791+ "BINARYMIME". The value "BINARYMIME" associated with this
1792+ parameter indicates that this message is a Binary MIME message (in
1793+
1794+
1795+
1796+
1797+
1798+ Vaudreuil Standards Track [Page 5]
1799+
1800+ RFC 3030 Binary ESMTP December 2000
1801+
1802+
1803+ strict compliance with [MIME]) with arbitrary octet content being
1804+ sent. The revised syntax of the value is as follows, using the
1805+ ABNF notation of [RFC822]:
1806+
1807+ body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
1808+
1809+ 6) No new verbs are defined for the BINARYMIME extension.
1810+
1811+ 7) This extension may be used for SMTP message submission. [Submit]
1812+
1813+ 8) The maximum length of a MAIL FROM command line is increased by 16
1814+ characters by the possible addition of the BODY=BINARYMIME keyword
1815+ and value;.
1816+
1817+ A sender-SMTP may request that a binary MIME message be sent without
1818+ transport encoding by sending a BODY parameter with a value of
1819+ "BINARYMIME" with the MAIL command. When the receiver-SMTP accepts a
1820+ MAIL command with the BINARYMIME body-value, it agrees to preserve
1821+ all bits in each octet passed using the BDAT command. Once a
1822+ receiver-SMTP supporting the BINARYMIME service extension accepts a
1823+ message containing binary material, the receiver-SMTP MUST deliver or
1824+ relay the message in such a way as to preserve all bits in each
1825+ octet.
1826+
1827+ BINARYMIME cannot be used with the DATA command. If a DATA command
1828+ is issued after a MAIL command containing the body-value of
1829+ "BINARYMIME", a 503 "Bad sequence of commands" response MUST be sent.
1830+ The resulting state from this error condition is indeterminate and
1831+ the transaction MUST be reset with the RSET command.
1832+
1833+ It is especially important when using BINARYMIME to ensure that the
1834+ MIME message itself is properly formed. In particular, it is
1835+ essential that text be canonically encoded with each line properly
1836+ terminated with <CR><LF>. Any transformation of text into non-
1837+ canonical MIME to observe local storage conventions MUST be reversed
1838+ before sending as BINARYMIME. Some line-oriented shortcuts will
1839+ break if used with BINARYMIME. A sender-SMTP MUST use the canonical
1840+ encoding for a given MIME content-type. In particular, text/* MUST
1841+ be sent with <CR><LF> terminated lines.
1842+
1843+ Note: Although CR and LF do not necessarily represent ends of text
1844+ lines in BDAT chunks and use of the binary transfer encoding is
1845+ allowed, the RFC 2781 prohibition against using a UTF-16 charset
1846+ within the text top-level media type remains.
1847+
1848+
1849+
1850+
1851+
1852+
1853+
1854+ Vaudreuil Standards Track [Page 6]
1855+
1856+ RFC 3030 Binary ESMTP December 2000
1857+
1858+
1859+ The syntax of the extended MAIL command is identical to the MAIL
1860+ command in [RFC821], except that a BODY=BINARYMIME parameter and
1861+ value MUST be added. The complete syntax of this extended command is
1862+ defined in [ESMTP].
1863+
1864+ If a receiver-SMTP does not indicate support the BINARYMIME message
1865+ format then the sender-SMTP MUST NOT, under any circumstances, send
1866+ binary data.
1867+
1868+ If the receiver-SMTP does not support BINARYMIME and the message to
1869+ be sent is a MIME object with a binary encoding, a sender-SMTP has
1870+ three options with which to forward the message. First, if the
1871+ receiver-SMTP supports the 8bit-MIMEtransport extension [8bit] and
1872+ the content is amenable to being encoded in 8bit, the sender-SMTP may
1873+ implement a gateway transformation to convert the message into valid
1874+ 8bit-encoded MIME. Second, it may implement a gateway transformation
1875+ to convert the message into valid 7bit-encoded MIME. Third, it may
1876+ treat this as a permanent error and handle it in the usual manner for
1877+ delivery failures. The specifics of MIME content-transfer-encodings,
1878+ including transformations from Binary MIME to 8bit or 7bit MIME are
1879+ not described by this RFC; the conversion is nevertheless constrained
1880+ in the following ways:
1881+
1882+ 1. The conversion MUST cause no loss of information; MIME
1883+ transport encodings MUST be employed as needed to insure this
1884+ is the case.
1885+
1886+ 2. The resulting message MUST be valid 7bit or 8bit MIME. In
1887+ particular, the transformation MUST NOT result in nested Base-
1888+ 64 or Quoted-Printable content-transfer-encodings.
1889+
1890+ Note that at the time of this writing there are no mechanisms for
1891+ converting a binary MIME object into an 8-bit MIME object. Such a
1892+ transformation will require the specification of a new MIME content-
1893+ transfer-encoding.
1894+
1895+ If the MIME message contains a "Binary" content-transfer-encoding and
1896+ the BODY parameter does not indicate BINARYMIME, the message MUST be
1897+ accepted. The message SHOULD be returned to the sender with an
1898+ appropriate DSN. The message contents MAY be returned to the sender
1899+ if the offending content can be mangled into a legal DSN structure.
1900+ "Fixing" and forwarding the offending content is beyond the scope of
1901+ this document.
1902+
1903+
1904+
1905+
1906+
1907+
1908+
1909+
1910+ Vaudreuil Standards Track [Page 7]
1911+
1912+ RFC 3030 Binary ESMTP December 2000
1913+
1914+
1915+ 4. Examples
1916+
1917+ 4.1 Simple Chunking
1918+
1919+ The following simple dialogue illustrates the use of the large
1920+ message extension to send a short pseudo-RFC 822 message to one
1921+ recipient using the CHUNKING extension:
1922+
1923+ R: <wait for connection on TCP port 25>
1924+ S: <open connection to server>
1925+ R: 220 cnri.reston.va.us SMTP service ready
1926+ S: EHLO ymir.claremont.edu
1927+ R: 250-cnri.reston.va.us says hello
1928+ R: 250 CHUNKING
1929+ S: MAIL FROM:<Sam@Random.com>
1930+ R: 250 <Sam@Random.com> Sender ok
1931+ S: RCPT TO:<Susan@Random.com>
1932+ R: 250 <Susan@random.com> Recipient ok
1933+ S: BDAT 86 LAST
1934+ S: To: Susan@random.com<CR><LF>
1935+ S: From: Sam@random.com<CR><LF>
1936+ S: Subject: This is a bodyless test message<CR><LF>
1937+ R: 250 Message OK, 86 octets received
1938+ S: QUIT
1939+ R: 221 Goodbye
1940+
1941+ 4.2 Pipelining BINARYMIME
1942+
1943+ The following dialogue illustrates the use of the large message
1944+ extension to send a BINARYMIME object to two recipients using the
1945+ CHUNKING and PIPELINING extensions:
1946+
1947+ R: <wait for connection on TCP port
1948+ S: <open connection to server>
1949+ R: 220 cnri.reston.va.us SMTP service ready
1950+ S: EHLO ymir.claremont.edu
1951+ R: 250-cnri.reston.va.us says hello
1952+ R: 250-PIPELINING
1953+ R: 250-BINARYMIME
1954+ R: 250 CHUNKING
1955+ S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME
1956+ S: RCPT TO:<gvaudre@cnri.reston.va.us>
1957+ S: RCPT TO:<jstewart@cnri.reston.va.us>
1958+ R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
1959+ R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
1960+ R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
1961+ S: BDAT 100000
1962+ S: (First 10000 octets of canonical MIME message data)
1963+
1964+
1965+
1966+ Vaudreuil Standards Track [Page 8]
1967+
1968+ RFC 3030 Binary ESMTP December 2000
1969+
1970+
1971+ S: BDAT 324
1972+ S: (Remaining 324 octets of canonical MIME message data)
1973+ S: BDAT 0 LAST
1974+ R: 250 100000 octets received
1975+ R: 250 324 octets received
1976+ R: 250 Message OK, 100324 octets received
1977+ S: QUIT
1978+ R: 221 Goodbye
1979+
1980+ 5. Security Considerations
1981+
1982+ This extension is not known to present any additional security issues
1983+ not already endemic to electronic mail and present in fully
1984+ conforming implementations of [RFC821], or otherwise made possible by
1985+ [MIME].
1986+
1987+ 6. References
1988+
1989+ [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of
1990+ Large and Binary MIME Messages", RFC 1830, August 1995.
1991+
1992+ [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
1993+ 821, August 1982.
1994+
1995+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
1996+ Messages", STD 11, RFC 822, August 1982.
1997+
1998+ [MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail
1999+ Extensions (MIME) Part One: Format of Internet Message
2000+ Bodies", RFC 2045, November 1996.
2001+
2002+ [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
2003+ December 1998.
2004+
2005+ [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
2006+ Crocker, "SMTP Service Extensions", RFC 1869, November
2007+ 1995.
2008+
2009+ [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
2010+ Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
2011+ RFC 1652, July 1994.
2012+
2013+ [PIPE] Freed, N., "SMTP Service Extensions for Command
2014+ Pipelining", RFC 2920, September 2000.
2015+
2016+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2017+ Requirement Levels", BCP 14, RFC 2119, March 1997.
2018+
2019+
2020+
2021+
2022+ Vaudreuil Standards Track [Page 9]
2023+
2024+ RFC 3030 Binary ESMTP December 2000
2025+
2026+
2027+ 7. Author's Address
2028+
2029+ Gregory M. Vaudreuil
2030+ Lucent Technologies
2031+ 17080 Dallas Parkway
2032+ Dallas, TX 75248-1905
2033+
2034+ Phone/Fax: +1-972-733-2722
2035+ EMail: GregV@ieee.org
2036+
2037+
2038+
2039+
2040+
2041+
2042+
2043+
2044+
2045+
2046+
2047+
2048+
2049+
2050+
2051+
2052+
2053+
2054+
2055+
2056+
2057+
2058+
2059+
2060+
2061+
2062+
2063+
2064+
2065+
2066+
2067+
2068+
2069+
2070+
2071+
2072+
2073+
2074+
2075+
2076+
2077+
2078+ Vaudreuil Standards Track [Page 10]
2079+
2080+ RFC 3030 Binary ESMTP December 2000
2081+
2082+
2083+ Appendix A - Changes from RFC 1830
2084+
2085+ Numerous editorial changes including required intellectual property
2086+ boilerplate and revised authors contact information
2087+
2088+ Corrected the simple chunking example to use the correct number of
2089+ bytes. Updated the pipelining example to illustrate use of the BDAT
2090+ 0 LAST construct.
2091+
2092+
2093+
2094+
2095+
2096+
2097+
2098+
2099+
2100+
2101+
2102+
2103+
2104+
2105+
2106+
2107+
2108+
2109+
2110+
2111+
2112+
2113+
2114+
2115+
2116+
2117+
2118+
2119+
2120+
2121+
2122+
2123+
2124+
2125+
2126+
2127+
2128+
2129+
2130+
2131+
2132+
2133+
2134+ Vaudreuil Standards Track [Page 11]
2135+
2136+ RFC 3030 Binary ESMTP December 2000
2137+
2138+
2139+ Full Copyright Statement
2140+
2141+ Copyright (C) The Internet Society (2000). All Rights Reserved.
2142+
2143+ This document and translations of it may be copied and furnished to
2144+ others, and derivative works that comment on or otherwise explain it
2145+ or assist in its implementation may be prepared, copied, published
2146+ and distributed, in whole or in part, without restriction of any
2147+ kind, provided that the above copyright notice and this paragraph are
2148+ included on all such copies and derivative works. However, this
2149+ document itself may not be modified in any way, such as by removing
2150+ the copyright notice or references to the Internet Society or other
2151+ Internet organizations, except as needed for the purpose of
2152+ developing Internet standards in which case the procedures for
2153+ copyrights defined in the Internet Standards process must be
2154+ followed, or as required to translate it into languages other than
2155+ English.
2156+
2157+ The limited permissions granted above are perpetual and will not be
2158+ revoked by the Internet Society or its successors or assigns.
2159+
2160+ This document and the information contained herein is provided on an
2161+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2162+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2163+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2164+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2165+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2166+
2167+ Acknowledgement
2168+
2169+ Funding for the RFC Editor function is currently provided by the
2170+ Internet Society.
2171+
2172+
2173+
2174+
2175+
2176+
2177+
2178+
2179+
2180+
2181+
2182+
2183+
2184+
2185+
2186+
2187+
2188+
2189+
2190+ Vaudreuil Standards Track [Page 12]
2191+
2192 diff --git a/rfcs/rfc3463.txt b/rfcs/rfc3463.txt
2193new file mode 100644
2194index 0000000..5544b2c
2195--- /dev/null
2196+++ b/rfcs/rfc3463.txt
2197 @@ -0,0 +1,899 @@
2198+
2199+
2200+
2201+
2202+
2203+
2204+ Network Working Group G. Vaudreuil
2205+ Request for Comments: 3463 Lucent Technologies
2206+ Obsoletes: 1893 January 2003
2207+ Category: Standards Track
2208+
2209+
2210+ Enhanced Mail System Status Codes
2211+
2212+ Status of this Memo
2213+
2214+ This document specifies an Internet standards track protocol for the
2215+ Internet community, and requests discussion and suggestions for
2216+ improvements. Please refer to the current edition of the "Internet
2217+ Official Protocol Standards" (STD 1) for the standardization state
2218+ and status of this protocol. Distribution of this memo is unlimited.
2219+
2220+ Copyright Notice
2221+
2222+ Copyright (C) The Internet Society (2003). All Rights Reserved.
2223+
2224+ Abstract
2225+
2226+ This document defines a set of extended status codes for use within
2227+ the mail system for delivery status reports, tracking, and improved
2228+ diagnostics. In combination with other information provided in the
2229+ Delivery Status Notification (DSN) delivery report, these codes
2230+ facilitate media and language independent rendering of message
2231+ delivery status.
2232+
2233+ Table of Contents
2234+
2235+ 1. Overview ......................................................2
2236+ 2. Status Code Structure .........................................3
2237+ 3. Enumerated Status Codes .......................................5
2238+ 3.1 Other or Undefined Status ...................................6
2239+ 3.2 Address Status ..............................................6
2240+ 3.3 Mailbox Status ..............................................7
2241+ 3.4 Mail system status ..........................................8
2242+ 3.5 Network and Routing Status ..................................9
2243+ 3.6 Mail Delivery Protocol Status ..............................10
2244+ 3.7 Message Content or Message Media Status ....................11
2245+ 3.8 Security or Policy Status ..................................12
2246+ 4. References ...................................................13
2247+ 5. Security Considerations ......................................13
2248+ Appendix A - Collected Status Codes ..........................14
2249+ Appendix B - Changes from RFC1893 ............................15
2250+ Author's Address .............................................15
2251+ Full Copyright Statement .....................................16
2252+
2253+
2254+
2255+ Vaudreuil Standards Track [Page 1]
2256+
2257+ RFC 3463 Enhanced Mail System Status Codes January 2003
2258+
2259+
2260+ 1. Overview
2261+
2262+ There is a need for a standard mechanism for the reporting of mail
2263+ system errors richer than the limited set offered by SMTP and the
2264+ system specific text descriptions sent in mail messages. There is a
2265+ pressing need for a rich machine-readable, human language independent
2266+ status code for use in delivery status notifications [DSN]. This
2267+ document proposes a new set of status codes for this purpose.
2268+
2269+ SMTP [SMTP] error codes have historically been used for reporting
2270+ mail system errors. Because of limitations in the SMTP code design,
2271+ these are not suitable for use in delivery status notifications.
2272+ SMTP provides about 12 useful codes for delivery reports. The
2273+ majority of the codes are protocol specific response codes such as
2274+ the 354 response to the SMTP data command. Each of the 12 useful
2275+ codes are overloaded to indicate several error conditions. SMTP
2276+ suffers some scars from history, most notably the unfortunate damage
2277+ to the reply code extension mechanism by uncontrolled use. This
2278+ proposal facilitates future extensibility by requiring the client to
2279+ interpret unknown error codes according to the theory of codes while
2280+ requiring servers to register new response codes.
2281+
2282+ The SMTP theory of reply codes are partitioned in the number space in
2283+ such a manner that the remaining available codes will not provide the
2284+ space needed. The most critical example is the existence of only 5
2285+ remaining codes for mail system errors. The mail system
2286+ classification includes both host and mailbox error conditions. The
2287+ remaining third digit space would be completely consumed as needed to
2288+ indicate MIME and media conversion errors and security system errors.
2289+
2290+ A revision to the SMTP theory of reply codes to better distribute the
2291+ error conditions in the number space will necessarily be incompatible
2292+ with SMTP. Further, consumption of the remaining reply-code number
2293+ space for delivery notification reporting will reduce the available
2294+ codes for new ESMTP extensions.
2295+
2296+ The following status code set is based on the SMTP theory of reply
2297+ codes. It adopts the success, permanent error, and transient error
2298+ semantics of the first value, with a further description and
2299+ classification in the second. This proposal re-distributes the
2300+ classifications to better distribute the error conditions, such as
2301+ separating mailbox from host errors.
2302+
2303+ Document Conventions
2304+
2305+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
2306+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
2307+ document are to be interpreted as described in BCP 14 [RFC2119].
2308+
2309+
2310+
2311+ Vaudreuil Standards Track [Page 2]
2312+
2313+ RFC 3463 Enhanced Mail System Status Codes January 2003
2314+
2315+
2316+ 2. Status Code Structure
2317+
2318+ This document defines a new set of status codes to report mail system
2319+ conditions. These status codes are used for media and language
2320+ independent status reporting. They are not intended for system
2321+ specific diagnostics.
2322+
2323+ The syntax of the new status codes is defined as:
2324+
2325+ status-code = class "." subject "." detail
2326+
2327+ class = "2"/"4"/"5"
2328+
2329+ subject = 1*3digit
2330+
2331+ detail = 1*3digit
2332+
2333+ White-space characters and comments are NOT allowed within a status-
2334+ code. Each numeric sub-code within the status-code MUST be expressed
2335+ without leading zero digits.
2336+
2337+ Status codes consist of three numerical fields separated by ".". The
2338+ first sub-code indicates whether the delivery attempt was successful.
2339+ The second sub-code indicates the probable source of any delivery
2340+ anomalies, and the third sub-code indicates a precise error
2341+ condition.
2342+
2343+ Example: 2.1.23
2344+
2345+ The code space defined is intended to be extensible only by standards
2346+ track documents. Mail system specific status codes should be mapped
2347+ as close as possible to the standard status codes. Servers should
2348+ send only defined, registered status codes. System specific errors
2349+ and diagnostics should be carried by means other than status codes.
2350+
2351+ New subject and detail codes will be added over time. Because the
2352+ number space is large, it is not intended that published status codes
2353+ will ever be redefined or eliminated. Clients should preserve the
2354+ extensibility of the code space by reporting the general error
2355+ described in the subject sub-code when the specific detail is
2356+ unrecognized.
2357+
2358+
2359+
2360+
2361+
2362+
2363+
2364+
2365+
2366+
2367+ Vaudreuil Standards Track [Page 3]
2368+
2369+ RFC 3463 Enhanced Mail System Status Codes January 2003
2370+
2371+
2372+ The class sub-code provides a broad classification of the status.
2373+ The enumerated values for each class are defined as:
2374+
2375+ 2.XXX.XXX Success
2376+
2377+ Success specifies that the DSN is reporting a positive delivery
2378+ action. Detail sub-codes may provide notification of
2379+ transformations required for delivery.
2380+
2381+ 4.XXX.XXX Persistent Transient Failure
2382+
2383+ A persistent transient failure is one in which the message as
2384+ sent is valid, but persistence of some temporary condition has
2385+ caused abandonment or delay of attempts to send the message.
2386+ If this code accompanies a delivery failure report, sending in
2387+ the future may be successful.
2388+
2389+ 5.XXX.XXX Permanent Failure
2390+
2391+ A permanent failure is one which is not likely to be resolved
2392+ by resending the message in the current form. Some change to
2393+ the message or the destination must be made for successful
2394+ delivery.
2395+
2396+ A client must recognize and report class sub-code even where
2397+ subsequent subject sub-codes are unrecognized.
2398+
2399+ The subject sub-code classifies the status. This value applies to
2400+ each of the three classifications. The subject sub-code, if
2401+ recognized, must be reported even if the additional detail provided
2402+ by the detail sub-code is not recognized. The enumerated values for
2403+ the subject sub-code are:
2404+
2405+ X.0.XXX Other or Undefined Status
2406+
2407+ There is no additional subject information available.
2408+
2409+ X.1.XXX Addressing Status
2410+
2411+ The address status reports on the originator or destination
2412+ address. It may include address syntax or validity. These
2413+ errors can generally be corrected by the sender and retried.
2414+
2415+ X.2.XXX Mailbox Status
2416+
2417+ Mailbox status indicates that something having to do with the
2418+ mailbox has caused this DSN. Mailbox issues are assumed to be
2419+ under the general control of the recipient.
2420+
2421+
2422+
2423+ Vaudreuil Standards Track [Page 4]
2424+
2425+ RFC 3463 Enhanced Mail System Status Codes January 2003
2426+
2427+
2428+ X.3.XXX Mail System Status
2429+
2430+ Mail system status indicates that something having to do with
2431+ the destination system has caused this DSN. System issues are
2432+ assumed to be under the general control of the destination
2433+ system administrator.
2434+
2435+ X.4.XXX Network and Routing Status
2436+
2437+ The networking or routing codes report status about the
2438+ delivery system itself. These system components include any
2439+ necessary infrastructure such as directory and routing
2440+ services. Network issues are assumed to be under the control
2441+ of the destination or intermediate system administrator.
2442+
2443+ X.5.XXX Mail Delivery Protocol Status
2444+
2445+ The mail delivery protocol status codes report failures
2446+ involving the message delivery protocol. These failures
2447+ include the full range of problems resulting from
2448+ implementation errors or an unreliable connection.
2449+
2450+ X.6.XXX Message Content or Media Status
2451+
2452+ The message content or media status codes report failures
2453+ involving the content of the message. These codes report
2454+ failures due to translation, transcoding, or otherwise
2455+ unsupported message media. Message content or media issues are
2456+ under the control of both the sender and the receiver, both of
2457+ which must support a common set of supported content-types.
2458+
2459+ X.7.XXX Security or Policy Status
2460+
2461+ The security or policy status codes report failures involving
2462+ policies such as per-recipient or per-host filtering and
2463+ cryptographic operations. Security and policy status issues
2464+ are assumed to be under the control of either or both the
2465+ sender and recipient. Both the sender and recipient must
2466+ permit the exchange of messages and arrange the exchange of
2467+ necessary keys and certificates for cryptographic operations.
2468+
2469+ 3. Enumerated Status Codes
2470+
2471+ The following section defines and describes the detail sub-code. The
2472+ detail value provides more information about the status and is
2473+ defined relative to the subject of the status.
2474+
2475+
2476+
2477+
2478+
2479+ Vaudreuil Standards Track [Page 5]
2480+
2481+ RFC 3463 Enhanced Mail System Status Codes January 2003
2482+
2483+
2484+ 3.1 Other or Undefined Status
2485+
2486+ X.0.0 Other undefined Status
2487+
2488+ Other undefined status is the only undefined error code. It
2489+ should be used for all errors for which only the class of the
2490+ error is known.
2491+
2492+ 3.2 Address Status
2493+
2494+ X.1.0 Other address status
2495+
2496+ Something about the address specified in the message caused
2497+ this DSN.
2498+
2499+ X.1.1 Bad destination mailbox address
2500+
2501+ The mailbox specified in the address does not exist. For
2502+ Internet mail names, this means the address portion to the left
2503+ of the "@" sign is invalid. This code is only useful for
2504+ permanent failures.
2505+
2506+ X.1.2 Bad destination system address
2507+
2508+ The destination system specified in the address does not exist
2509+ or is incapable of accepting mail. For Internet mail names,
2510+ this means the address portion to the right of the "@" is
2511+ invalid for mail. This code is only useful for permanent
2512+ failures.
2513+
2514+ X.1.3 Bad destination mailbox address syntax
2515+
2516+ The destination address was syntactically invalid. This can
2517+ apply to any field in the address. This code is only useful
2518+ for permanent failures.
2519+
2520+ X.1.4 Destination mailbox address ambiguous
2521+
2522+ The mailbox address as specified matches one or more recipients
2523+ on the destination system. This may result if a heuristic
2524+ address mapping algorithm is used to map the specified address
2525+ to a local mailbox name.
2526+
2527+ X.1.5 Destination address valid
2528+
2529+ This mailbox address as specified was valid. This status code
2530+ should be used for positive delivery reports.
2531+
2532+
2533+
2534+
2535+ Vaudreuil Standards Track [Page 6]
2536+
2537+ RFC 3463 Enhanced Mail System Status Codes January 2003
2538+
2539+
2540+ X.1.6 Destination mailbox has moved, No forwarding address
2541+
2542+ The mailbox address provided was at one time valid, but mail is
2543+ no longer being accepted for that address. This code is only
2544+ useful for permanent failures.
2545+
2546+ X.1.7 Bad sender's mailbox address syntax
2547+
2548+ The sender's address was syntactically invalid. This can apply
2549+ to any field in the address.
2550+
2551+ X.1.8 Bad sender's system address
2552+
2553+ The sender's system specified in the address does not exist or
2554+ is incapable of accepting return mail. For domain names, this
2555+ means the address portion to the right of the "@" is invalid
2556+ for mail.
2557+
2558+ 3.3 Mailbox Status
2559+
2560+ X.2.0 Other or undefined mailbox status
2561+
2562+ The mailbox exists, but something about the destination mailbox
2563+ has caused the sending of this DSN.
2564+
2565+ X.2.1 Mailbox disabled, not accepting messages
2566+
2567+ The mailbox exists, but is not accepting messages. This may be
2568+ a permanent error if the mailbox will never be re-enabled or a
2569+ transient error if the mailbox is only temporarily disabled.
2570+
2571+ X.2.2 Mailbox full
2572+
2573+ The mailbox is full because the user has exceeded a per-mailbox
2574+ administrative quota or physical capacity. The general
2575+ semantics implies that the recipient can delete messages to
2576+ make more space available. This code should be used as a
2577+ persistent transient failure.
2578+
2579+ X.2.3 Message length exceeds administrative limit
2580+
2581+ A per-mailbox administrative message length limit has been
2582+ exceeded. This status code should be used when the per-mailbox
2583+ message length limit is less than the general system limit.
2584+ This code should be used as a permanent failure.
2585+
2586+
2587+
2588+
2589+
2590+
2591+ Vaudreuil Standards Track [Page 7]
2592+
2593+ RFC 3463 Enhanced Mail System Status Codes January 2003
2594+
2595+
2596+ X.2.4 Mailing list expansion problem
2597+
2598+ The mailbox is a mailing list address and the mailing list was
2599+ unable to be expanded. This code may represent a permanent
2600+ failure or a persistent transient failure.
2601+
2602+ 3.4 Mail system status
2603+
2604+ X.3.0 Other or undefined mail system status
2605+
2606+ The destination system exists and normally accepts mail, but
2607+ something about the system has caused the generation of this
2608+ DSN.
2609+
2610+ X.3.1 Mail system full
2611+
2612+ Mail system storage has been exceeded. The general semantics
2613+ imply that the individual recipient may not be able to delete
2614+ material to make room for additional messages. This is useful
2615+ only as a persistent transient error.
2616+
2617+ X.3.2 System not accepting network messages
2618+
2619+ The host on which the mailbox is resident is not accepting
2620+ messages. Examples of such conditions include an immanent
2621+ shutdown, excessive load, or system maintenance. This is
2622+ useful for both permanent and persistent transient errors.
2623+
2624+ X.3.3 System not capable of selected features
2625+
2626+ Selected features specified for the message are not supported
2627+ by the destination system. This can occur in gateways when
2628+ features from one domain cannot be mapped onto the supported
2629+ feature in another.
2630+
2631+ X.3.4 Message too big for system
2632+
2633+ The message is larger than per-message size limit. This limit
2634+ may either be for physical or administrative reasons. This is
2635+ useful only as a permanent error.
2636+
2637+ X.3.5 System incorrectly configured
2638+
2639+ The system is not configured in a manner that will permit it to
2640+ accept this message.
2641+
2642+
2643+
2644+
2645+
2646+
2647+ Vaudreuil Standards Track [Page 8]
2648+
2649+ RFC 3463 Enhanced Mail System Status Codes January 2003
2650+
2651+
2652+ 3.5 Network and Routing Status
2653+
2654+ X.4.0 Other or undefined network or routing status
2655+
2656+ Something went wrong with the networking, but it is not clear
2657+ what the problem is, or the problem cannot be well expressed
2658+ with any of the other provided detail codes.
2659+
2660+ X.4.1 No answer from host
2661+
2662+ The outbound connection attempt was not answered, because
2663+ either the remote system was busy, or was unable to take a
2664+ call. This is useful only as a persistent transient error.
2665+
2666+ X.4.2 Bad connection
2667+
2668+ The outbound connection was established, but was unable to
2669+ complete the message transaction, either because of time-out,
2670+ or inadequate connection quality. This is useful only as a
2671+ persistent transient error.
2672+
2673+ X.4.3 Directory server failure
2674+
2675+ The network system was unable to forward the message, because a
2676+ directory server was unavailable. This is useful only as a
2677+ persistent transient error.
2678+
2679+ The inability to connect to an Internet DNS server is one
2680+ example of the directory server failure error.
2681+
2682+ X.4.4 Unable to route
2683+
2684+ The mail system was unable to determine the next hop for the
2685+ message because the necessary routing information was
2686+ unavailable from the directory server. This is useful for both
2687+ permanent and persistent transient errors.
2688+
2689+ A DNS lookup returning only an SOA (Start of Administration)
2690+ record for a domain name is one example of the unable to route
2691+ error.
2692+
2693+ X.4.5 Mail system congestion
2694+
2695+ The mail system was unable to deliver the message because the
2696+ mail system was congested. This is useful only as a persistent
2697+ transient error.
2698+
2699+
2700+
2701+
2702+
2703+ Vaudreuil Standards Track [Page 9]
2704+
2705+ RFC 3463 Enhanced Mail System Status Codes January 2003
2706+
2707+
2708+ X.4.6 Routing loop detected
2709+
2710+ A routing loop caused the message to be forwarded too many
2711+ times, either because of incorrect routing tables or a user-
2712+ forwarding loop. This is useful only as a persistent transient
2713+ error.
2714+
2715+ X.4.7 Delivery time expired
2716+
2717+ The message was considered too old by the rejecting system,
2718+ either because it remained on that host too long or because the
2719+ time-to-live value specified by the sender of the message was
2720+ exceeded. If possible, the code for the actual problem found
2721+ when delivery was attempted should be returned rather than this
2722+ code.
2723+
2724+ 3.6 Mail Delivery Protocol Status
2725+
2726+ X.5.0 Other or undefined protocol status
2727+
2728+ Something was wrong with the protocol necessary to deliver the
2729+ message to the next hop and the problem cannot be well
2730+ expressed with any of the other provided detail codes.
2731+
2732+ X.5.1 Invalid command
2733+
2734+ A mail transaction protocol command was issued which was either
2735+ out of sequence or unsupported. This is useful only as a
2736+ permanent error.
2737+
2738+ X.5.2 Syntax error
2739+
2740+ A mail transaction protocol command was issued which could not
2741+ be interpreted, either because the syntax was wrong or the
2742+ command is unrecognized. This is useful only as a permanent
2743+ error.
2744+
2745+ X.5.3 Too many recipients
2746+
2747+ More recipients were specified for the message than could have
2748+ been delivered by the protocol. This error should normally
2749+ result in the segmentation of the message into two, the
2750+ remainder of the recipients to be delivered on a subsequent
2751+ delivery attempt. It is included in this list in the event
2752+ that such segmentation is not possible.
2753+
2754+
2755+
2756+
2757+
2758+
2759+ Vaudreuil Standards Track [Page 10]
2760+
2761+ RFC 3463 Enhanced Mail System Status Codes January 2003
2762+
2763+
2764+ X.5.4 Invalid command arguments
2765+
2766+ A valid mail transaction protocol command was issued with
2767+ invalid arguments, either because the arguments were out of
2768+ range or represented unrecognized features. This is useful
2769+ only as a permanent error.
2770+
2771+ X.5.5 Wrong protocol version
2772+
2773+ A protocol version mis-match existed which could not be
2774+ automatically resolved by the communicating parties.
2775+
2776+ 3.7 Message Content or Message Media Status
2777+
2778+ X.6.0 Other or undefined media error
2779+
2780+ Something about the content of a message caused it to be
2781+ considered undeliverable and the problem cannot be well
2782+ expressed with any of the other provided detail codes.
2783+
2784+ X.6.1 Media not supported
2785+
2786+ The media of the message is not supported by either the
2787+ delivery protocol or the next system in the forwarding path.
2788+ This is useful only as a permanent error.
2789+
2790+ X.6.2 Conversion required and prohibited
2791+
2792+ The content of the message must be converted before it can be
2793+ delivered and such conversion is not permitted. Such
2794+ prohibitions may be the expression of the sender in the message
2795+ itself or the policy of the sending host.
2796+
2797+ X.6.3 Conversion required but not supported
2798+
2799+ The message content must be converted in order to be forwarded
2800+ but such conversion is not possible or is not practical by a
2801+ host in the forwarding path. This condition may result when an
2802+ ESMTP gateway supports 8bit transport but is not able to
2803+ downgrade the message to 7 bit as required for the next hop.
2804+
2805+ X.6.4 Conversion with loss performed
2806+
2807+ This is a warning sent to the sender when message delivery was
2808+ successfully but when the delivery required a conversion in
2809+ which some data was lost. This may also be a permanent error
2810+ if the sender has indicated that conversion with loss is
2811+ prohibited for the message.
2812+
2813+
2814+
2815+ Vaudreuil Standards Track [Page 11]
2816+
2817+ RFC 3463 Enhanced Mail System Status Codes January 2003
2818+
2819+
2820+ X.6.5 Conversion Failed
2821+
2822+ A conversion was required but was unsuccessful. This may be
2823+ useful as a permanent or persistent temporary notification.
2824+
2825+ 3.8 Security or Policy Status
2826+
2827+ X.7.0 Other or undefined security status
2828+
2829+ Something related to security caused the message to be
2830+ returned, and the problem cannot be well expressed with any of
2831+ the other provided detail codes. This status code may also be
2832+ used when the condition cannot be further described because of
2833+ security policies in force.
2834+
2835+ X.7.1 Delivery not authorized, message refused
2836+
2837+ The sender is not authorized to send to the destination. This
2838+ can be the result of per-host or per-recipient filtering. This
2839+ memo does not discuss the merits of any such filtering, but
2840+ provides a mechanism to report such. This is useful only as a
2841+ permanent error.
2842+
2843+ X.7.2 Mailing list expansion prohibited
2844+
2845+ The sender is not authorized to send a message to the intended
2846+ mailing list. This is useful only as a permanent error.
2847+
2848+ X.7.3 Security conversion required but not possible
2849+
2850+ A conversion from one secure messaging protocol to another was
2851+ required for delivery and such conversion was not possible.
2852+ This is useful only as a permanent error.
2853+
2854+ X.7.4 Security features not supported
2855+
2856+ A message contained security features such as secure
2857+ authentication that could not be supported on the delivery
2858+ protocol. This is useful only as a permanent error.
2859+
2860+ X.7.5 Cryptographic failure
2861+
2862+ A transport system otherwise authorized to validate or decrypt
2863+ a message in transport was unable to do so because necessary
2864+ information such as key was not available or such information
2865+ was invalid.
2866+
2867+
2868+
2869+
2870+
2871+ Vaudreuil Standards Track [Page 12]
2872+
2873+ RFC 3463 Enhanced Mail System Status Codes January 2003
2874+
2875+
2876+ X.7.6 Cryptographic algorithm not supported
2877+
2878+ A transport system otherwise authorized to validate or decrypt
2879+ a message was unable to do so because the necessary algorithm
2880+ was not supported.
2881+
2882+ X.7.7 Message integrity failure
2883+
2884+ A transport system otherwise authorized to validate a message
2885+ was unable to do so because the message was corrupted or
2886+ altered. This may be useful as a permanent, transient
2887+ persistent, or successful delivery code.
2888+
2889+ 4. Normative References
2890+
2891+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2892+ Requirement Levels", BCP 14, RFC 2119, March 1997.
2893+
2894+ [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
2895+ 821, August 1982.
2896+
2897+ [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
2898+ for Delivery Status Notifications", RFC 3464, January 2003.
2899+
2900+ 5. Security Considerations
2901+
2902+ This document describes a status code system with increased
2903+ precision. Use of these status codes may disclose additional
2904+ information about how an internal mail system is implemented beyond
2905+ that currently available.
2906+
2907+
2908+
2909+
2910+
2911+
2912+
2913+
2914+
2915+
2916+
2917+
2918+
2919+
2920+
2921+
2922+
2923+
2924+
2925+
2926+
2927+ Vaudreuil Standards Track [Page 13]
2928+
2929+ RFC 3463 Enhanced Mail System Status Codes January 2003
2930+
2931+
2932+ Appendix A - Collected Status Codes
2933+
2934+ X.1.0 Other address status
2935+ X.1.1 Bad destination mailbox address
2936+ X.1.2 Bad destination system address
2937+ X.1.3 Bad destination mailbox address syntax
2938+ X.1.4 Destination mailbox address ambiguous
2939+ X.1.5 Destination mailbox address valid
2940+ X.1.6 Mailbox has moved
2941+ X.1.7 Bad sender's mailbox address syntax
2942+ X.1.8 Bad sender's system address
2943+
2944+ X.2.0 Other or undefined mailbox status
2945+ X.2.1 Mailbox disabled, not accepting messages
2946+ X.2.2 Mailbox full
2947+ X.2.3 Message length exceeds administrative limit.
2948+ X.2.4 Mailing list expansion problem
2949+
2950+ X.3.0 Other or undefined mail system status
2951+ X.3.1 Mail system full
2952+ X.3.2 System not accepting network messages
2953+ X.3.3 System not capable of selected features
2954+ X.3.4 Message too big for system
2955+
2956+ X.4.0 Other or undefined network or routing status
2957+ X.4.1 No answer from host
2958+ X.4.2 Bad connection
2959+ X.4.3 Routing server failure
2960+ X.4.4 Unable to route
2961+ X.4.5 Network congestion
2962+ X.4.6 Routing loop detected
2963+ X.4.7 Delivery time expired
2964+
2965+ X.5.0 Other or undefined protocol status
2966+ X.5.1 Invalid command
2967+ X.5.2 Syntax error
2968+ X.5.3 Too many recipients
2969+ X.5.4 Invalid command arguments
2970+ X.5.5 Wrong protocol version
2971+
2972+ X.6.0 Other or undefined media error
2973+ X.6.1 Media not supported
2974+ X.6.2 Conversion required and prohibited
2975+ X.6.3 Conversion required but not supported
2976+ X.6.4 Conversion with loss performed
2977+ X.6.5 Conversion failed
2978+
2979+
2980+
2981+
2982+
2983+ Vaudreuil Standards Track [Page 14]
2984+
2985+ RFC 3463 Enhanced Mail System Status Codes January 2003
2986+
2987+
2988+ X.7.0 Other or undefined security status
2989+ X.7.1 Delivery not authorized, message refused
2990+ X.7.2 Mailing list expansion prohibited
2991+ X.7.3 Security conversion required but not possible
2992+ X.7.4 Security features not supported
2993+ X.7.5 Cryptographic failure
2994+ X.7.6 Cryptographic algorithm not supported
2995+ X.7.7 Message integrity failure
2996+
2997+ Appendix B - Changes from RFC1893
2998+
2999+ Changed Authors contact information.
3000+
3001+ Updated required standards boilerplate.
3002+
3003+ Edited the text to make it spell-checker and grammar checker
3004+ compliant.
3005+
3006+ Modified the text describing the persistent transient failure to more
3007+ closely reflect current practice and understanding.
3008+
3009+ Eliminated the restriction on the X.4.7 codes limiting them to
3010+ persistent transient errors.
3011+
3012+ Author's Address
3013+
3014+ Gregory M. Vaudreuil
3015+ Lucent Technologies
3016+ 7291 Williamson Rd
3017+ Dallas, Tx. 75214
3018+
3019+ Phone: +1 214 823 9325
3020+ EMail: GregV@ieee.org
3021+
3022+
3023+
3024+
3025+
3026+
3027+
3028+
3029+
3030+
3031+
3032+
3033+
3034+
3035+
3036+
3037+
3038+
3039+ Vaudreuil Standards Track [Page 15]
3040+
3041+ RFC 3463 Enhanced Mail System Status Codes January 2003
3042+
3043+
3044+ Full Copyright Statement
3045+
3046+ Copyright (C) The Internet Society (2003). All Rights Reserved.
3047+
3048+ This document and translations of it may be copied and furnished to
3049+ others, and derivative works that comment on or otherwise explain it
3050+ or assist in its implementation may be prepared, copied, published
3051+ and distributed, in whole or in part, without restriction of any
3052+ kind, provided that the above copyright notice and this paragraph are
3053+ included on all such copies and derivative works. However, this
3054+ document itself may not be modified in any way, such as by removing
3055+ the copyright notice or references to the Internet Society or other
3056+ Internet organizations, except as needed for the purpose of
3057+ developing Internet standards in which case the procedures for
3058+ copyrights defined in the Internet Standards process must be
3059+ followed, or as required to translate it into languages other than
3060+ English.
3061+
3062+ The limited permissions granted above are perpetual and will not be
3063+ revoked by the Internet Society or its successors or assigns.
3064+
3065+ This document and the information contained herein is provided on an
3066+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
3067+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
3068+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
3069+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
3070+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3071+
3072+ Acknowledgement
3073+
3074+ Funding for the RFC Editor function is currently provided by the
3075+ Internet Society.
3076+
3077+
3078+
3079+
3080+
3081+
3082+
3083+
3084+
3085+
3086+
3087+
3088+
3089+
3090+
3091+
3092+
3093+
3094+
3095+ Vaudreuil Standards Track [Page 16]
3096+
3097 diff --git a/rfcs/rfc6531.txt b/rfcs/rfc6531.txt
3098new file mode 100644
3099index 0000000..ff3f324
3100--- /dev/null
3101+++ b/rfcs/rfc6531.txt
3102 @@ -0,0 +1,1011 @@
3103+
3104+
3105+
3106+
3107+
3108+
3109+ Internet Engineering Task Force (IETF) J. Yao
3110+ Request for Comments: 6531 W. Mao
3111+ Obsoletes: 5336 CNNIC
3112+ Category: Standards Track February 2012
3113+ ISSN: 2070-1721
3114+
3115+
3116+ SMTP Extension for Internationalized Email
3117+
3118+ Abstract
3119+
3120+ This document specifies an SMTP extension for transport and delivery
3121+ of email messages with internationalized email addresses or header
3122+ information.
3123+
3124+ Status of This Memo
3125+
3126+ This is an Internet Standards Track document.
3127+
3128+ This document is a product of the Internet Engineering Task Force
3129+ (IETF). It represents the consensus of the IETF community. It has
3130+ received public review and has been approved for publication by the
3131+ Internet Engineering Steering Group (IESG). Further information on
3132+ Internet Standards is available in Section 2 of RFC 5741.
3133+
3134+ Information about the current status of this document, any errata,
3135+ and how to provide feedback on it may be obtained at
3136+ http://www.rfc-editor.org/info/rfc6531.
3137+
3138+ Copyright Notice
3139+
3140+ Copyright (c) 2012 IETF Trust and the persons identified as the
3141+ document authors. All rights reserved.
3142+
3143+ This document is subject to BCP 78 and the IETF Trust's Legal
3144+ Provisions Relating to IETF Documents
3145+ (http://trustee.ietf.org/license-info) in effect on the date of
3146+ publication of this document. Please review these documents
3147+ carefully, as they describe your rights and restrictions with respect
3148+ to this document. Code Components extracted from this document must
3149+ include Simplified BSD License text as described in Section 4.e of
3150+ the Trust Legal Provisions and are provided without warranty as
3151+ described in the Simplified BSD License.
3152+
3153+ This document may contain material from IETF Documents or IETF
3154+ Contributions published or made publicly available before November
3155+ 10, 2008. The person(s) controlling the copyright in some of this
3156+ material may not have granted the IETF Trust the right to allow
3157+
3158+
3159+
3160+ Yao & Mao Standards Track [Page 1]
3161+
3162+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3163+
3164+
3165+ modifications of such material outside the IETF Standards Process.
3166+ Without obtaining an adequate license from the person(s) controlling
3167+ the copyright in such materials, this document may not be modified
3168+ outside the IETF Standards Process, and derivative works of it may
3169+ not be created outside the IETF Standards Process, except to format
3170+ it for publication as an RFC or to translate it into languages other
3171+ than English.
3172+
3173+ Table of Contents
3174+
3175+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3176+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3177+ 1.2. Changes Made to Other Specifications . . . . . . . . . . . 3
3178+ 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3179+ 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
3180+ 3.1. Framework for the Internationalization Extension . . . . . 4
3181+ 3.2. The SMTPUTF8 Extension . . . . . . . . . . . . . . . . . . 5
3182+ 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3183+ 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 8
3184+ 3.5. Non-ASCII Addresses and Reply-Codes . . . . . . . . . . . 9
3185+ 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9
3186+ 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10
3187+ 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10
3188+ 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10
3189+ 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
3190+ 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
3191+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
3192+ 4.1. SMTP Service Extensions Registry . . . . . . . . . . . . . 13
3193+ 4.2. SMTP Enhanced Status Code Registry . . . . . . . . . . . . 13
3194+ 4.3. WITH Protocol Types Sub-Registry of the Mail
3195+ Transmission Types Registry . . . . . . . . . . . . . . . 15
3196+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
3197+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
3198+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3199+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
3200+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
3201+
3202+
3203+
3204+
3205+
3206+
3207+
3208+
3209+
3210+
3211+
3212+
3213+
3214+
3215+
3216+ Yao & Mao Standards Track [Page 2]
3217+
3218+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3219+
3220+
3221+ 1. Introduction
3222+
3223+ The document defines a Simple Mail Transfer Protocol [RFC5321]
3224+ extension so servers can advertise the ability to accept and process
3225+ internationalized email addresses (see Section 1.1) and
3226+ internationalized email headers [RFC6532].
3227+
3228+ An extended overview of the extension model for internationalized
3229+ email addresses and the email header appears in RFC 6530 [RFC6530],
3230+ referred to as "the framework document" in this specification. A
3231+ thorough understanding of the information in that document and in the
3232+ base Internet email specifications [RFC5321] [RFC5322] is necessary
3233+ to understand and implement this specification.
3234+
3235+ 1.1. Terminology
3236+
3237+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
3238+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
3239+ document are to be interpreted as described in RFC 2119 [RFC2119].
3240+
3241+ The terms "UTF-8 string" or "UTF-8 character" are used to refer to
3242+ Unicode characters, which may or may not be members of the ASCII
3243+ subset, in UTF-8 [RFC3629], a standard Unicode Encoding Form. All
3244+ other specialized terms used in this specification are defined in the
3245+ framework document or in the base Internet email specifications. In
3246+ particular, the terms "ASCII address", "internationalized email
3247+ address", "non-ASCII address", "SMTPUTF8", "internationalized
3248+ message", and "message" are used in this document according to the
3249+ definitions in the framework document [RFC6530].
3250+
3251+ Strings referred to in this document, including ASCII strings, MUST
3252+ be expressed in UTF-8.
3253+
3254+ This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some
3255+ basic rules in this document are identified in Section 3.3 as being
3256+ defined (under the same names) in RFC 5234 [RFC5234], RFC 5321
3257+ [RFC5321], RFC 5890 [RFC5890], or RFC 6532 [RFC6532].
3258+
3259+ 1.2. Changes Made to Other Specifications
3260+
3261+ This specification extends some syntax rules defined in RFC 5321 and
3262+ permits internationalized email addresses in the envelope and in
3263+ trace fields, but it does not modify RFC 5321. It permits data
3264+ formats defined in RFC 6532 [RFC6532], but it does not modify RFC
3265+ 5322. It does require that the 8BITMIME extension [RFC6152] be
3266+ announced by the SMTPUTF8-aware SMTP server and used with
3267+ "BODY=8BITMIME" by the SMTPUTF8-aware SMTP client, but it does not
3268+ modify the 8BITMIME specification in any way.
3269+
3270+
3271+
3272+ Yao & Mao Standards Track [Page 3]
3273+
3274+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3275+
3276+
3277+ This specification replaces an earlier, experimental, approach to the
3278+ same problem [RFC5336]. Section 6 of RFC 6530 [RFC6530] describes
3279+ the changes in approach between RFC 5336 [RFC5336] and this
3280+ specification. Anyone trying to convert an implementation from the
3281+ experimental specification to the specification in this document will
3282+ need to review those changes carefully.
3283+
3284+ 2. Overview of Operation
3285+
3286+ This document specifies an element of the email internationalization
3287+ work, specifically the definition of an SMTP extension for
3288+ internationalized email. The extension is identified with the token
3289+ "SMTPUTF8".
3290+
3291+ The internationalized email headers specification [RFC6532] provides
3292+ the details of email header features enabled by this extension.
3293+
3294+ 3. Mail Transport-Level Protocol
3295+
3296+ 3.1. Framework for the Internationalization Extension
3297+
3298+ The following service extension is defined:
3299+
3300+ 1. The name of the SMTP service extension is "Internationalized
3301+ Email".
3302+
3303+ 2. The EHLO keyword value associated with this extension is
3304+ "SMTPUTF8".
3305+
3306+ 3. No parameter values are defined for this EHLO keyword value. In
3307+ order to permit future (although unanticipated) extensions, the
3308+ EHLO response MUST NOT contain any parameters for this keyword.
3309+ The SMTPUTF8-aware SMTP client MUST ignore any parameters if
3310+ they appear for this keyword; that is, the SMTPUTF8-aware SMTP
3311+ client MUST behave as if the parameters do not appear. If an
3312+ SMTP server includes SMTPUTF8 in its EHLO response, it MUST be
3313+ fully compliant with this version of this specification.
3314+
3315+ 4. One OPTIONAL parameter, SMTPUTF8, is added to the MAIL command.
3316+ The parameter does not accept a value. If this parameter is set
3317+ in the MAIL command, it indicates that the SMTP client is
3318+ SMTPUTF8-aware. Its presence also asserts that the envelope
3319+ includes the non-ASCII address, the message being sent is an
3320+ internationalized message, or the message being sent needs the
3321+ SMTPUTF8 support.
3322+
3323+
3324+
3325+
3326+
3327+
3328+ Yao & Mao Standards Track [Page 4]
3329+
3330+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3331+
3332+
3333+ 5. The maximum length of a MAIL command line is increased by 10
3334+ characters to accommodate the possible addition of the SMTPUTF8
3335+ parameter.
3336+
3337+ 6. One OPTIONAL parameter, SMTPUTF8, is added to the VERIFY (VRFY)
3338+ and EXPAND (EXPN) commands. The SMTPUTF8 parameter does not
3339+ accept a value. The parameter indicates that the SMTP client
3340+ can accept Unicode characters in UTF-8 encoding in replies from
3341+ the VRFY and EXPN commands.
3342+
3343+ 7. No additional SMTP verbs are defined by this extension.
3344+
3345+ 8. Servers offering this extension MUST provide support for, and
3346+ announce, the 8BITMIME extension [RFC6152].
3347+
3348+ 9. The reverse-path and forward-path of the SMTP MAIL and RCPT
3349+ commands are extended to allow Unicode characters encoded in
3350+ UTF-8 in mailbox names (addresses).
3351+
3352+ 10. The mail message body is extended as specified in RFC 6532
3353+ [RFC6532].
3354+
3355+ 11. The SMTPUTF8 extension is valid on the submission port
3356+ [RFC6409]. It may also be used with the Local Mail Transfer
3357+ Protocol (LMTP) [RFC2033]. When these protocols are used, their
3358+ use should be reflected in the trace field WITH keywords as
3359+ appropriate [RFC3848].
3360+
3361+ 3.2. The SMTPUTF8 Extension
3362+
3363+ An SMTP server that announces the SMTPUTF8 extension MUST be prepared
3364+ to accept a UTF-8 string [RFC3629] in any position in which RFC 5321
3365+ specifies that a <mailbox> can appear. Although the characters in
3366+ the <local-part> are permitted to contain non-ASCII characters, the
3367+ actual parsing of the <local-part> and the delimiters used are
3368+ unchanged from the base email specification [RFC5321]. Any domain
3369+ name to be looked up in the DNS MUST conform to and be processed as
3370+ specified for Internationalizing Domain Names in Applications (IDNA)
3371+ [RFC5890]. When doing lookups, the SMTPUTF8-aware SMTP client or
3372+ server MUST either use a Unicode-aware DNS library, or transform the
3373+ internationalized domain name to A-label form (i.e., a fully-
3374+ qualified domain name that contains one or more A-labels but no
3375+ U-labels) as specified in RFC 5890 [RFC5890].
3376+
3377+ An SMTP client that receives the SMTPUTF8 extension keyword in
3378+ response to the EHLO command MAY transmit mailbox names within SMTP
3379+ commands as internationalized strings in UTF-8 form. It MAY send a
3380+ UTF-8 header [RFC6532] (which may also include mailbox names in
3381+
3382+
3383+
3384+ Yao & Mao Standards Track [Page 5]
3385+
3386+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3387+
3388+
3389+ UTF-8). It MAY transmit the domain parts of mailbox names within
3390+ SMTP commands or the message header as A-labels or U-labels
3391+ [RFC5890]. The presence of the SMTPUTF8 extension does not change
3392+ the server-relaying behaviors described in RFC 5321.
3393+
3394+ If the SMTPUTF8 SMTP extension is not offered by the SMTP server, the
3395+ SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized
3396+ email address and MUST NOT transmit a mail message containing
3397+ internationalized mail headers as described in RFC 6532 [RFC6532] at
3398+ any level within its MIME structure [RFC2045]. (For this paragraph,
3399+ the internationalized domain name in A-label form as specified in
3400+ IDNA definitions [RFC5890] is not considered to be
3401+ "internationalized".) Instead, if an SMTPUTF8-aware SMTP client
3402+ (sender) attempts to transfer an internationalized message and
3403+ encounters an SMTP server that does not support the extension, the
3404+ best action for it to take depends on other conditions. In
3405+ particular:
3406+
3407+ o If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it
3408+ MAY choose its own way to deal with this scenario using the wide
3409+ discretion for changing addresses or otherwise fixing up and
3410+ transforming messages allowed by RFC 6409. As long as the
3411+ resulting message conforms to the requirements of RFC 5321 (i.e.,
3412+ without the SMTPUTF8 extension), the details of that
3413+ transformation are outside the scope of this document.
3414+
3415+ o If it is not an MSA or is an MSA and does not choose to transform
3416+ the message to one that does not require the SMTPUTF8 extension,
3417+ it SHOULD reject the message. As usual, this can be done either
3418+ by generating an appropriate reply during the SMTP transaction or
3419+ by accepting the message and then generating and transmitting a
3420+ non-delivery notification. If the latter choice is made, the
3421+ notification process MUST conform to the requirements of RFC 5321,
3422+ RFC 3464 [RFC3464], and RFC 6533 [RFC6533].
3423+
3424+ o As specified in Section 2.2.3 of RFC 5321, an SMTP client with
3425+ additional information and/or knowledge of special circumstances
3426+ MAY choose to requeue the message and try later and/or try an
3427+ alternate MX host as specified in that section.
3428+
3429+ This document applies when an SMTPUTF8-aware SMTP client or server
3430+ supports the SMTPUTF8 extension. For all other cases, and for
3431+ addresses and messages that do not require an SMTPUTF8 extension,
3432+ SMTPUTF8-aware SMTP clients and servers do not change the behavior
3433+ specified in RFC 5321 [RFC5321].
3434+
3435+
3436+
3437+
3438+
3439+
3440+ Yao & Mao Standards Track [Page 6]
3441+
3442+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3443+
3444+
3445+ If an SMTPUTF8-aware SMTP server advertises the Delivery Status
3446+ Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533
3447+ [RFC6533].
3448+
3449+ 3.3. Extended Mailbox Address Syntax
3450+
3451+ RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely
3452+ in terms of ASCII characters. This document extends <Mailbox> to add
3453+ support of non-ASCII characters.
3454+
3455+ The key changes made by this specification include:
3456+
3457+ o The <Mailbox> ABNF rule is imported from RFC 5321 and updated in
3458+ order to support the internationalized email address. Other
3459+ related rules are imported from RFC 5321, RFC 5234, RFC 5890, and
3460+ RFC 6532, or are extended in this document.
3461+
3462+ o The definition of <sub-domain> is extended to permit both the RFC
3463+ 5321 definition and a UTF-8 string in a DNS label that conforms
3464+ with IDNA definitions [RFC5890].
3465+
3466+ o The definition of <atext> is extended to permit both the RFC 5321
3467+ definition and a UTF-8 string. That string MUST NOT contain any
3468+ of the ASCII graphics or control characters.
3469+
3470+ The following ABNF rules imported from RFC 5321, Section 4.1.2, are
3471+ updated directly or indirectly by this document:
3472+
3473+ o <Mailbox>
3474+
3475+ o <Local-part>
3476+
3477+ o <Dot-string>
3478+
3479+ o <Quoted-string>
3480+
3481+ o <QcontentSMTP>
3482+
3483+ o <Domain>
3484+
3485+ o <Atom>
3486+
3487+ The following ABNF rule will be imported from RFC 6532, Section 3.1,
3488+ directly:
3489+
3490+ o <UTF8-non-ascii>
3491+
3492+
3493+
3494+
3495+
3496+ Yao & Mao Standards Track [Page 7]
3497+
3498+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3499+
3500+
3501+ The following ABNF rule will be imported from RFC 5234, Appendix B.1,
3502+ directly:
3503+
3504+ o <DQUOTE>
3505+
3506+ The following ABNF rule will be imported from RFC 5890, Section
3507+ 2.3.2.1, directly:
3508+
3509+ o <U-label>
3510+
3511+ The following rules are extended in ABNF [RFC5234] as follows.
3512+
3513+ sub-domain =/ U-label
3514+ ; extend the definition of sub-domain in RFC 5321, Section 4.1.2
3515+
3516+ atext =/ UTF8-non-ascii
3517+ ; extend the implicit definition of atext in
3518+ ; RFC 5321, Section 4.1.2, which ultimately points to
3519+ ; the actual definition in RFC 5322, Section 3.2.3
3520+
3521+ qtextSMTP =/ UTF8-non-ascii
3522+ ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2
3523+
3524+ esmtp-value =/ UTF8-non-ascii
3525+ ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2
3526+
3527+ 3.4. MAIL Command Parameter Usage
3528+
3529+ If the envelope or message being sent requires the capabilities of
3530+ the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply
3531+ the SMTPUTF8 parameter with the MAIL command. If this parameter is
3532+ provided, it MUST not accept a value. If the SMTPUTF8-aware SMTP
3533+ client is aware that neither the envelope nor the message being sent
3534+ requires any of the SMTPUTF8 extension capabilities, it SHOULD NOT
3535+ supply the SMTPUTF8 parameter with the MAIL command.
3536+
3537+ Because there is no guarantee that a next-hop SMTP server will
3538+ support the SMTPUTF8 extension, use of the SMTPUTF8 extension always
3539+ carries a risk of transmission failure. In fact, during the early
3540+ stages of deployment for the SMTPUTF8 extension, the risk will be
3541+ quite high. Hence, there is a distinct near-term advantage for
3542+ ASCII-only messages to be sent without using this extension. The
3543+ long-term advantage of casting ASCII [ASCII] characters (0x7f and
3544+ below) as UTF-8 form is that it permits pure-Unicode environments.
3545+
3546+
3547+
3548+
3549+
3550+
3551+
3552+ Yao & Mao Standards Track [Page 8]
3553+
3554+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3555+
3556+
3557+ 3.5. Non-ASCII Addresses and Reply-Codes
3558+
3559+ An SMTPUTF8-aware SMTP client MUST NOT send an internationalized
3560+ message to an SMTP server that does not support SMTPUTF8. If the
3561+ SMTP server does not support this option, then the SMTPUTF8-aware
3562+ SMTP client has three choices according to Section 3.2 of this
3563+ specification.
3564+
3565+ The three-digit reply-codes used in this section are based on their
3566+ meanings as defined in RFC 5321.
3567+
3568+ When messages are rejected because the RCPT command requires an ASCII
3569+ address, the reply-code 553 is returned with the meaning "mailbox
3570+ name not allowed". When messages are rejected because the MAIL
3571+ command requires an ASCII address, the reply-code 550 is returned
3572+ with the meaning "mailbox unavailable". When the SMTPUTF8-aware SMTP
3573+ server supports enhanced mail system status codes [RFC3463], reply-
3574+ code "X.6.7" [RFC5248] (see Section 4) is used, meaning "Non-ASCII
3575+ addresses not permitted for that sender/recipient".
3576+
3577+ When messages are rejected for other reasons, the server follows the
3578+ model of the base email specification in RFC 5321; this extension
3579+ does not change those circumstances or reply messages.
3580+
3581+ If a message is rejected after the final "." of the DATA command
3582+ because one or more recipients are unable to accept and process a
3583+ message with internationalized email headers, the reply-code "554" is
3584+ used with the meaning "Transaction failed". If the SMTPUTF8-aware
3585+ SMTP server supports enhanced mail system status codes [RFC3463],
3586+ reply code "X.6.9" [RFC5248] (see Section 4) is used to indicate this
3587+ condition, meaning "UTF-8 header message cannot be transmitted to one
3588+ or more recipients, so the message must be rejected".
3589+
3590+ The SMTPUTF8-aware SMTP servers are encouraged to detect that
3591+ recipients cannot accept internationalized messages and generate an
3592+ error after the RCPT command rather than waiting until after the DATA
3593+ command to issue an error.
3594+
3595+ 3.6. Body Parts and SMTP Extensions
3596+
3597+ The MAIL command parameter SMTPUTF8 asserts that a message is an
3598+ internationalized message or the message being sent needs the
3599+ SMTPUTF8 support. There is still a chance that a message being sent
3600+ via the MAIL command with the SMTPUTF8 parameter is not an
3601+ internationalized message. An SMTPUTF8-aware SMTP client or server
3602+ that requires accurate knowledge of whether a message is
3603+ internationalized needs to parse all message header fields and MIME
3604+
3605+
3606+
3607+
3608+ Yao & Mao Standards Track [Page 9]
3609+
3610+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3611+
3612+
3613+ header fields [RFC2045] in the message body. However, this
3614+ specification does not require that the SMTPUTF8-aware SMTP client or
3615+ server inspects the message.
3616+
3617+ Although this specification requires that SMTPUTF8-aware SMTP servers
3618+ support the 8BITMIME extension [RFC6152] to ensure that servers have
3619+ adequate handling capability for 8-bit data, it does not require non-
3620+ ASCII body parts in the MIME message as specified in RFC 2045. The
3621+ SMTPUTF8 extension MAY be used as follows (assuming it is appropriate
3622+ given the body content):
3623+
3624+ - with the BODY=8BITMIME parameter [RFC6152], or
3625+
3626+ - with the BODY=BINARYMIME parameter, if the SMTP server advertises
3627+ BINARYMIME [RFC3030].
3628+
3629+ 3.7. Additional ESMTP Changes and Clarifications
3630+
3631+ The information carried in the mail transport process involves
3632+ addresses ("mailboxes") and domain names in various contexts in
3633+ addition to the MAIL and RCPT commands and extended alternatives to
3634+ them. In general, the rule is that, when RFC 5321 specifies a
3635+ mailbox, this SMTP extension requires UTF-8 form to be used for the
3636+ entire string. When RFC 5321 specifies a domain name, the
3637+ internationalized domain name SHOULD be in U-label form if the
3638+ SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label
3639+ form.
3640+
3641+ The following subsections list and discuss all of the relevant cases.
3642+
3643+ 3.7.1. The Initial SMTP Exchange
3644+
3645+ When an SMTP connection is opened, the SMTP server sends a "greeting"
3646+ response consisting of the 220 reply-code and some information. The
3647+ SMTP client then sends the EHLO command. Since the SMTP client
3648+ cannot know whether the SMTP server supports SMTPUTF8 until after it
3649+ receives the response to the EHLO, the SMTPUTF8-aware SMTP client
3650+ MUST send only ASCII (LDH label or A-label [RFC5890]) domains in the
3651+ EHLO command. If the SMTPUTF8-aware SMTP server provides domain
3652+ names in the EHLO response, they MUST be in the form of LDH labels or
3653+ A-labels.
3654+
3655+ 3.7.2. Mail eXchangers
3656+
3657+ If multiple DNS MX records are used to specify multiple servers for a
3658+ domain (as described in Section 5 of RFC 5321 [RFC5321]), it is
3659+ strongly advised that all or none of them SHOULD support the SMTPUTF8
3660+
3661+
3662+
3663+
3664+ Yao & Mao Standards Track [Page 10]
3665+
3666+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3667+
3668+
3669+ extension. Otherwise, unexpected rejections can happen during
3670+ temporary or permanent failures, which users might perceive as
3671+ serious reliability issues.
3672+
3673+ 3.7.3. Trace Information
3674+
3675+ The trace information <Return-path-line>, <Time-stamp-line>, and
3676+ their related rules are defined in Section 4.4 of RFC 5321 [RFC5321].
3677+ This document updates <Mailbox> and <Domain> to support non-ASCII
3678+ characters. When the SMTPUTF8 extension is used, the 'Reverse-path'
3679+ clause of the Return-path-line may include an internationalized
3680+ domain name that uses the U-label form. Also, the 'Stamp' clause of
3681+ the Time-stamp-line may include an internationalized domain name that
3682+ uses the U-label form.
3683+
3684+ If the messages that include trace fields are sent by an SMTPUTF8-
3685+ aware SMTP client or relay server without the SMTPUTF8 parameter
3686+ included in the MAIL commands, trace field values must conform to RFC
3687+ 5321 regardless of the SMTP server's capability.
3688+
3689+ When an SMTPUTF8-aware SMTP server adds a trace field to a message
3690+ that was or will be transmitted with the SMTPUTF8 parameter included
3691+ in the MAIL commands, that server SHOULD use the U-label form for
3692+ internationalized domain names in the new trace field.
3693+
3694+ The protocol value of the 'WITH' clause when this extension is used
3695+ is one of the SMTPUTF8 values specified in the "IANA Considerations"
3696+ section of this document.
3697+
3698+ 3.7.4. UTF-8 Strings in Replies
3699+
3700+ 3.7.4.1. MAIL Command
3701+
3702+ If an SMTP client follows this specification and sends any MAIL
3703+ commands containing the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP
3704+ server is permitted to use UTF-8 characters in the email address
3705+ associated with 251 and 551 reply-codes, and the SMTP client MUST be
3706+ able to accept and process them. If a given MAIL command does not
3707+ include the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server MUST
3708+ NOT return a 251 or 551 response containing a non-ASCII mailbox.
3709+ Instead, it MUST transform such responses into 250 or 550 responses
3710+ that do not contain non-ASCII addresses.
3711+
3712+ 3.7.4.2. VRFY and EXPN Commands and the SMTPUTF8 Parameter
3713+
3714+ If the SMTPUTF8 parameter is transmitted with the VRFY and EXPN
3715+ commands, it indicates that the SMTP client can accept UTF-8 strings
3716+ in replies to those commands. The parameter with the VRFY and EXPN
3717+
3718+
3719+
3720+ Yao & Mao Standards Track [Page 11]
3721+
3722+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3723+
3724+
3725+ commands SHOULD only be used after the SMTP client sees the EHLO
3726+ response with the SMTPUTF8 keyword. This allows an SMTPUTF8-aware
3727+ SMTP server to use UTF-8 strings in mailbox names and full names that
3728+ occur in replies, without concern that the SMTP client might be
3729+ confused by them. An SMTP client that conforms to this specification
3730+ MUST accept and correctly process replies to the VRFY and EXPN
3731+ commands that contain UTF-8 strings. However, an SMTPUTF8-aware SMTP
3732+ server MUST NOT use UTF-8 strings in replies if the SMTP client does
3733+ not specifically allow such replies by transmitting this parameter
3734+ with the VRFY and EXPN commands.
3735+
3736+ Most replies do not require that a mailbox name be included in the
3737+ returned text, and therefore a UTF-8 string is not needed in them.
3738+ Some replies, notably those resulting from successful execution of
3739+ the VRFY and EXPN commands, do include the mailbox.
3740+
3741+ VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
3742+
3743+ vrfy = "VRFY" SP String
3744+ [ SP "SMTPUTF8" ] CRLF
3745+ ; String may include Non-ASCII characters
3746+
3747+ expn = "EXPN" SP String
3748+ [ SP "SMTPUTF8" ] CRLF
3749+ ; String may include Non-ASCII characters
3750+
3751+ The SMTPUTF8 parameter does not accept a value. If the reply to a
3752+ VRFY or EXPN command requires a UTF-8 string, but the SMTP client did
3753+ not use the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server
3754+ MUST use either the reply-code 252 or 550. Reply-code 252, defined
3755+ in RFC 5321 [RFC5321], means "Cannot VRFY user, but will accept the
3756+ message and attempt the delivery". Reply-code 550, also defined in
3757+ RFC 5321 [RFC5321], means "Requested action not taken: mailbox
3758+ unavailable". When the SMTPUTF8-aware SMTP server supports enhanced
3759+ mail system status codes [RFC3463], the enhanced reply-code as
3760+ specified below is used. Using the SMTPUTF8 parameter with a VRFY or
3761+ EXPN command enables UTF-8 replies for that command only.
3762+
3763+ If a normal success response (i.e., 250) is returned, the response
3764+ MAY include the full name of the user and MUST include the mailbox of
3765+ the user. It MUST be in either of the following forms:
3766+
3767+ User Name <Mailbox>
3768+ ; Mailbox is defined in Section 3.3 of this document.
3769+ ; User Name can contain non-ASCII characters.
3770+
3771+ Mailbox
3772+ ; Mailbox is defined in Section 3.3 of this document.
3773+
3774+
3775+
3776+ Yao & Mao Standards Track [Page 12]
3777+
3778+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3779+
3780+
3781+ If the SMTP reply requires UTF-8 strings, but a UTF-8 string is not
3782+ allowed in the reply, and the SMTPUTF8-aware SMTP server supports
3783+ enhanced mail system status codes [RFC3463], the enhanced reply-code
3784+ is "X.6.8" [RFC5248] (see Section 4), meaning "A reply containing a
3785+ UTF-8 string is required to show the mailbox name, but that form of
3786+ response is not permitted by the SMTP client".
3787+
3788+ If the SMTP client does not support the SMTPUTF8 extension, but
3789+ receives a UTF-8 string in a reply, it may not be able to properly
3790+ report the reply to the user, and some clients might mishandle that
3791+ reply. Internationalized messages in replies are only allowed in the
3792+ commands under the situations described above.
3793+
3794+ Although UTF-8 strings are needed to represent email addresses in
3795+ responses under the rules specified in this section, this extension
3796+ does not permit the use of UTF-8 strings for any other purposes.
3797+ SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in
3798+ replies except in the limited cases specifically permitted in this
3799+ section.
3800+
3801+ 4. IANA Considerations
3802+
3803+ 4.1. SMTP Service Extensions Registry
3804+
3805+ IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension"
3806+ registry of the "Mail Parameters" registry, according to the
3807+ following data:
3808+
3809+ +----------+---------------------------------+-----------+
3810+ | Keywords | Description | Reference |
3811+ +----------+---------------------------------+-----------+
3812+ | SMTPUTF8 | Internationalized email address | [RFC6531] |
3813+ +----------+---------------------------------+-----------+
3814+
3815+ 4.2. SMTP Enhanced Status Code Registry
3816+
3817+ The code definitions in this document replace those specified in RFC
3818+ 5336, following the guidance in Sections 3.5 and 3.7.4.2 of this
3819+ document, and based on RFC 5248 [RFC5248]. IANA has updated the
3820+ "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry"
3821+ with the following data:
3822+
3823+
3824+
3825+
3826+
3827+
3828+
3829+
3830+
3831+
3832+ Yao & Mao Standards Track [Page 13]
3833+
3834+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3835+
3836+
3837+ Code: X.6.7
3838+ Sample Text: Non-ASCII addresses not permitted for that
3839+ sender/recipient
3840+ Associated basic status code: 550, 553
3841+ Description: This indicates the reception of a MAIL or RCPT command
3842+ that non-ASCII addresses are not permitted.
3843+ Defined: RFC 6531 (Standards Track)
3844+ Submitter: Jiankang YAO
3845+ Change controller: ima@ietf.org
3846+
3847+
3848+ Code: X.6.8
3849+ Sample Text: UTF-8 string reply is required, but not permitted by
3850+ the SMTP client
3851+ Associated basic status code: 252, 550, 553
3852+ Description: This indicates that a reply containing a UTF-8 string
3853+ is required to show the mailbox name, but that form of
3854+ response is not permitted by the SMTP client.
3855+ Defined: RFC 6531 (Standards Track)
3856+ Submitter: Jiankang YAO
3857+ Change controller: ima@ietf.org
3858+
3859+
3860+ Code: X.6.9
3861+ Sample Text: UTF-8 header message cannot be transferred to one or
3862+ more recipients, so the message must be rejected
3863+ Associated basic status code: 550
3864+ Description: This indicates that transaction failed after the
3865+ final "." of the DATA command.
3866+ Defined: RFC 6531 (Standards Track)
3867+ Submitter: Jiankang YAO
3868+ Change controller: ima@ietf.org
3869+
3870+
3871+ Code: X.6.10
3872+ Description: This is a duplicate of X.6.8 and is thus deprecated.
3873+
3874+
3875+
3876+
3877+
3878+
3879+
3880+
3881+
3882+
3883+
3884+
3885+
3886+
3887+
3888+ Yao & Mao Standards Track [Page 14]
3889+
3890+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3891+
3892+
3893+ 4.3. WITH Protocol Types Sub-Registry of the Mail Transmission Types
3894+ Registry
3895+
3896+ IANA has modified or added the following entries in the "WITH
3897+ protocol types" sub-registry under the "Mail Transmission Types"
3898+ registry.
3899+
3900+ +--------------+------------------------------+---------------------+
3901+ | WITH | Description | Reference |
3902+ | protocol | | |
3903+ | types | | |
3904+ +--------------+------------------------------+---------------------+
3905+ | UTF8SMTP | ESMTP with SMTPUTF8 | [RFC6531] |
3906+ | UTF8SMTPA | ESMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
3907+ | UTF8SMTPS | ESMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
3908+ | | STARTTLS | |
3909+ | UTF8SMTPSA | ESMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
3910+ | | STARTTLS and AUTH | [RFC6531] |
3911+ | UTF8LMTP | LMTP with SMTPUTF8 | [RFC6531] |
3912+ | UTF8LMTPA | LMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
3913+ | UTF8LMTPS | LMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
3914+ | | STARTTLS | |
3915+ | UTF8LMTPSA | LMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
3916+ | | STARTTLS and AUTH | [RFC6531] |
3917+ +--------------+------------------------------+---------------------+
3918+
3919+ 5. Security Considerations
3920+
3921+ The extended security considerations discussion in the framework
3922+ document [RFC6530] applies here.
3923+
3924+ More security considerations are discussed below:
3925+
3926+ Beyond the use inside the email global system (in SMTP envelopes and
3927+ message headers), internationalized email addresses will also show up
3928+ inside other cases, in particular:
3929+
3930+ o the logging systems of SMTP transactions and other logs to monitor
3931+ the email systems;
3932+
3933+ o the trouble ticket systems used by security teams to manage
3934+ security incidents, when an email address is involved;
3935+
3936+ In order to avoid problems that could cause loss of data, this will
3937+ likely require extending these systems to support full UTF-8, or
3938+ require providing an adequate mechanism for mapping non-ASCII strings
3939+ to ASCII.
3940+
3941+
3942+
3943+
3944+ Yao & Mao Standards Track [Page 15]
3945+
3946+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
3947+
3948+
3949+ Another security aspect to be considered is related to the ability by
3950+ security team members to quickly understand, read, and identify email
3951+ addresses from the logs, when they are tracking an incident.
3952+ Mechanisms to automatically and quickly provide the origin or
3953+ ownership of an internationalized email address SHALL be implemented
3954+ for use by log readers that cannot easily read non-ASCII information.
3955+
3956+ The SMTP commands VRFY and EXPN are sometimes used in SMTP
3957+ transactions where there is no message to transfer (by tools used to
3958+ take automated actions in case potential spam messages are
3959+ identified). Sections 3.5 and 7.3 of RFC 5321 give detailed
3960+ descriptions of use and possible behaviors. Implementation of
3961+ internationalized addresses can also affect logs and actions by these
3962+ tools.
3963+
3964+ 6. Acknowledgements
3965+
3966+ This document revises RFC 5336 [RFC5336] based on the result of the
3967+ Email Address Internationalization (EAI) working group's discussion.
3968+ Many EAI working group members did tests and implementations to move
3969+ this document to the Standards Track. Significant comments and
3970+ suggestions were received from Xiaodong LEE, Nai-Wen HSU, Yangwoo KO,
3971+ Yoshiro YONEYA, and other members of JET and were incorporated into
3972+ the specification. Additional important comments and suggestions,
3973+ and often specific text, were contributed by many members of the
3974+ working group and design team. Those contributions include material
3975+ from John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit
3976+ Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung,
3977+ Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey
3978+ Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele,
3979+ Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee, and Lars
3980+ Eggert. Of course, none of the individuals are necessarily
3981+ responsible for the combination of ideas represented here.
3982+
3983+ Thanks a lot to Dave Crocker for his comments and helping with ABNF
3984+ refinement.
3985+
3986+ 7. References
3987+
3988+ 7.1. Normative References
3989+
3990+ [ASCII] American National Standards Institute (formerly United
3991+ States of America Standards Institute), "USA Code for
3992+ Information Interchange", ANSI X3.4-1968, 1968.
3993+
3994+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3995+ Requirement Levels", BCP 14, RFC 2119, March 1997.
3996+
3997+
3998+
3999+
4000+ Yao & Mao Standards Track [Page 16]
4001+
4002+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
4003+
4004+
4005+ [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
4006+ Extension for Delivery Status Notifications (DSNs)",
4007+ RFC 3461, January 2003.
4008+
4009+ [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
4010+ RFC 3463, January 2003.
4011+
4012+ [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
4013+ for Delivery Status Notifications", RFC 3464,
4014+ January 2003.
4015+
4016+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
4017+ 10646", RFC 3629, November 2003.
4018+
4019+ [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
4020+ Registration", RFC 3848, July 2004.
4021+
4022+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
4023+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
4024+
4025+ [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
4026+ Mail System Status Codes", RFC 5248, June 2008.
4027+
4028+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
4029+ October 2008.
4030+
4031+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
4032+ October 2008.
4033+
4034+ [RFC5890] Klensin, J., "Internationalizing Domain Names in
4035+ Applications (IDNA definitions)", RFC 5890, June 2010.
4036+
4037+ [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
4038+ Service Extension for 8-bit MIME Transport", STD 71,
4039+ RFC 6152, March 2011.
4040+
4041+ [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
4042+ STD 72, RFC 6409, November 2011.
4043+
4044+ [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
4045+ Internationalized Email", RFC 6530, February 2012.
4046+
4047+ [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
4048+ Email Headers", RFC 6532, February 2012.
4049+
4050+ [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed.,
4051+ "Internationalized Delivery Status and Disposition
4052+ Notifications", RFC RFC6533, February 2012.
4053+
4054+
4055+
4056+ Yao & Mao Standards Track [Page 17]
4057+
4058+ RFC 6531 SMTP Extension for SMTPUTF8 February 2012
4059+
4060+
4061+ 7.2. Informative References
4062+
4063+ [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
4064+ October 1996.
4065+
4066+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
4067+ Extensions (MIME) Part One: Format of Internet Message
4068+ Bodies", RFC 2045, November 1996.
4069+
4070+ [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission
4071+ of Large and Binary MIME Messages", RFC 3030,
4072+ December 2000.
4073+
4074+ [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
4075+ Transport Layer Security", RFC 3207, February 2002.
4076+
4077+ [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
4078+ for Authentication", RFC 4954, July 2007.
4079+
4080+ [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
4081+ Email Addresses", RFC 5336, September 2008.
4082+
4083+ [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
4084+ July 2009.
4085+
4086+ Authors' Addresses
4087+
4088+ Jiankang YAO
4089+ CNNIC
4090+ No.4 South 4th Street, Zhongguancun
4091+ Beijing
4092+ China
4093+
4094+ Phone: +86 10 58813007
4095+ EMail: yaojk@cnnic.cn
4096+
4097+
4098+ Wei MAO
4099+ CNNIC
4100+ No.4 South 4th Street, Zhongguancun
4101+ Beijing
4102+ China
4103+
4104+ Phone: +86 10 58812230
4105+ EMail: maowei_ietf@cnnic.cn
4106+
4107+
4108+
4109+
4110+
4111+
4112+ Yao & Mao Standards Track [Page 18]
4113+